本文导读： Apache Doris 助力荔枝微课构建了标准的、计算对立的实时数仓平台，目前 Apache Doris 曾经撑持了荔枝微课外部 90% 以上的业务场景，整体可达到毫秒级的查问响应，数据时效性实现 T+1 到分钟级的晋升，开发效率更是实现了 50% 的增长，满足了各业务场景需要、实现降本提效，深得十方融海各数据部门高度认可。

作者： 陈城，数据中台组组长

深圳十方融海科技有限公司成立于 2016 年，是一家数字职业在线教育头部企业，业务涵盖“数字职业技能课程、常识分享平台「荔枝微课」、智慧教育解决方案「女娲云教室」”，推出了多类数字素养与数字技能课程服务，助力用户在数字时代实现技能进阶与职业进阶。2016年上线荔枝微课，已倒退成为国内头部常识分享平台。2021年上线女娲云教室，实现了“教学练”一体化模式，填补了国内在线教学与实操脱轨的空白。

业务介绍

荔枝微课隶属于深圳十方融海科技有限公司，是一个收费应用的在线教育平台。荔枝微课领有海量的常识内容，包含直播视频、录播视频、音频等多种形式。

通过技术和数据的赋能，推动荔枝微课继续翻新，也为微课平台方和合作伙伴在视频的翻新和销售方面提供了更强劲的反对。在业务经营过程中咱们须要对用户进行全方位剖析，高效为业务赋能。数据平台旨在集成各种数据源的数据，整合造成数据资产，为业务提供用户全链路生命周期、实时指标剖析、标签圈选等剖析服务。

晚期架构及痛点

晚期架构选用的是 Hadoop 生态圈组件，以 Spark 批计算引擎为外围构建了最后的离线数仓架构，基于 Flink 计算引擎进行实时处理。从源端采集到的业务数据和日志数据将分为实时和离线两条链路：

  • 在实时局部，业务库数据通过 Binlog 的形式接入，日志数据应用 Flume-Kafka-Sink 进行实时采集，利用 Flink 将数据计算写入到 Kafka 和 MySQL中。在实时数仓的外部，恪守数据分层的实践以实现最大水平的数据复用。
  • 在离线局部，利用 Sqoop 和 DataX 对全量和增量业务库中的数据进行定时同步，日志数据通过 Flume 和日志服务进行采集。当不同数据源进入到离线数仓后，首先应用 Hive on Spark/Tez 进行定时调度解决，接着依据维度建模通过 ODS、DWD、DWS、ADS 层数据，这些数据存储在 HDFS 和对象存储 COS 上，最终利用 Presto 进行数据查问展现，并通过 Metabase 提供交互式剖析服务。同时为了保障数据的一致性，咱们会通过离线数据对实时数据进行定期笼罩。

问题与挑战：

基于 Hadoop 的晚期架构能够满足咱们的初步需要，而面对较为简单的剖析诉求则显得爱莫能助，再加上近年来，荔枝微课用户体量一直回升，数据量呈指数级回升，为了更好的为业务赋能，进步用户应用体验，业务侧对数据的实时性、可用性、响应速度也提出了更高的要求。在这样的背景下，晚期架构裸露的问题也越发显著：

  • 组件繁多，保护简单，运维难度十分高
  • 数据处理链路过长，导致查问提早变高
  • 当有新的数据需要时，牵一发而动全身，所需开发周期比拟长
  • 数据时效性低，只可满足 T+1 的数据需要，从而也导致数据分析效率低下

技术选型

通过对数据规模及晚期架构存在的问题进行评估，咱们决定引入一款实时数仓来搭建新的数据平台，同时心愿新的 OLAP 引擎能够具备以下能力：

  1. 反对 Join 操作，可满足不同业务用户灵便多变的剖析需要
  2. 反对高并发查问，可满足日常业务的报表剖析需要
  3. 性能强悍，能够在海量数据场景下实现疾速响应
  4. 运维简略，缩减运维人力的投入和老本的收入，实现降本提效
  5. 对立数仓构建，简化繁琐的大数据软件栈
  6. 社区沉闷，在应用过程中遇到问题，可迅速与社区取得联系

