关于数据库:重构实时离线一体化数仓Apache-Doris-在思必驰的应用实践

作者：赵伟，思必驰大数据高级研发，10 年大数据开发和设计教训，负责大数据平台根底技术和 OLAP 剖析技术开发。社区奉献：Doris-spark-connector 的实时读写和优化。

业务背景

思必驰是国内业余的对话式人工智能平台公司，领有全链路的智能语音语言技术，致力于成为全链路智能语音及语言交互的平台型企业，自主研发了新一代人机交互平台 DUI 和人工智能芯片 TH1520，为车联网、IoT 及政务、金融等泛滥行业场景合作伙伴提供自然语言交互解决方案。

思必驰于 2019 年首次引入 Apache Doris，基于 Apache Doris 构建了实时与离线一体的数仓架构。绝对于过来架构，Apache Doris 凭借其灵便的查问模型、极低的运维老本、短平快的开发链路以及优良的查问性能等诸多方面劣势，现在曾经在实时业务经营、自助 / 对话式剖析等多个业务场景失去使用，满足了 设施画像 / 用户标签、业务场景实时经营、数据分析看板、自助 BI、财务对账等多种数据分析需要。在这一过程中咱们也积攒了诸多应用上的教训，在此分享给大家。

架构演进

晚期业务中离线数据分析是咱们的次要需要，近几年，随着业务的一直倒退，业务场景对实时数据分析的要求也越来越高，晚期数仓架构逐步力不从心，暴露出很多问题。为了满足业务场景对查问性能、响应工夫及并发能力更高的要求，2019 年正式引入 Apache Doris 构建实时离线一体的数仓架构。

以下将为大家介绍思必驰数仓架构的演进之路，晚期数仓存在的优缺点，同时分享咱们抉择 Apache Doris 构建新架构的起因以及面临的新问题与挑战。

晚期数仓架构及痛点

如上图所示，晚期架构基于 Hive +Kylin 来构建离线数仓，实时数仓架基于 Spark+MySQL 来构建实时剖析数仓。

咱们业务场景的数据源次要分为三类，业务数据库如 MySQL，利用零碎如 K8s 容器服务日志，还有车机设备终端的日志。数据源通过 MQTT/HTTP 协定、业务数据库 Binlog、Filebeat 日志采集等多种形式先写入 Kafka。在晚期架构中，数据经 Kafka 后将分为实时和离线两条链路，首先是实时局部，实时局部链路较短，通过 Kafka 缓冲完的数据通过 Spark 计算后放入 MySQL 中进行剖析，对于晚期的实时剖析需要，MySQL 根本能够满足剖析需要。而离线局部则由 Spark 进行数据荡涤及计算后在 Hive 中构建离线数仓，并应用 Apache Kylin 构建 Cube，在构建 Cube 之前须要提前做好数据模型的的设计，包含关联表、维度表、指标字段、指标须要的聚合函数等，通过调度零碎进行定时触发构建，最终应用 HBase 存储构建好的 Cube。

晚期架构的劣势：

1. 晚期架构与 Hive 联合较好，无缝对接 Hadoop 技术体系。
2. 离线数仓中基于 Kylin 的预计算、表关联、聚合计算、准确去重等场景，查问性能较高，在并发场景下查问稳定性也较高。

晚期架构解决了过后业务中较为紧迫的查问性能问题，但随着业务的倒退，对数据分析要求一直升高，晚期架构毛病也开始逐步凸显进去。

晚期架构的痛点：

1. 依赖组件多。Kylin 在 2.x、3.x 版本中强依赖 Hadoop 和 HBase，利用组件较多导致开发链路较长，架构稳定性隐患多，保护老本比很高。
2. Kylin 的构建过程简单，构建工作容易失败。Kylin 构建须要进行打宽表、去重列、生成字典，构建 Cube 等如果每天有 1000-2000 个甚至更多的工作，其中至多会有 10 个甚至更多任务构建失败，导致须要大量工夫去写主动运维脚本。
3. 维度 / 字典收缩重大。维度收缩指的是在某些业务场景中须要多个剖析条件和字段，如果在数据分析模型中抉择了很多字段而没有进行剪枝，则会导致 Cube 维度收缩重大，构建工夫变长。而字典收缩指的是在某些场景中须要长时间做全局准确去重，会使得字典构建越来越大，构建工夫也会越来越长，从而导致数据分析性能继续降落。
4. 数据分析模型固定，灵活性较低。在理论利用过程中，如果对计算字段或者业务场景进行变更，则要回溯局部甚至全副数据。
5. 不反对数据明细查问。晚期数仓架构是无奈提供明细数据查问的，Kylin 官网给的解决办法是下推给 Presto 做明细查问，这又引入了新的架构，减少了开发和运维老本。

架构选型

