银联商务是国内大型的非银行支付机构，沉淀了庞大、真实、优质的数据资产数据。随着业务的不断扩展，早期基于 Hadoop 的大数据平台已无法高效支撑拓展性、时效性与便捷性的业务需求，因此2020 年起，银联商务开启了数据平台的升级之旅，基于Doris 构建了新一代实时数据仓库架构，使数据导入性能提升 2-5 倍、ETL 场景性能提升 3-12 倍、查询分析响应速度提升 10-15 倍，满足大规模数据导入和实时极速查询的业务需求，解决了业务和数据快速增长问题。

一、应用场景

在长期为各行各业的海量商户提供服务的过程中，银联商务沉淀了大量的交易数据、用户数据、终端数据以及经营数据等。

通过对这些数据的挖掘和利用，为银联商务总、分、子公司以及商户提供多元化的数据服务，典型数据服务场景包括：

经营分析场景：建设指标体系和驾驶舱，帮助业务方及管理者实时了解整体业务经营状态
业务经营场景：建设标签体系，更好理解用户画像及需求，从而提供精准的产品和业务服务
数据分析和挖掘场景：构建自助分析和报表服务，更好地了解业务情况并做出科学决策
对外数据服务场景：构建对账单、报表和数据报告服务，以帮助商户更好地了解市场需求。

为满足上述场景需求，银联商务早在 2015年就引入了Hadoop体系构建了大数据平台，并基于Hive构建了离线数仓。该架构整合了来自 MySQL、Oracle、MongoDB 等多业务系统的数据，按照T+1的时效性归集到Hive离线数仓中，经由 Hive数仓各层的加工处理后分别同步至不同组件中提供数据查询服务，包括基于Kylin与HBase构建Cube进行指标查询分析，并使用Hbase进行增量数据的质量监测，同时还将处理完毕的数据同步到Oracle 中提供业务数据查询。

该架构各组件各司其职、整体架构清晰。在移动支付快速席卷的浪潮下，支付场景更加多元化，总部及分子公司对于数据应用的建设需求不断涌现，而传统的大数据平台已经无法高效支撑业务和数据的不断增长，痛点逐步展现出来：

数据时效性：整体数据处理链路较长，最新业务数据从生产到应用的时间间隔太长，无法充分发挥实时数据的价值
查询效率低：Kylin早期承担了大多指标查询分析的需求，随着业务量增长、Kylin数据预处理的成本越来越高，无法支持灵活快速的的分析诉求，而hive在应对复杂查询时效性能不足，只能依赖于堆加机器，这无疑大大增加了硬件资源成本；
运维成本和扩展性：整体架构涉及多个组件，运维工作量较大，在应对业务需求增长的过程中可扩展性不足，无法敏捷响应数据的快速增长和数据应用快速上线的要求

二、OLAP选型

面向各行各业的数千万商户、行业特点和实际需求各不相同，在对企业内部众多平台系统以及对客户提供的产品进行全面梳理后，银联商务确定了数字化转型要实现的核心目标——“全量打通、准确实时、随需自助、智能交互”。

具体而言，“全量打通”即各平台间充分互通、数据融合共享，便于更全面掌握数据主题的全方位信息、充分发挥数据的协同效应；“准确实时”即充分发挥数据的实时价值，并根据技术手段保证数据又“快”又“准”，为后续分析打好坚实基础；“随需自取”即提供自助式的服务，灵活组合、按需取用；“智能交互”即充分利用技术手段，从被动式的接受服务，变成主动式的能力输出，提供分析、预测、辅助决策等智能服务，响应用户需求、实现双向交互。

而具体到数据服务层面，在为内外部客户提供数据服务的过程中，银联商务注意到用户对数据分析的性能、分析模式的灵活性、数据服务的稳定性以及数据应用的时效性有着更高的期望，因此我们决定对现有架构升级，旨在满足新的业务诉求、解决早期架构存在的问题，于是在 2020 年正式启动了银联商务数据架构的升级之旅，升级目标主要包含几方面：

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

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

三、实时数仓构建

在架构的迭代过程中，一方面需要务必保证业务无缝运转、避免系统切换造成业务体验受影响，另一方面需要兼顾与旧有架构的兼容、根据实际情况逐步迭代、渐进式调整，同时也希望充分发挥全新架构的能力优势，因此建设路径逐步明晰：

引入实时数据处理和分析链路，提升数据时效性
推动数据应用从离线迁至实时，并持续提升查询分析效率，为业务提效；
打通离线与实时数据链路的屏障，统一数据口径和数据服务出口，提供一致性的数据服务体验

因此在新的架构中，在原有离线数据仓库体系中增加了一条实时链路，通过kafka将mysql等各类业务数据库中的实时数据归集并传输到Doris中，并利用Flink和 Doris SQL 对数据进行加工处理。在Doris内部构建了从ODS到ADS的数仓分层体系，同时基于Doris提供的Multi-Catalog（多源数据目录）能力打通对Hive数据的查询，避免了繁重的数据迁移成本。各上层数据应用统一对接 Doris 即可，无需在离线数据和实时数据间进行切换，由Doris 统一对外提供查询服务。

