共计 5172 个字符，预计需要花费 13 分钟才能阅读完成。
导读： 随着业务量快速增长，云积互动对数据的实时性及灵活性提出更高要求，晚期基于 CDH 的大数据平台已无奈满足以后难度以及复杂度较高的的业务需要，因而云积互动于 2021 引进 Apache Doris 在局部业务中应用，并在应用过程中逐步发掘出 Apache Doris 更多弱小之处以及劣势，最终决定在 2022 年全面利用 Apache Doris，基于 Apache Doris 来构建云积互动企业级实时离线对立数仓。
作者|云积互动大数据团队 王杰 & 蒙磊
业务背景
云积互动，全称深圳市云积分科技有限公司，成立于 2014 年，是国内当先的 AI 驱动的消费者经营服务提供商，致力于倒退消费者经营相干实践、技术、算法、模型及软件工具，为寰球消费性企业提供基于 AI 的消费者经营零碎及经营策略服务，打造消费者经营畛域最佳服务和实际规范，帮忙企业构建消费者经营外围能力，以应答以后及将来的场景化经营挑战。目前已成为天猫、京东、抖音、腾讯等支流电商和社交平台深度合作伙伴，服务客户 2300+，其中世界 500 强客户超过 18 家，包含寰球第一的美妆、日化、医药集团，均深度服务超过 7 年。
业务需要
云积互动的次要业务是以消费者经营为外围，蕴含了会员通，CRM，策略营销，数据资产等一系列业务，如下图所示。
晚期云积互动的大数据需要较少，起步也比拟晚，2019 年才开始搭建基于 CDH 的大数据平台，因而大数据平台的次要目标是为了满足晚期较为繁多的 BI 数据看板及报表性能。近年来，随着业务量快速增长，数据量的增长，业务对数据的实时性及灵活性提出更高的要求，大数据平台也从晚期的只须要满足繁多的 BI 服务需要，扩大到须要反对各业务线，蕴含圈人服务，人群剖析，AI 智能数据等多种业务需要。晚期基于 CDH 的大数据平台已无奈满足以后难度以及复杂度较高的的业务需要。
大数据平台的迭代
晚期数仓架构
晚期公司业务量较少，基于 Hive+Spark 构建的离线数仓即可满足晚期大数据的需要。晚期架构次要用于反对 BI 相干性能，数据大屏，自助报表等利用，大部分的指标仅要求 T+1 的指标。
下图为云积互动晚期数仓架构，晚期的数据源次要为业务数据库 MySQL 以及日志，数据通过 Streamsets 实时采集数据并经 ETL 后传入 ODS 层，存储到 Kudu 中，通过 Impala 对 ODS 层的数据进行解决，实现实时查问业务的需要。通过 Hive 构建了离线数仓的 DWD、DWS 以及 DIM 层，应用 Spark 进行离线工作的计算与调度，最终解决并计算实现的数据输入到 MySQL 和 Kylin 中，利用于下层业务利用及剖析。
存在的问题
- 查问效率低：应用 Impala 多表查问速度太慢，亿级别表 Join 时，查问工夫基本上在 3 分钟以上，局部简单查问会在超过 3 分钟左右断定超时；同时应用 Impala 并行查问对内存耗费较大，影响其余工作运行。
- 存储老本太高：应用多个零碎存储数据（Hive，Hbase，Kudu），存储老本较高，随着业务量的增长，数据量指数级的增多，存储老本更是成倍数减少。
- 开发难度大：数仓开发基于代码，不能满足灵便的指标需要，当剖析需要越来越多时，存在多个场景组合查问、自定义等查问场景，面对这样的场景，必须进行再开发，开发和工夫老本都很高。
- 数据链路长：较长的链路使得数据的一致性很难保障，数据在某一环节呈现问题，排查难度高，运维老本也会减少。
技术选型
基于业务对数据实时性及灵活性更高的要求，咱们在 2021 年初对以后市面上较为风行的剖析引擎 ClickHouse 和 Apache Doris 进行了调研，调研中咱们发现，Apache Doris 具备高性能、简略易用、实现成本低等诸多劣势。基于此，咱们决定在局部业务上开始应用 Apache Doris，在应用的过程中逐步发掘出 Apache Doris 更多弱小之处以及劣势，Apache Doris 在很多方面非常贴合咱们的诉求，因而，咱们决定在 2022 年全面利用 Apache Doris 在数据仓库中，基于 Apache Doris 构建云积互动企业级数仓，抉择 Apache Doris 的次要起因如下：
1. 该架构开发效率高，查问性能远高于 Hive。
- 数仓 ETL 由原来的 Spark 工作改为 Doris SQL 工作，应用 SQL 开发模式可进行疾速迭代，开发效率晋升了近一倍。
- Doris 查问反对物化视图索引减速，Doris 在 1.0 版本开始引入了向量化引擎，性能晋升 2~3 倍，均匀查问耗时升高了 60%。
2. 该架构对 OLAP 反对更好，反对更为灵便的查问。
- Doris 反对 Cube 函数，实现了 Kylin 的多维计算性能，极大的缩小了 SQL 的开发量。
- Doris 反对 Bitmap 类型，可实现人群之间的疾速交并差计算并落地新人群。
3. 反对主键惟一和聚合模型的表，极大的缩小了开发难度。
- 应用主键惟一模型可做到根据主键数据笼罩，主动实现数据更新性能。
- 应用聚合模型的表，缩小了 ETL 过程中的 Join 操作，同时解决了下层数据达到工夫不统一而导致的数据关联不上的问题。
新数仓架构
最开始应用新的数仓架构次要是要解决圈人速度慢的问题，圈人服务的外围在于人群圈选，通过 SQL 代码或标签取值组合等多种形式，实现人群查找，帮客户找到合乎画像的人群，当初各行各业都会设计广告营销场景，其中也包含云积互动，而如何疾速精确找到对的人推送广告就成了大数据场景须要解决的问题。过后咱们只是在局部性能上应用了 Apache Doris，用 Apache Doris 代替了 Spark+Impala 来实现实时圈人性能，出其不意的是，Apache Doris 投入使用之后成果极佳，新版架构的实时圈人业务均匀每个工作耗时由 3~5 分钟升高到 10 秒左右，并且在人群落地方面，应用存储更小的 Bitmap 代替原来的人群落地为表，不仅数据管理不便，而且磁盘空间占用缩小了 80% 左右。
除此之外，在一段时间的应用和学习中咱们发现 Apache Doris 丰盛的性能和外围劣势，综上起因，咱们产生了用 Apache Doris 数仓代替 Hive 数仓的想法，并迅速的付诸于实际。
当确定数仓应用 Apache Doris 之后，联合以后的业务需要以及晚期架构须要解决的问题，须要将多平台数据买通，构建对立数据口径和数据指标，咱们将数据仓库构建分为：ODS 层，DWD 层，DWS 层和 ADS 层，下图为各个分层次要负责的数据类型。
新数仓的分层逻辑如下：
- ODS 层： 从业务侧、日志零碎和埋点零碎等拉取过去的数据，依照原字段名存入 ODS 层。
- DWD 层： 数据依照维度进行拆分，轻度聚合，将多个平台数据依照同一规范定义进行解决。
- DWS 层： 次要负责数据的聚合、数据宽表、基于维度的一些计算指标等等。值得注意的是，DWS 层中的局部表应用了 AGGREGATE KEY 模型，AGGREGATE KEY 模型能够提前聚合数据，适宜报表和多维度业务，能够无效防止数据汇总时的 Join 操作，局部指标能够应用该表个性实现，无需敲代码，升高了开发成本。
- ADS 层： 各业务模块依据各自的需要，将数据从 DWS 层汇聚数据指标到 ADS 层。
新架构设计
数据接入：
业务数据 MySQL 存储在多台 RDS 中，因 Binlog 的留存工夫较短，且数据寄存于多服务器，同时还进行了分库存储，因而如何接入历史数据以及如何同时接入多个库的数据成了辣手的问题。在调研过程中咱们发现 FlinkCDC 能够完满解决上述问题：FlinkCDC 能够在接入历史数据之后主动切换为读取 Binlog，且 2.x 版本曾经反对断点续传，反对程度扩大，反对动静增加表。
日志和埋点数据咱们采纳 Kafka + Doris Routine Load 导入形式，Routine Load 反对反对用户提交一个常驻的导入工作，通过一直的从指定的数据源读取数据，将数据导入到 Doris 中，反对 Json 解析，并且能够做一些简略的 ETL，极大的缩小了代码开发的工作。
数据加工：
数据加工采纳了 Doris SQL、Insert into 的形式将增量计算完的后果导入到数仓分层中（ODS/DWD/DWS/ADS）。因业务需要对数据的实时性容许存在一点提早性，因而将 Dolphinscheduler 设置为每 5 分钟调度一次增量 SQL；同时设置数仓每一层错峰执行工作，防止工作梗塞。
对于数据量比拟小的表能够用一个 SQL 实现导入，而对于数据量大的表，为防止 union，须要分成多个 insert into 来执行。但有些大表的逻辑是多个大表的 Join 后果，对于这种场景，咱们利用 AGGREGATE KEY 模型的表来解决，利用表的聚合个性来代替 SQL 的 Join 操作。
任务调度：
任务调度始终沿用 Dolphinscheduler，页面化的操作简略不便，且对 SQL 的反对敌对，整个大数据平台的工作都是通过该调度器实现。目前应用了 2.x 以上的版本，反对应用钉钉报警和邮件报警的性能来监控工作，工作失败将通过钉钉或者邮件发送。
监控：
应用 Prometheus+Grafana 对 Doris 集群和 Flink 工作进行监控治理，页面化的监控，极大的缩小运维老本。
优化计划
- 应用 Flink CDC 启动多个同步工作后，磁盘 IO 飙升导致查问提早变高。
- 对接多个数据源 CDC 工作同步数据时，两头数据写入 Kafka 进行合并和数据消峰， 缩小写入 Doris 的工作数。
- 调整 DorisSink 写入频率， 管制每批次数据量 。
- 优化局部表的分辨别桶， 升高数据分片数量 。
- Doris 1.1.0-rc05 版本偶发后盾合并线程继续合并已删除的 Tablet, 合并继续失败且数据版本最多的那个 Tablet 的版本数量升高至 150 左右。
- 应用元数据管理工具 meta_tool 删除已生效的 Tablet 元数据， 版本数量显著降落，稳固在 30 左右 。
- 对大表的超过两年的数据做冷备份， 缩小大表的 Tablet 数 ，升高整个 Doris 集群对 Tablet 的治理压力。
3. Bitmap 存储散列用户 ID，应用 Bitmap 相干函数计算时性能较差。
- 用户惟一 ID 通过字符串转换生成，基数大且十分稠密；应用全局字典生成紧凑的 ID 代替，优化后性能进步近五倍。
总结与收益
- Apache Doris 构建的离线 + 实时数仓一体化，采纳 SQL 开发，并用 Dolphinscheduler 一键部署调度， 极大的升高开发难度和开发工作量 ，可进行疾速迭代以满足目前行业日益增长的数据需要。
- 新架构采纳 Flink+Doris 的架构体系，FlinkCDC+StreamLoad 能够做到流批一体化数据接入，缩小了组件的应用，解决了数据的冗余存储， 服务器资源节俭了 30%， 数据存储磁盘占用缩小 40%，同时组件的运维老本大大减少。
- Doris 的易用性极高，反对 MySQL 协定和规范 SQL，各业务线均可通过查问 MySQL 的形式进行数据查问，极大的缩小了学习老本。
- 从 2021 年 Apache Doris 上线云积互动的第一个业务至今，Apache Doris 在云积互动外部已成为大数据服务的根底 ，承当了包含人群剖析、报表查问、指标计算等场景下的在线 / 离线需要，在较小的集群规模下反对了每天近 2 万次的用户在线剖析查问。
将来布局
目前新的数据仓库曾经建设实现，基于 Apache Doris 较多优异个性以及与业务需要较高吻合性，以后团队曾经在着手搭建基于 Apache Doris 的数据品质治理和数据血统，后续咱们打算基于 Apache Doris 搭建数据指标体系。上面简略分享一下咱们在数据品质治理和数据管理的实现想法。
1. 数据品质治理： 在 Apache Doris 的 ODS 层建表时设定一些非空主键，这些字段都是业务逻辑上的必须字段，当数据接入会给定一些默认值，这样就能够清晰的分类出这些数据，在品质剖析中进行输入；在 ETL 中也会存在一些逻辑谬误数据，这类数据会通过定时的 Doris SQL 脚本进行输入，同时也能够反馈到业务侧进行数据修复。2. 数据血统： 依靠 Doris 提供的 SQL 审计性能，应用采集工具 Filebeat/Logstash 继续采集审计日志发送到 Kafka，应用开源的 SQL 解析工具或者抽取 Doris 的 SQL 解析模块针对 DDL 或者 DML 进行解析，解析后的数据存入图数据库或者关系型数据库供业务端展现；该性能的实现对于数据问题排查、数据资产治理均有意义。
围绕着 Apache Doris 为外围的数据平台建设目前也在始终迭代倒退，当然在应用中也发现了该产品的一些须要优化的中央，但不可否认它优良的性能和丰盛的性能，后续咱们也将继续一直地进行优化，将优化计划奉献给 Apache Doris 社区。
作者介绍：
王杰 ：云积互动大数据团队 leader，负责数据平台研发及数据治理
蒙磊 ：云积互动大数据高级开发，负责数据平台研发和数仓开发
相干链接：
Apache Doris 代码仓库：https://github.com/apache/doris
Apache Doris 官网：http://doris.apache.org/
