1.1 Doris概述

        ​ Apache Doris 是一个基于 MPP 架构的高性能、实时的分析型数据库，以极速易用的特点被人们所熟知，仅需亚秒级响应时间即可返回海量数据下的查询结果，不仅可以支持高并发的点查询场景，也能支持高吞吐的复杂分析场景。基于此，Apache Doris 能够较好的满足报表分析、即席查询、统一数仓构建、数据湖联邦查询加速等使用场景，用户可以在此之上构建用户行为分析、AB 实验平台、日志检索分析、用户画像分析、订单分析等应用

        ​ Apache Doris 最早是诞生于百度广告报表业务的 Palo 项目，2017 年正式对外开源，2018 年 7 月由百度捐赠给 Apache 基金会进行孵化，之后在 Apache 导师的指导下由孵化器项目管理委员会成员进行孵化和运营。目前 Apache Doris 社区已经聚集了来自不同行业数百家企业的 400 余位贡献者，并且每月活跃贡献者人数也超过 100 位。 2022 年 6 月，Apache Doris 成功从 Apache 孵化器毕业，正式成为 Apache 顶级项目（Top-Level Project，TLP）

        ​ Apache Doris 如今在中国乃至全球范围内都拥有着广泛的用户群体，截止目前， Apache Doris 已经在全球超过 2000 家企业的生产环境中得到应用，在中国市值或估值排行前 50 的互联网公司中，有超过 80% 长期使用 Apache Doris，包括百度、美团、小米、京东、字节跳动、腾讯、网易、快手、微博、贝壳等。同时在一些传统行业如金融、能源、制造、电信等领域也有着丰富的应用

1.2 Doris使用场景

        Doris数据库是一个分布式列式存储和查询系统，主要用于实时分析和查询海量数据。它适用于以下场景：

• 实时分析：Doris数据库可以快速查询和分析海量数据，支持实时查询和聚合操作，可以帮助企业快速做出决策并调整业务策略。
• 大数据仓库：Doris数据库可以作为企业的数据仓库，存储大规模的数据，并提供高效的查询和分析能力，帮助企业更好地理解和利用数据。
• 日志存储和分析：Doris数据库可以快速存储和分析实时生成的日志数据，支持实时查询和聚合操作，帮助企业及时发现和解决问题。
• 金融数据分析：Doris数据库可以存储和分析金融相关的大规模数据，如证券交易数据、客户信息等，帮助金融机构更好地理解市场趋势、客户需求等信息。

总之，Doris数据库适用于需要处理海量数据、需要实时查询和分析数据的场景。

经过各种数据整合和处理后，数据源通常存储在实时数仓Doris和离线数据湖或数仓（Apache Hive、Apache Iceberg或Apache Hudi中）。

Apache Doris 广泛应用于以下场景：

报告分析

• 实时仪表板
• 生成内部分析师和经理的报告
• 面向用户或客户的高并发报表分析：比如网站主 做站点分析，广告主 做广告报表等场景，并发通常需要上千QPS，查询时延需要亚秒级响应。著名电商京东在广告报表中使用Doris，每天写入100亿行数据，上万并发查询QPS，99%查询延迟150ms。

即席查询

        面向分析师的具有不规则查询模式和高吞吐量要求的的自助服务分析。小米基于Doris构建了增长分析平台（Growth Analytics，GA），利用用户行为数据进行业务增长分析，平均查询延迟10秒，95%查询延迟30秒以下，数万每天的 SQL 查询数。

统一数据仓库建设

        Doris 是一个满足统一数据仓库建设需求，简化复杂数据软件栈的平台。海底捞基于Doris的统一数据仓库取代了由Apache Spark、Apache Hive、Apache Kudu、Apache HBase、Apache Phoenix组成的旧架构，大大简化了架构。

数据湖查询

        通过使用外部表联合位于 Apache Hive、Apache Iceberg 和 Apache Hudi 中的数据，在避免数据复制的同时大大提高了查询性能。

1.3 Doris架构

Doris整体架构如下图所示，Doris 架构非常简单，只有两类进程

• Frontend（FE）：主要负责用户请求接入、查询解析和规划、元数据管理、节点管理等相关工作。
• 后端（BE）：主要负责数据存储和查询计划执行。

