一、背景​​

在数据驱动决策的实践中，企业通常需要多种分析工具的组合支持。例如，用户行为分析、地理位置潜力评估、供给动态追踪、人口流动研究以及业务交叉分析等场景，往往需要差异化的解决方案。
这些工具在技术实现上呈现显著差异：

• ​​功能形态​​：从标准化分析模型到高度定制化报表，从支持秒级响应的即席查询到需数小时计算的离线任务
• ​​数据架构​​：既有基于多表关联的动态计算模型，也有依赖预聚合的快速查询方案
• ​​技术栈​​：涉及OLAP引擎、批处理框架、NoSQL数据库等多种技术选型
• ​​交互需求​​：包含只读/读写模式、数据上传/下载等不同功能特性
  ​​平台化建设的核心挑战​​
  在构建模块化数据分析平台时，我们面临多维度的复杂度：如何通过统一的底层架构，兼容多样的分析主题（用户/地理/供给等）、计算模式（实时/离线）、技术引擎（内存计算/批量处理）以及功能需求，同时实现三个核心目标——

1. ​​开发提效​​：通过标准化组件降低重复建设
2. ​​质量保障​​：建立统一的质量监控体系
3. ​​成本优化​​：通过资源调度与弹性扩缩容降低运维成本
   这要求平台设计既要有足够的扩展性适配当前技术生态，又要具备前瞻性以应对未来3-5年的业务演进。我们在分层架构设计、计算引擎抽象、服务治理等领域持续探索，力求在灵活性与标准化之间找到最佳平衡点。

二、分析类应用构建方式演进

阶段一、需求驱动（使用平台之前采用的建设方式）

平台建设之前，所有系统，传统的业务开发方式，根据产品模块（业务）的划分将系统拆分为对应的一个个微服务（或者单体），case by case 实现功能。例如 用户分析 有用户细查、用户报告、路径分析等模块，系统层就对应了同等数量的微服务。仅用户分析一个产品就十几个服务，再加上其他产品，导致服务数量膨胀过多，带来较高的复杂度。每个服务都有完整的 Controller、Service、DAO层，有完整的存储引擎和中间件和发布项、流水线，需要单独部署运维。由于人力不能随之增加，容易超出承载能力。

此种开发方式存在的问题：
由于支持的产品数量变多，缺乏统一规划，容易导致服务拆分不合理、缺少复用性、难以统一维护，造成服务和代码数量膨胀（仅用户分析一项服务数20多个）、系统质量问题频发（用户分析 2022年线上问题数45个）、日常运维耗时耗力（2022年每周耗时 2～3pd 排查处理问题）、研发成本增高（2022年用户分析上线一个模型要40天）等问题。

阶段二、分而治之、中心化开发方式（业界采用的方式）

业界采用的构建方式一般根据产品的类型的不同，分为通用分析和报表分析不同的分析方式。不同的分析方式使用完全不同的构建方式。

通用分析类（例如神策、字节TEA）：常见的建设方式是使用统一的数据模型（明细模型），存储引擎（ClickHouse）构建。系统层基于统一的数据层开发，往往比较薄，架构较为简单。​​

报表分析类：

• 报表托拉拽式生成（公司魔数、字节 DataWind），通过组合各种组件配置成看板。组件通过页面选择、配置方式完成，整体无需写代码即可完成开发。该方式的优势在于开发门槛低、上线速度快，缺点在于灵活度不够，无法满足复杂的交互和计算需求。
• 框架开发（BIQuery、筑底），在微服务中嵌入框架，部分逻辑使用框架提供的功能开发，例如数据库连接。这种开发方式的问题在于：1）需要一定的学习成本和代码门槛 2）且框架不支持自定义扩展，增加新组件需要修改框架本身 3）框架非平台，无法统一管理各个应用。

业界的构建方式不完全适合公司，原因是：
1) 公司分析产品的建设具有特殊性。例如与字节对比，由于组织架构不同、分析系统业务范围不同，因此系统复杂度不同。其他公司负责通用分析与定制化分析在不同的团队，分开建设，往往是同类产品（指的是定制分析类和通用分析类）内部架构统一，不同类系统建设统一化平台架构的需求不高。
**2) 探索分析产品建设中有快速迭代试错的需求。**产品需要快速迭代上线产品，以验证不同的分析模式，下线效果不佳的分析模式。这些分析模式短时间内难以抽象为通用的分析模型，通过产品迭代进行探索。

3) 分析产品建设与通用化报表建设思路不同。相比于通用分析报表，具有产品化（独立产品而非报表集合）、重体验（针对用户使用习惯优化）、强交互（例如地图缩放、联动）、高性能（即席分析的性能要求）的业务特点，通用化的平台（例如公司魔数、字节风神）难以满足。

因此，业务特点导致业界没有完全对标的产品。需要根据业务特点，吃透竞品建设内在逻辑，设计出符合公司业务需要、可以解决实际问题的，具有创新性的系统性甚至先进性的方案。

阶段三、统一使用平台平台化开发（目前的开发方式）
平台平台形成了“平台搭台，业务唱戏的合作模式”。平台提供了常用的功能，业务方通过插件扩展业务逻辑，通过配置编排流程。增加新功能模块从增加服务，变成了增加配置和插件包，更加轻量和简单。同时平台和业务也能配合，业务可以扩展平台功能，业务插件也可以更好的下沉到平台层复用。
相对于阶段一，新增模块不再需要新增微服务，只需新增配置+插件包，服务数量从十几个减少到个位数，变得更为轻量和精简。
相对于阶段二，1）平台不再区分通用分析和报表分析开发方式，两者使用统一的应用构建方式，便于统一设计、统一开发、统一运维。2）解决了平台无法扩展，无法灵活满足业务需求的痛点。

三、平台平台应用建设

3.1 平台应用与技术模型

为了应对分析类产品的多样性与复杂度，需要对产品进行建模。以下是平台分析类产品应用建模与对技术实践的建模。

平台分析类产品应用模型：

• 产品应用层指整个的对外产品，例如用户分析、地理位置分析。
• 产品应用下包含不同的分析模型（模块），例如 用户分析 包含用户报告分析模块，留存分析模型，地理位置分析包含潜客洞察模块、人口迁徙模块等。
  以上两个层次是用户看得见的，下面的层次是在用户心智之外的概念层。概念层的建模用于更加容易推导出技术模型。
• 分析模型（模块）按照查询的即时性分类，可以分为在线分析和离线分析。
• 在线分析和离线分析有自己不同的业务过程，在线分析分为前置查询（查询菜单配置，例如可选的业务线、城市等）和结果查询（分析结果）两步，离线分析包含前置查询、离线任务运行与状态管理、结果查询三步。其中前置查询和结果查询都可以有同步查询
• 同步查询和异步查询两者都可以由功能点拼接出来。例如城市列表下载功能可以由数据源数据取回功能+数据格式化功能+下载功能组成。

平台技术模型：
目前仅使用到编排层抽象，看板层抽象按需建设，看板模板层暂无需求。

• 看板模板：技术模型里产品是由多个看板模板（不是具体的看板）组合而成的。例如用户分析是由用户报告类看板、用户路径类看板等构成。用户报告类看板下有用户配置的自己的报告看板。当前没有动态构建产品的需求，无需这一层能力。
• 编排/看板：每个分析模块，可以使用同一个看板模板配置出多个看板。看板也可以单拿出来作为一个功能，用户可以配置自己的看板。对于不是很复杂的功能或者原子性的分析组件，使用编排。编排指的是将多个功能接口组合成一个逻辑功能接口提供服务。
• 平台服务：产品中在线分析和离线分析分别对应在线服务和离线服务。
• 平台框架：业务过程固化成框架，确定每一个业务过程对应技术层所干的事情。
• 平台/业务插件：产品功能点可以封装为插件，以插件粒度开发和复用，后面有相同功能时，可以复用该插件实现功能，无需再次开发。

3.2 平台标准建设

基于上述模型，平台定义了一些标准与协议，用于规范认知与实践落地，包含分析业务流程、网关接口标准结构、插件数据流转协议、插件编写标准、配置文件标准结构等。

• 分析业务流程：
  • 在线分析分为前置处理、引擎执行前、引擎执行、引擎执行后、结果后处理五步。所有使用平台在线分析框架（FastBI）构建的应用，均遵循以上业务流程。
    
  • 离线分析业务流程：模型渲染、模型调度、模型执行、数据导入、模型后处理
    
• 插件编写标准：前处理插件，需要继承 PreHandle、分析处理插件需要继承 BuIldInAnalysis、后处理插件需要继承 PostHandle。​​
• 网关接口标准结构：
  • 接口路径：/api/bi/{appKey}/{queryId}
  • 请求方法：POST
  • 接口参数：JSON类型，要求可以反序列化成 Map<String,Object>
  • 返回结构：code、message、data、pageInfo

