共计 8111 个字符，预计需要花费 21 分钟才能阅读完成。
导读：本文是货拉拉大数据引擎负责人杨秋吉在 DataFunSummit 2022 多维分析架构峰会上的演讲分享，分享的主题是《货拉拉基于 Apache Doris 的 OLAP 体系演进及建设办法》，具体解说了货拉拉从 OLAP1.0 到 3.0 的演进过程，其中不乏有值得借鉴的方法论以及粗浅的技术思考，心愿能对大家有所帮忙。
分享人 | 货拉拉大数据引擎负责人 杨秋吉
业务背景
货拉拉成立于 2013 年，成长于粤港澳大湾区，是一家从事同城、跨城货运、企业版物流服务、搬家、汽车销售及车后市场服务的互联网物流公司。截至 2022 年 4 月，货拉拉的业务范围曾经笼罩了国内 352 座城市，月活司机达到 58 万，月活用户达到 760 万，蕴含 8 条以上的业务线。
货拉拉大数据体系为撑持公司业务，当初曾经成立三个 IDC 集群、领有上千台规模的机器数量，存储量达到了 20PB、日均工作数达到了 20k 以上，并且还处在快速增长的过程中。
大数据体系
货拉拉大数据体系从下往上分为 5 层，最上面的是 根底层和接入层 ，这两层次要会提供根底数据的存储、计算以及集群的治理性能。在根底层和接入层之上是 平台层和数仓 。在平台层之中蕴含了数据研发平台和数据治理平台，基于平台层的能力和数据仓库的数据体系，在这之下面蕴含了含有业务属性的 服务层和应用层。整个体系自下而上相互支持，实现反对业务和赋能业务的能力。
图 1.1 货拉拉大数据体系
数据处理流
货拉拉典型的数据处理流，能够分成数据集成、采集、数据的存储计算、数据服务四局部，同时也蕴含了实时、离线以及在线三大业务场景。
图 1.2 货拉拉大数据数据流
在数据采集阶段会存在实时采集和离线采集两条路线。
- 实时采集比拟典型的场景为用户端上埋点会间接同步到大数据平台做存储，供后续的在线和离线计算应用。
- 离线的数据次要是来自于业务方的数据库，会通过天或者是小时定期采集到大数据存储中，以供后续应用。
两头是数据的存储和计算阶段。在离线场景中会通过对数据 ETL 之后转换为结构数仓的分层体系。实时比拟典型的场景为数据在通过 Flink 的解决后会间接落在线存储系统，相似于 HBase 和 OLAP 等等，为后续的业务零碎提供数据服务。
OLAP 演进概览
货拉拉从 2021 年开始进行 OLAP 的技术钻研，截至目前曾经经验 3 个阶段：
- 2021 年上半年为货拉拉的 OLAP1.0 阶段，这个阶段咱们次要是反对公司的罗盘业务，咱们引入的是可能提供较好的单表根据和查问能力的 Apache Druid 引擎。
- 2021 年下半年为货拉拉的 OLAP2.0 阶段，咱们反对了智能定位工具，这个阶段引入了够提供单表明细查问，并且还有较高的压缩率 ClickHouse。
- 往年为货拉拉的 OLAP3.0 阶段，随同着公司业务需要的一直增多，咱们也会须要用到多数据源的关联剖析。基于此，因为 Apache Doris 具备大表关联剖析的能力，咱们引入了 Apache Doris 引擎。
图 2.1 货拉拉 OLAP 体系演进过程
OLAP1.0 孕育期
业务需要剖析
先看下没有引入 OLAP 之前的业务数据流：
图 3.1 OLAP1.0 业务场景
依据该图能够看到业务的数据通过实时和离线解决之后会落在 MySQL，MySQL 之中贮存了维度聚合之后的后果数据，这也意味着会在 Flink 之中做大量的聚合剖析，依据业务须要的相应维度所做的一系列组合都是在 Flink 之中做实时聚合，最初将后果贮存到 MySQL。
存在的问题：
- 存在存储瓶颈，相似于 Kylin 之中的维度爆炸的问题。
- 开发成本、高效率低。当业务侧须要新增维度的时候会须要对 Flink 中的所有作业都做肯定的批改，而后再从新上线。
- 无奈反对局部聚合需要。
对于存在的这些问题，咱们通过剖析之后，总结出了 3 个背地存在的需要点：
- 业务侧心愿可能横向扩容，解决存储瓶颈。
- 心愿可能自由组合维度做剖析，晋升业务侧开发效率。
- 心愿可能反对任意维度实现跨度的剖析。
解决方案
依据业务需要，并通过调研，咱们决定应用 OLAP 引擎来反对业务需要。那咱们如何抉择一款 OLAP 引擎，并把它稳固的利用到生产之中呢？
咱们总结了如下的 4 个步骤作为解决思路：
图 3.2 OLAP 1.0 解决思路
技术调研
技术调研阶段，咱们比照了 Durid、ClickHouse、Kylin、Presto 和 Doris 等等引擎。联合咱们上述的 3 个业务需要，最终咱们抉择了 Druid 引擎。
起因是 Druid 除了可能满足咱们的业务需要之外，还有一个比拟重要的影响因素是 Druid 引擎是纯 Java 开发，与咱们的技术栈比拟吻合，可控性更高。
图 3.3 OLAP1.0 技术调研
POC 阶段
POC 过程中，从以下 3 个步骤着手：
- 性能验证。在性能验证中，咱们会收集业务侧的 SQL，之后提取 SQL Pattern，而后再依据 Druid 引擎的 Rollup 语义做 SQL 的改写，波及到大量 UDF 的改写、Rollup 语义兼容以及 Count Distinct 语义兼容等等。
- 性能验证。咱们会间接采纳业务实在的数据和业务实在的 SQL 来执行。验证过程中咱们会将 Cache 敞开，别离统计 P75、P90、P99 的查问耗时。在这过程中，咱们会发现有局部查问的性能没有达到要求，之后咱们会做性能剖析。Druid 引擎自身没有比较完善的性能剖析工具，不可能很好的打印出它的执行打算以及各个算子的耗时，所以咱们采纳了第三方的 Arthas 火焰图进行剖析。定位了相应的算子后，最终咱们通过优化咱们建表导数的逻辑以及索引构建的逻辑，并次要通过调整 Segment 大小的同时退出物化视图的办法，进行一些参数的调整以此来优化性能。
- 准确性验证。咱们将业务实在数据同时写 Hive 表和 Druid，之后跑 Hive SQL 和 Druid SQL，来进行数据品质的校对。在这个过程中咱们会发现例如 StringLast 函数等一些函数会在特定的场景下呈现计算值不稳固的问题。
图 3.4 OLAP1.0 POC 验证
稳定性保障
当 POC 验证实现之后，接下来咱们会进行稳定性的保障。咱们将 稳定性保障分为事先、事中、预先 3 个阶段：
图 3.5 OLAP1.0 稳定性保障
上线阶段
当稳定性保障建设实现之后就会进入到上线阶段。上线过程咱们同样分成了 3 个阶段：
- OLAP 测试阶段。在这个阶段中，业务的数据会接入到 Druid 之中，然而业务的实在查问还是通过原来的 MySQL 库。这个阶段次要会验证 Druid 引擎的数据品质和 Druid 集群的稳定性。
- 上线察看阶段。在这个阶段，业务的查问会切回到 Druid。同时旧的 MySQL 链路还没有下线，业务侧可能随时切回 MySQL 链路。
- OLAP 运行稳固阶段。咱们会把 MySQL 旧的链路下线，做资源的回收。
图 3.6 OLAP1.0 上生产
问题总结
上面总结了 1.0 阶段时遇到的问题：
- 数据导入局部中，实时数据乱序为典型问题。
- 在数据准确性验证阶段发现 StringLast 的函数值不稳固。
- Durid 没有一个高效的精准去重的函数。
图 3.7 OLAP1.0 问题总结
OLAP2.0 欠缺期
业务需要剖析
在 OLAP2.0 阶段次要有以下 4 个业务需要：
图 4.1 OLAP2.0 业务需要剖析
下图是简略的业务工具的截图，从图中能够看到，OLAP2.0 须要可能反对汇总与明细，同时基于这些能力可能做一个疾速的问题定位。
图 4.2 OLAP2.0 业务需要剖析骤去实现。
解决方案
图 4.3 OLAP2.0 技术调研
OLAP2.0 咱们引入了 CliclkHouse。ClickHouse 可能比拟好地反对简单的数据类型，同时因为业务侧是埋点数据，所以对于实时导入语义要求并没有那么高。
没有采纳 Druid 次要是有 2 个起因：
- Druid 对于简单的数据结构反对度并不是很好。
- Druid 尽管可能反对明细查问，然而 Druid 的明细查问和聚合查问得分成不同的表，这样就会额定的引入一系列的存储老本。
剩下的局部就是 POC、上生产的步骤，这两个步骤和 OLAP1.0 阶段比拟相似，所以在这里就不过多开展介绍。
OLAP3.0 成熟期
业务需要剖析
2022 年随着公司业务的倒退，更多的产品线对于多数据源关联场景下的在线剖析需要也会变得越来越迫切。比如说 AB 试验场景与实时数仓场景，这两个场景对于多表关联需要，尤其是大表的多表关联需要也变得越来越迫切。
图 5.1 OLAP3.0 需要剖析
举一个 AB 试验的例子。从下图能够看到，例子中是须要把 AB 试验的一个数据和前面相应的司机与用户的埋点数据关联到一起并做剖析。在这种状况下，咱们就会发现之前的两种工具都会存在一系列的弊病。
图 5.2 OLAP3.0 需要剖析
解决方案
技术调研
在技术调研阶段咱们察看了 Druid 和 ClickHouse。Druid 引擎能够反对一些维表的简略 Join，ClickHouse 则可能反对 Broadcast 这种基于内存的 Join，然而对于大数据量千万级甚至亿级的一些表的 Join 而言，ClickHouse 的性能体现不是很好。
图 5.3 OLAP3.0 技术调研
接下来咱们对 Doris 进行了调研，咱们发现 Doris 是可能反对小表的 Join，对大表的话也同样可能反对基于 Shuffle 的 Join，对于简单数据类型（Array、JSon）的反对，通过跟 Apache Doris 社区沟通，预计将在 2022 年 7 月份的新版本中公布。通过在多个维度和需要满足度上进行比照，咱们最终抉择了 Apache Doris，也是因为 Apache Doris 的 SQL 反对度十分的欠缺。
图 5.4 OLAP3.0 技术调研
POC 阶段
咱们除了援用业务实在的数据和场景做验证以外，还引入了 TPC-DS 的数据集做了验证。
在多表关联的场景下对单天数据进行查问，对 5 亿左右的数据量进行 Join，TP75 大略是 9 秒左右。在数据品质阶段咱们也是把 TPC- DS 的数据集以及业务实在数据集，别离在 Hive 和 Doris 外面做了双跑验证，发现两者都是可能齐全对得上的。
图 5.5 OLAP3.0 POC
稳定性保障
与之前一样仍然是从事前的容量评估和压测、事中的监控和定位来进行。
图 5.6 OLAP3.0 稳定性测试
上面是咱们的监控图，次要是对于 Compaction 相干的一些监控，感兴趣的同学能够看看。（文末 QA 环节有局部解说）
图 5.7 OLAP3.0 稳定性监控
问题总结
第一个问题是查问性能的优化。
业务侧的需要为 7 天的查问 RT 须要在 5 秒内实现，在优化前，咱们发现 7 天的查问 RT 是在 30 秒左右。对于这个问题，咱们的次要优化策略是把小表 Join 大表改成了大表 Join 小表，次要原理是因为 Doris 默认会应用右表的数据去构建一个 Hashtable。
还有相似下图中的状况：union all 是在子查问中，而后再和外层的另外一张大表做 Join 的查问形式。这种查问形式没有用到 Runtime Filter 的个性，因而咱们将 union all 提到子查问外，这样就可能用到 Runtime Filter，这应该是因为这里的条件下没有推下去所导致的。同时运行时采纳的 Bloom Filter 是能够将 HashKey 条件下推到大表 Scan 阶段做过滤。在通过对这两者优化之后便可能满足咱们的查问性能需求了。
图 5.8 OLAP3.0 问题 1
第二个问题是 UnhealthyTablet 不降落，并且在查问阶段会呈现 -230 的报错。
这个问题的场景是咱们在没有停 FIink 写工作的时候，对 BE 机器交替重启，重启完会呈现很多 UnhealthyTablet。通过咱们后续的剖析发现，其中一个起因次要是在 Coordinator BE 在做二阶段提交的时候比拟偶合，Coordinator BE 的二阶段提交 Commit 后，也就是大部分的正本是曾经 Commit 后且在 Publish 前，在这短短的工夫范畴内 BE 机器被重启，这也导致会呈现 Tablet 状态不统一的状况。同时因为咱们过后把参数调整的过大，导致了 Compaction 压力过大。
最初的解决办法：与 Aapache Doris 社区的同学通过互助排查，引入了社区 1.1.0 的 Patch，同时对相应的数据做了复原。
图 5.9 OLAP3.0 问题 2
参数优化
- 关上 Profile。Doris 对于查问的性能剖析具备十分好的 Profile 文件，这一点是十分赞的！咱们能够看到各个算子在每一个阶段查问耗时以及数据处理量，这方面相比于 Druid 来说是十分便捷的！
- 调大单个查问的内存限度，同时把 BE 上的执行个数由 1 个调整成为 8 个，并且减少了 Compaction 在单个磁盘下的数据量。对于 Stream Load，咱们把 Json 格局的最大的内存由 100 兆调整成为 150 兆，增大了 Rowset 内 Segment 的数量，并且开启了 SQL 级和 Partition 级的缓存。
图 5.10 OLAP3.0 参数优化
数据流
下图是应用 Doris 之后的数据流图：
图 5.11 OLAP3.0 数据流
数据流中，咱们在 Flink 中做的事件曾经很少了，通过数据简略的 ETL 后就能够把数据间接灌入到 Doris。通过 Doris 一系列的聚合计算、union 计算以及多表关联计算之后，业务侧就能够间接查问 Doris 来获取相干数据。
总结与思考
总结：咱们 OLAP 的引进次要还是从业务需要的角度登程来匹配适合的引擎，为业务精细化运维提供技术支持。在这之后，咱们也思考了一套较为欠缺的上线流程及稳定性保障计划，为业务的安稳运行提供能力保障。
思考：咱们认为很难有单个引擎可能富含各种场景。因而在技术选型时，须要针对于需要特点和引擎特点进行正当抉择。
后续布局
咱们心愿能够向 OLAP 平台化发展，通过实现自助化建模的同时在这方面做一些多引擎的路由，使其可能反对各类聚合、明细以及关联等场景。
图 6.1 后续布局 OLAP 平台化
除 OLAP 平台化之外，后续咱们的引擎演进打算从高效、稳固和内核演进三局部来进行。
图 6.2 后续布局 引擎演进
稳定性方面：对 Doris 还要持续深刻内核了解，提供肯定的二次开发。另外 Doris 社区的相干原理以及代码级别的教程数量非常丰盛，这也间接性升高了咱们深刻 Doris 原理的难度。
内核演进方面：咱们发现 Doris 根本可能笼罩 Druid 所有场景，因而后续打算以 Doris 引擎为主，Clickhous 引擎为辅，逐步将 Druid 的相干业务向 Doris 迁徙。
Q&A 环节
Q：方才讲到了后续要从 Druid 引擎迁徙到 Doris，要实现迁徙的老本有多大呢？
A：迁徙老本方面和咱们之前的老本是一样的。咱们上线的时候也会采纳以下形式：先把业务的数据同时往 Druid 和 Doris 之中写，写完之后的业务迁徙会波及一些 SQL 革新。因为 Doris 更加靠近 MySQL 的协定，比起 Druid SQL 会更加便捷，所以这部分的迁徙老本不是很大。
Q：方才介绍的第二个场景之中的监控图都看了哪些指标呢？
A: 对于监控图，咱们会比拟关注 Doris 的数据导入。而在数据导入局部，咱们最关注的就是 Compaction 的效率，是否有 Compaction 的沉积。咱们当初还是采纳的默认参数，也就是 Compaction 的分数就代表它的版本号，所以咱们监控的更多的是它的版本。对于这方面的监控，社区也曾经有了比较完善的相应技术计划，咱们也是参考了社区的技术计划来进行了监控的指标搭建。
Q：从指标上看，Doris 的实时服务在线查问性能怎么样？在数据导入状况下性能损耗能够从这些指标上看进去吗？
A：实时导入方面次要是从 Compaction 的效率来看。联合到咱们这边的业务场景，最多的一张表，单表一天也有 6 亿到 10 亿的数据量的导入，也是一张埋点。另外对于峰值，它的 QPS 也是能达到千到万的，所以导入这一块压力不是很大。
Q：SQL 缓存和分区缓存实际效果怎么样？
A：SQL 缓存方面成果还好，对于很多离线场景，尤其是首页这种查问的数据量而言。比方以昨天或者是过来一个小时之前的这种状况来说，SQL 缓存命中率会十分高。分区级缓存方面，咱们分区的工夫还是设的是小时级，这意味着如果这个查问外面波及到的一些分区在一个小时内没有数据更新的话，那么就会走 SQL 缓存；如果有更新的话就会走分区级缓存。总体来看成果还好，然而咱们这边命中比拟多的还是 SQL 级的缓存。
Q：Doris 的查问导入合并和缓存的 BE 节点的内存个别怎么调配？
A：缓存方面咱们调配的不大，还是采纳的偏默认的 1G 以内。导入方面咱们设计的是 parallel_fragment_exec_instance_num 这个参数，大略在 8G 左右。
Q：能够解释一下 OLAP3.0 的解决思路吗？
A：对于 OLAP3.0 方面来说，业务的次要诉求就是大表 Join。除此之外，还有一些相似于导入的进度统一等等。
在大表 Join 方面，咱们也比照了很多的引擎。Druid 这方面就是偏维表；Clickhouse 这方面还是偏基于内存方面的 Broadcast。正因如此，次要是基于大表 Join 的出发点，咱们抉择引入了在 Join 这方面能力更强的 Doris。
Q：Druid、ClickHouse 和 Doris 应该都是近实时的，就是 Near Real-time，他们的写入不是立即可见的，是这样吗？
A：是这样的。像 Doris 和 ClickHouse 之前的写入都是 Flink 间接去写，咱们也没有齐全做到来一条数据就写一条，都是一个微批次。一个批次最大能够达到 150 兆的数据沉积，写入一次的工夫距离也是到 10 秒左右，没有做到齐全的实时写入。
Q：不便走漏一下货拉拉目前 Doris 的集群的应用状况，比方机器的数量和数据量吗？
A：咱们的集群数量还不算很多，10 多台。
Q：对于 Doris 的运维方面，它的便捷性和 Druid、ClickHouse、Kylin、Presto 这些相比，有很好的扩展性吗？
A：咱们感觉是有的。第一个是在咱们 Druid 方面碰到了一个比拟大的痛点，就是它的角色特地多，有 6 种角色，所以须要部署的机器会十分多。另外一点是 Druid 的内部依赖也十分多，Druid 依赖于 HDFS、离线导入还须要有 Hadoop 集群。
第二个是 ClickhHouse 方面，咱们过后应用的版本对于 Zookeeper 也是有比拟大的依赖。另外，ClickHouse 也是偏伪分布式的，有点相似于数据库的一种分表。Doris 本身就只有 FE、BE，内部依赖会非常少，所以咱们从部署的角度同时思考到 Doris 的横向扩大方面，Doris 的扩缩容也可能做到自均衡，所以相比而言 Doris 会更好一些。
Q：在实时特色场景下，分钟级的数据更新对服务性能要求比拟高，能够用 Doris 吗？能达到 TP99 200 毫秒以下吗？
A：TP99 可能否达到 200 毫秒以下次要和你查问 SQL 相干。
例如咱们这边的很多波及到大表 Join 的查问，波及的分区数据量大略在 10 亿量别，业务侧对于查问性能要求是 5 秒以内，通过 Doris 是能够满足咱们需要的。如果是实时特色这种业务，是否能达到 200 毫秒可能须要通过一轮理论测试能力失去后果。
材料下载
关注公众号 「SelectDB」，后盾回复“ 货拉拉 ”！ 限时下载 完整版 PPT 材料！
退出社区
欢送酷爱开源的小伙伴退出 Apache Doris 社区，除了能够在 GitHub 上提 PR 或 Issue，也欢送大家积极参与到社区日常建设中来，比方：
加入社区 征文活动，进行技术解析、利用实际等文章产出；作为讲师参加 Doris 社区的线上线下流动；积极参与 Doris 社区用户群的发问与解答等。
最初，欢送更多的开源技术爱好者退出 Apache Doris 社区，携手成长，共建社区生态。
SelectDB 是一家开源技术公司，致力于为 Apache Doris 社区提供一个由全职工程师、产品经理和反对工程师组成的团队，凋敝开源社区生态，打造实时剖析型数据库畛域的国内工业界规范。基于 Apache Doris 研发的新一代云原生实时数仓 SelectDB，运行于多家云上，为用户和客户提供开箱即用的能力。
相干链接：
SelectDB 官方网站：
https://selectdb.com (We Are Coming Soon)
Apache Doris 官方网站：
http://doris.apache.org
Apache Doris Github：
https://github.com/apache/doris
Apache Doris 开发者邮件组：
dev@doris.apache.org
