共计 6643 个字符，预计需要花费 17 分钟才能阅读完成。
导读：同程数科成立于 2015 年，是同程团体旗下的游览产业金融服务平台。2020 年，同程数科基于 Apache Doris 丰盛的数据接入形式、优异的并行运算能力、极简运维等个性，引入 Apache Doris 进行数仓架构 2.0 的搭建。本文具体讲述了架构 1.0 到 2.0 的演进过程及 Doris 的利用实际，心愿对大家有所帮忙。
作者 | 同程数科大数据高级工程师 王星
业务背景
业务介绍
同程数科是同程团体旗下的游览产业金融服务平台，前身是同程金服，正式成立于 2015 年。同程数科以“数字科技引领游览产业”为愿景，保持以科技的力量，赋能我国游览产业。
目前，同程数科的业务涵盖产业金融服务、生产金融服务、金融科技及数字科技等板块，累计服务笼罩超过千万用户和 76 座城市。
图 1.1 业务场景 - 业务介绍
业务需要
次要蕴含四大类：
- 看板类：次要包含业务实时驾驶舱以及 T+1 业务看板等。
- 预警类：次要包含风控熔断、资金异样以及流量监控等。
- 剖析类：次要包含及时性数据查问剖析以及长期取数等。
- 财务类：次要包含清理以及领取对账需要。
图 1.2 业务场景 - 业务需要
综合以上业务需要，咱们进行了零碎架构建设。
架构演进之 1.0
工作流程
图 2.1 架构演变 - 架构 1.0
架构 1.0 是前几年十分风行的以 SteamSets 和 Apache Kudu 为外围的第一代架构。
该架构通过 StreamSets 进行数据库 Binlog 采集后实时写入 Apache Kudu 中，最初通过 Apache Impala 和可视化工具进行查问和应用。这个过程存在架构链路较长以及 SteamSets 对局部配置复用性体现欠佳的问题，另外 Apache Kudu 的多表关联与大表关联存在肯定的性能瓶颈，且对 IO 方面要求较高。
图 2.1 下半局部中实时计算流程的利用与上半局部较为相近，在实时计算中，埋点数据发送到 Kafka 后会通过 Flink 进行实时计算，并将计算结果数据落入剖析库与 Hive 库中用于数仓关联。
劣势与有余
图 2.2 架构演变 长处与毛病
劣势：
- 架构 1.0 抉择了 CDH 全家桶。CDH 提供了泛滥大数据组件，能够互相集成并投入使用，同时其配置绝对灵便。
- 应用的 SteamSets 反对可视化利落式与配置式的开发方式，因而开发人员对 SteamSets 的承受程度较高。。
有余：
- 组件引入过多，保护老本随之减少；当数据呈现问题时，排查与修复链路绝对较长。
- 多种技术架构和过长的开发链路，进步了数仓人员的学习老本与要求，数仓人员须要在不同中央转换后再进行开发，导致开发流程不顺畅、开发效率升高。
- Apache Kudu 在大表关联 Join 方面性能差强人意。
- 因为架构应用 CDH 构建，离线集群和实时集群未进行拆散，造成资源相互竞争；离线跑批的过程中对 IO 或磁盘耗费较大，无奈保障实时数据的及时性。
- 尽管 SteamSets 装备了预警能力，但作业恢复能力仍绝对欠缺。配置多个工作时对 JVM 的耗费较大，导致复原速度较慢。
架构演进之 2.0
工作流程
因为架构 1.0 的有余远多于长处，在 2020 年，咱们调研了市面许多进行实时开发的组件，发现了 Apache Doris，通过调研比照，最终决定将 Apache Doris 引入了架构 2.0。
图 3.1 架构演变 - 架构 2.0
引入 Apache Doris 后，对整体架构进行了以下革新：
- 通过 Canal 的 CDC 能力，将 MySQL 数据采集到 Kafka 中。因 Apache Doris 与 Kafka 的符合度较高，能够便捷地应用 Routine Load 进行数据加载与接入。
- 对原有离线计算的数据链路进行了轻微调整。对于存储在 Hive 中的数据，Apahce Doris 反对通过 Broker Load 将 Hive 数据引入进来，因而离线集群的数据能够间接加载进 Doris 之中。
选型 Doris
图 3.2 架构 2.0- 选型 Doris
在选型的过程中，Apache Doris 整体体现堪称惊艳：
- 数据接入：提供了丰盛的数据导入形式，可能反对泛滥数据源的接入。
- 数据连贯：Doris 反对 JDBC 与 ODBC 等连贯形式，对 BI 工具的可视化展现比拟敌对，可能便捷地与 BI 工具进行连贯，另外 Doris 实现了 MySQL 协定层，能够通过各类 Client 工具间接拜访 Doris。
- SQL 语法：Doris 反对规范 SQL，语法向 MySQL 兼容，对于数仓人员学习老本较低；
- MPP 并行计算：Doris 基于 MPP 架构提供了十分优良的并行计算能力，对于大表 Join 反对得十分好。
- 最重要的一点：Doris 官网文档十分健全，对于用户而言上手较快。
零碎选型调研时，咱们也理解了 ClickHouse，ClickHouse 对 CPU 的利用率较高，在单表查问时体现比拟优良，然而在多查问高 QPS 的状况下体现欠佳。
联合以上几点因素，最终咱们抉择了 Apache Doris。
Doris 部署架构
图 3.3 架构 2.0-Doris 部署架构
Apache Doris 部署架构极为简略，次要是 FE 和 BE：
FE 是前端节点，次要进行用户申请的接入、元数据和集群的治理以及查问打算的生成。
BE 是后端节点，次要进行数据存储以及查问打算的生成及执行。
Doris 运维非常简便：
3 月份咱们对机房的机器进行了滚动式迁徙，12 台 Doris 节点机器在三天内全副迁徙实现，整体操作较为简单，次要用于机器下架、搬移及上架；FE 扩容与缩容动作破费的工夫也不多，只使用了 Add 与 Drop 等简略指令。
特地留神：尽量不要应用相似于 Drop 等指令间接对 BE 进行操作。当应用 Drop 指令进行强制删除时，Doris 会提醒并要求手动确认是否删除，强制删除后数据将无奈复原。因而倡议采纳接触形式下线节点，该形式在数据迁徙工作实现之后，能够间接将 BE 节点再次退出，较为灵便。
Doris 实时零碎架构
图 3.4 Doris 实时零碎架构
数据源：在实时零碎架构中，数据源来自产业金融、生产金融、风控数据等业务线，通过 Canal 和 API 接口进行采集。
数据采集：Canal 通过 Canal- Admin 进行数据采集后，将数据发送到 Kafka 音讯队列之中，再通过 Routine Load 接入到 Doris 集群。
Doris 数仓：Doris 集群构建了数据仓库的三层分层，别离是：应用了 Unique 模型的 DWD 明细层、Aggregate 模型的 DWS 汇总层以及 ADS 应用层。
数据利用：架构利用于实时看板、数据及时性剖析以及数据服务三方面。
Doris 新数仓特点
图 3.5 Doris 新数仓特点
数据导入形式简便，依据不同场景采纳 3 种不同的导入形式：
- Routine Load：次要用于业务数据的接入并作为生产 Kafka 的常驻工作存在。当咱们提交 Rountine Load 工作时，Doris 外部会有一个常驻过程实时生产 Kafka，一直从 Kafka 中读取数据导入进 Doris 中。
- Broker Load：进行如根底维度表及历史数据等离线数据导入工作。
- Insert Into：用于定时跑批作业，负责将 DWD 层数据处理，造成 DWS 层以及 ADS 层。
Doris 的良好数据模型，晋升了咱们的开发效率：
- Unique 模型在 DWD 层接入时应用，能够无效避免反复生产数据。
- Aggregate 模型用作聚合。在 Doris 中，Aggregate 反对如 Sum、Replace、Min、Max 4 种形式的聚合模型，聚合的过程中应用 Aggregate 底层模型能够缩小很大部分 SQL 代码量，不再须要本人做 Sum、Min、Max 等动作，对于从 DWD 层到 DWS/ADS 层较为敌对。
Doris 应用门槛低，查问效率高：
- 反对 MySQL 协定，反对规范 SQL，查问语法高度兼容 MySQL，对剖析人员较为敌对。
- 反对物化视图与 Rollup 物化索引。物化视图底层相似 Cube 的概念与预计算的过程，与 Kylin 中以空间换工夫的形式相似，均是在底层生成非凡的表，在查问中命中物化视图时将疾速响应。
特地提醒：物化视图尽管很有帮忙，但在过多应用时，每个物化视图均须要占用额定的存储空间，数据导入时将会导致效率降落。
Doris 极简的零碎架构，运维成本低:
- 零碎只有 BE 和 FE 两个模块，不依赖如 Zookeeper 等三方组件，部署简略。
- 针对 FE 和 BE 的操作进行了监控配置，产生异样时会进行及时性重启。
Doris 经验总结
图 4.1 如何更敌对地应用 Doris
在应用 Apache Doris 的过程中，咱们整顿了一部分教训，帮忙开发人员更敌对地应用 Doris。对于开发人员，最关注的中央有以下几点：
- 开发方面：如何将内部数据接入 Doris 并疾速实现 ETL 开发，这会影响开发人员的报表产出速度。
- 调度治理：开发人员不心愿在开发实现并上线工作后，呈现报错或不稳固的状况，须要保障任务调度的稳定性以及调度恢复能力。
- 数据查问：因为生产与办公网络两头有隔断，办公网络不能间接应用生产网络的连贯，并且无奈通过客户端的模式解决网络隔断，只能通过 Web 模式解决，如何平安便捷地进行查问和剖析成为开发人员关注的问题。
- 集群治理：集群出现异常情况时可能及时进行捕获及自动化解决。
总而言之，咱们心愿建设一个 高效率、高质量，高稳定性 的平台。
Doris 开发优化
依据开发者关注的几个问题，咱们进行了一些开发优化。
数据接入
数据接入方面进行了半自动化相干工作并做了疾速生成组件，能够依据数据源 / 表生成 Routine Load 脚本，只有对 Kafka 的 Broker 或 Topic 进行批改就能够疾速造成 Routine Load 工作。Broker Load 工作与 Routine Load 相似，在抉择数仓源之后就能够及时生成 Broker Load 所需脚本。在接入 Doris 时须要提前创立表，对于这方面也能够进行相似操作，通过源疾速生成创立语句。
图 5.1 数据平台 - Doris 开发
上述次要使用了底层元数据，依据不同的数据源拿到不同的元数据后就能够对工作进行疾速生成。
提交动作和保护治理
在工作生成后，咱们在 Routine Load 方面进行了封装。因为 Routine Load 是常驻过程，咱们只须要再进行一次提交，状态就会变成 Running，若出现异常状态会被检测进去，监控方面在后续会向大家进行展现。
图 5.2 数据平台 - Doris 开发
监控与治理
咱们能够在对提交的 Routine Load 进行查问并查看是否存在异样，同时能够将咱们须要关注的 Routine Load 退出监控中，监控会定期对工作进行主动扫描，产生问题时会进行提醒并尝试将工作从新拉起。
Broker Load 同样能够对工作进行监测。针对于 Broker Load Label 名称不能反复的问题，咱们采取生成 UUID 的形式进行解决，以此更好地帮忙大家晋升应用体验。
图 5.3 数据平台 - Doris 开发
如上图展现，咱们能够在 Routine Load 中进行暂停和终止的动作，帮忙大家更好地应用开发的作业与治理。
自研查问页面，集成 Doris Help 性能
因为生产与办公网段隔离，咱们只能通过 Web 进行查问。之前咱们曾尝试应用 Hue 集成 Doris 进行查问的计划，Doris 反对通过 MySQL 协定连贯到 Hue，但如果咱们集成 Hue 的话，所有人都能够通过 Hue 查问 Doris 的数据，安全性问题无奈保障，无奈满足咱们对权限的要求。
图 5.4 数据平台 -Doris 数据查问
所以咱们在本人的平台内开发了查问页面来解决此问题。图中右边局部能够依据 DB 列出上面所有的表，左边局部是查问剖析页面与查问后果，是咱们自行开发的相似于 Navicat 的客户端软件。
同时咱们对 Doris Help 性能进行了性能集成，在大家在不晓得如何应用 Doris 时提供帮忙。通过集成 Doris Help，咱们能够通过关键字搜寻的性能进行语法和示例查问解决问题。
即便没有集成 Doris Help，也能够在 FE 节点自带的 Web 页面进行查看，FE 节点内置能够查看整个集群信息且具备 Help 性能的 Web 页面。在咱们实现自研查问页面并集成 Doris Help 后，能够间接应用，从而跳过须要应用 Admin 账号连贯才能够应用 FE 的步骤。
Doris 集群监控页面
同时咱们开发了 Doris 集群监控页面，在集群监控页面中能够看到 FE、BE 以及 Broker 的节点情况。当集群产生异样情况时，监控零碎会发送主动揭示并尝试将集群拉起，同时也能够通过页面化的模式察看节点的衰弱度状况。
图 5.5 数据平台 - Doris 集群监控
对于 Doris 下层利用而言，次要还是依赖 Doris 提供的 API 与指令实现 Doris 下层的利用动作，咱们做的只是将 Doris 提供的指令针对使用者进行更敌对地集成以及页面化展现。
新架构的收益
图 6.1 新架构收益
- 数据接入：在晚期通过 SteamSets 进行数据接入的过程中须要手动建设 Kudu 表。因为不足工具，整个建表和创立工作的过程须要 20-30 分钟。现在能够通过平台与疾速构建语句实现数据疾速接入，每张表的接入过程从之前的 20-30 分钟缩短到当初的 3-5 分钟，性能晋升了 5-6 倍。
- 数据开发：在晚期架构中进行聚合或其余动作时，须要写大量长篇幅 SQL 代码。应用 Doris 之后，咱们能够间接应用 Doris 中自带的 Unique、Aggregate 等数据模型及能够很好反对日志类场景的 Duplicate 模型，在 ETL 过程中大幅度放慢开发过程。
- 查问剖析：Doris 底层带有物化视图及 Rollup 物化索引等性能，能够晋升查问效率，同时 Doris 底层对于大表关联进行了诸多优化策略，如 Runtime Filter 以及其余 Join 和自定义优化策略。相较于 Doris，Apache Kudu 则须要有较为深刻的优化教训能力更好地应用。
- 数据报表：最后应用 Kudu 报表查问须要 1-2 分钟才可能实现渲染，而 Doris 则是秒级甚至是毫秒级的响应速度。
- 环境保护：Doris 没有 Hadoop 生态系统的复杂度，整个链路较为清晰，保护老本远低于 Hadoop，尤其是在集群迁徙过程中，Doris 的运维便捷性尤为突出。
将来瞻望
图 7.1 将来瞻望
- 尝试引入 Doris Manager：社区中正在进行对于 Doris Manager 宣导，后续咱们也筹备引入并积极参与 Doris Manager 进行集群保护与治理。
- 实现基于 Flink CDC 的数据接入：以后架构中没有引入 Flink CDC，而是持续沿用了 Canal 采集到 Kafka 后再采集到 Doris 中的架构，链路相对来说较长。采纳 Flink CDC 尽管能够持续精简整体架构，然而还须要写肯定代码量，对于 BI 人员间接应用感触并不敌对，咱们心愿数仓人员只须要 SQL 或在页面上实现操作就能够应用。在 3.0 架构的布局中，咱们打算引入 Flink CDC 性能并对下层利用进行裁减。Flink CDC 的引入为大家带来“快就是慢，慢就是快”的思维理念，当然 Flink 社区的倒退速度很快，只有在充沛学习大家的教训后，才能够更敌对地引入，并在学习教训的过程中对架构进行迭代与优化。
- 紧跟社区迭代打算：咱们正在应用的 Doris 版本绝对较老，当初新版本 Doris 在内存治理、查问性能等方面有了较大幅度的晋升，后续咱们将紧跟社区迭代节奏对集群进行降级并体现新个性。
- 强化建设相干体系：咱们当初的指标体系治理如报表元数据、业务元数据等保护与治理仍旧有待进步。数据品质监控方面，尽管目前蕴含了数据品质监控性能，但对于整个平台监控与数据自动化监控方面还须要强化与改善。
退出社区
欢送更多酷爱开源的小伙伴退出 Apache Doris 社区，参加社区建设，除了能够在 GitHub 上提 PR 或 Issue 之外，也欢送大家积极参与到社区日常建设中来，比方：
加入社区 征文活动，进行技术解析、利用实际等文章产出；作为讲师参加 Doris 社区的线上线下流动；积极参与 Doris 社区用户群的发问与解答等。
最初，欢送更多的开源技术爱好者退出 Apache Doris 社区，携手成长，共建社区生态。
SelectDB 是一家开源技术公司，致力于为 Apache Doris 社区提供一个由全职工程师、产品经理和反对工程师组成的团队，凋敝开源社区生态，打造实时剖析型数据库畛域的国内工业界规范。基于 Apache Doris 研发的新一代云原生实时数仓 SelectDB，运行于多家云上，为用户和客户提供开箱即用的能力。
相干链接：
SelectDB 官方网站：
https://selectdb.com
Apache Doris 官方网站：
http://doris.apache.org
Apache Doris Github：
https://github.com/apache/doris
Apache Doris 开发者邮件组：
dev@doris.apache.org