3.3 平台操作流程、SOP

基于上述标准，平台总结出常见场景下的操作流程，用于快速、标准化地支持应用建设，例如插件部署流程、问题定位处理流程、项目搭建操作流程等。

四、回顾与展望

4.1 2023 应用建设过程回顾

基于上述模型与平台实现，2023年平台应用于用户留存分析专项一期二期、地理位置分析节假日迁徙报告专项、地理位置分析场景专项开发中，约占整体需求专项的50% 。

• 效率方面：2023年使用平台开发的专项需求中，无需求delay，研发效率提升50%以上，地理位置分析即席查询场景下实现了每个多维分析报表开发时间从3.5PD提升至0.55PD；2023年产品需求交付未影响产品侧的正常规划 （2022年产品侧反馈需求迭代困难）。
• 成本方面：节约机器数 12 台，节省人力成本1_{2PD/周（之前每周需要2}3PD排查问题，现在需要0.5PD ），仅需 L6同学（L7指导） 即可完成日常需求开发（之前需要L7主力，L8指导）
• 质量方面：截止2023年，有6个产品模块同时使用平台，支持的MAU 1000+，有关平台平台线上问题数为0
  随着支持的需求变多，效果会更加明显。

模型应用（建设过程）：
以用户分析留存分析专项为例
应用模型建设：

技术模型建设：

4.2 2024 规划

总体从家庭作坊式开发 → 自动化阶段(人工处理少部分特殊业务逻辑，剩下的平台帮助解决)→ 智能化阶段（AI 员工辅助开发）三步走。
2024年主要的产品专项有：可视化应用升级（分析看板）、转化分析组件、路径分析组件、事件分析组件、用户分析（用户分层）组件。

• 需求支持度方面：1）转化分析组件、路径分析组件、用户分析组件能力基本具备，与留存分析类似。2）分析看板能力对应技术模型的第二层，待建设。3） 事件分析可能用到元数据管理服务，新建能力还是复用已有能力待定。
• 开发效率提升方面：配置的托拉拽开发（对标业界开发方式）、AI驱动开发(下一代开发方式)可以按需建设。

一、技术篇

1.1 空间数据表示

介绍了空间数据如何表示、如何索引、常见的运算。数仓开发中实用的概念、技术。

1.1.1 大地测量系统

• 坐标表示
  使用经纬度表示，比如天安门广场一点的经纬度：116.397303,39.909269
• WGS84
  大地坐标系，世界大地测量系统（World Geodetic System, WGS）是一种用于地图学、大地测量学和导航（包括全球定位系统）的大地测量系统标准。
  WGS包含一套地球的标准经纬坐标系、一个用于计算原始海拔数据的参考椭球体，和一套用以定义海平面高度的引力等势面数据。
  GPS全球定位系统使用的就是WGS 84参考系。
• GCJ02
  火星坐标系，地形图非线性保密处理算法，国测局坐标,是一种基于WGS-84制定的大地测量系统。
  此坐标系所采用的混淆算法会在经纬度中加入看似随机的偏移。
  GCJ02 座标串换成WGS-84的地图就可能造成100－700米不等的偏移。
  GCJ-02大量使用正弦函数制造高频噪音，形成了一个超越方程，导致基本不可能获得解析解。
  GCJ-02坐标系统本身保密，但是目前已有等多种语言的开源转换实现。

1.1.2 空间对象类型

空间对象，是指定义空间数据的几种基础数据对象，主要是由常见的点、线、面组成。

• 点(Point)
• 线(LineString)
• 面(Polygon)
  其他：
• 多点(MultiPoint)
• 多线(MultiLineString)
• 多面(MultiPolygon)

1.1.3 空间数据格式

• WKT/WKB
  WKT(Well-Known Text)，是一种兼容了可读性和存储性的数据格式。WKB，是它的二进制格式，更适合数据库存储。
• GeoJSON
  Json，定义了geometry对象。在线检验GeoJSON的规范性： http://geojson.io/

示例：

空间对象类型	形状	WKT格式	GeoJSON格式
Point		POINT (30 10)	{ "type": "Point", "coordinates": [30, 10] }
LineString		LINESTRING (30 10, 10 30, 40 40)	{ "type": "LineString", "coordinates": [ [30, 10], [10, 30], [40, 40] ] }
Polygon		POLYGON ((30 10, 40 40, 20 40, 10 20, 30 10))	{ "type": "Polygon", "coordinates": [ [[30, 10], [40, 40], [20, 40], [10, 20], [30, 10]] ] }
Polygon		POLYGON ((35 10, 45 45, 15 40, 10 20, 35 10), (20 30, 35 35, 30 20, 20 30))	{ "type": "Polygon", "coordinates": [ [[35, 10], [45, 45], [15, 40], [10, 20], [35, 10]], [[20, 30], [35, 35], [30, 20], [20, 30]] ] }
MultiPoint		MULTIPOINT ((10 40), (40 30), (20 20), (30 10))	{ "type": "MultiPoint", "coordinates": [ [10, 40], [40, 30], [20, 20], [30, 10] ] }
MultiPoint		MULTIPOINT (10 40, 40 30, 20 20, 30 10)
MultiLineString		MULTILINESTRING ((10 10, 20 20, 10 40), (40 40, 30 30, 40 20, 30 10))	{ "type": "MultiLineString", "coordinates": [ [[10, 10], [20, 20], [10, 40]], [[40, 40], [30, 30], [40, 20], [30, 10]] ] }
MultiPolygon		MULTIPOLYGON (((30 20, 45 40, 10 40, 30 20)), ((15 5, 40 10, 10 20, 5 10, 15 5)))	{ "type": "MultiPolygon", "coordinates": [ [ [[30, 20], [45, 40], [10, 40], [30, 20]] ], [ [[15, 5], [40, 10], [10, 20], [5, 10], [15, 5]] ] ] }
MultiPolygon		MULTIPOLYGON (((40 40, 20 45, 45 30, 40 40)), ((20 35, 10 30, 10 10, 30 5, 45 20, 20 35), (30 20, 20 15, 20 25, 30 20)))	{ "type": "MultiPolygon", "coordinates": [ [ [[40, 40], [20, 45], [45, 30], [40, 40]] ], [ [[20, 35], [10, 30], [10, 10], [30, 5], [45, 20], [20, 35]], [[30, 20], [20, 15], [20, 25], [30, 20]] ] ] }

1.2 空间索引

空间索引，是空间数据库用来优化空间查询的数据库索引，它是能够使得用户高效查询空间对象的一种数据结构。

传统的数据库索引(B树)，并不适合处理空间查询，比如点是否落入多边形内、点之间距离等等。如果不建立索引，则任何搜索都将需要对空间数据库中的每个记录进行“顺序扫描”，从而导致处理时间更长。

1.2.1 需要索引的查询

• 窗口查询：给定一个查询窗口（通常是一个矩形），返回与查询窗口相重叠的物体。
  
• 点查询：给定一个点，返回包含这个点的所有几何图形

1.2.2 索引查询过程

通过索引操作对象的MBB来进行查询一共分为两步

• Filtering: 过滤掉MBB(minimum bounding box，最小限定箱)不相交的数据集，剩下的MBB被索引到的称为一个数据的超集。
  
• Refinement: 测试实际的几何形状会不会满足查询条件，精确化。
  
  • 如何判断两个MBR是否相交？ 只要任一矩形的最右端都大于另一矩形的最左端且任一矩形最高端大于另一矩形的最低端，则两矩形相交；反之，若其中任一条件不满足，两矩形不相交。
    

1.2.3 空间索引分类

• 空间驱动的结构
  这些数据结构是基于将二维空间划分为单元(或网格)，并根据空间关系(重叠或相交)把空间对象映射到单元。IBM DB2和Microsoft SQL Server等商业数据库使用这些方法。
• 数据驱动的结构
  这些数据结构直接由空间对象集合的分区来组织。使用mbr对数据对象进行分组，以适应其在嵌入空间中的分布。商业数据库，如开源数据库 PostGIS和MySQL，都使用这些数据结构。

1.2.4 空间索引举例