两种类型的进程都可以水平扩展，单个集群最多可以支持数百台机器和数十 PB 的存储容量。并且这两类流程通过一致性协议保证了服务的高可用性和数据的高可靠性。这种高度集成的架构设计大大降低了分布式系统的运维成本。

        Doris采用MySQL协议，高度兼容MySQL方言，支持标准SQL。用户可以通过各种客户端工具访问Doris，支持与BI工具无缝对接。

在存储引擎方面，Doris采用列式存储对数据进行按列编码压缩和读取，在实现极高压缩率的同时减少大量扫描无关数据，从而更高效地利用IO和CPU资源.

Doris 还支持比较丰富的索引结构来减少数据扫描：

• 支持排序复合键索引：最多可以指定三列组成复合排序键。有了这个索引，可以对数据进行有效的剪枝，更好的支持高并发的上报场景。
• Z-order 索引：使用Z-order 索引，您可以高效地对架构中的任意字段组合运行范围查询。
• MIN/MAX 索引：有效过滤数字类型的等价和范围查询
• 布隆过滤器：对高基数列的等价过滤和修剪非常有效
• 倒排索引：它可以快速搜索任何字段

在存储模型方面，Doris 支持多种存储模型，针对不同场景有针对性的优化：

• 聚合键模型：通过预先聚合来合并具有相同键的值列，以显着提高性能。
• 唯一键模型：键是唯一的。具有相同键的数据将被覆盖，以实现行级数据更新。
• 重复键模型：详细的数据模型，可以满足事实表的详细存储。

Doris 还支持强一致性物化视图，物化视图的更新和选择在系统内部自动完成，不需要用户手动选择，从而显着降低了物化视图的维护成本。

        在查询引擎方面，Doris采用了MPP模型，节点间和节点内并行执行，也支持多张大表的分布式shuffle join，可以更好的应对复杂的查询。

        Doris查询引擎是向量化的，所有内存结构都可以以列格式布局，从而实现显著减少虚拟函数调用、提高缓存命中率和高效使用SIMD指令。宽表聚合场景中的性能比非向量化引擎高 5-10 倍。 

        Doris使用自适应查询执行技术，可以根据运行时的统计动态调整执行计划，例如运行时过滤器技术，在运行时生成过滤器推送到探测端，并自动将过滤器穿透到探测端，大大减少了探测端的数据量，提高了连接性能。Doris 的运行时过滤器支持 In/Min/Max/Bloom 过滤器。 

查询优化器

在优化器方面，Doris 使用了 CBO 和 RBO 的组合，RBO 支持常量折叠、子查询重写、谓词下推等，CBO支持 Join 重新排序。CBO仍在持续优化中，主要集中在更准确的统计信息收集和推导、更准确的成本模型预测等方面。

未来，Apache Doris除了数据分析之外，还将提升数据工程能力，更好地覆盖企业数据ETL/ELT场景，通过一个平台满足多种混合工作负载。另一方面，对云基础设施做深度优化，利用云提供的弹性和新硬件，提供性价比更好的产品。

查询速度提升15倍！银联商务基于 Apache Doris 的数据平台升级实践

为什么选择 Apache Doris？

• 易于使用：两个进程，没有其他依赖；在线集群伸缩，自动副本恢复；兼容MySQL协议，使用标准SQL。
• 高性能：通过列式存储引擎、现代 MPP 架构、矢量化查询引擎、预聚合物化视图和数据索引，为低延迟和高吞吐量查询提供极快的性能。
• 单一统一：单一系统可以支持实时数据服务、交互式数据分析和离线数据处理场景。
• 联邦查询：支持Hive、Iceberg、Hudi等数据湖和MySQL、Elasticsearch等数据库的联邦查询。
• 多种数据导入方式：支持从HDFS/S3批量导入，从MySQL Binlog/Kafka流式导入；支持通过HTTP接口进行微批量写入，也支持在JDBC中使用Insert实时写入。
• 丰富生态： Spark使用Spark-Doris-Connector读写Doris；Flink-Doris-Connector 使 Flink CDC 能够实现 Exactly-once 数据写入 Doris；提供 DBT Doris Adapter 用于将 Doris 中的数据与 DBT 进行转换。

