本文导读: 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 引擎能够具有以下才能:
- 支撑 Join 操作,可满意不同事务用户灵敏多变的剖析需求
- 支撑高并发查询,可满意日常事务的报表剖析需求
- 性能强悍,能够在海量数据场景下完成快速呼应
- 运维简略,减缩运维人力的投入和本钱的开销,完成降本提效
- 一致数仓构建,简化繁琐的大数据软件栈
- 社区活跃,在运用过程中遇到问题,可敏捷与社区取得联系
依据以上要求,咱们快速定位了 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 飞速开展,越来越好!