空间驱动结构 GeoHash：
GeoHash 是一种将经纬度坐标（ lat/lon ）编码成字符串的方式。这么做的初衷只是为了让地理位置在 url 上呈现的形式更加友好，但现在 GeoHash 已经变成一种在数据库中有效索引地理坐标点和地理形状的方式。
GeoHash是一个二进制字符串，其中每个字符表示全局经纬度矩形的交替划分。从图8可以看出空间平面划分的过程。第一次划分将矩形分成两个GeoHash代码为“0”和“1”的正方形。位于垂直分区左侧的空间对象具有以“0”开头的 GeoHash，而位于右半部分的空间对象具有以“1”开头的GeoHash作为其第一个前缀。然后，每一边的数据进一步水平分割:在这一行以上的对象接收“0”，而在这一行以下的对象接收“1”作为它们的第二个前缀。模式继续分裂，直到达到所需的解决方案。每个Geohash矩形可以被分解成4个子哈希，划分5次,把整个世界分为 32 个单元的格子。单元又可以继续被分解成 32 个更小的单元，不断重复下去，以此类推。

GeoHash 使用 Base32 编码成字符串，比如下图展示了北京9个区域的GeoHash字符串，分别是WX4ER，WX4G2、WX4G3等等，每一个字符串代表了某一矩形区域。也就是说，这个矩形区域内所有的点（经纬度坐标）都共享相同的GeoHash字符串。
字符串越长，表示的范围越精确。

数据驱动的结构 R 树：
R树是B树在高维空间的扩展，是一棵平衡树。每个R树的叶子结点包含了多个指向不同数据的指针，这些数据可以是存放在硬盘中的，也可以是存在内存中。
根据R树的这种数据结构，当我们需要进行一个高维空间查询时，我们只需要遍历少数几个叶子结点所包含的指针**（即缩小到某个区域下去进行查询，还是采用缩小范围的思想）**，查看这些指针指向的数据是否满足要求即可。这种方式使我们不必遍历所有数据即可获得答案，效率显著提高。

1.3 空间数据计算

空间数据计算包含坐标转换、索引计算、关系计算。例如：

• 转换
  • 坐标系转换：gps转换为火星坐标系,火星转换为gps坐标系
  • WKT 格式与 GeoGSON 转换
• 度量
  • 两点之间的球面距离
  • 计算多边形面积
• 索引
  • 点所在的 GeoHash
  • 点到 GeoHash 中点的距离
  • 面所在的 GeoHash
  • GeoHash 合并
  • 把传入的GeoHash列表（以字符串形式传入，逗号分隔）进位至指定targetLevel
• 关系
  • 几何 A 经过几何 B。
  • 几何 A 完全包含在(Within)几何 B 中。
  • 几何 A 完全包含几何 B。
  • 几何之间彼此没有相交或接触（不相交）。
  • 几何完全重合。
  • 几何相互叠加。
  • 几何接触于一点。

1.4 空间数据处理在数仓计算中的应用举例

已有用户流量表（包含经纬度字段）和 POI 维度数据表（包含POI 经纬度字段），计算某天内以 POI 为圆心，半径 1 km 的客流。

解法：

1.5 大数据地理信息系统（GIS）

1.5.1 什么是GIS

GIS(Geographic Information System)，它是在计算机硬、软件系统支持下，对整个或部分地球表层（包括大气层）空间中的有关地理分布数据进行输入、存储、查询、分析和显示的计算机系统。
GIS将数据连接到地图上，将位置数据(事物所在的位置)与所有类型的描述信息(事物所在的位置)整合在一起。
地理信息系统通过使用位置作为“关键指标变量”，提供了将以前不相关的信息关联起来的能力。

1.5.2 技术体系

GIS 技术发展

GIS基础软件五大技术体系，即：大数据GIS技术（Big Data GIS）、人工智能 GIS 技 术（AI- GIS）、新 一 代 三维 GIS 技 术 （New Three-D GIS）、分布式 GIS 技术（Distributed GIS）、跨平台 GIS 技术（Cross-platform GIS），合称 “BitDC”

1.5.3 技术应用

交通、国防、灾害预防、教育、能源、工程等
例如：

• 增强现实——商业用途的增强现实：如广告和餐馆评论
• 地理围栏——用地理围栏限制汽车停放，是汽车共享和租赁的基础
• 自动驾驶汽车——自动驾驶汽车配备激光雷达、GPS等
• 实时交通——共享实时交通信息和道路警报

二 、应用篇

2.1 业务场景分类

• 开城开站/选址： 业务在某个位置分析其线下客流（业务上限）、用户特征（通勤群体、白领群体等）、位置本身的特征（旅游城市、小区聚集地等），以及用户线上化渗透情况，再结合业务线自身采集的周边环境、业务供给等评估，来选定业务适合在哪些地方，什么范围开城/开站，或进行线下推广活动。
• 业务策略调整： 根据业务当前渗透情况、平台渗透情况、需求量情况等及时调整业务已有运营策略或对制定新策略，如平台流量倾斜、省内补贴资源调配、活动上线策略等
• 业务规模&潜客空间评估： 对于业务线的一些客观特性，评估在地域范围内需求上限、业务已达成情况等，从而制定业务目标、评估可增长空间、分析当前不同区域业务特征及对应策略等

2.2 技术分类

2.2.1 点、面汇总类分析

定义：分析区域内点（地图里的POI）、面（地图里的AOI） 的分布、数量、面积、种类、属性等信息，支持上卷下钻。

例如：计算xx城市餐饮外卖业务渗透率，即计算开通外卖的POI 的数量与全部餐饮POI的数量的比值。

2.2.2 多点、线性分析

OD 分析：

通过设置统计口径及空间粒度等相关参数，支持用户获取不同区域之间的居住和工作人口流动的数量、画像。辅助掌握不同区域之间联系紧密程度及诸如城镇化建设等相关政策的研究及制定。

可查询分析不同市、区之间的通勤信息和不同时间维度下的OD数量，以此判断职住平衡情况与城市间的出行、往来强度。

通过设置O点和D点范围、空间粒度等相关参数，支持用户获取不同区域之间的出发点-到达点数量、画像。辅助掌握城市出行强度及邻近城市之间的往来强度

职住分析：

通过设置统计口径、空间粒度等相关参数，支持用户获取不同市、区之间的通勤信息：通勤人口画像、通勤距离、通勤方式和通勤时间等

迁徙分析：

通过设置出发区域、到达区域、时间范围等相关参数，支持用户获取不同城市之间的迁徙数量和迁徙人群画像。方便掌握城市之间人群流动特征。百度迁徙： https://qianxi.baidu.com/

驻留分析：

随着定位技术的不断发展，嵌入在手机的GPS、北斗等位置传感器可以周期性地记录移动对象的位置，产生了海量的轨迹数据，如行人轨迹、出租车轨迹、共享单车轨迹等。来自于这些轨迹数据中的驻留点（即移动对象在一段时间内停留在某个区域范围内产生的轨迹点）蕴含了丰富的移动对象停留信息，如出租车候车、行人游玩、货车装卸货等，这些可以帮助我们获取某一地点的动态访问信息，继而挖掘地点的动态特征，全面理解地点的时空信息

三、解决方案案例：商业选址

3.1 解决哪些问题

1. 已有门店布局是否合理？
2. 哪些区域适合新开店？
3. 某点位是否适合开店？

3.2 解决方案

（1）看概况，选片区——网点推荐

1. 根据不同行业的需求和选址城市的基本属性提供科学的模型评分规则，从目标客户属性、共生及竞对商家、商业氛围、周边配套、客群净需求等多维度对全城进行大数据扫描。

2. 用户在平台可选择意向选址城市，配置个性化模型参数及其权重，输出模型的综合量化结果和可视化评估结果，查看推荐网格和叠加现有网点的网格的情况，

3. 导出网格的详细数据，一目了然地锁定最佳价值区位。

   

(2) 评点位——定点评估

打破时空信息不对称，全方位评估备选点位特征，高效推动选址决策

支持以多种方式快速锁定评估点位及其范围，包括关键词检索、上传点位坐标、自定义形状圈选、商圈选择，一键获取被评估区域的人口分析、职住分析、客流分析、品牌分析、设施分析、OD分析、交通分析和活力趋势分析的全维度可视化报告，支持保存和下载分析报告和相关数据。同时，平台打破时空信息的不对称性，支持多个点位的横向空间对比分析和单一点位的纵向时间对比分析，全方位评估备选点位情况，高效推动选址决策。

ElasticSearch 简介

为什么需要使用 ES 进行搜索

结构化数据 VS 非结构化数据

想了解为什么需要ES进行搜索，需要先对比一下结构化数据和非结构化数据。

• 结构化数据：
  也称作行数据，关系型数据库进行存储和管理,是由二维表结构来逻辑表达和实现(可以使用行、列来表现)的数据，严格地遵循数据格式与长度规范。
• 非结构化数据：
  又可称为全文数据，不定长或无固定格式，不适于由数据库二维表来表现，包括所有格式的办公文档、XML、HTML、word文档，邮件，各类报表、图片和音频、视频信息等。