升级目标主要包含几方面：

• 统一、简洁：单一系统即可完成数据加工和服务的统一，以简化数据处理流程，提高工作效率；
• 稳定、高效：支持高效的数据加工和高性能的数据查询，同时系统和平台的稳定性得以充分的保证；
• 准确、实时：支持数据实时更新以及接入，保证数据准确、不丢不重；
• 安全、可靠：确保数据访问和数据存储的安全性，支持集群灾备、数据高可靠；

        基于以上目标，我们进行了深入的调研，在对比了多种大数据组件后，选择引入 Apache Doris 来构建新一代实时数据仓库架构。

实时数据仓库体系的建设与实践

        在建设数据仓库体系时，银联商务遵循边治理、边建设、边赋能的原则，数据治理为关键一环，而统一规划又是其核心内容。因此数据仓库的统一规划能够确保数据仓库结构设计的合理性，不仅有利于后续对架构的管理维护，也有利于对数据可靠性和一致性的保障。因此我们在数据仓库统一规划方面采取了以下措施：

 01 数仓分层的合理规划

合理的数仓分层对数据的管理以及查询性能的充分发挥起着关键作用，基于 Apache Doris 丰富的数据模型，我们对数仓的分层进行了提前规划。先来了解 Doris 数据模型都具备哪些特性：

• Duplicate Key 模型：适用于明细数据查询场景，可支持任何维度的即席查询；

• Unique Key 模型：适用于对数据有唯一性约束的场景、需要支持数据精确去重，或者有数据更新需求、可支持大宽表的多流 Upsert 和部分列更新；

• Aggregate Key 模型：适用于报表查询场景，通过数据的预聚合来加速报表分析。

结合实际应用场景和数据模型，我们来介绍银联商务数仓分层策略：

• ODS 层主要采用 Duplicate Key 模型，例如在交易清算场景中，银联商务每天有几千万的清算数据需处理，清算日期跨度长达一年，这就要求所有数据能被完整地存储。为了满足这一需求，我们在 ODS 层选择 Duplicate Key 模型，完全按照导入文件中的明细数据进行存储，没有任何聚合操作。而部分商户订单数据涉及到订单状态的更新，因此采取 Unique Key 模型，在数据导入过程中如果商户 id 以及订单 id 相同时自动更新成最新状态。

• DWD 与 DWS 层所采取的数据模型基本相同，其本质差异在于对于业务数据的抽象程度，主要采用的是 Unique Key 模型，而部分有明细数据存储的场景还保留了 Duplicate Key 模型。以结算划付场景为例，将结算日期作为分区字段，设置表模型为 Unique Key 模型，通过这种方式能够实现跨度长达一年结算数据状态的自动更新。

• ADS 层作为高度业务数据的抽象，采用了 Aggregate Key 模型，通过对所有结算数据进行预聚合，可大幅提高数据查询和分析的效率，减少实时计算的压力。

02 分桶分区策略的合理设置

分区分桶是优化数据存储和提升查询效率的重要手段，合理设置分桶数和分桶字段可以有效提升查询速度和数据加工脚

本的执行效率。在数仓应用中，我们参考实际数据规模和官网的设置建议，会对每一张表均规划了分桶字段和分桶数。例如，在分店宽表中经常需要查询分店维度数据，因此我们将分店作为分桶字段，并根据表的大小设置分桶数。以下是我们在不同 Tablet 下 Bucket 设置的数量，可供参考：

03 多源数据迁移方案

        在银联商务各分支机构数据迁移至 Doris 的过程中，我们发现分支机构本地系统采用的数据库种类繁多，文件存储格式也比较复杂，这给数据迁移工作带来不小的挑战。为确保数据迁移的顺利进行，我们针对不同数据和文件格式制定了相应的迁移方案。

 Doris 支持多种丰富的数据迁移方式，无论是离线数据同步还是实时数据同步，都能找到高效快捷的数据迁移方式：

• 在实时场景中，使用 Flink CDC 方式实时获取 MySQL Binlog，其中一部分数据直接通过 Flink CDC 写入 Doris，另一部分高流量数据则先同步至 Kafka 中进行削峰、再经由 Flink-Doris-Connector 写入到 Doris 中。