这一升级，极大提升了数据处理的效率和查询的便捷性，当前我们正逐步推进离线数仓向以 Doris为核心的实时数仓迁移，为更高效和更大规模的数据管理和分析做好准备。

接下来将介绍基于Doris的实时数仓架构的规划与设计，将从数据模型、分桶策略、数据同步与加工方式出现，分享实时架构搭建的实践经验。

四、实时数仓体系的建设与实践

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

4.1 数仓分层的合理规划

合理的数仓分层对数据的管理以及查询性能的充分发挥起着关键作用，基于Doris丰富的数据模型，对数仓的分层进行了提前规划。Doris 数据模型有：

Duplicate Key明细模型：适用于明细数据查询场景，可支持任何唯独的即席查询
Unique Key更新模型：适用于对数据唯一约束的场景，需要支持数据的精准去重，或者有数据更新需求，可支持大宽表的多流upsert和部分列的更新；
Aggregate Key聚合模型：适用于报表查询场景，通过数据的预聚合来加速报表分析

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

ODS层主要采用明细模型，例如在交易清算场景中，银联商务每天有几千万的清算数据需处理，清算日期跨度长达一年，这就要求所有数据能被完整存储。为了满足这一需求，在ODS层选择Duplicate Key明细模型，完全按照导入文件中的明细数据进行存储，没有任何聚合操作。而部分商户订单数据涉及到订单状态的更新，因此采取Unique Key更新模型，在数据导入过程中如果商户id以及订单id相同时自定更新成最新状态。
DWD与DWS层所采取的数据模型基本相同，其本质差异在于对业务数据的抽象程度，主要采用的是Unique Key更新模型，而部分有明细数据存储的场景还保留了Duplicate Key明细模型。以结算划付场景为例，将结算日期作为分区字段，表模型为 Unique Key 模型，通过这种方式能够实现跨度长达一年结算数据状态的自动更新。
ADS层作为高度业务数据的抽象，采用了Aggregate Key聚合模型，通过对所有结算数据进预聚合，可大幅度提高数据查询和分析的效率，减少实时计算的压力。

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

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

4.3 多源数据迁移方案

在银联商务各分支机构数据迁移至 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 中来，同时，多文件格式的同步解决了分支机构数据不统一、不规范的问题，大大降低了各分支机构数据迁移的难度及成本，为银联商务的数据整合和统一管理提供了有力支持。

4.4 全量与增量数据的同步

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

在全量同步场景中，我们首先创建相同表结构的临时表，将全量数据导入临时表后、再利用 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} ...

4.5 离线数据加工任务迁移

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

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

五、金融级数仓稳定性最佳实践

当前Doris 在银联商务已广泛应用于多个业务场景，服务内部各类经营分析报表、用户标签、自助取数平台等应用，并对外部商户提供了对账单、报表、数据报告等多种数据服务，因此集群的稳定性和可用性对于平台用户体验和业务连续性而言至关重要，任何集群故障或不稳定因素都可能导致业务决策受阻、用户信任度受影响。

5.1 多租户资源隔离

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

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

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

该策略的优点在于，即使单个租户的资源使用量增加，也只会影响该租户在特定场景下的使用，不会对其他租户，其他场景产生任何影响，有效提升了平台的稳定性。

5.1.2 基于Resource Tag的多租户数据与查询隔离

而面对总-分公司的数据使用场景，我们采用了基于Resource Tag的资源组物理隔离方式，以确保数据的安全性和独立性。

目前在Doris 中存储了丰富多样的数据，基于数据安全的角度考虑，对数据可见范围进行了精细划分，总公司可以访问到公司层的全部数据，而分公司只能访问自身业务范畴内的数据。除此以外，还有部分数据是由总公司授权分公司进行查询，或者分公司个性化数据需要与总公司数据进行关联。在这一场景之下，我们采取了Resource Tag的资源隔离模式，将数据和集群可用资源单独划分开来。

具体而言，我们为分公司配置独立的资源组，将分公司个性化数据以三副本的方式存储到独立资源组中，同时将总公司数据设置为四副本，将其中三副本存储在总公司资源组中，剩余单副本存储到分公司独立资源组中。当分公司查询总公司数据时，仅会查询分公司资源组中的单副本数据，通过这样的方式即保证了数据的安全性，也提高了系统的稳定性及可靠性。具体方案如下：

设置 BE 节点标签：分配总公司资源组和分公司资源组，并在服务器上设置对应标签。
设置数据分布：建表时设置 replication_allocation ，同时将总分公司比例设置为 3:1，该比例可结合总分公司的实际使用情况灵活调整。
设置用户资源组：为用户设置对应的默认资源组，总、分公司使用各自资源组，从而实现总分公司查询隔离。