为解决以上问题，咱们开始摸索新的数仓架构优化计划，先后对市面上利用最为宽泛的 Apache Doris、Clickhouse 等 OLAP 引擎进行选型调研。相较于 ClickHouse 的沉重运维、各种各样的表类型、不反对关联查问等，联合咱们的 OLAP 剖析场景中的需要，综合思考，Apache Doris 体现较为优良，最终决定引入 Apache Doris。

新数仓架构

如上图所示，咱们基于 Apache Doris 构建了实时 + 离线一体的新数仓架构，与晚期架构不同的是，实时和离线的数据别离进行解决后均写入 Apache Doris 中进行剖析。

因历史起因数据迁徙难度较大，离线局部根本和晚期数仓架构保持一致，在 Hive 上构建离线数仓，当然齐全能够在 Apache Doris 上间接构建离线数仓。

绝对晚期架构不同的是，离线数据通过 Spark 进行荡涤计算后在 Hive 中构建数仓，而后通过 Broker Load 将存储在 Hive 中的数据写入到 Apache Doris 中。这里要阐明的，Broker Load 数据导入速度很快，天级别 100-200G 数据导入到 Apache Doris 中仅须要 10-20 分钟。

实时数据流局部，新架构应用了 Doris-Spark-Connector 来生产 Kafka 中的数据并通过简略计算后写入 Apache Doris。从架构图所示，实时和离线数据对立在 Apache Doris 进行剖析解决，满足了数据利用的业务需要，实现了实时 + 离线一体的数仓架构。

新架构的收益：

1. 极简运维，保护成本低，不依赖 Hadoop 生态组件。Apache Doris 的部署简略，只有 FE 和 BE 两个过程，FE 和 BE 过程都是能够横向扩大的，单集群反对到数百台机器，数十 PB 的存储容量，并且这两类过程通过一致性协定来保障服务的高可用和数据的高牢靠。这种高度集成的架构设计极大的升高了一款分布式系统的运维老本。在应用 Doris 三年工夫中破费的运维工夫非常少，相比于基于 Kylin 搭建的晚期架构，新架构破费极少的工夫去做运维。
2. 链路短，开发排查问题难度大大降低。基于 Doris 构建实时和离线对立数仓，反对实时数据服务、交互数据分析和离线数据处理场景，这使得开发链路变的很短，问题排查难度大大降低。
3. 反对 Runtime 模式的 Join 查问。Runtime 相似 MySQL 的表关联，这对数据分析模型频繁变更的场景十分敌对，解决了晚期构造数据模型灵活性较低的问题。
4. 同时反对 Join、聚合、明细查问。解决了晚期架构中局部场景无奈查问数据明细的问题。
5. 反对多种减速查问形式。反对上卷索引，物化视图，通过上卷索引实现二级索引来减速查问，极大的晋升了查问响应工夫。
6. 反对多种联邦查问形式。反对对 Hive、Iceberg、Hudi 等数据湖和 MySQL、Elasticsearch 等数据库的联邦查问剖析。

问题和挑战：

在建设新数仓架构过程中，咱们遇到了一些问题：

• 高并发场景对 Apache Doris 查问性能存在肯定影响。咱们别离在 Doris 0.12 和 Doris 1.1 版本上进行测试，同一时间同样的 SQL，10 并发和 50 并发进行拜访，性能差异较大。
• 在实时写入场景中，当实时写入的数据量比拟大时，会使得 IO 比拟密集，导致查问性能降落。
• 大数据量下字符串准确去重较慢。目前应用的是 count distinct 函数、Shuffle 和聚合算子去重，此形式算力比较慢。以后业内常见的解决办法个别是针对去重列构建字典，基于字典构建 Bitmap 索引后应用 Bitmap 函数去重。目前 Apache Doris 只反对数字类型的 Bitmap 索引，具备肯定的局限性。

业务场景的利用

Apache Doris 在思必驰最先利用在实时经营业务场景以及自助 / 对话式剖析场景，本章节将介绍两个场景的需要及利用状况。

实时经营业务场景

首先是实时经营业务场景，如上图所示，实时经营业务场景的技术架构和前文所述的新版数仓架构基本一致：

• 数据源：数据源新版架构图中统一，包含 MySQL 中的业务数据，利用零碎埋点数据以及设施和终端日志。
• 数据导入：离线数据导入应用 Broker Load，实时数据导入应用 Doris-Spark-Connector。
• 数据存储与开发：简直所有的实时数仓全副在 Apache Doris 构建，有一部分离线数据放在 Airflow 上执行 DAG 跑批工作。

• 数据利用：最上层是业务侧提出的业务剖析需要，包含大屏展现，数据经营的实时看板、用户画像、BI 看板等。

在实时经营业务场景中，数据分析的需要次要有两方面：