• 在离线场景中，数据来源更加多样、并且文件格式也更加复杂，因此采用了多种方式进行数据迁移。对于 S3 和 HDFS 上的历史数据及增量数据，使用 Broker Load 进行批量导入；对于 Hive 及 JDBC 外表存储的数据，使用 Insert into 方式进行同步；对于文件格式的数据，使用 Flink Ftp Connector 和 Flink Doris Connector 同步（因 Ftp 方式在银联商务内部是跨系统的数据文件交互方式，文件的格式复杂，因此开发了 Flink Ftp Connector，可支持复杂的数据格式、支持多换行符等复杂应用场景）。

• 丰富的数据迁移方式使得我们可以轻松地将数据从各类数据库迁移至 Doris 中来，同时，多文件格式的同步解决了分支机构数据不统一、不规范的问题，大大降低了各分支机构数据迁移的难度及成本，为银联商务的数据整合和统一管理提供了有力支持。

04 全量与增量数据的同步

        在大量离线数据同步的过程中，业务的连续性和数据的准确性保证十分重要，因此我们采取了两种方式来应对全量数据同步和增量数据同步。

在全量同步场景中，我们首先创建相同表结构的临时表，将全量数据导入临时表后、再利用 ALTER TABLE t1 REPLACE WITH TABLE t2 语句对临时表和正式表进行原子替换操作，该临时表即成为正式表，且前端业务查询不会有任何的阻滞。在增量同步场景则创建了新的增量分区，将增量数据直接同步至增量分区。

05 离线数据加工任务迁移

        当前我们已经把离线数仓的数据加工任务直接迁移到 Doris 进行，采用 Doris SQL 进行数据加工处理，通过调度平台进行任务调度。

        以流水交易宽表场景为例，过去每天需加工三千万条数据、在 Hive 离线数仓采用的 TEZ 计算引擎进行数据加工，在分配 2T 的计算资源下，整条链路加工耗时长达 2.5 小时。当将数据加工任务迁移至 Apache Doris 后，仅使用过去一半的计算资源，即可将整条链路加工耗时缩短为 0.5 小时，整条链路执行效率提升 5 倍以上，且单个脚本执行时效也从 8 分钟提升到 10 秒。

01 多租户资源隔离

在实际业务运行过程中，往往存在多个业务或者不同部门同时查询同一份数据的情况发生，在有限的资源条件下往往可能因查询任务件的资源抢占导致查询性能下降甚至集群不稳定，同时针对组织架构的不同层级对于数据的可见性要求也不一致，因此我们结合自身业务类型以及 Apache Doris 多租户资源隔离能力进行了深度应用。

单查询资源限制，保证查询间资源可控

在对内部多个应用进行梳理后，我们根据业务分析负载对场景和租户进行了细分，主要划分为数据加工（ETL）、数据探索（Ad-hoc）、数据看板（Reporting）和数据服务（Data Serving）四个场景。为确保各个场景及租户之间的独立性，我们对每个场景的单查询进行了资源限制。具体来说，我们为每个租户设置了四类 Doris 账号，并对账号的 CPU 和内存使用资源进行了限制，初始值统一设置为 5 CPU，后续则根据各租户使用情况进行微调，以达到适配的资源分配。目前银联商务各场景分配情况如下：

02 精细用户权限管理

为了满足业务需求和法规合规的要求，银联商务建立了严格的用户权限管理制度。该制度明确了不同用户群体的角色和权限，确保了用户只能访问其需要的功能和数据。以下为银联商务用户权限管理的方案：

• 用户权限设置：针对每个分支机构不同场景的不同用户，为用户设置不同的数据使用权限。
• 库、表、行级权限管理：为满足各分公司权限管理需求，一般会为每个分公司建立视图，该方式操作繁琐，且与 Hive 数仓的使用有较大差异，可能需要对表、语句进行修改。通过 ROW POLICY机制可以便捷实现库、表、行级的权限控制，并可以将原来 Hive 数仓的任务较为无缝地迁移到 Doris 中。
• 列级权限管理：当前采用构建视图的方式进行列级权限管理。
•