最新公告
  • 本站一直秉承服务宗旨:履行“站长”责任,销售只是起点 服务永无止境!”的经营理念立即加入
  • 一次有趣的Elasticsearch+矩阵变换聚合实践

    作者介绍

    *,Elastic Stack 深度用户,通过 Elastic 工程师认证,2012年接触 Elasticsearch,对 Elastic Stack 技术栈开发、架构、运维等方面有深入体验,实践过多种大中型项目;为企业提供 Elastic Stack 咨询培训以及调优实施;多年实战经验,爱捣腾各种技术产品,擅长大数据,机器学习,系统架构。

    背景需求

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

    同时需要满足以下用户需求:
    1、用户需要在地图上展示客户的聚合分布;
    2、聚合分布维度按照全国、省、市、区县、乡镇划分。

    地图展示样例:非内部效果图

    筛选条件

    用户端基于多个筛选条件过滤聚合,选择任意条件组合,如下:
    • 行政区域:
    按照国家4级行政区域:省、市、区、镇等数量在5000+以上
    • 企业组织架构:
    企业内部多层级组织架构:大区、小区等数量超过3000+以上
    • 客户企业类型:
    客户企业类型划分:2B、2C等数量在10+以上
    • 客户行业类型:
    客户企业行业所属类型划分,如家具、服装、电子、3C等数量在100+以上
    • 企业业务类型:
    企业物流业务类型,如寄件、派件、未寄件派件等
    • 日期范围:
    日期范围筛选限制在1个月,即日期的滑动窗口在1~31天(这个限定范围是与业务部门多次讨论得来,否则后面实现的代价会更大,原有是多个月的窗口期)

    筛选条件说明

    业务模型

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

    样例数据模型说明

    聚合数据模型

    聚合数据模型说明:基于前面的业务模型数据聚合,按照区域+其它条件聚合,获取聚合后分组客户数量。

    聚合后的业务数据模型

    技术抽象

    业务需求是一个很典型的聚合统计,多数大数据产品或者传统关系数据库都支持,相反 Elasticsearch 聚合支持的不怎么好,不能满足需求。
    业务需求的技术本质实际上是一个去重然后分组聚合的过程:

    1、去重合并:按照客户维度去重,合并符合过滤条件的客户数据,相同多条客户数据合并为单条数据;
    2、聚合分组:按照聚合维度分组,并计算出分组后的客户数量。

    技术抽象过程

    技术尝试

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

    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 列分表代表从下单日期往后叠加的日期,列存储的值代表当天是否有下单以及业务类型。

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

    客户端行转列示意图

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

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

    客户日期列逻辑合并

    业务查询

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

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

    说明案例:查询2019-03-01~2019-03-05 客户聚合数据

    结语

    本次需求的技术实现比较曲折,在探讨大数据分析方面做了一次很重要的探索实践,没有一种通用的数据产品即可满足性能与功能,所以在面对实际业务问题要去探讨多种技术的混合实践。本次项目中的 Hive+ES 结合就是一次很有趣的混合。

    学会培养一些算法思维,用微观算法的思维分析问题解决问题。本次项目中采用矩阵转换,有效避免了诸多技术产品的不足,满足了性能与功能。

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

    声明:本文由原文作者“*”授权转载,对未经许可擅自使用者,保留追究其法律责任的权利。


    【*云Elastic Stack】100%兼容开源ES,独有9大能力,提供免费X-pack服务(单节点价值$6000)

    相关活动


    更多折扣活动,请访问*云 Elasticsearch 官网

    *云 Elasticsearch 商业通用版,1核2G ,SSD 20G首月免费
    *云 Logstash 2核4G首月免费


    1. 本站所有资源来源于用户上传和网络,如有侵权请邮件联系站长!
    2. 分享目的仅供大家学习和交流,您必须在下载后24小时内删除!
    3. 不得使用于非法商业用途,不得违反国家法律。否则后果自负!
    4. 本站提供的源码、模板、插件等等其他资源,都不包含技术服务请大家谅解!
    5. 如有链接无法下载、失效或广告,请联系管理员处理!
    6. 本站资源售价只是赞助,收取费用仅维持本站的日常运营所需!
    7. 如有侵权麻烦联系邮箱2697381891@qq.com删除文章!

    源码库 » 一次有趣的Elasticsearch+矩阵变换聚合实践
    • 3047会员总数(位)
    • 37766资源总数(个)
    • 0本周发布(个)
    • 0 今日发布(个)
    • 1198稳定运行(天)

    提供最优质的资源集合

    立即查看 了解详情