其他的不同之处还有：
结构化数据往往占用的空间较小，占企业数据的 20% 左右，容易管理。
非结构化数据通常占用更多的存储空间，约占企业数据的 80% 左右，比较难以管理

结构化搜索 vs 全文搜索

结构化搜索：
通常查询具有固有结构的数据
答案要么是肯定的，要么是否定的（即便是类似正则匹配这样的结构化搜索，正则表达式匹配数据也是确定的）
数据要么属于查询结果集合，要么不属于。

全文搜索：
通常查询全文字段/文档的所有内容
答案返回的是一系列可能的数据
数据有一定概率属于结果集合

到这里，为什么需要使用 ES 进行搜索的答案就很明确了：对于非结构化文本（比如评论内容），传统的结构化搜索难以满足需求，于是就会使用 ES 进行全文搜索。当然 ES 不仅可以进行全文搜索，也可以进行一部分的结构化搜索，更加扩大了他的应用范围。对于数据量巨大的情景，有公司会使用 ES 代替传统的 MySQL 管理数据。

ES 基本概念介绍

本小结主要是介绍 ES 的一些基本概念，目的是方便之前没有了解过 ES 的同学可以理解这次分享所介绍的内容。

ES 存储模型

ES 在设计存储模型时，考虑了大家从关系型数据库转换肯能带来的困难，于是设计了 Index、Type、Document、Field 分别于对应传统关系型数据库(比如 MySQL) 的 Database、Table、Row、Column。
注意： ES 存储时，并没有 Type 的概念，同一个Index 里的 Type 会拍平存储，只是方便理解才会对使用者提供这样一个抽象。由于Type 的存在会带来一些问题，在后续的版本里会逐步移除，详情参见：https://www.elastic.co/guide/en/elasticsearch/reference/6.7/removal-of-types.html

ES 与 Lucene

ES 底层基于 Lucene 开发，Lucene作为其核心来实现索引和搜索的功能。我们虽然讲的是 ES，但很大一部分内容是 Lucene 的实现。

评分机制

ES 相似度(Similarity)机制

什么是相似度？

前文中讲到，全文搜索返回的数据是有一定概率属于结果集。相似度就是反应这个概率大小的指标。
ES 把每一篇文档与查询词的相似度计算出来，使用一个数值来表示（评分），然后按照评分又高到底的顺序返回前 n 条数据。这就是一次查询的大致过程。

如何计算相似度？

相似度是使用相关算法计算的，ES 内部(也就是 Lucene)使用的称为 Lucene实用评分函数,大致长这样：

$$score(q,d)= \displaystyle \sum^{}_{t\, in \, d} {(tf(t \, in \, d) \cdot idf(t)^2 \cdot norm(t , d) \cdot boost(t) )}$$

下面会详细介绍每一部分的意义。

Lucene 评分函数的产生

Lucene 评分函数借鉴了词频/逆向文档频率（TF/IDF:term frequency/inverse document frequency）算法 和 向量空间模型（VSM:vector space model）
并于 ES 版本 5.0 将 TF/IDF 模型更换为 BM25 模型
下面分别介绍提到的这几个概念

词频/逆向文档频率（TF/IDF）

公式详解：

$$TF score * IDF score * fieldNorms$$

其中：

$TF score$ 是词频得分，它的公式是:

$$\sqrt{tf}$$

tf 是要查询的词在一个文档中出现的次数。

$IDF score$ 是逆向文档频率的得分，等于文档频率 的倒数取log。
文档频率 就是要出现查询的词文档数与文档总数加一的比，代表了查询的词在全部文档中占的大小。

$$idf(t\,in\,d)=1+\log{_2 2} \frac{numDocs}{docFreq+1}$$

numDocs 即为文档总数； docFreq 即为出现要查询词出现在文档(这个概念对应关系型数据库的“记录”,见上文)中出现的次数；
IDF score 的意义在于考虑查询的词在文档总数出现的频率，对总分产生影响。查询的词在文档中出现的频率越高，对结果产生的影响越小。比如想 “的”，“你” 等常见的词几乎出现在每一个文档中，对结果会有很小的影响。

$fieldNorms$ 是字段长度归一值。它的计算方式为：

$$\frac{1}{\sqrt{length}}$$

length 表示文档的长度。
fieldNorms 的意义在于考虑文档长度对于查询得分的影响。例如在一条短信中匹配到搜索的词与在一本书中匹配到，肯定是这个短信更有可能属于结果集。

将所有的分项带入，得到 TF/IDF 的公式：

$$TF score * IDF score * fieldNorms$$

$$= \sqrt{tf} * （1+\log{_2 2} \frac{numDocs}{docFreq+1}） * \frac{1}{\sqrt{length}}$$

TF/IDF 在 ES 中的体现

ES 中的数据：

搜索”zhang“ 后，得到的前一条结果及其得分的详情：

我们可以看到框选的部分： tf、idf、fieldNorm 分别对应前文公式的三个部分。感兴趣的同学可以自己具体计算一下得分。

空间向量模型 (VSM)

上面介绍的TF/IDF 模型是针对一个词来进行查询的，如果我们搜索多个词，改怎么处理呢？
向量空间模型（Vector Space Model） 提供一种比较多词查询的方式，模型将文档和查询都以 向量（vectors）的形式表示。

举例来说：^[1]

假设我们有三个文档：

I am happy in summer 。
After Christmas I’m a hippopotamus 。
The happy hippopotamus helped Harry 。

我们要在这三个文档中搜索 “happy hippopotamus” (快乐的河马)
可以为每个文档都创建包括每个查询词 （ happy 和 hippopotamus ）权重的向量(事实上使用的是得分，这里为了便于理解，人工指定了权重)，然后将这些向量置入同一个坐标系中：

通过比较各个文档的向量与查询词的向量的夹角(计算时使用夹角的余弦值)，来判断哪个文档与查询更为接近。

具体计算时，使用**余弦相似度**公式计算：

$$cos{\theta}= \frac{\vec{a} \cdot \vec{b}}{|a|\cdot |b|}$$

Lucene 实用评分函数

Lucene 实用评分函数是有余弦相似度公式演变而来。图中相同颜色的框代表的含义是一样的。

我们可以看到，Lucene 实用评分函数改变的是 $docLenNorm(d)$ 增加了 $queryBoost(q)$ 和 $docBoost(d)$。
上文提到过 $docLenNorm(d)= \frac{1}{\sqrt{length}}$ ，考虑了文档的长度，而余弦相似度公式中对应的部分为 $\frac{1}{|a|}$，为 $\vec{b}$ 的单位长度，未考虑文档长度。
$queryBoost(q)$ 和 $docBoost(d)$ 分别代表查询的权重提升和文档的权重提升，可以更为灵活的手工指定，影响搜索结果。

BM25 相似度

BM25 全称 Okapi BM25 是 Okapi Best Match 25 的缩写。
ES 版本 5.0 将 TF/IDF 模型更换为了 BM25 模型。BM25可以看做是 TF/IDF 的改良。
BM25 与 TF/IDF 相比，主要体现在 TF 和 fieldNorms 的计算上。

IDF

对于IDF，我们看到两者的趋势基本是一致的

TF

对于 TF 我们看到，传统的 TF 曲线随着 tf(词频) 的升高，其值无限的增加，而 BM 25的
TF 值收敛到一个值($k$)。在一定程度上，词频越高，固然得分也应该越高。但是不能没有限度。否则像是网页搜索，站长可以通过作弊，使得词频达到极高的值，就达到了垄断这个词的效果 了。

fieldNorms

BM25 将 fieldNorms 与词频进行合并，一起对得分产生影响,称为 tfNorm

tfNorm

$$tfNorm = ((k + 1) * tf) / (k * (1.0 - b + b * L) + tf)$$

$L$：表示文档的长度是平均文档长度的多少倍。计算方式：$\frac{|d|}{avgDl})$
$b$ 参数的作用：调节 L 的影响程度,当b=0时，文档的长度对于结果没有影响

下图展示了文档长度对于得分的影响：

BM25 公式

将以上部分组合起来，我们得到了 BM25 的公式：

$$IDF * ((k + 1) * tf) / (k * (1.0 - b + b * (\frac{|d|}{avgDl})) + tf)$$

更多

分享的第二部分，请查看 深入理解 ES 查询机制[二]（即将推出）

扩展阅读

Delta Lake

Delta Lake 是 Databricks (俗称"砖厂") 开源的一个文件存储层,目前运行在 Spark 上。它主要提供了以下功能（摘自官网）：

1. ACID 事务(ACID transactions)
2. Schema 相关特性：Schema 本地存储、支持 Schema 约束、Schema 演变 (Scalable Metadata Handling、Schema Enforcement、Schema Evolution)
3. 数据版本控制 (Time Travel (data versioning))
4. 支持数据更新删除 （Updates and Deletes）
5. 统一了流数据和批处理数据落地 (Unified batch and streaming sink)

