导读：在长期服务广大规模商户的过程中，银联商务已沉淀了庞大、真实、优质的数据资产数据，这些数据不仅是银联商务开启新增长曲线的基础，更是进一步服务好商户的关键支撑。为更好提供数据服务，银联商务实现了从 Hadoop 到 Apache Doris 的架构升级，使数据导入性能提升 2-5 倍、ETL 场景性能提升 3-12 倍、查询分析响应速度提升 10-15 倍，满足大规模数据导入和实时极速查询的业务需求，解决了业务和数据快速增长问题，提升了数据应用构建的效率，充分助力业务提效与数字资产的服务化，推进数字化进程的落地，展示了 Apache Doris 在推动金融科技创新方面的巨大潜力。
银联商务是国内大型的非银行支付机构，提供以银行卡收单、网络支付为基础的综合支付服务，以及多样化和专业化的商户增值和科技创新服务，始终致力于为商户、合作伙伴及消费者构筑普惠、便捷、高效、安全的支付环境。截至 2023 年 12月，银联商务已累计服务大中型、知名企业在内的各类商户超过 2500 万家，累计铺设终端超 4000 万台，实体服务网络覆盖中国大陆所有地级以上城市及港澳地区，收单交易笔数连续十年蝉联尼尔森亚太地区收单机构榜首。
如今，数据已经成为了推动经济增长的新动力，数字技术正在成为社会发展的重要引擎。随着数字经济的迅猛发展，金融企业纷纷加大在金融科技领域的投入，以提升自身的数字化运营能力，加速数字化转型的进程。在这一背景之下，银联商务以 “全量打通、准确实时、随需自助、智能交互” 为数字化转型目标，加快推进数字基础设施建设。
在长期服务广大规模商户的过程中，银联商务已沉淀了庞大、真实、优质的数据资产数据，这些数据不仅是银联商务开启新增长曲线的基础，更是进一步服务好商户的关键支撑。为了实现数据资产可管理、可视化、可赋能的建设目标，银联商务早在 2015 年就基于 Hadoop 体系构建了大数据平台，为公司及商户提供了数据支持。但随着业务的不断扩展，银联商务总公司各部门和分子公司对于数据应用的建设需求不断涌现，早期基于 Hadoop 的大数据平台已无法高效支撑拓展性、时效性与便捷性的业务需求，因此数据平台的迭代升级势在必行。
2020 年起，银联商务开启了数据平台的升级之旅，基于 Apache Doris 构建了新一代实时数据仓库架构，使数据导入性能提升 2-5 倍、ETL 场景性能提升 3-12 倍、查询分析响应速度提升 10-15 倍，满足大规模数据导入和实时极速查询的业务需求，解决了业务和数据快速增长问题，提升了数据应用构建的效率，充分助力业务提效与数字资产的服务化，推进数字化进程的落地。
应用场景
在长期为各行各业的海量商户提供服务的过程中，银联商务沉淀了大量的交易数据、用户数据、终端数据以及经营数据等。通过对这些数据的挖掘和利用，为银联商务总、分、子公司以及商户提供多元化的数据服务，可以发掘隐藏在其中的价值和消费趋势，成为掌握经营掌控、进行经营决策的有效工具。典型数据服务场景包括：
- 经营分析场景：建设指标体系和驾驶舱，帮助业务方及管理者实时了解整体业务经营状态。
- 业务运营场景：建设标签体系，更好理解用户画像及需求，从而提供精准的产品和业务服务。
- 数据分析和挖掘场景：构建自助分析和报表服务，更好地了解自己的业务情况并做出科学决策。
- 对外数据服务场景：构建对账单、报表和数据报告服务，以帮助商户更好地了解市场需求。
为满足上述场景需求，银联商务早在 2015 年就引入了 Hadoop 体系构建了大数据平台，并基于 Hive 构建了离线数仓。该架构整合了来自 MySQL、Oracle、MongoDB 等多业务系统的数据，按照 T+ 1 的时效性归集到 Hive 离线数仓中，经由 Hive 数仓各层的加工处理后分别同步至不同组件中提供数据查询服务，包括基于 Kylin 与 HBase 构建 Cube 进行指标查询分析，并使用 HBase 进行增量数据的质量监测，同时还将处理完毕的数据同步到 Oracle 中提供业务数据查询。
该架构各组件各司其职、整体架构清晰，在早期承载了业务对于数据查询服务的需求。在移动支付快速席卷的浪潮下，支付场景更加多元化，银联商务业务规模稳步增长、总部及分子公司对于数据应用的建设需求不断涌现，而传统的大数据平台已经无法高效支撑业务和数据的不断增长，痛点逐步展现出来：
- 数据时效性：整体数据处理链路较长，大规模数据导入和加工处理的效率低，最新业务数据从生产到应用的时间间隔太长，无法充分发挥实时数据的价值；
- 查询效率低：Kylin 早期承担了大多指标查询分析的需求，随着业务量增长、数据预处理的成本越来越高、无法支持灵活快速的分析诉求，而 Hive 在应对复杂查询时性能不足、只能依赖于堆加机器，这无疑大大增加了硬件资源成本；
- 运维成本和可扩展性：整体架构涉及多个组件，运维工作量较大，在应对业务需求增长的过程中可扩展性不足，无法敏捷响应数据的快速增长和数据应用快速上线的要求。
目标及选型
面向各行各业的数千万商户、行业特点和实际需求各不相同，在对企业内部众多平台系统以及对客户提供的产品进行全面梳理后，银联商务确定了数字化转型要实现的核心目标——“全量打通、准确实时、随需自助、智能交互”。
具体而言，“全量打通”即各平台间充分互通、数据融合共享，便于更全面掌握数据主题的全方位信息、充分发挥数据的协同效应；“准确实时”即充分发挥数据的实时价值，并根据技术手段保证数据又“快”又“准”，为后续分析打好坚实基础；“随需自取”即提供自助式的服务，灵活组合、按需取用，甚至实现量身定制、因客而变；“智能交互”即充分利用技术手段，从被动式的接受服务，变成主动式的能力输出，提供分析、预测、辅助决策等智能服务，响应用户需求、实现双向交互。
而具体到数据服务层面，在为内外部客户提供数据服务的过程中，银联商务注意到用户对数据分析的性能、分析模式的灵活性、数据服务的稳定性以及数据应用的时效性有着更高的期望，因此我们决定对现有架构升级，旨在满足新的业务诉求、解决早期架构存在的问题，于是在 2020 年正式启动了银联商务数据架构的升级之旅，升级目标主要包含几方面：
- 统一、简洁：单一系统即可完成数据加工和服务的统一，以简化数据处理流程，提高工作效率；
- 稳定、高效：支持高效的数据加工和高性能的数据查询，同时系统和平台的稳定性得以充分的保证；
- 准确、实时：支持数据实时更新以及接入，保证数据准确、不丢不重；
- 安全、可靠：确保数据访问和数据存储的安全性，支持集群灾备、数据高可靠；
基于以上目标，我们进行了深入的调研，在对比了多种大数据组件后，选择引入 Apache Doris 来构建新一代实时数据仓库架构。
基于 Apache Doris 的新一代实时数仓架构
在架构的迭代过程中，一方面我们需要务必保证业务无缝运转、避免系统切换造成业务体验受影响，另一方面需要兼顾与旧有架构的兼容、根据实际情况逐步迭代、渐进式调整，同时也希望充分发挥全新架构的能力优势，因此建设路径逐步明晰：
- 引入实时数据处理和分析链路，提升数据时效性；
- 推动数据应用从离线迁至实时，并持续提升查询分析效率，为业务提效；
- 打通离线与实时数据链路的屏障，统一数据口径和数据服务出口，提供一致性的数据服务体验；
因此在新的架构中，在原有离线数据仓库体系中增加了一条实时链路，通过 Kafka 将 MySQL 等各类业务数据库中的实时数据归集并传输到 Apache Doris 中，并利用 Flink 和 Doris SQL 对数据进行加工处理，在 Doris 内部构建了从 ODS 到 ADS 的数仓分层体系。同时基于 Doris 提供的 Multi-Catalog 能力打通对 Hive 数据的查询，避免了繁重的数据迁移成本。各上层数据应用统一对接 Doris 即可，无需在离线数据和实时数据间进行切换，由 Doris 统一对外提供查询服务。
这一升级，极大提升了数据处理的效率和查询的便捷性，当前我们正逐步推进离线数仓向以 Apache Doris 为核心的实时数仓迁移，为更高效和更大规模的数据管理和分析做好准备。
接下来我们将介绍基于 Apache Doris 的实时数仓架构的规划与设计，我们将从数据模型、分桶策略、数据同步与加工方式出发，分享实时架构搭建的实践经验。
实时数据仓库体系的建设与实践
在建设数据仓库体系时，银联商务遵循边治理、边建设、边赋能的原则，数据治理为关键一环，而统一规划又是其核心内容。因此数据仓库的统一规划能够确保数据仓库结构设计的合理性，不仅有利于后续对架构的管理维护，也有利于对数据可靠性和一致性的保障。因此我们在数据仓库统一规划方面采取了以下措施：
数仓分层的合理规划
合理的数仓分层对数据的管理以及查询性能的充分发挥起着关键作用，基于 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 模型，通过对所有结算数据进行预聚合，可大幅提高数据查询和分析的效率，减少实时计算的压力。
分桶分区策略的合理设置
分区分桶是优化数据存储和提升查询效率的重要手段，合理设置分桶数和分桶字段可以有效提升查询速度和数据加工脚本的执行效率。在数仓应用中，我们参考实际数据规模和官网的设置建议，会对每一张表均规划了分桶字段和分桶数。例如，在分店宽表中经常需要查询分店维度数据，因此我们将分店作为分桶字段，并根据表的大小设置分桶数。以下是我们在不同 Tablet 下 Bucket 设置的数量，可供参考：
多源数据迁移方案
在银联商务各分支机构数据迁移至 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 中来，同时，多文件格式的同步解决了分支机构数据不统一、不规范的问题，大大降低了各分支机构数据迁移的难度及成本，为银联商务的数据整合和统一管理提供了有力支持。
全量与增量数据的同步
在大量离线数据同步的过程中，业务的连续性和数据的准确性保证十分重要，因此我们采取了两种方式来应对全量数据同步和增量数据同步。
在全量同步场景中，我们首先创建相同表结构的临时表，将全量数据导入临时表后、再利用 ALTER TABLE t1 REPLACE WITH TABLE t2 语句对临时表和正式表进行原子替换操作，该临时表即成为正式表，且前端业务查询不会有任何的阻滞。在增量同步场景则创建了新的增量分区，将增量数据直接同步至增量分区。
alter table ${DB_NAME}.${TBL_NAME} drop partition IF EXISTS p${P_DOWN_DATE};
ALTER TABLE ${DB_NAME}.${TBL_NAME} ADD PARTITION IF NOT EXISTS p${P_DOWN_DATE} VALUES [('${P_DOWN_DATE}'), ('${P_UP_DATE}'));
LOAD LABEL ${TBL_NAME}_${load_timestamp} ...
离线数据加工任务迁移
当前我们已经把离线数仓的数据加工任务直接迁移到 Doris 进行，采用 Doris SQL 进行数据加工处理，通过调度平台进行任务调度。
以清分流水交易宽表场景为例，过去每天需加工三千万条数据、在 Hive 离线数仓采用的 TEZ 计算引擎进行数据加工，在分配 2T 的计算资源下，整条链路加工耗时长达 2.5 小时。当将数据加工任务迁移至 Apache Doris 后，仅使用过去一半的计算资源，即可将整条链路加工耗时缩短为 0.5 小时，整条链路执行效率提升 5 倍以上，且单个脚本执行时效也从 8 分钟提升到 10 秒。
金融级数仓稳定性最佳实践
当前 Apache Doris 在银联商务已广泛应用于多个业务场景，服务了内部各类经营分析报表、用户标签、自助取数平台等应用，并对外部商户提供了对账单、报表、数据报告等多种数据服务，因此集群的稳定性和可用性对于平台用户体验和业务连续性而言至关重要，任何集群故障或不稳定因素都可能导致业务决策受阻、用户信任度受影响。
因此银联商务采取大量措施来保证集群稳定性和可用性，包括多租户资源隔离、精细权限管理、集群灾备以及多种稳定性调优策略。
多租户资源隔离
在实际业务运行过程中，往往存在多个业务或者不同部门同时查询同一份数据的情况发生，在有限的资源条件下往往可能因查询任务件的资源抢占导致查询性能下降甚至集群不稳定，同时针对组织架构的不同层级对于数据的可见性要求也不一致，因此我们结合自身业务类型以及 Apache Doris 多租户资源隔离能力进行了深度应用。
单查询资源限制，保证查询间资源可控
在对内部多个应用进行梳理后，我们根据业务分析负载对场景和租户进行了细分，主要划分为数据加工（ETL）、数据探索（Ad-hoc）、数据看板（Reporting）和数据服务（Data Serving）四个场景。为确保各个场景及租户之间的独立性，我们对每个场景的单查询进行了资源限制。具体来说，我们为每个租户设置了四类 Doris 账号，并对账号的 CPU 和内存使用资源进行了限制，初始值统一设置为 5 CPU，后续则根据各租户使用情况进行微调，以达到适配的资源分配。目前银联商务各场景分配情况如下：
该策略的优点在于，即使单个租户的资源使用量增加，也只会影响该租户在特定场景下的使用，不会对其他租户、其他场景产生任何影响，有效提升了平台的稳定性。
基于 Resource Tag 的多租户数据与查询隔离
而面对总-分公司的数据使用场景，我们采用了基于 Resource Tag 的资源组物理****隔离方式，以确保数据的安全性和独立性。
目前在 Apache Doris 中存储了丰富多样的数据，基于数据安全的角度考虑，对数据可见范围进行了精细划分，总公司可以访问到公司层的全部数据，而分公司只能访问自身业务范畴内的数据。除此以外，还有部分数据是由总公司授权分公司进行查询，或者分公司个性化数据需要与总公司数据进行关联。在这一场景之下，我们采取了 Resource Tag 的资源隔离模式，将数据和集群可用资源单独划分开来。
具体而言，我们为分公司配置独立的资源组，将分公司个性化数据以三副本的方式存储到独立资源组中，同时将总公司数据设置为四副本，将其中三副本存储在总公司资源组中，剩余单副本存储到分公司独立资源组中。当分公司查询总公司数据时，仅会查询分公司资源组中的单副本数据，通过这样的方式即保证了数据的安全性，也提高了系统的稳定性及可靠性。具体方案如下：
- 设置 BE 节点标签：分配总公司资源组和分公司资源组，并在服务器上设置对应标签。
- 设置数据分布：建表时设置
replication_allocation，同时将总分公司比例设置为 3:1，该比例可结合总分公司的实际使用情况灵活调整。 - 设置用户资源组：为用户设置对应的默认资源组，总、分公司使用各自资源组，从而实现总分公司查询隔离。
更灵活的资源隔离方案
基于 Resource Tag 的资源隔离方案实现的是物理层级的资源隔离，尽管在独立性方面更佳、但在资源的利用率方面还存在一定的优化空间，并且无法保证进程内更细粒度的资源隔离，因此 Apache Doris 在 2.0 版本中推出了 Workload Group 资源软限制。
从实现原理来看， Workload Group 通过对工作负载分组管理，将用户执行的 Query 与 Workload Group 相关联，可限制单个 Query 在 BE 节点上的 CPU 和内存资源的百分比，并可以配置开启资源组的内存软限制。当集群资源紧张时，可自动终止内存占用较大的查询任务以缓解集群压力。当集群资源空闲时，当 Workload Group 使用资源超过预设值时，其他 Workload Group 可以共享空闲集群资源，并自动突破阙值、确保查询任务的稳定执行，通过这一方式实现内存和 CPU 资源的精细化管控。
我们也在持续探索新版本特性与业务的结合，后续对于数据加工、数据探索、数据看板和数据服务等场景的单查询资源限制可以通过 Workload Group 来实现，并且还可以进一步利用任务优先级和任务排队机制来保证关键业务的优先运转。
精细用户权限管理
为了满足业务需求和法规合规的要求，银联商务建立了严格的用户权限管理制度。该制度明确了不同用户群体的角色和权限，确保了用户只能访问其需要的功能和数据。以下为银联商务用户权限管理的方案：
- 用户权限设置：针对每个分支机构不同场景的不同用户，为用户设置不同的数据使用权限。
- 库、表、行级权限管理：为满足各分公司权限管理需求，一般会为每个分公司建立视图，该方式操作繁琐，且与 Hive 数仓的使用有较大差异，可能需要对表、语句进行修改。通过
ROW POLICY机制可以便捷实现库、表、行级的权限控制，并可以将原来 Hive 数仓的任务较为无缝地迁移到 Doris 中。 - 列级权限管理：当前采用构建视图的方式进行列级权限管理。
集群稳定性保障
- SQL 熔断：平台对内部用户开放后，经常会面临用户查询 SQL 不规范消耗过多资源的情况，针对于这种情况，采用 SQL 熔断机制对高危的 SQL 及时熔断，以保证集群的稳定运行。
- 导入并发控制：考虑我们经常需将历史数据同步到平台中，这就会涉及大量数据修改任务，可能对集群会造成比较大的压力。因此，我们使用了 Unique Key 模型的 Merge-on-Write 更新模式、启用了 Vertical Compaction 和 Segment Compaction 并通过调整 Compaction 参数调整，以控制数据导入频率、减轻集群的压力。
- 网络流量控制：针对离线、实时不同场景设置了 QoS ，通过 QoS 策略进一步实现网络隔离。考虑到银联商务内部有上海和武汉两套集群，异地网络交互过程中的流量至关重要，因此，我们通过 QoS 策略来实现了精确的网络隔离操作，确保不同场景下的网络服务质量与稳定性。
- 监控报警：为满足公司内部夜班值班监控的要求，我们使用 Doris 与内部监控报警平台进行对接。将 Doris 相关的监控报警与声光监控、CU 即时通讯软件以及邮件进行了对接，实现了对问题的实时监控和处理。
基于 CCR 的集群灾备能力
对于金融企业而言，服务稳定性和数据安全性是至关重要的一环，而灾备方案是确保业务连续性和数据安全性的重要措施，通过集群灾备，能够在灾难或故障发生时迅速恢复业务和数据，最大程度地减少损失和风险。
对于银联商务的核心业务数据，我们期望能够实现跨集群异地的灾备，因此我们基于跨集群数据复制能力构建主备集群的双活方案。正常业务查询访问的是主集群，关键业务数据会同步写入至备用集群且保持实时更新，这样即使某个集群发生宕机事件，也可以迅速切换到备用集群，以快速恢复核心业务和数据。
总结与规划
面对日益增长的数据处理和分析需求，银联商务选择基于 Apache Doris 构建新一代实时数据仓库，截至目前 Apache Doris 已经服务了经营分析报表、用户标签、自助取数等多个内部业务以及对外商户数据服务场景。
仅以对账单查询场景为例，在半年对账单场景下数据查询时效从 8 分钟降低到 3 秒，提速超 100 倍，在全年对账单查询中耗时也缩短至 2 分钟内，多数典型查询场景性能提升了 10- 15 倍，整体查询分析效率得到极大幅度提升。此外，数据导入性能平均提升了 2- 5 倍，数据处理加工速度效率提升了 3- 12 倍，数据应用的时效性得到大幅增强。
通过更高效、更实时、更灵活的数据分析支持，银联商务能够更好地理解市场、把握机会、优化运营，从而实现业务的持续增长和创新发展。未来，银联商务还将继续深入使用 Apache Doris ，并在以下三个方面进行探索和实践：
- 统一查询引擎：将 Doris 作为联邦查询的统一入口，通过 Multi-Catalog 接入底层各数据源。同时将 Doris 完全作为对外数据服务的统一出口，实现数据查询服务的统一路由，为用户提供更便捷、更高效的数据查询服务。
- 存算分离架构：进一步探索存算分离架构、实现资源的弹性扩缩容，并将离线数仓任务全部迁移到 Doris 中，实现实时化改造以及计算负载的进一步隔离。
- 自动化运维：对接公司内部的业务流程，实现相关工作的自动化运维处理，并完成业务问题的快速排查；基于 Doris 实现更灵活的数据血缘分析，帮助银联商务更好地理解数据之间的关系和影响，为业务决策提供更准确的数据管理支持。
