elasticsearch时间范围查询_一次有趣的Elasticsearch+矩阵变换聚合实践

序言

Elasticsearch聚合功能非常丰富，性能也相当不错，特别适合实时聚合分析场景，但在二次聚合上也有明显短板，不支持。

项目是一个基于日期维度做预处理的技术方案，以下是结合Elasticsearch优缺点扬长避短的一次尝试性实战，非常有意思，希望可以带来一些参考，同时欢迎各种讨论。

需求背景

公司所属行业是物流速运，面向企业服务(简称ToB模式)，提供多种物流运输方案产品，客户分布遍布全国，客户数量在百万级以上，日均产生物流运输需求在几十万票以上，对于客户订单的聚合统计分析查询需求强烈，且需要一定的实时性。

用户需求

• 用户要求在地图上展示客户的聚合分布
• 聚合分布维度按照全国、省、市、区县、乡镇 划分。如图：

示意图，非内部效果图

筛选条件

用户端基于多个筛选条件过滤聚合，多条件任意组合，如下：

• 行政区域

按照国家4级行政区域：省、市、区、镇等数量在5000+以上

• 企业组织架构

企业内部多层级组织架构：大区、小区等数量超过3000+以上

• 客户企业类型

客户企业类型划分：2B、2C等数量在10+以上

• 客户行业类型

客户企业行业所属类型划分，如家具、服装、电子、3C等数量在100+以上

• 企业业务类型

企业物流业务类型，如寄件、派件、未寄件派件等

• 日期范围

日期范围筛选限制在1个月，即日期的滑动窗口在1~31天(这个限定范围是与业务部门多次讨论得来，否则后面实现的代价会更大，原有是多个月的窗口期)

筛选条件说明

业务模型

原始数据模型说明：

• 客户下单一次，业务系统记录一条数据
• 客户下单多次，业务系统记录多条数据

业务需求数据模型说明：

• 单个客户即使单天下单多次，单天聚合统计也只能算1个客户。
• 单个客户连续多天都有下单，多天聚合统计也只能算1个客户。
• 业务类型有寄件/派件，按照其中一种处理，逻辑比较计算。

业务数据模型转换示意图

聚合模型

聚合数据模型说明

• 基于业务数据聚合，按照区域+其它部分条件聚合
• 统计组合后条件下的分组客户数量

聚合最终数据模型

技术探索

业务需求是一个很典型的聚合统计，多数大数据产品或者传统关系数据库都支持，相反Elasticsearch聚合支持的不怎么好，不能满足需求。

技术抽象

业务需求的技术本质实际上是一个去重然后分组聚合的过程。

• 去重合并

按照客户维度去重，合并符合过滤条件的客户数据，相同多条客户数据合并为单条数据

• 聚合分组

按照聚合维度分组，并计算出分组后的客户数量

去重分组过程

技术尝试

在实现业务需求过程中尝试过多种技术产品，遇到不少问题。

1.Mysql

当数据达到一定数量级，运行超时，甚至直接运行不起来

2.Prestodb

定位是秒级分析型产品，单任务启动就需要消耗好几秒的时间，且受资源限制，并发度与响应度不能满足要求。优点可与Hive很好结合。

3.MPP

Greenplum/Vertica/Infobright，与Prestodb其实本质差不多，都不能满足性能要求。

4.穷举法

探讨过将所有的过滤条件组合全部计算存储起来，业务系统只要去定位去查询，比如基于Kylin产品，查询复杂度确实低了，但计算量与存储量实在是太大，根本不现实。

穷举法计算量等于愚公

5. Elasticsearch

虽然提供了聚合能力，但不支持在一次聚合过程中完成去重与分组统计，也就是不支持复杂的二次聚合，这是ES局限，也是ES定位。

矩阵转换

尝试过几次不同的技术产品之后得出结论，单一的数据产品已有能力是无法满足要求的，正可谓鱼与熊掌不可兼得。所以必须改变思维，设计了一种矩阵变换的算法机制，结合Hive+ES实现，以下介绍这种技术实现方式。