特性详细介绍

下面将会对Delta Lake 的特性详细介绍。

ACID 事务

这里的 ACID 就是指原子性、一致性、隔离性和持久性。一致性、持久性之前就已经实现，这里主要是解释一下原子性和隔离性。
原子性： 一个事务要么成功要么失败，不存在中间状态。这一个特性对于数据的准确性，特别是出现失败时候仍然保持准确性至关重要。当 job 失败时已经写入的数据会自动回滚到未写入的状态，不需要手工处理。
隔离性： 基于乐观的并发控制实现可序列花的隔离级别。乐观的并发控制在竞争不很激烈的情况下，会提高性能。可序列花的隔离级别保证了即使并发执行读或写操作，仍然保证像在串行读写一样。
具体的，Delta Lake 支持并发读取、并发追加(追加的内容不依赖于任何的读取已经存在的数据)，但不支持并发修改，出现并发修改会抛出 concurrent modification exception。
隔离性保证无论是并发批处理操作、流操作或者是批流并发操作，数据都是准确的

Schema 相关特性

Hive Metastore 一般用中心化的存储（如 MySQL） 对 Schema 进行管理。在 Schema 数量特别巨大时(比如分区数特别多)，由于中心化存储伸缩性是非线性的，容易形成瓶颈。
Delta Lake 将元数据同样视为数据，保存在文件中，使得对大数据的处理能力可以运用在处理元数据上。
由于元数据由文件进行管理，所以有了更大的灵活性和可能性，Schema Enforcement （强制检验数据的 Schema，不通过则拒绝），Schema Evolution （根据数据自动更改 Schema，无需手动指定）

数据版本控制

事务都有了，实现版本控制也是顺带的事。Delta Lake 可以读取某个版本的数据或者恢复数据到某一个历史版本。

支持数据更新删除

支持包括单条数据、批量数据的更新和删除

统一了流数据和批处理数据落地

Delta Lake 还统一了流数据和批处理数据落地，而不需要最开始提到的 Lambda 架构。极大的简化了系统的复杂性

Delta Lake 快速体验

使用 Delta Lake 需要 Spark 2.4.2 及以上版本，如果仅仅想体验一下，可以使用 Docker 版 Spark

• 安装 Spark

1
2
3
4
5
6
7
8
9
10
11
12
13

docker run -d --name spark-master -h spark-master \
-p 8080:8080 \
-p 7077:7077 \
-p 4040:4040  \
-e ENABLE_INIT_DAEMON=false  \
bde2020/spark-master:2.4.3-hadoop2.7


docker run -d --name spark-worker-1 \
-p 8081:8081 \
--link spark-master:spark-master \
-e ENABLE_INIT_DAEMON=false \
bde2020/spark-worker:2.4.3-hadoop2.7

• 进入 Spark Shell

1

docker exec -it spark-master  /spark/bin/spark-shell --packages io.delta:delta-core_2.11:0.3.0

• 创建 Delta Table

1
2

val data = spark.range(0, 5)
data.write.format("delta").save("/tmp/delta-table")

• 其他更多实践请参阅 官方文档

实现原理

Delta Lake 的文件结构

Delta Lake 在原有的 Parquet 文件的基础上，增加了 _delta_log 文件夹。_delta_log 文件夹内包含 json 文件和 checkpoint.parquet 文件。

• 这些 json 文件称为 transaction log。其文件名是递增的，数字代表版本。每一个文件代表一个事务，存储了 Schema 信息，对文件的操作等。

1
2
3
4
5

{"commitInfo":{"timestamp":1563414817197,"operation":"WRITE","operationParameters":{"mode":"ErrorIfExists","partitionBy":"[]"},"isBlindAppend":true}}
{"protocol":{"minReaderVersion":1,"minWriterVersion":2}}
{"metaData":{"id":"72e1fda6-6860-477a-94bf-924c5935818b","format":{"provider":"parquet","options":{}},"schemaString":"{\"type\":\"struct\",\"fields\":[{\"name\":\"id\",\"type\":\"long\",\"nullable\":true,
\"metadata\":{}}]}","partitionColumns":[],"configuration":{},"createdTime":1563414816435}}
{"add":{"path":"part-00000-90a5fe90-b039-4cce-92be-ff70abc6aeac-c000.snappy.parquet","partitionValues":{},"size":263,"modificationTime":1563414816000,"dataChange":true}}

• checkpoint.parquet 是检查点，可以加速数据的读取

在没有检查点的情况下 ，需要从头开始读取 transaction log，重放每一个 transaction log 的文件操作，才会得到所需要的结果，有了检查点，获取数据的某一个版本时，只需要从距离版本最近的检查点，重放版本和检查点的 transaction log 即可得到指定版本的数据

实现原子操作

写入失败时： 事务不提交，不形成 transaction log 文件，本次事务写入的文件就不会纳入到当前表中。
写入成功时： 事务提交，transaction log 原子的生成，于是数据变持久性存在于当前 delta table 中

实现可序列化隔离级别

可序列化隔离的实现基于乐观并发控制
并发修改的情况： 事务开始是读取最新版本的数据，输出数据产生一个新的版本，在事务提交之前，检查是否还有其他提交的 transaction log 与本次提交有冲突，如果有冲突，抛出 ConcurrentModificationException。写入的数据不会提交，因此不会生效
并发追加的情况： 与之类似，不同点在于发现冲突时会检查 Schema 是否变化，如果没有变化，会自动重试，不会抛出异常

关于 Delta Lake 的思考

像 Delta Lake、 Netflix 的 iceberg 这种新一代的文件格式的出现，解决了大数据发展中批流存储不统一、不支持事务等等痛点。

Spark 诞生之初，就在计算模型上实现了批处理和流处理的统一，现在 Delta Lake 的出现，在存储层也将实现统一。
批流处理的大一统后不但意味着可以消除像 Lambda 架构这种变通的解决方案，而且目前常用的基于批处理的数据加工方式也可也会被流式的数据处理方式所取代。再加上可以支持事务。

届时，开发者可以把更多精力放在"如何从数据中提取有用的信息"这样一件事情上，更多的关注数据流应该如何变化，而不是关注任务说明时候执行，任务失败了怎么重试等等问题。

所以像 Lambda 架构、各种数据准确性检验任务、不同系统的数据导入工具、调度执行批处理任务等等，这些在大数据领域习以为常的解决方案会成为历史。

一方面这当然是好事，开发者可以各司其职，大数据系统也会更加统一
但另一方面，技术的升级往往会替代一部分人，而且会让我们之前的经验一文不值。所以需要我们更需要思考如何提升自己，让自己驾驭技术，而不是让技术取代自己，就像很多职业都需要自思考如何被人工智能取代一样。

什么是 Lambda 架构

Lambda 架构 是大数据量下的一种数据处理的架构，它同时使用批处理和流处理的方法处理大量数据。

Lambda 架构分层

标准的 Lambda 架构包含 batch layer(批处理层)、serving layer（服务层）、speed layer(实时层)

• 批处理层：包含 master dataset(存储全量数据) 和 batch view (批处理视图)。batch view 是由 master dataset 计算得来
• 实时层：由于批处理层数据处理存在延时，如果想获得实时数据，需要实时层的支撑。speed layer 与 batch layer非常相似，它们之间最大的区别是 speed layer 只处理最近的数据，batch layer 则要处理所有的数据。改层一般使用实时计算引擎（如 Spark Streaming、Flink）完成计算
• 服务层：对最终结果的查询提供支撑，合并批处理层、实时层结果。 一般使用 NoSQL 数据库存储，如 HBase

Lambda 架构解决的问题

Lambda 架构将两种异构的系统整合，实现了既能分又析历史数据，又能计算实时数据。历史数据保存了所有的明细，可以使用多变的方式分析；实时数据包含最新的信息，可以提供报警、及时分析等能力

Lambda 架构不足

由于实时层和批处理层使用的是不同架构的系统，因此需要对应开发不同的代码，而且需要对同样的数据处理两次：开发者需要熟悉不同的组件、需要维护数据的一致性，都是比较复杂的。
Delta Lake 的出现，解决历史数据和实时数据需要不同系统处理的问题。

Lambda 架构在 Twitter 的实践 ^[1]

架构图

批处理层

使用 Spark 将全量数据 (master dataset) 批处理为 批处理视图 （batch view），并保存在 NoSQL 数据库 Cassandra 中。使用 Akka 的调度器按一定的时间间隔调度执行

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

class BatchProcessingUnit {

  val sparkConf = new SparkConf()
    .setAppName("Lambda_Batch_Processor").setMaster("local[2]")
    .set("spark.cassandra.connection.host", "127.0.0.1")
    .set("spark.cassandra.auth.username", "cassandra")