基于以上要求，咱们疾速定位了 Apache Doris 和 ClickHouse 这两款开源 OLAP 引擎 ，这两款引擎都是当下应用较为宽泛、口碑不错的产品。在调研中发现， ClickHouse 对 Join 能力的反对较为个别，而咱们在大多数业务场景中都须要基于明细数据进行大数据量的 Join，同时 ClickHouse 不反对高并发，这也与 Apache Doris 造成显明的比照，Apache Doris 多表 Join 能力强悍，高并发能力优异，齐全能够满足咱们日常的业务报表剖析需要。除此之外，Apache Doris 能够同时反对实时数据服务、交互数据分析和离线数据处理多种场景，并且反对 Multi Catalog ，能够实现对立的数据门户，这几个特点都是咱们外围思考的几个能力。

当然在其余方面，Apache Doris 的劣势也比拟显著，比方架构简略、反对 MySQL 协定，部署不便疾速，运维零门槛，国内我的项目社区十分沉闷，SelectDB 团队给予社区业余的技术支持，等等，这些方面都远胜于 ClickHouse，因而咱们决最终定应用 Apache Doris 来搭建新的架构体系。

新的架构及计划

在新的架构中咱们采取 Apache Doris 和 Apache Flink 来构建实时数仓，多种数据源的数据通过 Flink CDC 或 Flink 加工解决后，入库到 Kafka 和 Apache Doris 中，最终由 Doris 提供对立的查问服务。

  • 在数据同步上，个别通过 Flink CDC 将 RDS 数据实时同步到 Doris，通过 Flink 将 Kafka 的日志数据加工解决到 Doris，重要的指标数据个别由 Flink 计算，再通过 Kafka 分层解决写入到 Doris 中。
  • 在存储媒介上， 次要应用 Apache Doris 进行流批数据的对立存储。

架构收益

  • 胜利构建了标准的、计算对立的实时数仓平台，Apache Doris 的 Multi Catalog 性能助力咱们对立了不同数据源进口，实现联邦查问。同时利用内部表插入的形式进行疾速数据同步和修复，真正实现了对立数据门户。
  • 数据实时性无效晋升，通过 Flink + Doris 架构，实时性从晚期 T+1 缩短为的分钟级提早。并发能力能力强，能够笼罩更多的业务场景。
  • 极大的缩小了运维老本，Doris 架构简略，只有 FE 和 BE 两个过程，不依赖其余零碎；另外，集群扩缩容非常简单，可实现用户无感知扩容
  • 开发周期从周级别降至天级别，开发周期大幅缩短，开发效率较之前晋升了 50 %。

搭建教训

数据建模

联合 Apache Doris 的个性，咱们对数据仓库进行了建模，建模形式与传统数仓相似：

1、ODS 层： ODS 层日志数据抉择 Duplicate 模型的分区表，分区表不便进行数据修复，Duplicate 模型还能够缩小非必要的 Compaction。ODS 层业务库数据采纳 Unique 数据模型（业务库 MySQL 单表数据通过 Flink CDC 实时同步到 Doris，Kafka 日志数据经 Flink 荡涤，通过 Doris 的 Routine Load 写入 Doris 作为 ODS 层），DISTRIBUTED BY HASH KEY 依据具体的业务场景进行抉择：

  • 如果思考机器资源，可抉择均匀分布的 KEY，让 Tablet 数据可能均匀分布，使得查问时各 BE 资源可能充分利用，避免出现木桶效应；
  • 如果思考大表 Join 性能，能够根据 Colocate Join 个性进行创立，让 Join 查问更高效；
  • Doris 1.2 版本中 Unqiue 模型开始反对写时合并 Merge On Write，进一步晋升了 Unique 模型的查问性能；

2、DWD 层：

  • 对于通过 Flink 将数据进行 Join 打宽解决别离写入 Doris 和 Kafka 中的场景，抉择应用 Unique 数据模型；
  • 对于高频查问的宽表抉择 Doris 的 Aggregate 模型，应用 REPLACE_IF_NOT_NULL 字段类型，将多个事实单表进行插入，通过 Doris 的 Compaction 机制能够无效缩小 Flink 状态 TTL 导致历史数据没有及时更新的问题。

3、DWS 层和 ADS 层： 次要采纳 Unique 数据模型，DWS 层依据数据量大小按天、月进行分区。除此之外，咱们还会利用 INSERT INTO 语句进行 5 分钟的任务调度和 T+1 的工作修复来进行数仓分层，便于需要的疾速开发和实时数据修复。对于 Duplicate 模型的数据表，咱们会创立 Rollup 的物化视图，通过击中物化视图查问可能放慢下层表查问效率。

数据开发