可转换性分析

分析原有业务需求，发现只有日期这个条件组合特别多，动态变化范围很大，如果按照单月最长31天计算组合数就有31的阶乘；其余的条件变化小，也没有动态的组合条件，所以重点解决日期组合这个条件。

可转换性分析示意图

数据行转列

原有业务数据是按照行存储，聚合日期最小粒度是天， 单个客户下单信息除了下单日期、业务类型，其余的是相同的。将单个客户单月31天的下单数据31条转换成1条数据31列存储，31列分表代表从下单日期往后叠加的日期，列存储的值代表当天是否有下单以及业务类型。

数据行转列示意图

• 本次行转列基于Hive实现，数仓ODS数据都存储在Hive上，方便做下一步数据清洗转换计算。
• 首先在Hive上 按照【客户+日期】维度将客户下单数据去重，并按照业务类型简单的逻辑计算，合并单日多次下单的业务类型。
• 客户数据按照日期排序，从历史日期到当下昨天日期，计算任务默认T+1
• 其次在Hive上 将去重后的客户数据，按照行转列模型将1～31天行数据转换到31列的数据，并填充原始行的业务类型值。

列合并逻辑计算

业务需求是按照日期范围聚合，在一个日期范围内，客户订单业务类型要做一些逻辑计算(业务类型：0/1/2)，按照最大，所以需要计算单个客户单条数据之后31天的业务类型。

列合并逻辑示意图

• 本次列合并逻辑计算基于Hive实现。
• 合并完整的数据之后按照月的维度分开存储，当计算任务下次T+1运行时，只要更新最近31天的数据，最多跨度2个月。
• 数据同步到Elasticsearch中，一个月一个索引，也只要更新最近的2个索引，单索引数据量在亿级以上。Elasticsearch更新索引也很方便，采用别名切换方式，可在毫秒间完成，ES这个优点有效的避免了业务系统查询停顿空白问题。

业务查询

选择Elasticsearch做为查询引擎是非常正确的，得益于Elasticsearch高效的查询机制以及高效的聚合能力。

• 依据 起始日期 定位 到该日期的月度索引，并锁定对于下单日期所有数据。Elasticsearch支持动态索引搜索，支持高效的过滤filter扫描。
• 依据结束日期与起始日期差值，定位到指定的 数据列
• 最后只要一次聚合即可返回数据，性能很好。Elasticsearch支持高效的聚合特性agg

案例：查询2019-03-01~2019-03-05之间的聚合数据

聚合查询过程示意图

结语

技术

• 本次需求的技术实现比较曲折，在探讨大数据分析方面做了一次很重要的探索实践，没有一种通用的数据系统即可满足性能与功能，所以在面对实际业务问题要去探讨多种技术的混合实践。本次项目中的Hive+ES结合就是一次很有趣的混合。
• 学会培养一些算法思维，用微观的眼光分析问题解决问题。本次项目中采用矩阵转换，有效避免了诸多技术产品的不足，满足了性能与功能。

项目

• 项目案例是在2019年3月完成，此时任职 跨越速运大数据中心。
• 项目方案依赖大数据平台实现大量的预计算，矩阵变换是由服务端工程师想出来的，典型的前后端配合完成

内容来源

• 本次内容源于 2019-04-20深圳Elastics-meetup分享大会《大会分享活动： Elasticsearch 实时高效聚合计算应用实践》重新整理。
• PPT回顾下载：ES社区 https://elasticsearch.cn/slides/192

关于作者

Elastic-stack产品深度用户，ES认证工程师，2012/2013年接触Elasticsearch，对Elastic-Stack开发、架构、运维等方面有深入体验，实践过多种Elasticsearch项目，最暴力的大数据分析应用，最复杂的业务系统应用；业余为企业提供Elastic-stack咨询培训以及调优实施。