  val sc = new SparkContext(sparkConf)

  def start: Unit ={
    val rdd = sc.cassandraTable("master_dataset", "tweets")
    val result = rdd.select("userid","createdat","friendscount").where("friendsCount > ?", 500)
    result.saveToCassandra("batch_view","friendcountview",SomeColumns("userid","createdat","friendscount"))
    result.foreach(println)
  }
}

实时层

实时层使用 Spark Streaming 实时处理 Kafka 消息，同样将计算结果存储在 Cassandra 中。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

object SparkStreamingKafkaConsumer extends App {
  val brokers = "localhost:9092"
  val sparkConf = new SparkConf().setAppName("KafkaDirectStreaming").setMaster("local[2]")
    .set("spark.cassandra.connection.host", "127.0.0.1")
    .set("spark.cassandra.auth.username", "cassandra")
  val ssc = new StreamingContext(sparkConf, Seconds(10))
  ssc.checkpoint("checkpointDir")
  val topicsSet = Set("tweets")
  val kafkaParams = Map[String, String]("metadata.broker.list" -> brokers, "group.id" -> "spark_streaming")
  val messages: InputDStream[(String, String)] = KafkaUtils.createDirectStream[String, String, StringDecoder, StringDecoder](ssc, kafkaParams, topicsSet)
  val tweets: DStream[String] = messages.map { case (key, message) => message }
  ViewHandler.createAllView(ssc.sparkContext, tweets)
  ssc.start()
  ssc.awaitTermination()
}

下面是 ViewHandler 的处理逻辑，主要是选择 follow 者数量大于 500 的记录

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

object ViewHandler {


  def createAllView(sparkContext: SparkContext, tweets: DStream[String]) = {
    createViewForFriendCount(sparkContext, tweets)
  }

  def createViewForFriendCount(sparkContext: SparkContext, tweets: DStream[String]) = {

    tweets.foreachRDD { (rdd: RDD[String], time: Time) =>
      val spark = SparkSession.builder.config(rdd.sparkContext.getConf).getOrCreate()
      val tweets: DataFrame = spark.sqlContext.read.json(rdd)
      tweets.createOrReplaceTempView("tweets")
      val wordCountsDataFrame: DataFrame = spark.sql("SELECT userId,createdAt, friendsCount from tweets Where friendsCount > 500 ")
      val res: DataFrame = wordCountsDataFrame.withColumnRenamed("userId","userid").withColumnRenamed("createdAt","createdat").withColumnRenamed("friendsCount","friendscount")
      res.write.mode(SaveMode.Append)
        .format("org.apache.spark.sql.cassandra")
        .options(Map( "table" -> "friendcountview", "keyspace" -> "realtime_view"))
        .save()
      wordCountsDataFrame.show(false)
      wordCountsDataFrame.printSchema()

    }
  }
}

服务层

服务层聚合了批处理层和实时层的数据，以满足 Ad hoc 的需要

1
2
3
4
5
6
7
8
9
10
11
12
13
14

def findTwitterUsers(minute: Long, second: Long, tableName: String = "tweets"): Response = {
  val batchInterval = System.currentTimeMillis() - minute * 60 * 1000
  val realTimeInterval = System.currentTimeMillis() - second * 1000
  val batchViewResult = cassandraConn.execute(s"select * from batch_view.friendcountview where createdat >= ${batchInterval} allow filtering;").all().toList
  val realTimeViewResult = cassandraConn.execute(s"select * from realtime_view.friendcountview where createdat >= ${realTimeInterval} allow filtering;").all().toList
  val twitterUsers: ListBuffer[TwitterUser] = ListBuffer()
  batchViewResult.map { row =>
    twitterUsers += TwitterUser(row.getLong("userid"), new Date(row.getLong("createdat")), row.getLong("friendscount"))
  }
  realTimeViewResult.map { row =>
    twitterUsers += TwitterUser(row.getLong("userid"), new Date(row.getLong("createdat")), row.getLong("friendscount"))
  }
  Response(twitterUsers.length, twitterUsers.toList)
}

字符串拼接基准测试

Java 中有这样一条优化建议，在循环中使用”+“号拼接字符串会带来很大的性能损失，应该使用StringBuilder。

这样的建议是否准确呢？我们可以设计基准测试来验证，使用的当然是我们的主角 JMH，下面是代码实现 (源码可以在 GitHub 上查看：地址)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

import java.util.concurrent.TimeUnit;

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

/**
 * 字符串拼接基准测试
 *
 * 测试结果：
 * <pre>
 * Benchmark                                         Mode  Cnt   Score    Error  Units
 * StringAppendBenchmarkTenK.stringAddBenchmark      avgt   25  82.590 ± 14.824  ms/op
 * StringAppendBenchmarkTenK.stringBufferBenchmark   avgt   25   0.127 ±  0.005  ms/op
 * StringAppendBenchmarkTenK.stringBuilderBenchmark  avgt   25   0.146 ±  0.010  ms/op
 * </pre>
 *
 * @author KevinZhang <kevin.zhang.me@gmail.com>
 */
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
public class StringAppendBenchmarkTenK {

    public static final int TEN_K = 10000;

    @Benchmark
    public String stringAddBenchmark() {
        String targetString = "";
        for (int i = 0; i < TEN_K; i++) {
            targetString += "hello";
        }
        return targetString;
    }

    @Benchmark
    public String stringBuilderBenchmark() {
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < TEN_K; i++) {
            sb.append("hello");
        }
        return sb.toString();
    }

    @Benchmark
    public String stringBufferBenchmark() {
        StringBuffer sb = new StringBuffer();
        for (int i = 0; i < TEN_K; i++) {
            sb.append("hello");
        }
        return sb.toString();
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(StringAppendBenchmarkTenK.class.getSimpleName())
                .forks(1)
                .build();

        new Runner(opt).run();
    }

}

可以看到有几个注解:

@BenchmarkMode 代表基准测试模式，包含

• Throughput 模式 ：吞吐量模式，测试单位时间内可以执行测试方法的次数（默认1秒）
• Average Time 模式：平均时间模式，测试平均每次操作需要多长时间，它的值等于 Throughput 模式的倒数
• Sample Time模式：时间取样模式，测试单位时间运行，自动取样执行的时间进行测量，其结果包含统计信息，比如 P99 、数据分布情况等等
• Single Shot Time模式：测试单次方法运行的时间，没有 预热阶段，适合测试冷启动所需要的时间
• All模式：同时使用以上所有模式

@Benchmark 代表这个方法是一个基准测试用例，作为测试用例的入口，类似JUnit 中 @Test 注解

@OutputTimeUnit 设置输出数据的单位，此处是毫秒，加上AverageTime 模式，最后的单位是 ms/op：每次操作需要多少毫秒

测试结果

下面是在我在本地运行的结果:

1
2
3
4

Benchmark                                         Mode  Cnt   Score    Error  Units
StringAppendBenchmarkTenK.stringAddBenchmark      avgt   25  82.590 ± 14.824  ms/op
StringAppendBenchmarkTenK.stringBufferBenchmark   avgt   25   0.127 ±  0.005  ms/op
StringAppendBenchmarkTenK.stringBuilderBenchmark  avgt   25   0.146 ±  0.010  ms/op

我们可以看到 stringAddBenchmark 代表简单Sting 相加的方式，使用平均时间模式，平均每次执行需要82.590毫秒，误差在 ± 14.824 ms。其他两个的意义与之类似。

结果分析

从结果中我们可以看到，

1. 使用简单的字符串相加比使用 StringBuffer 和 StringBuilder 慢了两个数量级；
2. StringBuilder 比 StringBuffer要慢一些；

结果 1 的原因是：String 在字符串拼接时，每次循环会创建新的 StringBuffer 对象(不是 String 对象)，然后把原来的对象销毁，而 StringBuffer / StringBuilder 在初始化时预留了一定的空间，在调用 append 方法时只有在预留空间不足时才会发生数组拷贝。

结果 2 的原因是：StringBuffer 是线程安全的，append 方法是加锁的；StringBuilder 是非线程安全的。两个类除了在线程安全上的区别，其他几乎没有任何差别。

1
2
3
4
5
6
7
8
9
10
11

// StringBuilder 的 toString 方法
public StringBuilder append(String str) {
        super.append(str);
        return this;
 }
// StringBuffer 的 toString 方法
public synchronized StringBuffer append(String str) {
        toStringCache = null;
        super.append(str);
        return this;
 }

展望

分析至此，我们还可以得出一个结论，**尽管在没有多线程竞争的情况下，加锁仍会损失一部分性能。**这个结论可以设计另一个基准测试来验证，读者有兴趣可以自己设计。