• 因为实时导入数据量比拟大，因而对实时数据的查问效率要求较高
• 在此场景中，有 20+ 人的团队在经营，须要同时开数据经营的看板，因而对实时写入的性能和查问并发会有比拟高的要求。

自助 / 对话式剖析场景

除以上之外，Apache Doris 在思必驰第二个利用是自助 / 对话式剖析场景。

如上图所示，在个别的 BI 场景中，用户方比方商务、财务、销售、经营、项目经理等会提出需要给数据分析人员，数据分析人员在 BI 平台上做数据看板，最终把看板提供给用户，用户从 BI 看板上获取所需信息，然而有时候用户想要查看明细数据、定制化的看板需要，或者在某些场景需做任意维度的上卷或者下钻的剖析，个别场景下 BI 看板是不反对的的，基于以上所述用户需要，咱们打造了自助对话式 BI 场景来解决用户定制化的需要。

与个别 BI 场景不同的是，咱们将自助 / 对话式 BI 场景从数据分析人员方下沉到用户方，用户方只须要通过打字，形容数据分析的需要。基于咱们公司自然语言解决的能力，自助 / 对话式 BI 场景会将自然语言转换成 SQL，相似 NL2SQL 技术，须要阐明的是这里应用的是定制的自然语言解析，绝对开源的 NL2SQL 命中率高、解析后果更准确。当自然语言转换成 SQL 后，将 SQL 给到 Apache Doris 查问失去剖析后果。由此，用户通过打字就能够随时查看任意场景下的明细数据，或者任意字段的上卷、下钻。

相比 Apache Kylin、Apache Druid 等预计算的 OLAP 引擎，Apache Doris 合乎以下几个特点：

• 查问灵便，模型不固定，反对自在定制场景。
• 反对表关联、聚合计算、明细查问。
• 响应工夫要疾速。

因而咱们很顺利的使用 Apache Doris 实现了自助 / 对话式剖析场景。同时，自助 / 对话式剖析在咱们公司多个数据分析场景利用反馈十分好。

实践经验

基于下面的两个场景，咱们应用过程当中积攒了一些教训和心得，分享给大家。

数仓 表设计：

1. 千万级 (量级供参考，跟集群规模有关系) 以下的数据表应用 Duplicate 表类型，Duplicate 表类型同时反对聚合、明细查问，不须要额定写明细表。

2. 当数据量比拟大时，应用 Aggregate 聚合表类型，在聚合表类型上做上卷索引，应用物化视图优化查问、优化聚合字段。因为 Aggregate 表类型是预计算表，会失落明细数据，如有明细查问需要，须要额定写一张明细表。

3. 当数据量又大、关联表又多时，可用 ETL 先写成宽表，而后导入到 Doris，联合 Aggregate 在聚合表类型下面做优化，也能够应用官网举荐 Doris 的 Join 优化：https://doris.apache.org/zh-C…

写入：

1. 通过 Spark Connector 或 Flink Connector 代替 Routine Load：最早咱们应用的是 Routine Load 实时写入 BE 节点，Routine Load 的工作原理是通过 SQL 在 FE 节点起一个相似于 Task Manager 的治理，把工作分发给 BE 节点，在 BE 节点起 Routine Load 工作。在咱们实时场景并发很高的状况下，BE 节点 CPU 峰值个别会达到 70% 左右，在这个前提下，Routine Load 也跑到 BE 节点，将重大影响 BE 节点的查问性能，并且查问 CPU 也将影响 Routine Load 导入，Routine Load 就会因为各种资源竞争死掉。面对此问题，目前解决办法是将 Routine Load 从 BE 节点拿进去放到资源调度上，用 Doris-Spark/Flink-Connector 替换 Routine Load。过后 Doris-spark-Connector 还没有实时写入的性能，咱们依据业务需要进行了优化，并将计划奉献给社区。

2. 通过攒批来管制实时写入频率：当实时写入频率较高时，小文件沉积过多、查问 IO 升高，小文件排序归并的过程将导致查问工夫加长，进而呈现查问抖动的状况。以后的解决办法是管制导入频次，调整 Compaction 的合并线程、间隔时间等参数，防止 Tablet 下小文件的沉积。

查问：

1. 减少 SQL 黑名单，管制异样大查问。个别用户在查问时没有加 where 条件，或者查问时抉择的工夫范畴较长，这种状况下 BE 节点的 SQL 会把磁盘的负载和 CPU 拉高，导致其余节点的 SQL 查问变慢，甚至呈现 BE 节点宕机的状况。目前的解决方案是应用 SQL 黑名单禁止全表及大量分区实时表的查问。

