作者纵腾集团数据技术架构师 张彬华
随着纵腾集团业务的快速发展，各产品线提出的数据需求越发严格，而早期基于多套 CDH 大数据架构的技术栈和组件繁杂，开发和运维难度高、效率低，数据质量和时效难以保障，已无法满足当下数据分析需求，严重影响相关工作的开展。因此， 纵腾集团在 2022 年正式引入 Apache Doris ，基于 Apache Doris 构建了新的流批一体数据架构，同时建立了以 Apache Doris 为核心 的数据中台。 构建过程中对读写时效性、服务的稳定性及高并发读写等多方面进行了优化，在这一过程中我们也积累了诸多实践经验，在此总结分享给大家。
早期架构
早期数仓架构主要分为两套基于 CDH 的大数据集群，这两套架构用于不同产品线的数仓需求、数据大屏和 BI 报表等应用。
这两套架构为独立的数据管道，具有耦合度低，集群间相互独立等特点，便于精细化管理。但随着业务需求的不断变化，这样的特点也引发出许多新的问题。
遇到的问题
架构选型
为了解决早期架构的痛点、更好满足日益严苛的数据需求，我们希望能有一款产品帮助我们快速构建流批一体的数仓架构、构建数据中台服务。
我们对传统数仓、 实时数仓和数据湖进行了对比。从上图可知， 传统数仓 可以支撑超 PB 级的海量数据，但是交互查询性能相对差一些，偏离线场景，不满足我们对数据实时性的要求； 数据湖 可以支撑超海量的数据，支持数据更新，查询性能适中，但是数据湖近两年才开始应用，成熟度较低，使用风险较大； 实时数仓 适用 PB 级数据存储，支持数据更新且查询性能非常好。结合我们的要求， 实时数仓与我们的使用和需求场景都比较贴合，因此我们最终决定选择实时数仓作为数据底座。
接着我们对市面上较为流行的三款实时数仓：ClickHouse、Apache Druid、Apache Doris 进行了选型对比，对比图如下：
对比可知，Apache Doris 优势明显、性价比更高，具有独立主从架构简单、运维更灵活便捷、丰富的数据模型、优秀的查询性能和周全的生态规划等诸多优势，对比这三个产品，Apache Doris 最符合我们的选型要求。
新数据架构
新数据架构基于 Apache Doris 简化了数据采集、存储和计算的流程：
基于上述几点进行了数据应用开发及对外提供数据服务，构建了数据中台。
数据中台
数仓建模
我们结合 Apache Doris 的特性重新对数仓进行了建模，数仓分层与传统数仓类似，其中 ODS 数据为存量加增量一体的导入模式，同时为防止出现[随机查询结果问题]， ODS 层最终选用 Unique 数据模型 ，相比于 Aggregate 模型可以实现写时合并（Merge-on-Write），有效提高数据实时性，且 Aggregate 模型查询性能更接近于 Duplicate 模型，对于 ODS 层是非常好的选择。
DIM/DED/DWS/ADS 层主要选用 Aggregate 数据模型 ；Aggregate 数据模型提供的四种聚合方式可以在大部分场景下达到事半功倍的效果，帮助我们快速应对不同的需求场景。
数据导入
ODS 层的数据导入目前主要以 Stream Load 为主 ，在 HDFS 上的历史存量数据也会通过 Broker Load 或 Spark Load 导入。 DW 层数据主要以 insert into 方式导入 ，同时为减轻 Doris 内存压力，我们将部分 ETL 任务放到 Kyuubi On Spark 引擎上去计算，目前在 DolphinScheduler 每天平稳调度 Doris DW 任务有上万个，其中大部分为 T+1 任务，小部分为小时级任务。
实践经验
对于以 Apache Doris 为核心的新数据架构，我们规划了 6 个阶段进行运行测试，直至可以上线运行。（重点关注压测阶段和运行阶段，有一些调试优化经验分享给大家）
1、准备阶段
引入 Apache Doris 时是 2022 年 2 月，因此选择当时最新版本 Apache Doris 0.15 Release 版本进行应用，主要考虑维度如下：
2、验证阶段
该阶段主要是为了 二次验证 官方文档中介绍的功能是否满足我们的实际运用场景，比如生态扩展中的 Connector、外表联邦查询、各种 Load 方式、多租户隔离及物化视图等。
3、压测阶段
压测阶段首先进行数据生成，数据集选用的是 TPC-DS 数据，接着根据 Doris 的特性对 DDL 和 SQL 等规则进行对应调整，最后通过脚本将数据导入到 Apache Doris 存储中，再通过自动化脚本进行查询及导入压测，最终将压测结果输出到 MySQL 表中，量化为图表进行展示。 下方为本阶段的基本配置及压测过程介绍：
- 硬件环境
- 软件环境
- 数据集信息
我们生成了 1T、5T、10T 的 TPC-DS 数据集，1T 的数据集约有 30 亿数据量。
查询压测
压测过程中，最初使用 0.15-release 版本进行测试，正巧 1.0-release 版本发布，后决定更换为 1.0-release 版本进行后续的压测。下图是基于 1T 的 TPC-DS 数据在同等硬件配置环境下和某商业 MPP 数据库的对比结果：
如图所示，Apache Doris 的查询压测性能优异，有着明显的性能优势， 作为开源产品能够达到这样的效果是非常优秀也是十分不易的 。
导入压测
经调整优化后， 最大写入时效为 269 MB/S&680K ops/s，平均写入时效 70 MB/S&180K ops/s，写入时效大幅提升 。
4、上线阶段
该阶段主要是确认 Apache Doris 上线需要的检查清单、预调参数、BE 资源组规划及用户权限的划分。
5、宣导阶段
该阶段主要是输出前面各阶段的 TimeLine、总结以及上线后使用 Apache Doris 的注意事项说明，比如我们用到多租户隔离，那么 DDL 建表时则需要在 Properties 中显示指定各副本对应的资源组：
create table zt_tableproperties("replication_allocation"="tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1"6、运行阶段
Tablet 规范问题
问题描述： 上线运行一段时间后，随着越来越多的数据增长，集群每次重启后一周左右，读写就会开始变得越来越慢，直到无法正常进行读写。
问题处理：
问题小结：
集群读写优化
问题描述： 1.1.3 release 版本中，高并发的同时进行 Stream Load、Broker Load、insert into 和查询时，读写会变得非常慢，如下图 11/01 19:00 并发上来后的 Txn Load 所示：
问题处理：
减少doris_be进程内存返回给linux系统的频率，从而减少tcmalloc频繁竞争锁的情况tc_use_memory_min = 207374182400tc_enable_aggressive_memory_decommit = falsetc_max_total_thread_cache_bytes=2073741824018:50 前将 Broker Load、insert into 和查询任务同时开启，18:50 后将 Stream Load 任务也开启（包括 80 bucket 的表），集群整体的读写性能不仅没有下降，反而 Stream Load 时效突破了压测阶段的最大值 269 MB/S&680K /ops/s ，并且持续稳定。
问题小结：
使用 Apache 1.1.3 及以上版本，非常推荐调整 Tcmalloc 相关参数，减少进程与系统之间的内存申请回收过程，可明显减少锁竞争的现象，大大提升读写性能和集群稳定性。（从 Apache Doris 1.1.5 版本开始，
增加了 Tcmalloc 简化配置
，可将众多 Tcmalloc 参数归约到参数
memory_mode
中，compact 为节约内存模式，performance 为性能模式，用户可根据实际需求进行调整）
总结收益
当前 Apache Doris 的生产集群为 3 FE + 9 BE 组合， 已导入集团存量和增量数据的 60%以及部分 DW 数据生成，3 副本共占 44.4TB 的存储。
依赖 Apache Doris 自身优异特性及其生态圈帮助我们快速构建了一套新的流批一体数据架构，平均每天实时入库的 数据量达到上亿规模 ，同时支持 上万个 * *调度任务 平稳运行，相比早期架构单表 查询效率提升近 5 倍 ，数据导入效率 提升近 2 倍**，内存资源使用率显著减少。除此之外，Apache Doris 以下优势也是我们快速构建数据架构的重要推动力：
未来规划
结合当下业务场景的考虑，未来我们将引入数据湖进行非结构化和结构化数据一体存储，进一步完善流批一体架构。同时也会将 Apache Doris 回归它最本质的定位，专注于 OLAP 分析场景，并通过 Apache Doris 统一湖仓查询引擎层，发挥其最大的功效。
最后，非常感谢 Apache Doris 社区和 SelectDB 团队的张家锋、曲率和杨勇强等小伙伴对我们无私的技术支持，未来我们也将持续参与 Apache Doris 社区建设中，贡献绵薄之力。祝 Apache Doris 社区和 SelectDB 越来越好，日臻完善！