线程安全的 Long 类型

说起线程安全的 long 类型的实现，不难想到有使用悲观锁锁synchronized 、乐观锁 AtomicLong 这两种实现，有没有性能更高的实现呢？肯定是有的，java 8 中发布的 LongAdder 就是为替代 AtomicLong 而存在的。

LongAdder 原理，简单来讲就是在多线程竞争激烈的情况下，LongAdder 将维护的值分散到多个段中，来减少CAS的重试，当需要获得结果时，只需要把各个段相加就可以了（类比 ConcurrentHashMap 分段锁的实现）。与 AtomicLong 多线程 CAS 更新单个值相比，理论上性能会有提升。

下面是我设计的基准测试的用例(源码可以在 GitHub 上查看：地址)，用来验证线程安全Long类型的不同实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97

import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;
import java.util.concurrent.atomic.LongAdder;

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Level;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.TearDown;
import org.openjdk.jmh.annotations.Threads;
import org.openjdk.jmh.annotations.Warmup;
import org.openjdk.jmh.runner.RunnerException;

import com.technologiesinsight.jmh.helper.LunchHelper;


/**
 *  synchronized 锁 vs AtomicLong vs LongAdder 基准测试
 *
 * <pre>
 * Benchmark                                  Mode  Cnt    Score    Error  Units
 * ThreadSafeLong.testAtomicLongIncrement     avgt   25  383.194 ± 23.359  ms/op
 * ThreadSafeLong.testLongAdderIncrement      avgt   25  108.105 ±  2.911  ms/op
 * ThreadSafeLong.testPrimitiveLongIncrement  avgt   25  908.964 ± 29.782  ms/op
 * </pre>
 * @author KevinZhang <kevin.zhang.me@gmail.com>
 */
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.MILLISECONDS)
//@Measurement(iterations = 1, time = 1, timeUnit = TimeUnit.SECONDS)
//@Warmup(iterations = 0, time = 1, timeUnit = TimeUnit.SECONDS)
//@Fork(1)
@State(Scope.Benchmark)
@SuppressWarnings("unused")
public class ThreadSafeLong {
    private static final Integer LOOP = 10000000;
    private final Object lock = new Object();

    private AtomicLong atomicLong;
    private LongAdder longAdder;
    private long primitiveLong;


    @Setup(Level.Iteration)
    public void setUp() {
        this.atomicLong = new AtomicLong();
        this.longAdder = new LongAdder();
        this.primitiveLong = 0L;
    }

    @Benchmark
    @Threads(2)
    public long testPrimitiveLongIncrement() {
        for (int i = 0; i < LOOP; i++) {
            synchronized (lock) {
                primitiveLong = primitiveLong + 1;
            }
        }
        return primitiveLong;
    }

    @Benchmark
    @Threads(2)
    public long testAtomicLongIncrement() {
        for (int i = 0; i < LOOP; i++) {
            atomicLong.incrementAndGet();
        }
        return atomicLong.get();
    }

    @Benchmark
    @Threads(2)
    public long testLongAdderIncrement() {
        for (int i = 0; i < LOOP; i++) {
            longAdder.increment();
        }
        return longAdder.longValue();
    }

    @TearDown(Level.Iteration)
    public void tearDown() {
        long atomicResult = atomicLong.get();
        long longAdderResult = longAdder.longValue();
        System.out.println(String.format("primitiveLongResult is %s,atomicResult is :%s;longAdderResult is %s", primitiveLong, atomicResult, longAdderResult));
    }

    public static void main(String[] args) throws RunnerException {
        LunchHelper.lunchBenchmark(ThreadSafeLong.class);
    }

}

相比于上一个案例，我们发现了几个关于 JMH 的“新面孔”

• @State(Scope.Benchmark) ：有时候测试用例中需要维护一些”状态“（测试用不是一个”纯函数“），”状态“的变化可能会影响测试的结果。所以需要由JMH 管理这些状态，并显示的声明这些状态的声明周期（有效范围）。状态生命周期分为三类，由State的参数指定:
  • Thread 每一个线程创建自己的状态对象。因此共享对象不会有线程安全问题。
  • Group 组内共享状态对象。不同分组可以使用 @Group(“groupName”) 指定
  • Benchmark 一次迭代运行中所有的线程共享状态对象。
• @Setup(Level.Iteration) :用于执行基准测试前执行一些操作，比如初始化等等。参数 Level表示改方法说明时候执行：
  • Trial 每次一个进程完整运行一遍测试用例之前执行：包括 warmUp 和 正式执行阶段
  • Iteration 每次迭代前会执行。一次完整的运行包含多次迭代过程，每次迭代运行一次测试的方法。
  • Invocation 每次方法调用前会执行。
• @TearDown : 类似@Setup ,在测试后执行
• @Thread :同时执行的线程数，用于线程下的基准测试
• 注释部分 @Measurement 等：用于测试用例开发阶段，提高执行速度，正式测试前需要注释掉
• LunchHelper.lunchBenchmark(ThreadSafeLong.class) JMH 启动助手

测试结果

1
2
3
4

Benchmark                                  Mode  Cnt    Score    Error  Units
ThreadSafeLong.testAtomicLongIncrement     avgt   25  383.194 ± 23.359  ms/op
ThreadSafeLong.testLongAdderIncrement      avgt   25  108.105 ±  2.911  ms/op
ThreadSafeLong.testPrimitiveLongIncrement  avgt   25  908.964 ± 29.782  ms/op

通过基准测试结果我们可以看到，testAtomicLongIncrement 代表使用 Atomic 类完成自增，运行 25 次后，所得到每次运行平均时间是383.194 ms，误差在± 23.359ms。其他结果的意义与之类似。

分析

从结果中可以看到，在两个线程竞争同一个 long 类型的情况下，LongAdder 性能最好名副其实，AtomicLong 次之，使用 synchronized 加锁性能最差。

在日常开发中，我们可以尝试使用 LongAdder 代替 AtomicInteger 和加锁的方式

展望

通过这个测试案例，我们可以分析出 JMH 测试框架本身的性能损耗，欢迎有兴趣的读者留言交流。

其他测试案例

源码 中还有其他一些测试案例，比如

• 常见几个Map的测试：位于 com.technologiesinsight.jmh.MapBenchmark

展望

很多公司编程对测试环节于不太重视，追求的是功能快速上线。这样的做法短期内可以提高开发速度，但如果从长远来看，单元测试，基准测试等测试，会减少后期维护、功能扩展的成本；对于开发者来说，掌握基本的测试理论和实践是一项基本的能力。

什么是基准测试

那么什么是基准测试呢？

简单来说，基准测试是为了评估测试目标的性能采取的一系列行动，包括运行一个或一组程序或者执行其他的操作。^[1]

基准测试按照其测试用例是否接近于真实运行的环境，分为微基准测试（Micro-Benchmarking）、模拟、回放、工业标准(生产环境)测试。^[2]

微基准测试 使用人造的测试用例对某类特定的操作做测试。这类特定的操作往往指的是软件的一小部分(比如一个方法)。

这篇文章主要介绍的是微基准测试。

基准测试应该注意的问题

基准测试不是随意的测试

基准测试不是仅仅执行一下，记一下结果就可以的。比如常常出现的问题就是忽略缓存对于测试结果的影响。

好的基准测试应该检查以下几点：

1. 严格检查实际测试的是什么
2. 确定理解测试了什么：对测试结果进行分析
3. 得出有效的结论

控制变量的个数

为保证得出正确的结论，控制不同的测试中除了被测试的变量，确保没有其他变量对结果造成影响。这个往往是比较难以达到的，比如对 Java 程序进行微基准测试，需要注意编译器优化(包括编译期优化和运行时优化 JIT)、机器负载、操作系统的缓存等等变量。做到这些需要使用合适的工具加上测试者对这些有一定的了解。

基准测试的环境和配置

基准测试之前，需尽力保证所测系统运行在最佳的系统和配置中，系统的性能以及达到真正的极限。比如”不服跑分“的测试中，确保被测手机的电量充足、系统没有开启省电模式等。

Java 中的微基准测试 JMH

Java 官方提供了一个基准测试工具 JMH(Java Microbenchmark Harness)，我们可以用它测试

1. 一段代码平均执行多长时间
2. 对比不同实现的性能

第一个微基准测试工程

最为便捷的是使用 Maven 创建项目：

1
2
3
4
5
6
7

mvn archetype:generate \
          -DinteractiveMode=false \
          -DarchetypeGroupId=org.openjdk.jmh \
          -DarchetypeArtifactId=jmh-java-benchmark-archetype \
          -DgroupId=com.technologiesinsight.jmh \
          -DartifactId=jmh-demo \
          -Dversion=1.0

