共计 6447 个字符，预计需要花费 17 分钟才能阅读完成。
福建纵腾网络有限公司（简称“纵腾团体”）成立于 2009 年，以“寰球跨境电商基础设施服务商”为企业定位，聚焦跨境仓储与物流，为寰球跨境电商商户、出口贸易企业、出海品牌商提供海内仓储、商业专线物流、定制化物流等一体化物流解决方案，旗下领有谷仓海内仓、云途物流、WORLDTECH 等知名品牌。
作者 | 纵腾团体数据技术架构师 张彬华
随着纵腾团体业务的疾速倒退，各产品线提出的数据需要越发严格，而晚期基于多套 CDH 大数据架构的技术栈和组件繁冗，开发和运维难度高、效率低，数据品质和时效难以保障，已无奈满足当下数据分析需要，重大影响相干工作的发展。因而，纵腾团体在 2022 年正式引入 Apache Doris，基于 Apache Doris 构建了新的流批一体数据架构，同时建设了以 Apache Doris 为外围的数据中台。 构建过程中对读写时效性、服务的稳定性及高并发读写等多方面进行了优化，在这一过程中咱们也积攒了诸多实践经验，在此总结分享给大家。
晚期架构
晚期数仓架构次要分为两套基于 CDH 的大数据集群，这两套架构用于不同产品线的数仓需要、数据大屏和 BI 报表等利用。
这两套架构为独立的数据管道，具备耦合度低，集群间互相独立等特点，便于精细化治理。但随着业务需要的一直变动，这样的特点也引发出许多新的问题。
遇到的问题
- 元数据和数据品质不足管控，数据品质无奈失去保障
- 不同业务数据独立存储保护导致数据孤岛，不利于数据整合
- 每个集群的机房散布不一，保护老本十分高
- 集群间的技术栈和组件较多且存在差异性，对对立开发运维和数据整合都极具挑战性
架构选型
为了解决晚期架构的痛点、更好满足日益严苛的数据需要，咱们心愿能有一款产品帮忙咱们疾速构建流批一体的数仓架构、构建数据中台服务。
咱们对传统数仓、实时数仓和数据湖进行了比照。从上图可知，传统数仓 能够撑持超 PB 级的海量数据，然而交互查问性能绝对差一些，偏离线场景，不满足咱们对数据实时性的要求；数据湖 能够撑持超海量的数据，反对数据更新，查问性能适中，然而数据湖近两年才开始利用，成熟度较低，应用危险较大；实时数仓 实用 PB 级数据存储，反对数据更新且查问性能十分好。联合咱们的要求，实时数仓与咱们的应用和需要场景都比拟贴合，因而咱们最终决定抉择实时数仓作为数据底座。
接着咱们对市面上较为风行的三款实时数仓：ClickHouse、Apache Druid、Apache Doris 进行了选型比照，比照图如下：
比照可知，Apache Doris 劣势显著、性价比更高，具备独立主从架构简略、运维更灵便便捷、丰盛的数据模型、优良的查问性能和周全的生态布局等诸多劣势，比照这三个产品，Apache Doris 最合乎咱们的选型要求。
新数据架构
新数据架构基于 Apache Doris 简化了数据采集、存储和计算的流程：
- 联合 DataHub 实现自研元数据采集和周期治理
- 通过 Seatunnel 集成 Flink Doris Connector 稍加革新实现全量加增量数据的一体化采集
- 简化存储媒介，对 ClickHouse、Kudu、HBase 等技术栈进行收敛，由 Apache Doris 进行流批数据的对立存储
- 以 Apache Doris 为外围数据底座，联合 Apache Kyuubi 的 JDBC 引擎直连查问（自研）和 Spark 引擎中的 Spark Doris Connector 进行 ETL 开发（原生），对立计算引擎治理、权限管控和对外服务。
基于上述几点进行了数据利用开发及对外提供数据服务，构建了数据中台。
数据中台
咱们以 Apache Doris 为外围底座创立了数据平台，外围性能包含：指标核心、元数据中心、根底配置核心、即席剖析和数据接口服务中心，其中指标核心和即席剖析的数据次要来源于 Aapche Doris，以后已上线几百个指标。
数仓建模
咱们联合 Apache Doris 的个性从新对数仓进行了建模，数仓分层与传统数仓相似，其中 ODS 数据为存量加增量一体的导入模式，同时为防止出现[随机查问后果问题]，ODS 层最终选用 Unique 数据模型，相比于 Aggregate 模型能够实现写时合并（Merge-on-Write），无效进步数据实时性，且 Aggregate 模型查问性能更靠近于 Duplicate 模型，对于 ODS 层是十分好的抉择。
DIM/DED/DWS/ADS 层次要选用 Aggregate 数据模型；Aggregate 数据模型提供的四种聚合形式能够在大部分场景下达到事倍功半的成果，帮忙咱们疾速应答不同的需要场景。
- SUM： 可能高效实现 PV 类指标计算，但对于 UV 类的指标须要思考预去重。
- MAX/MIN： 罕用于最大最小运单工夫节点类指标或包裹体积 / 分量最大最小值的指标计算。
- REPLACE_IF_NOT_NULL： 能够主动地过滤空值，十分便捷地实现仅记录最初一条数据，实用于大部分 DW 场景。
数据导入
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 版本进行利用，次要思考维度如下：
- 反对事务性插入语句性能
- 反对 Unique Key 模型下的 Upsert
- 反对 SQL 阻塞 List 性能，能够通过正则、哈希值匹配等形式避免某些 SQL 的执行
- 官网不反对跨两位版本号进行降级，而 0.15 为过后最新的 Release 版本，选用该版本利于前期版本升级
- 可通过资源标签的形式将一个 Apache Doris 集群中的 BE 节点划分为多个资源组，实现多租户和资源隔离
- 该版本提供了官网认可的 Flink-Doris-Connector/Spark-Doris-Connector/DataX Doriswriter 等插件，利于 ETL 流程建设
2、验证阶段
该阶段次要是为了 二次验证 官网文档中介绍的性能是否满足咱们的理论使用场景，比方生态扩大中的 Connector、表面联邦查问、各种 Load 形式、多租户隔离及物化视图等。
3、压测阶段
压测阶段首先进行数据生成，数据集选用的是 TPC-DS 数据，接着依据 Doris 的个性对 DDL 和 SQL 等规定进行对应调整，最初通过脚本将数据导入到 Apache Doris 存储中，再通过自动化脚本进行查问及导入压测，最终将压测后果输入到 MySQL 表中，量化为图表进行展现。下方为本阶段的根本配置及压测过程介绍：
– 硬件环境
- 内存：256G
- CPU：96C
- 硬盘：SSD 1.92T * 8
– 软件环境
- Apache Doris 版本：0.15-release/1.0-release（该阶段进行时，1.0-release 版本刚好公布）
- Apache Doris 集群：3 FE + 9 BE
- 零碎：CentOS Linux release 7.9.2009
– 数据集信息
咱们生成了 1T、5T、10T 的 TPC-DS 数据集，1T 的数据粗放有 30 亿数据量。
查问压测
压测过程中，最后应用 0.15-release 版本进行测试，刚巧 1.0-release 版本公布，后决定更换为 1.0-release 版本进行后续的压测。下图是基于 1T 的 TPC-DS 数据在等同硬件配置环境下和某商业 MPP 数据库的比照后果：
如图所示，Apache Doris 的查问压测性能优异，有着显著的性能劣势，作为开源产品可能达到这样的成果是十分优良也是非常不易的。
导入压测
- 导入形式：通过 DataX Doriswriter 以 StreamLoad 形式进行写入压测
- 数据起源：为防止因 Source 端起因影响写入时效，抉择 100 张雷同大表，即 100 个并发从内网 Hive 中导入（例如 tpcds-ds 的 store_sales_1t 表）
- 数据模型：选用 Unique 模型（模仿 ODS 层），同时为充分考虑 Compaction 性能及小文件场景，每张表设置 70 个 Tablet
经调整优化后，最大写入时效为 269 MB/S&680K ops/s，均匀写入时效 70 MB/S&180K ops/s，写入时效大幅晋升。
4、上线阶段
该阶段次要是确认 Apache Doris 上线须要的查看清单、预调参数、BE 资源组布局及用户权限的划分。
- 查看清单：包含但不限于 FE & BE 端口、网络查看及 Apache Doris 的一些功能性验证，例如读写是否失常等。
- 预调参数：确认优化后的 FE&BE 参数是否配置，是否开启
global enable_profile、动静分区以及数据盘保留地位是否有误等。 - BE 资源组：因为咱们须要通过 Apache Doris 的多租户个性对不同的用户进行资源隔离，所以须要提前布局好每个 BE 节点对应的资源组。
- 用户权限：对于不同的用户群体提前布局好权限范畴，比方分析师开发只须要
SELECT_PRIV权限，而 ETL 工程师须要SELECT_PRIV、LOAD_PRIV 和CREATE_PRIV权限。
5、宣导阶段
该阶段次要是输入后面各阶段的 TimeLine、总结以及上线后应用 Apache Doris 的注意事项阐明，比方咱们用到多租户隔离，那么 DDL 建表时则须要在 Properties 中显示指定各正本对应的资源组：
create table zt_table
......
properties("replication_allocation"="tag.location.group_a:1, tag.location.group_b:1, tag.location.group_c:1")6、运行阶段
Tablet 标准问题
问题形容： 上线运行一段时间后，随着越来越多的数据增长，集群每次重启后一周左右，读写就会开始变得越来越慢，直到无奈失常进行读写。
问题解决：
- 通过对生产和 UAT 环境的比照测试以及对数仓表的 Schema 的剖析，咱们发现有些表数据并不大，然而 Bucket 却设置的十分大。
- 联合
show data from database命令，咱们将整个集群所有表的 Bucket 信息列举进去，明确了大部分表的 Bucket 设置的不合理；而以后集群共 20T 左右数据，均匀 1T 数据近 10W 个 Tablet，这就会导致小文件过多，造成 FE 元数据负载过高，从而影响导入和查问性能。 - 定位起因后与社区小伙伴二次确认，并依据官网倡议将 Bucket 设置不合理的表全副调整，调整后集群逐渐复原读写失常。（行将公布的 Apache Dorie 1.2.2 版本将推出 Auto Bucket 动静分桶推算性能，能够依据历史数据和机器数目主动推算新建 Partition 的分桶个数，保障分桶数始终保持在正当范畴内，可无效解决上述问题）
问题小结：
- Tablet 数 = 分区数 桶数 正本数
- 1TB 数据的 Tablet 数量管制在 8000 个左右（三正本管制到 2.4W 左右）
- 倡议大表的单个 Tablet 存储数据大小在 1G-10G 区间，可避免过多的小文件产生
- 倡议百兆左右的维表 Tablet 数量管制在 3-5 个，保障肯定的并发数也不会产生过多的小文件
集群读写优化
问题形容： 1.1.3 release 版本中，高并发的同时进行 Stream Load、Broker Load、insert into 和查问时，读写会变得十分慢，如下图 11/01 19:00 并发上来后的 Txn Load 所示：
问题解决：
\1. 咱们进行了十几轮比照测验，论断如下：
-
- 写入速度与并发的增长成反比（但不会骤变，而是迟缓变动）
- 单表 Bucket（Tablet）设置过大会导致集群写入速度骤减；例如 A 库的 TA 表，设置 80 个 Bucket 时，启动相干 Flink Sink Job 就会导致集群整体写入速度迅速变慢，升高 Bucket（9~10 个）时写入恢复正常。
insert into select的 ETL 工作与 Stream Load 写入工作会进行资源抢占，同时并发运行会使整个集群读写变慢。
\2. 通过 be.INFO 发现，80 个 Bucket 表写入某个 Tablet 的 memsize/rows/flushsize/duration 数值比 10 个 Bucket 写入时的数值呈数倍之差，即 80 个 Bucket 表的数据写入时效无论 Memsize 还是 Flushsize 都十分小、但破费工夫却很长。
\3. 同时收集 Pstack 日志，通过剖析能够确定，Tcmalloc 在频繁地寻找 pageheap_lock，导致高频竞争锁从而升高了读写性能。
\4. 于是，进行如下参数调整：
缩小 doris_be 过程内存返回给 linux 零碎的频率，从而缩小 tcmalloc 频繁竞争锁的状况
tc_use_memory_min = 207374182400
tc_enable_aggressive_memory_decommit = false
tc_max_total_thread_cache_bytes=20737418240\5. 调参并滚动重启 BE 后，集群情况如下图所示：
18:50 前将 Broker Load、insert into 和查问工作同时开启，18:50 后将 Stream Load 工作也开启（包含 80 bucket 的表），集群整体的读写性能不仅没有降落，反而 Stream Load 时效冲破了压测阶段的最大值 269 MB/S&680K /ops/s，并且继续稳固。
问题小结：
应用 Apache 1.1.3 及以上版本，十分举荐调整 Tcmalloc 相干参数，缩小 doris_be 过程与零碎之间的内存申请回收过程，可显著缩小锁竞争的景象，大大晋升读写性能和集群稳定性。（从 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 以下劣势也是咱们疾速构建数据架构的重要推动力：
- 扩大表：联邦查问的设计，便于集成其它存储
- 数据表设计：丰盛的数据模型，可疾速应答不同的数据需要。
- 数据查问：不同的 Join 算子联合本身欠缺的优化器，让查问快而稳。
- 架构设计：架构清晰明了且运维简略，大大地升高了咱们的运维老本。
- 数据导入：各种 Load 形式及 Connector 的扩大，根本涵盖大部分的数据同步场景利用。
- 活跃度：社区高度沉闷，SelectDB 为 Apache Doris 社区组建了一支专职技术支持团队，疑难杂症根本能在 12H 内疾速响应并有社区小伙伴跟进和帮助解决。
将来布局
联合当下业务场景的思考，将来咱们将引入数据湖进行非结构化和结构化数据一体存储，进一步欠缺流批一体架构。同时也会将 Apache Doris 回归它最实质的定位，专一于 OLAP 剖析场景，并通过 Apache Doris 对立湖仓查问引擎层，施展其最大的效用。
最初，非常感谢 Apache Doris 社区和 SelectDB 团队的张家锋、曲率和杨勇强等小伙伴对咱们自私的技术支持，将来咱们也将继续参加 Apache Doris 社区建设中，奉献绵薄之力。祝 Apache Doris 社区和 SelectDB 越来越好，日臻完善！
