人群圈选效率提升30倍，云积互动基于ApacheDoris构

　　导读：随着业务量快速增长，云积互动对数据的实时性及灵活性提出更高要求，早期基于CDH的大数据平台已无法满足当前难度以及复杂度较高的的业务需求，因此云积互动于2021引进ApacheDoris在部分业务中使用，并在使用过程中逐渐发掘出ApacheDoris更多强大之处以及优势，最终决定在2022年全面应用ApacheDoris，基于ApacheDoris来构建云积互动企业级实时离线统一数仓。
　　作者云积互动大数据团队王杰蒙磊业务背景
　　云积互动，全称深圳市云积分科技有限公司，成立于2014年，是国内领先的AI驱动的消费者运营服务提供商，致力于发展消费者运营相关理论、技术、算法、模型及软件工具，为全球消费性企业提供基于AI的消费者运营系统及运营策略服务，打造消费者运营领域最佳服务和实践标准，帮助企业构建消费者运营核心能力，以应对当前及未来的场景化运营挑战。目前已成为天猫、京东、抖音、腾讯等主流电商和社交平台深度合作伙伴，服务客户2300，其中世界500强客户超过18家，包括全球第一的美妆、日化、医药集团，均深度服务超过7年。业务需求
　　云积互动的主要业务是以消费者运营为核心，包含了会员通，CRM，策略营销，数据资产等一系列业务，如下图所示。
　　早期云积互动的大数据需求较少，起步也比较晚，2019年才开始搭建基于CDH的大数据平台，因此大数据平台的主要目的是为了满足早期较为单一的BI数据看板及报表功能。近年来，随着业务量快速增长，数据量的增长，业务对数据的实时性及灵活性提出更高的要求，大数据平台也从早期的只需要满足单一的BI服务需求，扩展到需要支持各业务线，包含圈人服务，人群分析，AI智能数据等多种业务需求。早期基于CDH的大数据平台已无法满足当前难度以及复杂度较高的的业务需求。大数据平台的迭代早期数仓架构
　　早期公司业务量较少，基于HiveSpark构建的离线数仓即可满足早期大数据的需求。早期架构主要用于支持BI相关功能，数据大屏，自助报表等应用，大部分的指标仅要求T1的指标。
　　下图为云积互动早期数仓架构，早期的数据源主要为业务数据库MySQL以及日志，数据通过Streamsets实时采集数据并经ETL后传入ODS层，存储到Kudu中，通过Impala对ODS层的数据进行处理，实现实时查询业务的需求。通过Hive构建了离线数仓的DWD、DWS以及DIM层，使用Spark进行离线任务的计算与调度，最终处理并计算完成的数据输出到MySQL和Kylin中，应用于上层业务应用及分析。
　　存在的问题查询效率低：使用Impala多表查询速度太慢，亿级别表Join时，查询时间基本上在3分钟以上，部分复杂查询会在超过3分钟左右判定超时；同时使用Impala并行查询对内存消耗较大，影响其他任务运行。存储成本太高：使用多个系统存储数据（Hive，Hbase，Kudu），存储成本较高，随着业务量的增长，数据量指数级的增多，存储成本更是成倍数增加。开发难度大：数仓开发基于代码，不能满足灵活的指标需求，当分析需求越来越多时，存在多个场景组合查询、自定义等查询场景，面对这样的场景，必须进行再开发，开发和时间成本都很高。数据链路长：较长的链路使得数据的一致性很难保证，数据在某一环节出现问题，排查难度高，运维成本也会增加。技术选型
　　基于业务对数据实时性及灵活性更高的要求，我们在2021年初对当前市面上较为流行的分析引擎ClickHouse和ApacheDoris进行了调研，调研中我们发现，ApacheDoris具有高性能、简单易用、实现成本低等诸多优势。基于此，我们决定在部分业务上开始使用ApacheDoris，在使用的过程中逐渐发掘出ApacheDoris更多强大之处以及优势，ApacheDoris在很多方面十分贴合我们的诉求，因此，我们决定在2022年全面应用ApacheDoris在数据仓库中，基于ApacheDoris构建云积互动企业级数仓，选择ApacheDoris的主要原因如下：
　　1。该架构开发效率高，查询性能远高于Hive。数仓ETL由原来的Spark任务改为DorisSQL任务，使用SQL开发模式可进行快速迭代，开发效率提升了近一倍。Doris查询支持物化视图索引加速，Doris在1。0版本开始引入了向量化引擎，性能提升23倍，平均查询耗时降低了60。
　　2。该架构对OLAP支持更好，支持更为灵活的查询。Doris支持Cube函数，实现了Kylin的多维计算功能，极大的减少了SQL的开发量。Doris支持Bitmap类型，可实现人群之间的快速交并差计算并落地新人群。
　　3。支持主键唯一和聚合模型的表，极大的减少了开发难度。使用主键唯一模型可做到依据主键数据覆盖，自动实现数据更新功能。使用聚合模型的表，减少了ETL过程中的Join操作，同时解决了上层数据到达时间不一致而导致的数据关联不上的问题。新数仓架构
　　最开始使用新的数仓架构主要是要解决圈人速度慢的问题，圈人服务的核心在于人群圈选，通过SQL代码或标签取值组合等多种方式，实现人群查找，帮客户找到符合画像的人群，现在各行各业都会设计广告营销场景，其中也包括云积互动，而如何快速准确找到对的人推送广告就成了大数据场景需要解决的问题。当时我们只是在部分功能上使用了ApacheDoris，用ApacheDoris替代了SparkImpala来实现实时圈人功能，出乎意料的是，ApacheDoris投入使用之后效果极佳，新版架构的实时圈人业务平均每个任务耗时由35分钟降低到10秒左右，并且在人群落地方面，使用存储更小的Bitmap代替原来的人群落地为表，不仅数据管理方便，而且磁盘空间占用减少了80左右。
　　除此之外，在一段时间的使用和学习中我们发现ApacheDoris丰富的功能和核心优势，综上原因，我们产生了用ApacheDoris数仓替代Hive数仓的想法，并迅速的付诸于实践。
　　当确定数仓使用ApacheDoris之后，结合当前的业务需求以及早期架构需要解决的问题，需要将多平台数据打通，构建统一数据口径和数据指标，我们将数据仓库构建分为：ODS层，DWD层，DWS层和ADS层，下图为各个分层主要负责的数据类型。
　　新数仓的分层逻辑如下：ODS层：从业务侧、日志系统和埋点系统等拉取过来的数据，按照原字段名存入ODS层。DWD层：数据按照维度进行拆分，轻度聚合，将多个平台数据按照同一标准定义进行处理。DWS层：主要负责数据的聚合、数据宽表、基于维度的一些计算指标等等。值得注意的是，DWS层中的部分表使用了AGGREGATEKEY模型，AGGREGATEKEY模型可以提前聚合数据，适合报表和多维度业务，可以有效避免数据汇总时的Join操作，部分指标可以使用该表特性实现，无需敲代码，降低了开发成本。ADS层：各业务模块根据各自的需求，将数据从DWS层汇聚数据指标到ADS层。
　　新架构设计
　　数据接入：
　　业务数据MySQL存储在多台RDS中，因Binlog的留存时间较短，且数据存放于多服务器，同时还进行了分库存储，因此如何接入历史数据以及如何同时接入多个库的数据成了棘手的问题。在调研过程中我们发现FlinkCDC可以完美解决上述问题：FlinkCDC可以在接入历史数据之后自动切换为读取Binlog，且2。x版本已经支持断点续传，支持水平扩展，支持动态添加表。
　　日志和埋点数据我们采用KafkaDorisRoutineLoad导入方式，RoutineLoad支持支持用户提交一个常驻的导入任务，通过不断的从指定的数据源读取数据，将数据导入到Doris中，支持Json解析，并且可以做一些简单的ETL，极大的减少了代码开发的工作。
　　数据加工：
　　数据加工采用了DorisSQL、Insertinto的方式将增量计算完的结果导入到数仓分层中（ODSDWDDWSADS）。因业务需求对数据的实时性允许存在一点延迟性，因此将Dolphinscheduler设置为每5分钟调度一次增量SQL；同时设置数仓每一层错峰执行任务，避免任务堵塞。
　　对于数据量比较小的表可以用一个SQL完成导入，而对于数据量大的表，为避免union，需要分成多个insertinto来执行。但有些大表的逻辑是多个大表的Join结果，对于这种场景，我们应用AGGREGATEKEY模型的表来解决，利用表的聚合特性来代替SQL的Join操作。
　　任务调度：
　　任务调度一直沿用Dolphinscheduler，页面化的操作简单方便，且对SQL的支持友好，整个大数据平台的任务都是通过该调度器完成。目前使用了2。x以上的版本，支持使用钉钉报警和邮件报警的功能来监控任务，任务失败将通过钉钉或者邮件发送。
　　监控：
　　使用PrometheusGrafana对Doris集群和Flink任务进行监控管理，页面化的监控，极大的减少运维成本。优化方案使用FlinkCDC启动多个同步任务后，磁盘IO飙升导致查询延迟变高。对接多个数据源CDC任务同步数据时，中间数据写入Kafka进行合并和数据消峰，减少写入Doris的任务数。调整DorisSink写入频率，控制每批次数据量。优化部分表的分区分桶，降低数据分片数量。Doris1。1。0rc05版本偶发后台合并线程持续合并已删除的Tablet，合并持续失败且数据版本最多的那个Tablet的版本数量升高至150左右。使用元数据管理工具metatool删除已失效的Tablet元数据，版本数量显著下降，稳定在30左右。对大表的超过两年的数据做冷备份，减少大表的Tablet数，降低整个Doris集群对Tablet的管理压力。
　　3。Bitmap存储散列用户ID，使用Bitmap相关函数计算时性能较差。用户唯一ID通过字符串转换生成，基数大且非常稀疏；使用全局字典生成紧凑的ID代替，优化后性能提高近五倍。总结与收益ApacheDoris构建的离线实时数仓一体化，采用SQL开发，并用Dolphinscheduler一键部署调度，极大的降低开发难度和开发工作量，可进行快速迭代以满足目前行业日益增长的数据需求。新架构采用FlinkDoris的架构体系，FlinkCDCStreamLoad可以做到流批一体化数据接入，减少了组件的使用，解决了数据的冗余存储，服务器资源节省了30，数据存储磁盘占用减少40，同时组件的运维成本大大减少。Doris的易用性极高，支持MySQL协议和标准SQL，各业务线均可通过查询MySQL的方式进行数据查询，极大的减少了学习成本。从2021年ApacheDoris上线云积互动的第一个业务至今，ApacheDoris在云积互动内部已成为大数据服务的基础，承担了包括人群分析、报表查询、指标计算等场景下的在线离线需求，在较小的集群规模下支持了每天近2万次的用户在线分析查询。未来规划
　　目前新的数据仓库已经建设完成，基于ApacheDoris较多优异特性以及与业务需求较高吻合性，当前团队已经在着手搭建基于ApacheDoris的数据质量管理和数据血缘，后续我们计划基于ApacheDoris搭建数据指标体系。下面简单分享一下我们在数据质量管理和数据管理的实现想法。
　　1。数据质量管理：在ApacheDoris的ODS层建表时设定一些非空主键，这些字段都是业务逻辑上的必须字段，当数据接入会给定一些默认值，这样就可以清晰的分类出这些数据，在质量分析中进行输出；在ETL中也会存在一些逻辑错误数据，这类数据会通过定时的DorisSQL脚本进行输出，同时也可以反馈到业务侧进行数据修复。2。数据血缘：依托Doris提供的SQL审计功能，使用采集工具FilebeatLogstash持续采集审计日志发送到Kafka，使用开源的SQL解析工具或者抽取Doris的SQL解析模块针对DDL或者DML进行解析，解析后的数据存入图数据库或者关系型数据库供业务端展示；该功能的实现对于数据问题排查、数据资产管理均有意义。
　　围绕着ApacheDoris为核心的数据平台建设目前也在一直迭代发展，当然在使用中也发现了该产品的一些需要优化的地方，但不可否认它优秀的性能和丰富的功能，后续我们也将持续不断地进行优化，将优化方案贡献给ApacheDoris社区。
　　作者介绍：
　　王杰：云积互动大数据团队leader，负责数据平台研发及数据治理
　　蒙磊：云积互动大数据高级开发，负责数据平台研发和数仓开发
　　相关链接：
　　ApacheDoris代码仓库：https：github。comapachedoris
　　ApacheDoris官网：http：doris。apache。org