构建完成后，会发现一个文件夹 jmh-demo。这是一个标准的 maven 工程，会有一个默认的测试类：MyBenchmark,位于 com.technologiesinsight.jmh 包下，也就是上面命令的 -DgroupId 填写的包名。测试类内容如下：

1
2
3
4
5
6
7
8
9
10
11
12

package com.technologiesinsight.jmh;

import org.openjdk.jmh.annotations.Benchmark;

public class MyBenchmark {

    @Benchmark
    public void testMethod() {
        // This is a demo/sample template for building your JMH benchmarks. Edit as needed.
        // Put your benchmark code here.
    }
}

其中，我们可以在 testMethod 填写基准测试代码。

这里以声明一个字符串举例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

import org.openjdk.jmh.annotations.Benchmark;

/***
 *
 * Benchmark                Mode  Cnt          Score         Error  Units
 * MyBenchmark.testMethod  thrpt   25  217365928.196 ± 6111510.557  ops/s
 *
 */
public class MyBenchmark {
    @Benchmark
    public String testMethod() {
        return  "hello world";
    }

}

接下来就可以运行了，进入项目目录，执行 mvn clean package 打包，执行 java -jar target/benchmarks.jar 运行,控制台会出现类似如下信息：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

// 第一部分开始
# JMH version: 1.21
# VM version: JDK 1.8.0_201, Java HotSpot(TM) 64-Bit Server VM, 25.201-b09
# VM invoker: /Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/jre/bin/java
# VM options: -Dfile.encoding=UTF-8
# Warmup: 5 iterations, 10 s each
# Measurement: 5 iterations, 10 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: com.technologiesinsight.jmh.MyBenchmark.testMethod

// 第二部分开始
# Run progress: 0.00% complete, ETA 00:08:20
# Fork: 1 of 5
# Warmup Iteration   1: 188758589.759 ops/s
# Warmup Iteration   2: 187065201.979 ops/s
# Warmup Iteration   3: 206670810.488 ops/s
# Warmup Iteration   4: 211958028.465 ops/s
# Warmup Iteration   5: 224040261.103 ops/s
Iteration   1: 224379265.753 ops/s
Iteration   2: 208679880.245 ops/s
Iteration   3: 206755976.374 ops/s
Iteration   4: 214591855.201 ops/s
Iteration   5: 219524929.562 ops/s
// ……此处省略迭代信息

// 第三部分开始
Result "com.technologiesinsight.jmh.MyBenchmark.testMethod":
  217365928.196 ±(99.9%) 6111510.557 ops/s [Average]
  (min, avg, max) = (204122743.394, 217365928.196, 233217556.736), stdev = 8158691.742
  CI (99.9%): [211254417.640, 223477438.753] (assumes normal distribution)


# Run complete. Total time: 00:08:22

REMEMBER: The numbers below are just data. To gain reusable insights, you need to follow up on
why the numbers are the way they are. Use profilers (see -prof, -lprof), design factorial
experiments, perform baseline and negative tests that provide experimental control, make sure
the benchmarking environment is safe on JVM/OS/HW level, ask for reviews from the domain experts.
Do not assume the numbers tell you what you want them to tell.

Benchmark                Mode  Cnt          Score         Error  Units
MyBenchmark.testMethod  thrpt   25  217365928.196 ± 6111510.557  ops/s

输出信息可以分为三部分，使用 // 标注。第一部分是执行的环境、参数信息。第二分每次迭代的详情,第三部分是基准测试的结果。

我们着重看最后报告部分：

1
2

Benchmark                Mode  Cnt          Score         Error  Units
MyBenchmark.testMethod  thrpt   25  217365928.196 ± 6111510.557  ops/s

最重要的就是 Score 这一列，代表得分，单位是 ops/s 代表每秒钟可以执行多少次操作(其倒数就是平均运行一次测试用例需要多少时间)。因为赋值操作是十分轻量的操作，所以执行速度非常快，约为4.6纳秒就可以完成（未考虑测试框架本身微小的性能损耗）。

关于JMH 的运行方式

运行方式有多种，除了上面提到的使用命令行 java -jar 运行，也可以使用 IDEA 插件和 mian 方法运行。

• 使用 IntelliJ IDEA 插件：不需要写main 方法，也不需要打包，直接右键就可以运行。
• 使用 main 方法：不需要插件但需要写额外的 main 方法。 本系列的例子中提供了 helper 类方便的执行。

下一篇文章将会详细介绍 JMH 的使用方式，以及提供几个基准测试案例，来验证几个提高性能的方法。

参考资料

Arthas(阿尔萨斯),它是由阿里开源的一款 Java 诊断工具，继承自 BTace 和 Greys,提供了 ：

• 系统环境信息、虚拟机信息: (线程信息、内存信息、类加载信息)等的查看、监控。
• 运行时查看方法执行详情、方法调用链、方法调用统计信息。
• 提供内存中编译类、反编译加载的类、热加载类等功能

更多详细功能请到官方网站查看。

本系列文章的目的

Arthas 中文文档写的十分详尽，此处不再做文档的搬运工。文章主要是对其做一些归类总结
在阅读下面的内容之前，请先了解 官方命令列表

命令分类

使用 Arthas的第一步就是，熟练运用相关命令，活用相关命令，在真正出现线上问题，排查问题才能行云流水，一气呵成。下面对命令按照使用场景进行了分类分为：

• 公共工具：sc、sm、stack

• 线上异常排查：watch、tt

• 动态代码执行: ognl

• 热更新: jad、mc、redefine、classloader、dump

• 性能分析：jvm、trace、thread

• 彩蛋：：july、thanks

公共工具

用于查找类、方法、方法调用栈。大多数命令使用前都需要知道类和方法，这些公共的工具提供了快速定位目标的方法(通过通配符或者正则表达式)

线上异常排查

线上排查问题的流程一般是：

1. 查看日志，找到具体报错异常栈和报错位置，也可以使用 sc,sm,stack 等工具找到方法调用入口，再使用 tt 或者 watch -e 查看异常栈和报错位置

2. 查看方法调用细节，洞悉方法执行现场。

   有两个选择：使用tt (TimeTunnel 时空隧道)，使用 watch

   tt 命令

   可以保存当前方法调用的详细信息，包括入参、返回值、异常信息（如果有的话），方便快速定位。也可以重放调用（但是不一定准确）

   watch 命令

   观察某个方法的详情，具体信息可以在后面跟表达式指定。例如: watch demo.MathGame primeFactors "{params,returnObj}" 可以查看参数，返回值。

   如何选择：

   tt 可以保存多个方法调用现场，方便后续查看、重放。但是有时候查看、重放不一定准确，原因是tt 只是保存当时环境的对象引用，当对象值改变之后，你查看的时候看到的是最新的值，而不是当时调用的值，这时，需要使用 watch 命令准确的查看方法调用的现场

动态代码执行

上一步的异常排查发现出错位置和原因，如果仍然不知道如何修改，需要做一些探索，就需要动态代码执行工具了。Arthas 通过 ognl 表达式查看一些静态字段值，执行一些代码片段等。注意，getstatic 可以替代 ognl 查看类的静态字段的功能，但不建议学习，增加学习成本。

热更新

动态代码执行适合于执行一些表达式类短小精悍代码，对于大段代码就显得力不从心。于是就需要热更新技术了。
热更新工具箱包括 jad、mc、redefine、classloader、dump。热更新一段代码一般遵循一些顺序：

1. 反编译：使用jad 反编译已经加载的字节码，如果觉得反编译效果不好，可以使用 dump 转储字节码文件，然后使用其他工具反编译为代码。
2. 修改代码：修改想要更新的代码
3. 编译:可以使用 mc 命令编译更新的代码（需要指定class loader），也可以使用 idea 等第三方工具编译好，上传到服务器
4. 加载新的类：使用 redfine 命令加载

redefine 使用限制：

• 不支持新增属性、方法
• 正在运行的函数 redefine 后不会生效，只有方法运行完后下次运行才会生效。

使用技巧

匹配多个方法

如果想匹配多个方法，可以使用正则表达式，命令后面添加 -E 开启：

1

trace -E 'io\.netty\.channel\.nio\.NioEventLoop|io\.netty\.util\.concurrent\.SingleThreadEventExecutor'  'select|processSelectedKeys|runAllTasks' '@Thread@currentThread().getName().contains("IO-HTTP-WORKER-IOPool")&&#cost>500'

退出 Arthas

使用 exit/quit 命令结束当前回话，关闭客户端，但不会关闭服务端。使用 jps 查看，会看到Arthas 还在运行。需要使用 shutdown 命令完全关闭服务端。

参考文档

官方文档: https://alibaba.github.io/arthas/