业务背景
橙联股份是一家服务寰球跨境电商的科技公司，致力于通过市场剖析、零碎研发及资源整合，为客户提供物流、金融、大数据等多方面的服务产品，为寰球跨境电商提供高品质、全方位的服务解决方案。
随着公司业务的倒退和数据的一直增长，晚期基于 MySQL 的传统数仓架构曾经无奈应答公司数据的快速增长。业务的需要和经营的决策对于数据时效性的要求越来越高，对数仓准实时能力的需要越发强烈。
为了适应疾速的增长需要，橙联于 2022 年正式引入 Apache Doris，以 Apache Doris 为外围构建了新的数仓架构，构建过程中对服务稳定性、查问稳定性、数据同步等多方面进行了优化，同时建设了以 Apache Doris 为外围的数据中台，在这一过程中积攒了诸多应用及优化教训，在此分享给大家。
数仓架构演进
晚期数仓架构
公司在成⽴初期业务量不⼤，数据团队规模⽐较⼩，对数据的需要仅局限于大量 T + 1 定制化报表需要。因而，晚期数仓架构非常简略，如下图所示，间接应用 MySQL 构建数仓集市层，应用数仓集市层的数据进行报表开发，基于商业化的报表平台向需求方提供 T + 1 的数据报表服务。
存在的问题
- 随着公司业务规模扩充、数据量激增以及对数据时效性要求一直进步，使⽤ MySQL 进⾏数据分析越来越不能满⾜业务⽅的要求。
- 没有对数仓进⾏分层划域，烟囱式的开发模式数据复⽤性很差，开发成本⾼，业务⽅提出的需要不能疾速失去响应。对数据的品质和元数据的治理不足管控。
新数仓架构
为了解决旧架构日益凸显的问题，适应快速增长的数据和业务需要，往年正式引入 Apache Doris 构建新的数仓架构。
抉择 Apache Doris 的起因：
易⽤性 – 在以后利用场景下，引入新技术，将面临大量报表迁徙问题，因而必须要思考的产品易用性问题，而 Apache Doris 在学习老本、报表迁徙老本、服务运维老本上有着十分优良的体现，具体包含：
- 采⽤ MySQL 协定和语法，⽀持规范 SQL，能够通过各类客户端⼯具来拜访 Doris，可能与 BI ⼯具⽆缝对接。
- ⽀持多表 Join，针对不同场景的 Join 提供了多种优化⽅案。
- ⽣态扩大欠缺，离线数据的⾼效批量导⼊、流式数据的低提早实时导⼊都有很好的⽀持。
- 相较于业界其余热⻔ OLAP 数据库，Doris 的分布式架构⾮常简洁，只有 FE、BE 两个过程，运⾏不依赖任何第三⽅零碎。
- ⽀持弹性伸缩，对于部署、运维⾮常敌对。
性能 – 以后报表存在大量降耦聚合操作，对多表关联的查问性能和实时查问的时效性有着非常高的要求，而 Apache Doris 基于 MPP 架构实现，并自带了⾼效的列式存储引擎，能够反对：
- 数据的预聚合以及预聚合后果的⾃动更新。
- 数据的实时更新。
- ⾼并发查问。
基于以上的起因，最终抉择了以 Apache Doris 为外围构建新的数仓。
架构介绍
Apache Doris 的数仓架构非常简洁，不依赖 Hadoop 生态组件，构建及运维老本较低。
如以上架构图所示，咱们的数据源共有 4 种，业务数据 MySQL、文件系统 CSV、埋点数据和第三方零碎 API；针对不同的需要，应用了不同的数据导入形式，文件数据导入应用 Doris Stream Load，离线数据应用 DataX doriswriter 进行数据初始化，实时增量数据应用 Flink CDC + Flink Doris Connector 的形式进行数据同步；数据存储和计算层应用了 Doris，在分层设计上采纳 ODS(Operation Data Store 数据筹备区，也称为贴源层)、明细层 DWD、中间层 DWM、服务层 DWS、应用层 ADS 的分层思维，ODS 之后的分层数据通过 DolphinScheduler 调度 Doris SQL 进行增量和全量的数据更新。最终下层数据利用应用自研的一站式数据服务平台，能够和 Apache Doris 无缝对接，提供自助报表、自助取数、数据大屏、用户行为剖析的数据应用服务。
基于 Apache Doris 的数仓架构计划可同时反对离线和准实时利用场景，准实时的 Apache Doris 数仓能够笼罩 80% 以上的业务场景。这套架构大大降低了研发老本，进步了开发效率。
当然在架构构建过程中也遇到一些问题和挑战，咱们针对问题进行了相应的优化。
Apache Doris 构建数仓优化计划
在数仓的应用过程中，次要遇到三方面问题。首先是服务稳定性问题，其次是查问速度逐步变慢的问题，最初是 Doris 数据同步和 Doris SQL 调度问题。具体体现在以下：
服务稳定性
优化前
在 Apache Doris 应用初期，FE 和 BE 的部署形式如下：
- FE 负责元数据的治理、用户申请接入、查问的解析布局，资源占用较低，因而将 FE 和其余大数据组件混合部署 FE*3。
- BE 负责数据存储、计算、查问打算的执行，资源占用较大，因而 BE 进行独立部署且调配了较多的资源 BE（16C 128G 4T1） 7。
基于以上形式部署，应用初期运行的稳定性还不错。然而在应用了一段时间之后，这种部署形式裸露的问题就越来越显著。
存在的问题
- 首先，FE 混合部署存在资源竞争。其余组件与 FE 服务竞争资源，导致 FE 资源有余，服务运行稳定性不好。具体问题体现在：每当机器资源使用率打满，就会导致 FE 节点无奈连贯，长时间获取不到心跳而被 FE 集群断定为离线。
- 其次，BE 单磁盘存在 Compaction 效率低的问题。初期，咱们在部署 BE 时，每个节点只调配了 1 块 4T 的磁盘，尽管磁盘的空间并不小，然而磁盘的数量比拟少，Compaction 线程数只有 2，Compaction 效率很低，这是导致 BE Compaction Score 不衰弱的起因之⼀。
- Compaction 配置参数
compaction_task_num_per_disk每个磁盘上的工作数，默认为 2
max_compaction_threads Compaction线程的总数，默认为 10
total_permits_for_compaction_score Compaction工作配额，默认 10000
Compaction 工作机制：Apache Doris 的数据写⼊模型使⽤了与 LSM-Tree 相似的数据结构。数据以追加（Append）的⽅式写⼊磁盘，在读逻辑中，须要通过 Merge-on-Read 合并解决写入的数据。Merge-on-Read 会影响读取的效率，为了升高数据读取时须要合并的数据量，使⽤ LSM-Tree 的零碎会引⼊后盾数据合并逻辑，以⼀定策略定期的对数据进⾏合并。
优化后
为了解决以上的问题，对部署形式进行了优化以晋升服务的稳定性：
- FE 进行独⽴部署，防止了 FE 混合部署资源竞争问题
- BE 进行磁盘拆分，多磁盘部署，从原来一块 4T 磁盘变更为 5 块 1T 磁盘，使 BE Compaction 线程数晋升 5 倍，Compaction 效率、磁盘 I/O 带宽也失去了晋升
- 减少客户端连贯代理层 ProxySQL，对 FE 连贯进⾏负载平衡，解决 FE 连贯单点问题
- 减少 Supervisor 对 FE、BE 服务过程状态监控，FE、BE 过程意外宕机能够疾速复原
通过以上对部署的优化，Apache Doris 服务的稳定性有了很大的晋升，根本能够满足目前对稳定性的需要。
查问稳定性
初期刚部署时，无论进行数据导入还是数据查问，执行起来都比拟顺畅。但随着承载的表和数据导入作业数量一直增多，查问稳定性问题逐步裸露进去。
优化前
存在的问题
随着应用工夫和数据量的减少，集群开始频繁呈现不可用的问题，次要体现在以下几个方面：
- DDL 操作很难执行，查问速度变得比拟迟缓
- FE 服务频繁呈现 OOM 宕机，有时候甚至呈现无奈连贯的状况
下图是生产环境某张表的体积的大小和 Tablet 数量的状况。这张表的体积只有 275M，然而 Tablet 的数量却达到了 7410，这十分不合理。进一步排查确认整个集群 Tablet 数量十分宏大，集群只有 5T 的数据量，然而 Tablet 数量达到 150 万。
最后咱们对 Apache Doris 表数据量大小、分区粒度、Bucket 数量、Tablet 数量的关系及 Tablet 数量对集群的影响没有清晰的概念。开发人员在 Apache Doris 应用中更多的是谋求查问速度，将大部分的动静分区表的分区粒度设置的比拟小，分区 Bucket 数量设置却比拟大。
通过与 Apache Doris 社区小伙伴的沟通交流，理解到 Tablet 数量过大可能会导致元数据管理和运维压力增大，呈现查问速度迟缓、FE 不稳固的问题。
优化计划
首先明确 Tablet 数量的计算形式，Tablet 数量 = 分区数量 Bucket 数量 正本数。联合以后理论应用状况，确认能够在分区粒度和 Bucket 数量上进⾏优化。咱们将分区的粒度从按天、按周分区更改为按月分区，Bucket 数量依照数据体积大小进行正当的配置。如下图所示，是倡议数据体积大小对应的 Bucket 数量设定。
本次的优化指标是将 Tablet 数量从 150 万升高到 15 万，同时咱们也对将来的增长速度进行了布局，在三正本状况下，冀望 Tablet 数量增长速度是 30000/TB。
优化后
实际上，在仅对 ODS 表进⾏了分区粒度和 Bucket 数量调整后，集群 Tablet 数量从 150 万降落到了 50 万，效果显著。
优化前的 FE
下图是 FE JVM Heap Stat 的监控状况，每当 FE 执行 Checkpoint 时，元数据就会在内存中复制一份。体现在 FE JVM Heap Stat 上就是造成一个个的波峰。优化之前 FE 对内存占用简直继续在 90% 以上，而且每一个波峰都十分的尖利。
优化后的 FE
优化后，FE 堆内存占用显著降落，波峰也变得很平缓。FE 的稳定性失去了比拟显著的晋升。
优化前、后的 BE
BE Compaction Score 监控反映版本的沉积状况，版本沉积的数值在 100 内属于失常范畴，超过 100 阐明集群可能存在潜在危险。上文也讲到，查问时须要先进行文件合并，再进行数据查问，如果 Tablet 版本过多，版本合并会影响到查问的速度和稳定性。
通过磁盘的部署优化和 Tablet 优化后，BE Compaction Score 能够稳固在 50 以内，查问的稳定性和性能都失去了十分大的晋升。
数据同步优化
优化前：
MySQL 数据同步应用 Flink CDC -> Kafka -> Flink Doris Connector -> Doris 的形式全量 + 增量进入 Apache Doris。
在这个计划中，尽管 Flink CDC 反对全量历史数据的初始化，但因为历史遗留问题，局部表数据量较大，单表有几亿数据，而且这种表大多是没有设置任何分区和索引，在执行简略的 COUNT 查问时都须要破费十几分钟的工夫。
其次，Flink CDC 尽管能够进行增量数据同步，但对于这类表的全量数据初始化简直是不能实现的，因为 Flink CDC 做全量同步要先读取全量数据，而后对数据分块，再做数据同步，这种状况下，读取是十分十分迟缓的。
优化后
针对这种状况，在数据同步上，咱们做了以下优化：
全量同步应用 MySQL Dump -> CSV -> Doris Stream Load -> Doris
增量同步应用 Flink CDC -> Kafka -> Flink Doris Connector -> Doris
数据调度优化
咱们在应用 DolphinScheduler 进行 Doris SQL 的任务调度时，同一 node 下配置多条 SQL 时会呈现 node 执行状态异样的状况，导致工作流 DAG 的 node 依赖生效，前一个节点未执行完，后一个节点就开始执行，后果会有缺数据甚至没有数据的状况。这个问题是因为 DolphinScheduler 2.x 在同一个 node 下不反对按程序执行 MySQL 的多段 SQL，而 Doris 在 DolphinScheduler 中应用 MySQL 数据源创立连贯。
此问题在 DolphinScheduler 3.0.0 版本被修复，配置中能够设置多段 SQL 的分隔符，解决了 DAG 依赖关系生效的问题。
Apache Doris 元数据管理和数据血统实现计划
在没有元数据管理和数据血统之前，咱们常常会遇到一些问题，比方想找一个指标，却不晓得指标在哪张表，只能找相干开发人员来确认，当然也存在开发人员遗记指标的地位和逻辑的状况。因而只能通过层层筛选确认，此过程非常消耗工夫。
之前咱们将表的分层划域、指标口径、负责人等信息放在 Excel 表中，这种保护形式很难保障其完整性，保护起来也比拟艰难。当须要对数仓进行优化时，无奈确认哪些表是能够复用的、哪些表是能够合并的。当须要对表构造进行变更时，或者须要对指标的逻辑进行批改时，也无奈确定变更是否会对上游的报表产生影响。
在以上问题背景下，咱们常常受到用户的投诉，接下来介绍如何通过元数据管理和数据血统剖析计划来解决这些问题。
实现计划
元数据管理和数据血统是围绕 Apache Doris 开展，同时对 DolphinScheduler 的元数据进行了整合。
咱们将元数据分为物理元数据和业务元数据两大类：
- 物理元数据保护表的属性信息和调度信息
- 业务元数据保护数据在利用过程中约定的口径和标准信息
数据血统实现了表级血统和字段级血统：
- 表级血统反对粗粒度表关系和跨层援用剖析
- 字段级血统反对细粒度的影响剖析
上图中，右侧表格是物理元数据业务，元数据指标和血统剖析可能提供的数据服务。
接下来，一起看下元数据管理和数据血统的架构和工作原理。
架构介绍
元数据管理和数据血统实现计划技术栈
数据采集：应用 Apache Doris 提供的审计日志插件 Doris Audit Plugin 进行数据采集
数据存储：对审计日志插件做了定制化开发，应用 Kafka 存储 Doris 审计日志数据
血统解析：应用 Druid 进行 Doris SQL 解析
血缘关系存储：应用 Nebula Graph 存储血缘关系数据
业务元数据：因为业务元数据常常产生 CRUD，因而应用 MySQL 存储业务元数据信息
搜寻数据：应用 ElasticSearch 存储血缘关系查问索引以及表和字段的搜寻索引数据
接下来介绍一下个架构四个组成部分：审计日志的采集和荡涤服务、血统解析服务、元数据信息整合服务、利用接口服务。
Apache Doris 审计日志的采集 / 荡涤服务
思考到如果将数据荡涤逻辑放在审计日志插件中，当数据荡涤逻辑产生变更，可能会呈现数据脱漏，这样会对血统剖析和元数据管理产生影响，所以咱们将审计日志插件数据采集和数据荡涤进行理解耦，对 Apache Doris 的审计日志插件进行了革新，革新后审计日志插件能够实现审计日志数据的格式化以及将数据发送到 Kafka 的性能。
数据荡涤服务，首先在荡涤逻辑中减少数据重排逻辑，针对多个审计日志插件发送的数据进行从新排序，解决数据乱序的问题。其次把非标准 SQL 转化成规范 SQL，尽管 Apache Doris 反对 MySQL 协定以及规范 SQL 语法，但有一些建表语句、SQL 查问语法与规范 SQL 存在肯定差别，因而将非标准 SQL 转化为 MySQL 的规范语句，最初将数据发送到 ES 和 Kafka 中。
血统解析服务
血统解析服务应用 Druid 进行 Doris SQL 的解析，通过 Druid 形象语法树逐层递归获取表和字段的血缘关系，最初将血缘关系数据封装发送到图数据库、血统查问索引发送到 ES。进行血统解析的同时会将物理元数据和业务元数据发送到对应存储地位。
元数据信息整合服务
元数据信息整合服务借鉴了 Metacat 的架构实现计划。
Connector Manager 负责创立 Apache Doris 和 DolphinScheduler 的元数据链接，同时也反对后续其余类型数据源接入的扩大。
Meta Service 负责元数据信息获取的具体实现。Apache Doris 元数据信息次要从 information Schema 库、Restful API、以及 SHOW SQL 的查问后果三种路径来获取。DolphinScheduler 的工作流元数据信息和调度记录信息从 DolphinScheduler 元数据库获取。
利用接口服务
咱们提供了 3 种类型的利用接口服务，别离是血统利用接口服务、元数据利用接口服务和数据行为剖析利用接口服务。
- 血统利用接口服务提供表、字段、血缘关系、影响剖析的查问服务。
- 元数据利用接口服务提供元数据的查问和字段搜寻的服务。
- 数据行为剖析利用接口服务提供表构造变更记录、数据读写记录、产出信息的查问服务。
以上就是元数据管理和数据血统剖析架构的整体计划的全部内容介绍。
总结及收益
往年咱们实现了以 Apache Doris 为外围的准实时数仓建设，Apache Doris 通过半年的应用和优化，当初曾经趋于稳定，可能满足咱们生产的要求。
- 新的准实时数仓，对数据计算效率、数据时效的晋升是微小的。
以 On Time Delivery 业务场景报表计算为例，计算 1000w 单轨迹节点时效变动，应用 Apache Doris 之前 须要计算 2 个多小时，并且计算耗费的资源十分大，只能在闲暇时段进行错峰计算；应用 Apache Doris 之后，只须要 3min 就能够实现计算，之前每周更新一次的全链路物流时效报表，当初能够做到每 10 分钟更新最新的数据，达到了准实时的数据时效。
- 得益于 Apache Doris 的标准化 SQL，上手难度小，学习成本低，报表的迁徙工作全员都能够参加。
原来 报表应用 PowerBI 进行开发，须要对 PowerBI 有十分深刻的理解，学习老本很高，开发周期也很长，而且 PowerBI 不应用规范 SQL，代码可读性差；当初 基于 Doris SQL 加上自研的利落拽模式的报表平台，报表的开发成本直线降落，大部分需要的开发周期从周降落到了天。
将来布局
后续咱们也将持续推动基于 Apache Doris 的数据中台建设，对元数据管理的欠缺、数据血统的解析率继续进行优化，思考到数据血统是大家都渴望的利用，在将来血统解析成熟后，咱们会思考将其奉献给社区。
与此同时，咱们正在着手进行用户行为剖析平台的构建，也在思考应用 Apache Doris 作为外围的存储和计算引擎。目前 Apache Doris 在局部剖析场景反对的函数还不够丰盛，例如在有序窗口漏斗剖析场景，尽管 Apache Doris 曾经反对了 window_funnel 函数，然而每层漏斗转化的计算须要用到的 Array 相干计算函数还没有失去很好的反对。不过好在行将公布的 Apache Doris 1.2 版本将蕴含了 Array 类型以及相干函数，置信将来在越来越多的剖析场景中 Apache Doris 都将失去落地。
作者介绍
付帅，橙联（中国）有限公司数字化团队，大数据研发经理，负责数字化团队数据中台的研发以及 OLAP 引擎的利用落地及性能优化。