5.1.3 更灵活的资源隔离方案

基于 Resource Tag 的资源隔离方案实现的是物理层级的资源隔离，尽管在独立性方面更佳、但在资源的利用率方面还存在一定的优化空间，并且无法保证进程内更细粒度的资源隔离，因此 Doris 在 2.0 版本中推出了 Workload Group资源软限制。( Workload Group可限制组内任务在单个BE节点上的计算资源和内存资源的使用)

WORKLOAD GROUP - Apache Doris

从实现原理来看， Workload Group 通过对工作负载分组管理，将用户执行的 Query 与 Workload Group 相关联，可限制单个Query在BE节点上的CPU 和内存资源的百分比，并可以配置开启资源组的内存软限制。当集群资源紧张时，可自动终止哪些内存占用较大的查询任务以缓解集群压力。当集群资源空闲时，Workload Group使用资源超过预设值时，其他 Workload Group 可以共享空闲集群资源，并自动突破阙值、确保查询任务的稳定执行，通过这一方式实现内存和 CPU 资源的精细化管控。

我们也在持续探索新版本特性与业务的结合，后续对于数据加工、数据探索、数据看板和数据服务等场景的单查询资源限制可以通过 Workload Group 来实现，并且还可以进一步利用任务优先级和任务排队机制来保证关键业务的优先运转。

5.2 精细用户权限管理

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

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

5.3 集群稳定性保障

5.3.1 SQL熔断

平台对内部用户开放后，经常会面临用户查询SQL不规范消耗过多资源的情况，针对这种情况，采用SQL熔断机制对高危SQL及时熔断，以保证集群的稳定运行

5.3.2 导入并发控制

考虑经常需将历史数据同步到平台中，这就会涉及大量数据修改任务，可能对集群会造成比较大的压力。因此使用了 Unique Key 模型的 Merge-on-Write 更新模式、启动了Vertical Compaction 和 Segment Compaction 并通过调整 Compaction合并参数调整，以控制数据导入频率，减轻集群的压力。

5.3.3 网络流量控制

针对离线、实时不同场景设置了 QoS ，通过 QoS 策略进一步实现网络隔离。考虑到银联商务内部有上海和武汉两套集群，异地网络交互过程中的流量至关重要，因此，我们通过 QoS 策略来实现了精确的网络隔离操作，确保不同场景下的网络服务质量与稳定性。

5.3.4 监控报警

为满足公司内部夜班值班监控的要求，我们使用 Doris 与内部监控报警平台进行对接。将Doris 相关的监控报警与声光监控、CU 即时通讯软件以及邮件进行了对接，实现了对问题的实时监控和处理。

5.4 基于 CCR 的集群灾备能力

对于金融企业而言，服务稳定性和数据安全性是至关重要的一环，而灾备方案是确保业务连续性和数据安全性的重要措施，通过集群灾备，能够在灾难或故障发生时迅速恢复业务和数据，最大程度地减少损失和风险。

对于银联商务的核心业务数据，我们期望能够实现跨集群异地的灾备，因此我们基于跨集群数据复制能力，构架主备集群的双活方案。正常业务查询访问的是主集群，关键业务数据会同时写入至备用集群且保持实时更新，这样即使某个集群发生宕机事件，也可以迅速切换至备用集群，以快速恢复核心业务和数据。

六、总结与规划

截至目前 Doris已经服务了经营分析报表、用户标签、自助取数等多个内部业务以及对外商户数据服务场景。

仅以对账单查询场景为例，在半年对账单场景下数据查询时效从 8 分钟降低到 3 秒，提速超 100 倍，在全年对账单查询中耗时也缩短至 2 分钟内，多数典型查询场景性能提升了 10- 15 倍，整体查询分析效率得到极大幅度提升。此外，数据导入性能平均提升了 2- 5 倍，数据处理加工速度效率提升了 3- 12 倍，数据应用的时效性得到大幅增强。

未来，还将继续深入使用 Doris ，并在以下三个方面进行探索和实践：

统一查询引擎：将Doris作为联邦查询的统一出口，通过Multi-Catalog（多源目录）接入底层各数据源。同时将Doris完全作为对外服务的统一出口，实现数据查询服务的统一路由，为用户提供更便捷、更高效的数据查询服务。
存算分离架构：进一步探索存算分离架构，实现资源的弹性扩缩容，并将离线数仓任务全部迁移到Doris中，实现实时化改造以及计算负载的进一步隔离
自动化运维：对接公司内部的业务流程，实现相关工作的自动化运维处理，并完成业务问题的快速排查；基于 Doris 实现更灵活的数据血缘分析，帮助银联商务更好地理解数据之间的关系和影响

参考文章：

银联商务：Apache Doris 赋能“科技银商”，助力金融机构挖掘增长新机遇

声明：本文内容由网友自发贡献，转载请注明出处：【wpsshop】