【记录】实践场景

Apache Doris 在京东搜索实时 OLAP 探索与实践

https://doris.apache.org/zh-CN/blog/JD_OLAP/

在这里插入图片描述
通过对比开源的几款实时OLAP引擎，我们发现doris和clickhouse能够满足我们的需求，但是clickhouse的并发度太低是个潜在的风险，而且clickhouse的数据导入没有事务支持，无法实现exactly once语义，对标准sql的支持也是有限的。最终，我们选定doris作为聚合层，用于实时OLAP分析。对于流量数据，使用聚合模型建表；对于订单行，我们使用Uniq模型，保证同一个订单最终只会存储一条记录，从而达到订单行精准去重的目的。在flink处理时，我们也将之前的任务拆解，将反复加工的逻辑封装，每一次处理都生成新的topic流，明细层细分了不同粒度的实时流。

从 ClickHouse 到 Apache Doris，腾讯音乐内容库数据平台架构演进实践

升级前存在的问题：

数仓层：不支持部分列更新，当上游任一来源表产生延迟，均会造成大宽表延迟，进而导致数据时效性下降。
加速层：不同的标签跟指标特性不同、更新频率也各不相同。由于 ClickHouse 目前更擅长处理宽表场景，无区别将所有数据导入大宽表生成天的分区将造成存储资源的浪费，维护成本也将随之升高。
应用层：ClickHouse 采用的是计算和存储节点强耦合的架构，架构复杂，组件依赖严重，牵一发而动全身，容易出现集群稳定性问题，对于我们来说，同时维护 ClickHouse 和 Elasticsearch 两套引擎的连接与查询，成本和难度都比较高。

ClickHouse 由国外开源，交流具有一定的语言学习成本，遇到问题无法准确反馈、无法快速获得解决，与社区沟通上的阻塞也是促进我们进行架构升级的因素之一。

Apache Doris 的优势：

Doris 架构极简易用，部署只需两个进程，不依赖其他系统，运维简单；兼容 MySQL 协议，并且使用标准 SQL。
支持丰富的数据模型，可满足多种数据更新方式，支持部分列更新。
支持对 Hive、Iceberg、Hudi 等数据湖和 MySQL、Elasticsearch 等数据库的联邦查询分析。
导入方式多样，支持从 HDFS/S3 等远端存储批量导入，也支持读取 MySQL Binlog 以及订阅消息队列 Kafka 中的数据，还可以通过 Flink Connector 实时/批次同步数据源（MySQL,Oracle,PostgreSQL 等）到 Doris。
社区目前 Apache Doris 社区活跃、技术交流更多，SelectDB 针对社区有专职的技术支持团队，在使用过程中遇到问题均能快速得到响应解决。

同时我们也利用 Doris 的特性，解决了架构 1.0 中较为突出的问题。

数仓层：Apache Doris 的 Aggregate 数据模型可支持部分列实时更新，因此我们去掉了 DWM 集市层的构建，直接增量到 Doris / ES 中构建宽表，解决了架构 1.0 中上游数据更新延迟导致整个宽表延迟的问题，进而提升了数据的时效性。数据（指标、标签等）通过 Spark 统一离线加载到 Kafka 中，使用 Flink 将数据增量更新到 Doris 和 ES 中（利用 Flink 实现进一步的聚合，减轻了 Doris 和 ES 的更新压力）。
加速层：该层主要将大宽表拆为小宽表，根据更新频率配置不同的分区策略，减小数据冗余带来的存储压力，提高查询吞吐量。Doris 具备多表查询和联邦查询性能特性，可以利用多表关联特性实现组合查询。
应用层：DataSet 统一指向 Doris，Doris 支持外表查询，利用该特性可对 ES 引擎直接查询。