在荔枝微课业务中，经营人员常常会有调整直播课程信息、批改专栏名称等操作，针对维度疾速变动但宽表中维度列没有及时更新的场景，为了能更好的满足业务需要，咱们利用 Doris Aggregate 模型 的 REPLACE_IF_NOT_NULL 字段个性，通过Flink CDC 多表别离写入 Doris 维度表的局部列。 当课程维度表数据发生变化时，须要查问下层维度（专栏和直播间），对维度表补全，再将数据插入到 Doris 中；当下层维度（专栏和直播间）发生变化时，须要下钻查问课程表，补全对应的课程 ID ，再将数据插入到 Doris 中。通过该形式能够保障维度表中所有字段的实时性，数据查问时再通过宽表来关联维表补全维度字段展现数据。

库表设计

在初期设计阶段，为了更好的利用 Apache Doris 提供的 Colocation Join 性能，咱们特地设计了事实表的主键，如下图示例：

在业务库中课程表 A 和课程表 B 的关系是A.id=B.lecture_id，为了实现 Colocation Join，咱们将 B 的 distributed by hash key 设置为 lecture_id 。当面对多事实表时，先进行 Colocation Join ，再进行维度 Bucket Shuffle Join ，以实现疾速查问响应。而应用这个形式可能导致以下问题：

  • 入选取的 lecture_id 进行 DISTRIBUTED BY时，数据库主键 ID 并不是均匀分布的，在数据量很大的状况下可能会导致数据歪斜，而各个机器的 Tablet 大小不统一，在高并发查问时可能呈现 BE 机器资源应用不平衡，从而影响查问稳定性，造成资源节约。

基于以上问题，咱们尝试进行调整，并对查问效率和机器资源的占用这两方面进行了评估衡量，最终决定在尽量不影响查问效率的前提下，尽可能进步资源利用率。

  • 在资源利用上，咱们在建表时利用 colocate_with 属性，在不同数量和类型的 Distributed Key 创立不同的 Group，实现机器资源能得以充分利用。
  • 在查问效率上，依据业务场景和需要对前缀索引的字段程序进行针对性调整，对于必选或高频的查问条件，将字段放在 UNIQUE KEY 后面，依据维度依照从高到低的程序进行设计。其次咱们利用物化视图对字段程序进行调整，尽可能应用前缀索引进行查问，以放慢数据查问 。除此之外，咱们对数据量进行月、天分区，对明细数据进行分桶，通过正当库表的设计缩小 FE 元数据的压力。

数据管理

在数据管理方面，咱们进行了以下操作：

  • 监控告警： 对于重要的单表，咱们个别通过 Apache Doris 来创立内部表，通过数据品质监控来比照业务库数据和 Apache Doris 数据，进行数据品质稽查告警。
  • 数据备份与复原： 咱们会将 Doris 数据定期导入到 HDFS 进行备份，防止数据误删除或失落的状况产生。比方当因某些起因导致 Flink 同步工作失败、无奈从 Checkpoint 进行启动时，咱们可读取最新的数据进行同步，历史缺失数据通过内部表进行修复，使得同步工作可能疾速复原

收益总结

在新架构中咱们从 Hadoop 生态齐全的迁徙到 Flink + Doris 上，在下层构建不同的数据利用，比方自助报表、自助数据提取、数据大屏、业务预警等，Doris 通过应用层接口服务项目对立对外提供 API 查问，新架构的利用也为咱们带来了许多收益：

  • 撑持了荔枝微课外部 90% 以上的业务场景，整体可达到毫秒级的查问响应。
  • 反对千万级甚至亿级大表关联查问，可实现秒级甚至毫秒级响应。
  • Doris 对立了数据源进口，查问效率显著晋升，反对多种数据的联邦查问，升高了多数据查问的复杂度以及数据链路解决老本。
  • Doris 架构简略，极大简化了大数据的架构体系；并高度兼容 MySQL 的语法，极大升高开发人员接入老本。

将来布局

荔枝微课在引入 Apache Doris 之后，在外部失去了十分宽泛的利用，满足了各业务场景需要、实现降本提效，深得十方融海各数据部门高度认可。将来咱们期待 Apache Doris 在实时数据处理场景的能力上有更进一步的晋升，包含 Unique 模型上的局部列更新、单表物化视图上的计算加强、主动增量刷新的多表物化视图等，通过一直的迭代更新，使实时数仓的构建更加简略易用。

最初，感激 Apache Doris 社区和 SelectDB 的同学，感激其对问题的疾速响应和踊跃的技术支持，将来咱们也会继续将相干成绩奉献到社区，心愿 Apache Doris 飞速发展，越来越好！