本文导读：
同程数科是同程团体旗下的游览产业金融科技服务平台，为上下游企业和集体消费者提供数字金融科技服务。近年来，随着同程数科业务的一直拓展和用户量的减少，高效牢靠的一站式数据中心建设已成为必不可少的需要。为帮忙业务人员晋升数据开发的效率与品质，同程数科历经三代架构演进，最终引入 Apache Doris 搭建对立实时数仓，在后续的理论利用中，将实时数仓平台化，进一步构建了一站式数据平台 Ark，为业务人员提供了简略易用、便于保护的零碎，实现工作自主开发、灵便上线、简便查问、继续监控等应用性能。
作者：陈松，同程数科 大数据平台工程师
同程数科是同程团体旗下游览产业金融科技服务平台，前身为同程金服，成立于 2015 年 11 月，以数字科技引领游览产业，以科技的力量赋能游览产业为愿景，为游览公司在深层次的生态链条上构建竞争力，同时为游览产业链上下游企业和集体消费者提供数字金融科技服务。同程数科的业务涵盖了游览产业链金融服务、游览生产金融服务、领取科技等板块，累计服务用户超过千万，涵盖 76 座城市。 目前，同程数科已取得首轮策略投资，联结多家产业金融机构，为游览产业开辟新业务的服务平台。
近年来，随着同程数科业务的一直拓展和用户量的一直减少，咱们越来越须要一个牢靠、高效的数据中心，以帮忙企业更好地理解业务经营状况和制订策略，这包含但不限于建设实时业务报表看板、实时业务指标预警、营销用户画像与标签、以及金融风控实时监测等剖析工具。因而，咱们更加关注于实时数仓的构建，心愿利用数仓帮忙业务人员晋升数据开发的效率与品质，从而为业务剖析提供弱小的后盾。
基于此，咱们开始了实时数据仓库的探索之旅。现在，数仓架构曾经经验了三代演进，通过第一代离线架构与第二代 Lambda 架构的应用后，通过需要剖析与调研，最终引入 Apache Doris 搭建了对立的实时数据仓库。本文将具体介绍三代架构的演进过程，分享咱们如何基于 Apache Doris 搭建一站式数据平台 Ark，以及如何在业务应用、系统维护、数仓开发等方面达到降本增效的收益与成绩。晚期架构演进
晚期架构演进
在大数据技术倒退和使用的初期，同程数据以 Apache Hive 为外围建设了离线数仓，并应用 Hive 进行数仓分层。当数据从源头进入离线数仓后，通过 ODS、DWD、DWS 层级解决，数据输入至 MySQL、Redis、HBase 等利用数据库，以供报表平台应用。该架构尽管具备耦合性低、稳定性低等劣势，但其毛病也比拟显著，次要体现在当进行部分更新时须要对数据进行全量合并，流程简短，使数据更新工夫变长，时效性无奈失去保障。随着数据规模一直减少，部分更新需要越来越多，该架构在数据计算效率低下和资源利用不充沛的弊病也变得更加显著。
基于第一代架构存在的问题，咱们对架构进行了降级革新。第二代架构为典型的 Lambda 架构，在保留原有离线数仓的同时，新增了以 Apache Flink 与 Apache Kafka 为外围的实时数仓。在该架构中，离线链路次要对数据进行批量解决，负责解决周期性数据跑错的问题。新增的实时链路利用 Flink 对于数据源进行流式解决、利用 Kafka 对数仓分层，最终输入至利用数据库。
只管该架构解决了第一代架构中数据时效性较低的问题，然而在长期的运行中，咱们发现仍存在一些应用痛点：
- 架构简单，运维难度高： 因为两套链路同时运行，实时链路须要通过 Apache Flink 与 Apache Kafka 对数据进行流解决，离线链路须要利用 Apache Hive 与 Apache Spark 对数据进行批处理，并且两条链路的维表层中均利用 MySQL 或 Redis 进行存储，这导致整体架构波及的组件过多，数据处理流程过于简单。除此之外，该架构会反复计算雷同的数据，导致整体资源占用减少、运维治理成本增加、前期保护难度减少。
- 数据开发成本高： 实时数仓局部齐全依赖 Apache Kafka 进行数仓分层，而 Kafka 对于数据的存储周期具备限度，新的数据导入工作须要进行额定的开发工作，这将极大减少开发成本。
- 数据一致性低： 雷同的数据在实时数仓中流解决，离线数仓中批处理，存在数据处理逻辑不对立的问题，数据一致性与准确性得不到保障。因为无奈复用第一代架构中的数据血统、数据品质等管理体系，在运行过程中，当实时链路呈现乱序问题时，须要回放全量日志进行数据回溯，减少数据修复的复杂性。
Apache Doris 和 Clickhouse 选型比照
为了彻底解决晚期架构的问题，在引入新架构之前，咱们决定进行深度的产品调研来抉择更适宜的数仓搭建计划。咱们发现 MPP 架构数据库可能反对对立实时的数据分析，能够无效解决 Lambda 架构简单、数据一致性无奈保障的问题，而这一产品细分下，Apache Doris 与 Clickhouse 比拟匹配咱们的业务诉求。基于此，咱们对这两款 MPP 架构数据库进行了选型比照，并发现 Doris 的体现更加优异，十分合乎咱们的选型要求，具体表现如下：
- 产品易用性： ClickHouse 不反对规范 SQL，而 Apache Doris 反对规范 SQL 并兼容 MySQL 协定，使开发人员上手简略，不须要付出额定的学习老本。Join
- 性能优异： Doris 反对分布式 Join，查问灵便度较高，且性能体现优异。而 ClickHouse 因为 Join 查问限度、函数局限性以及可维护性较差等起因，不满足咱们以后的业务需要。
- 数据导入： Doris 的数据导入性能齐备，反对 Routine Load、Stream Load 和 JDBC Insert Into 等多种数据导入形式，即便在海量数据下也能保持数据稳固写入，性能与速度远高于 ClickHouse。
- 运维难度： Doris 架构精简，只有 FE 与 BE 两种角色，整体部署简略疾速，同时 Doris 在扩容方面十分快捷，反对滚动降级，只须要替换相干安装包即可。而 ClickHouse 对组件依赖较高，在应用和扩容上须要做许多筹备工作，这就要求提供一支业余的团队来反对日常的开发与运维工作。
更要害的是，Doris 能够同时反对实时数据服务、交互数据分析和离线数据处理等多场景。 Multi-Catalog 提供了联邦查问的能力，反对对多个数据源进行读取，进步数据的准确性和品质，简化工作开发流程。此外，这一性能能够使开发人员更疾速地找到所需数据，缩小查问工夫和老本，进步查问效率。因而 Apache Doris 的高效运行性能和低开发成本的劣势，更合乎咱们对一站式数据平台搭建的需要。
新一代对立实时数仓
引入 Apache Doris 后，咱们对架构进行了重构。如上图所示，咱们应用 Apache Doris 对立进行数据存储与计算，齐全代替了原先的离线架构与 Lambda 架构，并构建了一站式数仓，不仅保障了数据的一致性，还实现了架构的精简，极大升高了架构运维老本。 其次，在数据源进入实时数仓时，咱们新增了 Input 对立数据集成引擎，反对多种异构数据源的数据同步，实现数据入口的对立。总而言之，Doris 的引入真正帮忙咱们实现了数据集成、存储、计算、输入方面的对立，真正意义上实现了实时对立数仓。
基于 Apache Doris 的一站式数据平台
基于新一代的数仓，咱们搭建了一站式数据平台 Ark，心愿通过该数据平台实现工作开发、工作提交与测试、任务调度与监控、数据查问、集群监控等一体化服务，为内部人员在理论业务中晋升工作开发效率，进步工作监控品质。
- 数据开发： 咱们心愿内部数据接入 Apache Doris 时能够高效地进行 ETL 开发，晋升报表产出速度。
- 调度治理： 在业务人员开发实现并上线工作后，咱们须要保障任务调度的稳定性以及调度恢复能力，防止问题产生
- 数据查问： 因为生产与办公网络两头有隔断，办公网络不能间接应用生产网络的连贯，只能通过 Web 模式解决网络隔断，咱们心愿借助平台可能提供平安便捷地查问和剖析形式。
- 集群治理： 当集群出现异常情况时，咱们心愿平台可能及时监控捕获并进行自动化解决。
一键生成工作脚本，晋升工作开发效率
Apache Doris 反对丰盛的数据源接入，利用这一性能，在 Ark 平台中能够依据不同的数据源，获取绝对应的元数据信息来造成脚本，实现工作疾速生成。在数据接入方面，平台进行了半自动化代码的相干工作，并创立了疾速生成组件。如上图所示，在平台中输出数据源或表的信息能够主动生成 Routine Load 脚本。基于该脚本，只须要对 Apache Kafka 接入源进行 Topic 批改，即可马上生成 Routine Load 工作。同样，对于 Broker Load 的工作开发原理雷同，在抉择对应的数仓源之后，能够及时生成 Broker Load 所需脚本。利用 Doris 多源异构数据的写入能力，平台可能疾速构建代码，实现对 Routine Load 与 Broker Load 的高效工作开发。
主动调度监控，保障工作失常运行
在工作开发与提交之后，平台能够针对 Routine Load 或者 Broker Load 工作进行查问、查看是否存在异样等惯例调度操作。对于须要特地关注的工作，能够退出监控列表中，这样零碎会定期主动地对工作进行扫描，产生问题时会进行提醒并尝试将工作从新拉起。此外，因为 Routine Load 是常驻过程，对于该工作的监控，平台反对定期且继续的自动化监控性能，而对于 Broker Load 与其余惯例工作，平台在定期扫描后会对失败的工作进行预警提醒。
平安便捷的可视化查问剖析
因为生产与办公网段隔离，咱们只能通过 Web 进行查问，应用起来繁琐且不不便。为了解决这个问题，咱们已经尝试应用集成 Hue 的形式，使 Doris 通过 MySQL 协定连贯到 Hue 进行数据查问，尽管查问过程有所简化，然而这种办法存在数据安全隐患。因而，同程数科自行开发了外部查问剖析页面，设置了权限治理，解决了查问安全性的问题。同时，在 Ark 平台中集成了 Doris Help 性能，使业务人员可能通过关键字搜寻进行 SQL 语法和示例的查问，解决惯例查问操作问题，以此升高学习老本，进步内部人员查问的便捷性。
齐备智能的集群监控
通过 Apache Doris 集群监控页面能够实时监管 FE、BE 以及 Broker 节点情况。当集群产生异样情况时，监控零碎会发送主动揭示并尝试将集群拉起，及时对异常情况进行自动化解决，防止引发更大的问题。同时集群监控的看板也能够帮忙咱们察看节点的衰弱度状况，通过 FE 节点状态判断衰弱度高下。
总结收益与成绩
以后，同程数科曾经基于 Apache Doris 搭建了高度对立实时的数据仓库，并应用数十台 Doris 节点机器。此外，咱们还将 Doris 性能平台化至 Ark 一站式数据平台中，实现对于 Ark 平台可能无所不包的开发初衷。对于 Doris 的引入，为咱们带来以下收益与成绩：
- 缩减开发周期：利用平台一键开发性能，业务人员可能自主开发，无需将需要提给大数据团队，开发工夫由原来的半小时缩短到仅需三分钟，显著压缩了工作开发周期，开发效率晋升了十倍；
- 灵便数据开发：配合 Ark 一站式数据平台，数据开发可能灵便剖析，需要能够疾速上线；
- 对立数据处理：Doris 在数据导入、存储、计算实现对立，保证数据一致性，实现真正意义的实时对立；
- 晋升查问效率：从过来分钟级效应工夫到现在秒级甚至毫秒级，查问效率失去数十倍晋升；
- 升高学习老本：因为 Apache Doris 兼容 MySQL 协定，并且应用规范 SQL，在应用上简略易用。业务人员可能如同应用数据库一样应用大数据，从而进一步升高学习老本；
- 升高运维老本：Doris 的部署简略，精简架构使整体链路体系简洁，便于保护。
将来布局
在将来，咱们心愿基于 Apache Doris 可能搭建实时数仓生态体系，并在同程数科的外部进行大规模应用。咱们将会继续建设并优化基于 Apache Doris 一站式实时数仓架构，欠缺对立计算和存储、流批一体能力。对于 Ark 一站式数据平台继续迭代加强，整个实时数仓体系向着时效性、稳定性、灵活性倒退。欠缺 Ark 数据集成平台的图形化性能，继续减少更多异构数据源之间的数据同步性能，加强引擎对数据的解决能力。
其次，咱们将继续关注 Apache Doris 在数据湖剖析方面的能力，咱们心愿在湖中可能对多源异构数据进行采集，实现数据对立存储、对立多范式计算，最初由 Doris 的 API 接口对立对外提供服务。另外，咱们对于 Apache Doris 2.0 的尝鲜测试也十分感兴趣，特地是 倒排索引性能和 JSONB 数据类型的优化，在后续的架构优化中咱们会思考利用倒排索引替换现有的日志零碎，利用更新的 Json 数据类型进一步欠缺查问能力。
在此特别感谢 SelectDB 技术团队 长期以来的及时响应和技术支持。将来，咱们也会更积极参与社区奉献及流动，与社区共同进步和成长，欢送大家抉择和应用 Doris，置信 Doris 肯定不会让你悲观！