2. 应用 SQL Cache 和 SQL Proxy 实现高并发拜访。同时应用 SQL Cache 和 SQL Proxy 的起因在于，SQL Cache 的颗粒度到表的分区，如果数据产生变更，SQL Cache 将生效，因而 SQL Cache 缓存适宜数据更新频次较低的场景（离线场景、历史分区等）。对于数据须要继续写到最新分区的场景，SQL Cache 则是不实用的。当 SQL Cache 生效时 Query 将全副发送到 Doris 造成反复的 Runtime 计算，而 SQL Proxy 能够设置一秒左右的缓存，能够防止雷同条件的反复计算，无效进步集群的并发。

存储：

应用 SSD 和 HDD 做热温数据存储周期的拆散，近一年以内的数据存在 SSD，超过一年的数据存在 HDD。Apache Doris 反对对分区设置冷却工夫，但只反对创立表分区时设置冷却的工夫，目前的解决方案是设置主动同步逻辑，把历史的一些数据从 SSD 迁徙到 HDD，确保 1 年内的数据都放在 SSD 上。

降级：

降级前肯定要备份元数据，也能够应用新开集群的形式，通过 Broker 将数据文件备份到 S3 或 HDFS 等远端存储系统中，再通过备份复原的形式将旧集群数据导入到新集群中。

降级前后性能比照

思必驰最早是从 0.12 版本开始应用 Apache Doris 的，在往年咱们也实现了从 0.15 版本到最新 1.1 版本的降级操作，并进行了基于实在业务场景和数据的性能测试。

从以上测试报告中能够看到，总共 13 个测试 SQL 中，前 3 个 SQL 降级前后性能差别不显著，因为这 3 个场景次要是简略的聚合函数，对 Apache Doris 性能要求不高，0.15 版本即可满足需要。而在 Q4 之后的场景中，SQL 较为简单，Group By 有多个字段、多个字段聚合函数以及简单函数，因而降级新版本后带来的性能晋升非常明显，均匀查问性能较 0.15 版本晋升 2-3 倍。由此，十分举荐大家去降级到 Apache Doris 最新版本。

总结和收益

1. Apache Doris 反对构建离线 + 实时对立数仓，一个 ETL 脚本即可反对实时和离线数仓，大大缩短开发周期，升高存储老本，防止了离线和实时指标不统一等问题。

2. Apache Doris 1.1.x 版本开始全面反对向量化计算，较之前版本查问性能晋升 2-3 倍。经测试，Apache Doris 1.1.x 版本在宽表场景的查问性能已根本与 ClickHouse 持平。

3. 功能强大，不依赖其余组件。相比 Apache Kylin、Apache Druid、ClickHouse 等，Apache Doris 不须要引入第 2 个组件填补技术空档。Apache Doris 反对聚合计算、明细查问、关联查问，以后思必驰超 90% 的剖析需要已移步 Apache Doris 实现。得益于此劣势，技术人员须要运维的组件缩小，极大升高运维老本。

4. 易用性极高，反对 MySQL 协定和规范 SQL，大幅升高用户学习老本。

将来打算

1. Tablet 小文件过多的问题。Tablet 是 Apache Doris 中读写数据最小的逻辑单元，当 Tablet 小文件比拟多时会产生 2 个问题，一是 Tablet 小文件增多会导致元数据内存压力变大。二是对查问性能的影响，即便是几百兆的查问，但在小文件有几十万、上百万的状况下，一个小小的查问也会导致 IO 十分高。将来，咱们将做一个 Tablet 文件数量 / 大小比值的监控，当比值在不合理范畴内时及时进行表设计的批改，使得文件数量和大小的比值在正当的范畴内。

2. 反对基于 Bitmap 的字符串准确去重。业务中准确去重的场景较多，特地是基于字符串的 UV 场景，目前 Apache Doris 应用的是 Distinct 函数来实现的。将来咱们会尝试的在 Apache Doris 中创立字典，基于字典去构建字符串的 Bitmap 索引。
3. Doris-Spark-Connector 流式写入反对分块传输。Doris-Spark-Connector 底层是复用的 Stream Load，工作机制是攒批，容易呈现两个问题，一是攒批可能会会呈现内存压力导致 OOM，二是当 Doris-Spark-Connector 攒批时，Spark Checkpoint 没有提交，但 Buffer 已满并提交给 Doris，此时 Apacche Doris 中曾经有数据，但因为没有提交 Checkpoint，如果此时工作凑巧失败，启动后又会从新生产写入一遍。将来咱们将优化此问题，实现 Doris-Spark-Connector 流式写入反对分块传输。

更多资讯

近期，在 ClickHouse 发动的剖析型数据库性能测试排行榜 ClickBench 中，新一代云原生数仓 SelectDB 强势登顶，性能体现超过一众国内外产品，多项指标排行前列，并在业界最为通用的 c6a.4xlarge, 500gb gp2 机型下排行寰球第一！

详情请查看：https://mp.weixin.qq.com/s/7G…