1、金融信息化研究所（FITI）2022 年 11 月（白皮书）编制委员会主 任：潘润红副主任：习 辉、庄文君编委会成员（排名不分先后，按姓氏拼音排序）：董理斌、辜 敏、郭 煜、刘远东、李 凡、彭贵平、饶争光、田永江、童 蕙、王 瑜、魏文术、向 民、谢云龙、叶 涛、尤 鹏、尤 俊、周 全执 笔（排名不分先后，按姓氏拼音排序）：曹嘉欣、从平平、冯明亮、高 犇、高 鹏、侯 伟、黄海燕、黄书春、李 杰、李 智、刘志浩、刘振东、彭 强、孙玖山、苏 萌、王汉福、王健楠、王帅强、王志远、魏 冲、徐嘉禛、杨 锐、杨大鹏、赵昆鹏、赵义斌、张 倩、周晓阳、朱并队统稿人（排名不分先后，按姓氏拼音排序）：从平平、张 倩

2、主编单位：金融信息化研究所华为云计算技术有限公司中国工商银行股份有限公司交通银行股份有限公司中国光大银行股份有限公司招商银行股份有限公司参编单位：中信银行股份有限公司中国民生银行股份有限公司华夏银行股份有限公司兴业银行股份有限公司中原银行股份有限公司威海市商业银行股份有限公司江苏江南农村商业银行股份有限公司中电金信软件有限公司深圳市长亮科技股份有限公司北京宇信科技集团股份有限公司I金融数据仓库发展报告（白皮书）摘 要随着数字金融快速发展，金融业数据量爆发式增长，数据挖掘、分析、应用已逐步成为金融业务发展和管理决策的重要支撑手段，数据成为金融机构的核心资产。数据仓库可对异构源数据进行有效集成，面

3、向数据分析场景，支持全局信息共享和决策分析处理，充分释放数据价值，助力构建数据要素市场。针对金融数据服务、存储、处理、质量和安全等不同维度的需求，金融数据仓库需提供适配的架构和技术，包括超大规模并行处理满足海量数据的算力要求、高可用及容灾技术实现数据永远在线、动态负载管理满足多样化负载统一管理、数据安全技术保障数据合规访问、融合分析技术打通结构化与非结构化数据分析边界、弹性扩展技术满足系统在线按需扩展以及管控一体的智能运维释放运维压力等。为顺利开展金融数据仓库建设，金融机构应进行合理规划、精心组织、高效实施，准确把握数据仓库的 T+0，湖仓一体、数智融合、存算分离、高维分析、HTAP、Data

4、 Mesh、Data Fabric、现代数据栈及数据共享十大发展趋势，切实提升金融数据应用水平，助力金融科技快速发展、金融业数字化转型深入推进。I金融数据仓库发展报告（白皮书）目 录1.概述.011.1.数据仓库发展历程.011.2.数据仓库成为金融行业的重要应用.022.金融数据仓库发展现状.042.1.金融数据仓库建设进展.042.2.金融数据仓库数据存储情况.072.3.金融数据仓库投入情况.082.4.金融行业使用数据仓库的痛点及诉求.093.金融关键业务对数据仓库的要求.113.1.数据服务要求.113.2.数据存储要求.123.3.数据处理要求.143.4.数据质量要求.153.5

5、.数据安全要求.164.金融数据仓库总体设计与关键技术.184.1.金融数据仓库模型.184.1.1.数据仓库模型设计原则.184.1.2.数据仓库模型层次.204.1.3.数据仓库建模方式.204.2.金融数据仓库架构设计.214.2.1.数据仓库架构设计原则.214.2.2.数据仓库典型设计架构.224.3.金融数据仓库典型技术架构.234.4.金融数据仓库的关键技术.254.4.1.超大规模并行处理满足海量数据的算力要求.254.4.2.高可用及容灾技术实现数据永远在线.26II4.4.3.动态负载管理满足多样化负载统一管理.274.4.4.数据安全技术保障数据合规访问.294.4.5.

6、融合分析技术打通结构化与非结构化数据分析边界.304.4.6.弹性扩展技术满足系统在线按需扩展.304.4.7.管控一体的智能运维释放运维压力.315.金融数据仓库建设策略.335.1.指导原则.335.2.建设规划策略.335.2.1.实施规划.345.2.2.运营规划.355.3.实施要求.385.3.1.组织架构.385.3.2.实施过程.395.3.3.规范约束.395.3.4.实施注意事项.405.3.5.主要交付件.406.金融数据仓库十大发展趋势.426.1.T+0 分析.436.2.湖仓一体.446.3.数智融合.446.4.数据共享.456.5.存算分离.456.6.高维分析

7、.466.7.HTAP.466.8.数据网格（Data Mesh）.476.9.数据编织（Data Fabric）.476.10.现代数据栈（Modern Data Stack）.47附录：金融数据仓库行业实践.49金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究I图目录图 1 金融数据仓库建设情况.04图 2 不同类型金融机构使用我国主流数据仓库产品情况.05图 3 国有大行、股份制银行主流金融数据仓库产品使用情况.06图 4 金融数据仓库数据量分布情况.07图 5 不同类型金融机构数据仓库数据量情况.08图 6 数据仓库在所有数据库中的投入占比情况.08图

8、 7 金融数据仓库应用的主要痛点分析.09图 8 金融机构对数据仓库的诉求分析.10图 9 数据仓库典型设计架构示意图.22图 10 典型银行的数据仓库平台技术架构图.24图 11 数据仓库建设规划示意图.33图 12 容灾规划的三种形式.37图 13 实施组织架构图.38图 14 金融行业对数据仓库技术关注热度分布.42金融数据仓库发展报告（白皮书）01金融数据仓库发展报告（白皮书）1.概述1991 年 Bill Inmon 在Building the Data Warehouse书中提出数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用

9、于支持管理决策。1.1.数据仓库发展历程早在 20 世纪 70 年代就开始萌发数据仓库的概念，却在相当长一段时间都停留在理论层面。一直到数据仓库基本原理、技术架构以及分析系统等主要原则确定，数据仓库才初具雏形。但由于数据仓库的实施难度过大，在方法和架构上很难有清晰的路径，导致大多以失败告终。此时，02金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究数据集市因实施难度较低，并且能够满足企业部分业务部门的迫切需求，得到了一定的发展。而随着数据集市的不断增多，独立建设的数据集市由于遵循不同的标准和建设原则，导致多个数据集市的数据混乱、不一致，进而产生数据孤岛。为了解

10、决这个问题，1998 年 Inmon 提出了新的BI 架构 CIF（Corporation Information Factory，企业信息工厂），即在不同架构层次上采用不同的构件来满足不同的业务需求。进入21世纪，信息化转型的大潮席卷而来，数据量呈现爆炸式增长，得力于 Oracle、IBM 及 Teradata 等产品在分析型应用上的成熟，数据仓库产品快速发展。1.2.数据仓库成为金融行业的重要应用数据仓库作为金融行业数据分析平台的核心，能对异构源数据进行有效集成，面向数据分析场景，支持全局信息共享和决策分析处理，已成为金融行业重要的基础设施。经过几十年的演进和创新，当前各金融机构主要使用的

11、是第二代探索型数据仓库。未来，随着技术的迭代，金融数据仓库会不断向着运营型和智慧型迈进。初代描述型数据仓库，基于历史数据反映发生了什么事情。金融机构通过 BI 服务和固定报表等主要应用做 T+1 批量数据分析，为外部监管机构报送、内部经营分析及运营管理提供准确的数据支撑。第二代探索型数据仓库，增加了数据科学场景支持，业务分析师通过自助分析挖掘数据价值，研究历史数据得知为什么会发生这些情况。由于可以很好支持半结构化和非结构化数据，支持数据科学和机器学习，金融数据仓03金融数据仓库发展报告（白皮书）库的应用范围开始迅速扩展，除了传统的监管审计类报表应用，还涵盖了客户服务、产品销售、风险管理、绩效管

12、理等领域的完整数据应用，数据处理成为整个应用价值链交付中非常重要的环节。但随着互联网金融、移动支付等金融服务爆炸式扩展，金融机构在风险管控和运营管理的时效性面临越来越大的挑战。第三代运营型数据仓库应时而生，也称之为实时数仓，基于 T+0 数据描述正在发生的事情。其对探索型数据仓库的 ETL 方式、源批量文件接入方式进行了优化，以ELT 模式实时接入源数据，强调 HTAP 混合负载能力，解决时效性问题，让金融机构能够从实时动态的监控指标体系寻找机会、防控风险，帮助决策者实时运营。此外，目前金融机构内部数据平台尚未完全打通，机构之间数据处于割裂状态，资源配置效率不高。同时，国家政策提出要从“数字基

13、建”向“数智基建”转变，数据仓库作为数据基础设施的基石，通过数流和智流的融合，可助力资源配置效率提升、金融风险控制、数据资产共享。因此，金融机构开始探索面向未来的预测型数仓，也称之为智慧型数据仓库，可以描述将来要发生什么，以及如何引导未来。智慧型数仓融合数据分析技术和人工智能技术，引入人工智能在视频、图像、语音等非结构化数据的高效处理的能力，替代人类重复性工作，将有效提升工作效率与用户体验。总体而言，金融数据仓库从仅支持批量报表服务，到支持数据探索、实时分析、数智融合，支撑金融业务持续创新。04金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究2.金融数据仓库发

14、展现状2.1.金融数据仓库建设进展银行、证券、保险等不同领域的金融机构普遍建设了数据仓库，以满足金融业务对数据的需求。银行业建设数据仓库占比最高，证券业和保险业相对较低，同时，银行业不同类型机构数据仓库建设情况也不相同。国有大行、股份制银行、直辖市农商行及省联社基本都建设了数据仓库，占比达到 100%，而区域性城市商业银行尚有部分机构未建设数据仓库，以数据集市应用为主，如图 1 所示。图 1 金融数据仓库建设情况数据来源：金融信息化研究所金融数据仓库建设情况国有大行股份制银行城市商业银行直辖市农商行、省联社证券业保险业80.00%85.00%90.00%95.00%100.00%105.00%

15、100.00%100.00%92.31%100.00%88.46%86.67%05金融数据仓库发展报告（白皮书）不同类型金融机构使用我国主流数据仓库产品的情况也不相同，相较于证券业和保险业，银行业使用我国数据仓库产品的机构数量占比较高。不同类型的银行业金融机构使用情况也不同，其中国有大行基本都使用我国数据仓库产品或采取自研自建数据仓库的模式，机构数量占比达到 83.33%，其次是股份制商业银行和直辖市农商行、省联社，区域性城市商业银行使用我国数据仓库产品的机构数量占比较低，如图 2 所示。图 2 不同类型金融机构使用我国主流数据仓库产品情况数据来源：金融信息化研究所不同类型金融机构使用我国主流

16、数据仓库产品情况10.00%20.00%30.00%40.00%50.00%60.00%70.00%80.00%90.00%83.33%66.67%45.45%14.71%9.09%7.69%国有大行股份制银行 直辖市农商行、省联社城市商业银行证券业保险业0.00%06金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究1由于有些机构使用了多家厂商的数据仓库产品，因此不同产品的百分比加和大于 100%。通过调研全量的国有大行和股份制银行关于我国主流数据仓库产品使用情况，可以发现其使用最多的数据仓库产品是华为云GaussDB(DWS)，机构数量占比达到 38.89%

17、，其次是南大通用 GBase 8a 和阿里云 AnalyticDB，然后是阿里云 Maxcompute 和星环 ArgoDB，此外还有 2 家机构采用自研自建模式建设数据仓库，如图 3 所示。图 3 国有大行、股份制银行主流金融数据仓库产品使用情况1数据来源：金融信息化研究所国有大行、股份制银行使用主流数据仓库产品情况38.89%22.22%16.67%11.11%9.09%5.56%5.56%5.56%5.56%华为云GaussDB(DWS)TeradataOracle/Exadata南大通用GBase 8a阿里云AnalyticDB阿里云Maxcompute星环ArgoDB Vertica

18、Greenplum10.00%20.00%30.00%40.00%50.00%0.00%07金融数据仓库发展报告（白皮书）不同类型金融机构数据仓库存储的数据量差异较大，国有大行数据仓库存储的数据量平均值最大，达到 10.76PB；其次是股份制银行，数据仓库存储的数据量平均为 1.49PB；区域性城市商业银行、直辖市农商行、省联社、证券业、保险业等金融机构数据仓库存储的数据量平均值基本持平，均处于 TB 级别，只有个别金融机构达到了 PB 级别，如图 5 所示。2.2.金融数据仓库数据存储情况金融数据仓库存储的数据量基本是 TB 级别，其中，数据量在 50T以下的金融机构占比达到 45.75%，

19、接近一半。金融数据仓库存储的数据量达到 PB 级别的金融机构占比达到 15.96%，但基本在 10PB 以下，数据量在 10PB 以上的金融机构占比仅有 2.13%，如图 4 所示。图 4 金融数据仓库数据量分布情况数据来源：金融信息化研究所金融数据仓库数据量分布情况50T-100T10T以下200T-300T400T-500T1P-10P10T-50T100T-200T500T-1P300T-400T10P以上21.28%11.70%6.38%4.26%1.06%2.13%13.83%2.13%12.77%24.47%08金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、

20、信息安全研究图 5 不同类型金融机构数据仓库数据量情况数据来源：金融信息化研究所不同类型金融机构数据仓库数据量情况（平均值，单位：PB）1.490.260.280.330.250.002.004.006.008.0010.0012.00国有大行股份制银行城市商业银行 直辖市农商行、省联社证券业保险业10.762.3.金融数据仓库投入情况绝大部分金融机构数据仓库的投入在所有数据库投入中的占比均小于50%，机构数量占比达到 86.75%，其中投入占比小于 10%的金融机构占比最高，为 25.3%；数据仓库的投入在所有数据库投入中的占比在 70%以上的金融机构数量较少，仅有 4.81%，如图 6 所

21、示。图6 数据仓库在所有数据库中的投入占比情况数据来源：金融信息化研究所数据仓库在所有数据库中的投入占比情况60%-70%20%-30%0-10%80%-90%40%-50%10%-20%70%-80%50%-60%30%-40%90%-100%25.30%20.48%19.28%15.66%6.02%8.43%1.20%0.00%1.20%2.41%09金融数据仓库发展报告（白皮书）2.4.金融行业使用数据仓库的痛点及诉求不同类型金融机构现有数据仓库应用过程中面临的主要痛点各不相同。其中国有大行因其海量数据，更关注容量瓶颈问题；其他金融机构相对国有大行数据治理体系还不完善，基本都面临数据质量

22、问题。具体情况如图 7 所示。图 7 金融数据仓库应用的主要痛点分析数据来源：金融信息化研究所金融数据仓库应用的主要痛点分析数据质量性能数据时效性容量瓶颈原厂服务能力备份容灾其他扩容能力周边配套工具完善性成本数据互通（各系统之间）国有大行股份制银行城市商业银行 直辖市农商行、省联社证券业保险业90.00%80.00%70.00%60.00%50.00%40.00%30.00%20.00%10.00%0.00%10金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究总体来看，由于金融机构实时分析场景和预测分析的需求增加、数据量激增和数据共享需求增加，以及对数据仓库性

23、能要求不断提升，金融机构对数据仓库进一步发展的诉求主要集中在T+0分析、数智融合（AI）、湖仓一体、存算分离及数据共享。考虑实时分析、预测分析、数据量等因素，不同类型金融机构对数据仓库进一步发展的诉求不尽相同。具体情况如图 8 所示。图 8 金融机构对数据仓库的诉求分析数据来源：金融信息化研究所金融机构对数据仓库的诉求分析HTAP数据共享T+0分析其他存算分离数智融合（AI）湖仓一体高维分析国有大行股份制银行城市商业银行 直辖市农商行、省联社证券业保险业0.00%20.00%40.00%60.00%80.00%100.00%120.00%11金融数据仓库发展报告（白皮书）3.金融关键业务对数据

24、仓库的要求目前各家金融机构逐步建立企业级数据仓库,按照数据统一服务、数据集中存储、数据高效处理、数据质量和数据安全管理的要求，科学合理地对金融数据进行详细分类,准确收集和分析信息,确保企业管理层随时掌握企业的运营情况、经营风险和经营目标。3.1.数据服务要求一是在数据服务方式多样性方面，支撑金融关键业务的数据服务方式有数据文件服务、数据 API 服务、消息服务及数据管道。数据仓库作为数据生产者，提供数据消费是其业务价值的主要体现，金融数据仓库对接的部门和分支机构众多，通常达数百个之多，其数据消费方式多样，时效性要求也各不相同，数据仓库需要提供多种数据服务形式，以满足数据服务多样化诉求。具体而言

25、，监管报送、客户对账单、营销短信等金融业务场景需要数据文件服务。数据 API 服务主要应用于企业管理者视图、客户信息和交易消费记录的实时查询。消息服务主要应用于常规消息、系统活性跟踪、聚合统计系统运营、日志等数据的收集场景。数据管道每日批量从外部数据获取最新全量数据（如银联、汇法网等），实现对外部数据的统一接入、存储、应用和管理。12金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究二是在数据服务时效性方面，金融数据仓库的数据服务要包括批量服务和实时服务。金融业务场景对于数据服务的时效性要求不同，对于处理数据量大，计算复杂，时效性要求不高的业务场景需采用批量服务

26、，即根据确定数据范围进行一次性大规模批量加工计算，应用场景主要是风险指标计算，经营指标计算，监管报送报表计算等。对于计算量级相对较小，主要强调计算过程时间的业务场景需要采用实时服务，即计算当下给出结果，在金融业的应用场景主要是实时风控、实时营销以及实时报表等。三是在数据服务实用性方面，要提升数据的易读性、易用性、稳定性和可扩展性。在实际金融业务场景中，数据的易读性、易用性、稳定性和可扩展性是支持业务发展的必要要求。金融业务数据在实际业务发展过程中，是不断变化的，因此在建立金融数据仓库过程中，需要对数据指定统一的业务口径和业务标准，保证业务人员在进行业务数据分析过程中，能够快速了解数据指标的业务

27、含义和掌握该数据指标具体的使用场景。此外，还需要提升数据的稳定性和可扩展性，金融业务数据之间要有明确的勾稽关系和关联关系，数据要结构稳定，能够在金融业务的不断发展中进行补充和升级，保证业务的持续发展。3.2.数据存储要求一是在存储范围上要容纳内部数据和外部数据。在数据驱动业务发展的潮流下，金融机构仅仅通过业务数据、埋点数据及指标加工数据等内部数据进行分析管理，已远远无法满足目前金融行业的业务发展要求，需要引入用户调研数据和合作方数据等外部数据，实现内外数据的统一整合，13金融数据仓库发展报告（白皮书）才能够更好的得到市场信息，助力金融机构更好地规划未来的经营战略。二是在存储形式上要涵盖结构化数

28、据、非结构化数据和半结构化数据。虽然传统金融行业以结构化数据运营为主，但结构化数据已无法满足金融业务分析的需求，如客户画像、客户满意度分析、客户交易异常监控等，需要更多办公文档、图片、音频、视频、日志以及地理信息等半结构化、非结构化数据支撑。三是在存储时效上能实现当日数据和历史数据的分类和规划。金融数据仓库涉及数据分析的业务范围广泛，每日汇聚来自源业务系统和外部系统的数据，信息量多、数据量大，必要的存储策略和分类方法可以让数据应用更便捷。不同业务对数据的存储时效要求不同，例如反洗钱、征信报送等监管服务，需要定期对历史存量交易、客户信息进行摸底排查，故该部分数据需要按照历史数据的保留策略进行存储

29、。每日的交易流水统计、日志行为分析则仅需对最近一日的数据进行统计汇总后即可，保留当日数据。14金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究3.3.数据处理要求金融业务的丰富性和复杂性带来业务数据的多样性，金融数据仓库需要具有对金融业务数据的整合能力，将各类业务数据进行抽丝剥茧地拆分，形成具有公共服务能力的金融业务标签和管理指标。按照金融数据仓库集中存储和高效服务的要求，数据处理可根据数据流转形式进行数据分层，即贴源数据、模型数据、汇总数据和应用数据。一是贴源数据。对金融各业务系统数据进行采集、汇聚，需要尽可能保留原始业务流程数据，与业务系统基本保持一致，仅

30、做简单整合、非结构化数据结构化处理或者增加标识数据日期描述信息，不做深度清洗加工。二是模型数据。业务数据模型要实现数据的统一采集、整合、清洗、标准、存储和服务。从金融机构自身的视角对业务概念进行逻辑化、一致的表述，用数据语言说明业务需求和体现业务规则，将数据模型作为连接业务和技术的桥梁。三是汇总数据。汇总数据包括汇总模型、数据指标、数据标签等。从客户、组织、产品、交易等主题划分汇总模型，建议充分考虑数据通用性，同时应防止数据集中而导致的维度冗余，并以此作为指标、标签的数据基础。数据指标为上层应用衡量业务特征提供统计数值,建议兼顾上层应用的共性指标对数据进行汇总。数据标签是由元数据加工而来，一般

31、都需要结构化到字段粒度，并面向数据应用的业务端，解决数据怎么用、数据价值在哪里的问题。15金融数据仓库发展报告（白皮书）四是数据应用。应用服务直面金融业务需求，需要按照业务需求从模型数据层和汇总数据层进行数据抽取，形成满足业务口径的特定加工数据，以联机技术和接口方式提供，满足业务的特性化需求和性能要求。3.4.数据质量要求金融业务发展过程中，会产生多种多样的数据，有系统自动生成、有客户录入、有业务人员手工维护等各类数据。数据的来源不同，导致数据杂乱无章且无统一的标准。因此在金融数据仓库统一处理过程中，需对数据进行质量管控，形成统一的规范，保证数据能用可用，业务人员、开发人员常用善用。一是保障基

32、础数据的完整性、及时性、准确性、一致性、唯一性和有效性等。数据完整性是数据质量最基础的一项要求，要保证数据在创建、传递过程中无缺失和遗漏，包括实体、属性、记录及字段值完整四个方面。数据及时性是数据交付、抽取及展现要及时，需要保证数据获取时间在指定时间窗口内，获取频率在规定频率范围内，数据使用在有效时间周期内。数据准确性是要保证真实、准确地记录原始数据，无虚假数据和信息。数据一致性是要遵循统一的数据标准记录、传递数据和信息，主要体现在数据记录是否规范、数据是否符合逻辑。数据的唯一性是要求数据只能有唯一的标识符。数据的有效性是数据的值、格式和展现形式需要符合数据定义和业务定义的要求。二是有效避免指

33、标数据质量问题。指标数据质量问题的产生原因主要包括：口径和加工需求层面的问题，业务理解和沟通不足，造成需求16金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究和设计层面的质量缺陷；在指标加工的开发实施过程中，因为程序性的错误而产生的质量问题；指标在应用层面的误用或歧义，造成业务应用层面的理解不一致等情况。因此，金融机构针对不同原因应该有不同的管理策略。对于沟通和理解层面的问题，应该通过数据溯源和口径分析来解决；在加工过程的问题，应该通过数据验证和测试环节来把关。同时，指标类数据质量还存在应用层面的波动监控问题，在初始投产阶段验证正确的指标，可能在后续因为各种扰

34、动因素而产生质量缺陷，需要针对指标数据进行波动区间的监控和预警，对于重要的经营管理报表所涉及的指标，应该加入指标波动预警的响应机制，快速介入和应急处理。3.5.数据安全要求金融数据涉及大量的客户基础信息、客户交易信息，做好数据安全、防止数据丢失、数据泄露是重中之重。在进行金融数据保护过程中，需要对金融数据仓库内部的数据进行存储管理、服务监控、安全类别分级以及数据管控。一是加强数据存储安全，保障数据出现存储故障时，能够备份恢复。数据仓库系统因发生意外事故而导致存储数据丢失、系统瘫痪，需要通过软件或硬件恢复数据存储，保证数据不丢失、不遗漏。数据仓库备份可包括硬件备份、系统备份、应用系统及数据备份。

35、17金融数据仓库发展报告（白皮书）二是保障数据服务安全，在金融数据仓库在进行复杂计算的过程中，不存在敏感数据的增删改查等危险操作。金融数据仓库接入源数据的数据后进行清洗、合并、加工，需在处理过程进行定期跟踪和测试，保证数据服务安全。在对外交换上，需要制定确定的交互方式，形成数据责任制，避免造成对一份数据多次操作，引起数据变动，导致数据异常。三是强化数据安全等级设置，避免未经授权对敏感数据的增删改查操作。为开发人员使用便捷，数据表安全等级通常存在安全等级设置偏低的情况，因此，要根据数据分级的目标，通过设置合理的等级，加强对金融数据仓库平台下数据的安全管理，确保敏感数据的增删改查操作都能够经过适合

36、的授权。四是提升数据安全控制，避免人为故意操作导致数据安全管理问题。不论单位组织内的数据分级如何准确、资产保护目录如何完备、安全管控技术如何先进、角色分配和数据确权如何明晰，但只要管理流程有人参与，就必定是数据安全管理体系内最薄弱的一环。因此，建立一套完整的数据安全团队的人员建设和管理策略必不可少，从招聘、能力建设到实施管控，需要全面覆盖。18金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究4.金融数据仓库总体设计与关键技术金融业在深入推进数字化转型过程中，通过数字化技术记录大量的、形式多样的金融业务全流程数据，并且需要对这些数据进行挖掘分析，因此促进了金融数

37、据仓库技术的快速发展和不断创新。4.1.金融数据仓库模型4.1.1.数据仓库模型设计原则根据金融行业重点关注的客户管理、运营和绩效管理、财务管理、风险管理、信息管理等领域对数据使用的要求，数据仓库模型设计应遵循如下原则。一是兼顾泛化性和实用性。基于对业务的分解和梳理，对数据模型进行一定程度的抽象和整合，提高模型的泛化能力和稳定性，但过高的抽象程度会脱离业务实际，不便于理解和交流，增加数据模型的使用难度，因此数据模型要平衡抽象性和实用性。19金融数据仓库发展报告（白皮书）二是高内聚低耦合。从数据的业务特点和访问特点两个角度出发，对于监管报送类同质化较高的业务或者相关的数据，应在数据模型中进行整合

38、，轻度汇总；对于业务差异较大的数据应划分在不同的模型主题中；对于高频率同时访问的数据，应在数据模型中进行整合；对于低概率会同时访问的数据，考虑分开存放。三是核心模型与扩展模型分离。核心模型描述核心的业务流程和高频率的业务数据，扩展模型补充非必要信息或服务于个性化需求。扩展模型不应过度入侵核心模型，破坏核心模型的简洁性和可维护性。四是公共处理逻辑下沉。对于公共的、基础的数据处理，应在数据模型的底层实现，不应直接暴露给数据服务。相同的数据处理不应在多处存在。五是兼顾成本与性能。综合考虑数据存储成本和数据查询性能的影响，保留一定程度逆规范化设计，制定合理的数据更新策略。六是重视数据质量。数据模型设计

39、不能假设数据质量是符合要求的，应与数据治理紧密结合，实现数据标准的统一，实体表定义、字段命名、枚举值含义等都应做到清晰、规范、完整、一致，便于模型的使用和理解。为满足各金融机构合规报送要求，数据模型的定义统一标准化尤其重要。七是持续优化数据模型。数据模型设计不是一蹴而就的事，需要从业务整合能力、数据模型质量校验、数据模型使用情况三个角度持续进行优化，建立数据模型评价体系，及时优化设计不合理的模型。20金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究4.1.2.数据仓库模型层次数据仓库模型按照抽象程度由高到低依次是概念模型、逻辑模型、物理模型。概念模型仅包括给定

40、的领域和职能中基础和关键的业务实体，以及实体和实体之间关系的描述，主要由业务需求驱动，着眼于表现主要业务流程，并不需要考虑具体的实现过程和细节问题。逻辑模型是对数据需求的详细描述，是对概念模型的进一步分解和细化，通过添加必要的实体属性描述更多的业务细节，其不受任何技术或者特定实施条件的约束。物理模型设计需要将逻辑数据模型中定义的逻辑数据实体、属性、属性约束、关系等内容，如实转换为数据库软件能识别的物理数据实体关系。4.1.3.数据仓库建模方式数据仓库建模方式目前流行的是范式建模和维度建模。从不同方式和角度出发看待现实世界和具体的业务问题，不同的建模方式都有其优缺点和适用场景。表 1 不同建模方

41、式优缺点对比建模方式优点缺点范式建模1.范式化设计，数据冗余度低；2.模型稳定，泛化能力强；3.维护成本低。1.开发周期长，设计难度高；2.大量表关联影响查询性能；3.模型变动对数据应用的影响较大。维度建模1.面向分析设计，模型简单，紧密贴合业务目标；2.反范式化设计，开发周期短；3.查询性能高、使用门槛低。1.数据大量冗余；2.预处理阶段开销大，维护成本高；3.受业务变动影响大。21金融数据仓库发展报告（白皮书）因此，通过分析不同建模方式优缺点和适用场景，可以得出贴源数据层来自于上游应用系统，不需要数据建模；整合模型层、汇总模型层主要是为了抽象全局统一的数据视图，其模型的稳定性很重要，为了维

42、持模型的稳定性，这两层的数据建模一般以范式建模为主；数据集市层和业务层应用贴合紧密，需求变化快，为满足上层业务快速变化的需求，数据集市层一般以维度建模为主。4.2.金融数据仓库架构设计4.2.1.数据仓库架构设计原则数据仓库建设是一项企业级的浩大工程，需要充分考虑到数据仓库在整个企业业务发展过程的定位。按照可用性、持续性、可扩展性要求，整体设计原则如下。一是聚焦业务诉求。数据仓库面向数据分析和决策支撑，建设目标应紧贴业务诉求，确保数据仓库能够解决服务于核心业务，并解决业务痛点。二是立足企业级目标。数据仓库设计不同于普通数据库设计，应综合考虑企业整体业务流程，以及全部应用系统设计，形成企业级的数

43、据架构。三是把握核心业务。数据仓库需要对整个机构的业务数据进行整合与加工，只有把握住核心业务流程，才能够串联起其他次要业务，不至于迷失方向，偏离建设目标。22金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究四是数据结构清晰，数据流转有序。层次结构清晰，分层合理，各层级职责明确，层级间数据流转有序。五是全流程数据规范。数据仓库设计建设过程中，需要有明确、详细、可执行的规范要求，包括设计规范、流程规范、质量管控规范、安全规范。六是结合数据治理。数据治理保障高质量数据仓库建设，数据仓库设计协助理清数据流转，助力数据治理。4.2.2.数据仓库典型设计架构数据仓库总体上

44、可以分为四层，分别是贴源数据层、整合模型层、汇总模型层、数据集市层，具体的分层设计应结合具体的业务实际。图 9 数据仓库典型设计架构示意图全周期治理管控数据权限数据分级数据资产质量监测指标口径内部数据外部数据结构数据非结构数据贴源数据层客户产品协议合约交易整合模型层汇总加工统一指标加工统一标签加工汇总模型层智能营销实时查询客户画像风险监测数据探索AI建模自助BI交易管控风险计量利润测算监管报送数据应用层交易类场景分析类场景自助类场景数据仓库数据服务23金融数据仓库发展报告（白皮书）各个层级的职责如下：贴源数据层主要职责是采集获取保留原始数据，该层的数据应保留业务数据的原始样貌，不建议进行数据处

45、理。整合模型层是数据仓库的核心，按照业务特点建立抽象的数据主题模型，对所有的业务数据进行有效的重组、整合、汇聚，构建稳定的数据底座。汇总模型层是数据模型中的一个重要组成部分，主要是为了提高查询效率，减少指标重复计算，对各类应用系统的共性指标标签进行统一加工，确保数出同源。数据集市层是面向不同的业务应用，为满足多样化的数据使用需求，进行数据个性化加工，并对外提供数据服务。4.3.金融数据仓库典型技术架构数据仓库作为企业的核心数据分析平台，起到了承上启下的作用。上游对接企业的交易系统、实时消息、日志及第三方数据等平台；下游提供给企业管理人员、分析师团队、交易系统及外部客户分析加工结果。下面以典型银

46、行的数据仓库平台技术架构为切入点，简要说明数据仓库需要具备的关键技术。数据仓库平台整体分为采集层、存储计算层和应用层。采集层主要是从交易系统、日志系统、消息系统以及第三方系统进行数据采集。存储计算层对采集的数据进行加工处理,并对应用层提供数据消费服务。应用层基于存储计算层的原始数据、中间数据和结果数据，为金融机构经营提供经营决策、风险管理和控制、监管合规等分析应用以及数据展现。24金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究其中，存储计算层通常分为核心仓库区和大数据区，核心仓库区处理金融机构的高价值密度的结构化数据；大数据区处理贴源数据和历史数据，并进行历

47、史数据归档备份等。核心仓库区同时要承载数据的加工处理和数据供给消费，这两部分负载都是非常大的，建议分多集群建设，分别应对不同的负载，主要包括数据仓库集群、数据探索集群、数据集市集群等模块功能。数据仓库集群依据企业的数据模型设计，承载数据的批量计算，具有数据量大、计算量大、时效性要求高等特点，是一个计算密集型的系统。数据探索集群既承载复杂的长周期分析作业，也承载高并发、低时延的查询，具有并发要求高、混合负载管理能力要求高、扩展性要求高等特点，面向行内分析师、企业管理人员开放，用户对数据仓库集群批量运算的结图 10 典型银行的数据仓库平台技术架构图个贷催收分析实时事中风控信用卡账单查询实时个性化推

48、荐Region2Region1手机银行用户行为分析应用层业务应用存储计算层采集层大数据（历史数据/流式数据中心）数据湖/数据交换平台/历史库（对象存储）核心仓库（高价值密度数据中心）容灾集群历史数据平台Hive/Spark准实时处理Flink/SparkStreaming容灾数据集市监管反洗钱信用卡账单数据探索集群LAB1SSB AMPNLAB2数据仓库集群AMRTBMRTSUMPDMODSSTG互联网数据资信平台日志数据数据库消息平台(Kafka)爬虫平台25金融数据仓库发展报告（白皮书）果进行分析。随着金融机构对数据分析的依赖度越来越大，独立建设数据探索集群逐渐成为一种趋势。数据集市也称为

49、仓外集市，通常基于部门或领域的视角，对数据仓库中的数据做二次加工和分析，服务于特定的主题域，具有部署灵活，资源弹性，兼具批量和联机的特点。但由于部门和领域的数据多、差异大，数据集市往往建设的数量较多，规模差异较大。4.4.金融数据仓库的关键技术如 4.3 所描述，数据仓库各个集群的任务，负载特点，技术要求不尽相同，本节从 7 个方面对金融数据仓库的关键技术进行分析，力争涵盖金融数据仓库的核心关键技术。4.4.1.超大规模并行处理满足海量数据的算力要求金融领域有大量的数据，数据总量会达到 PB 级甚至百 PB 级；同时对性能要求很高，很多监管报送、运营报表需要在规定时间内完成，因此需要在基础架构

50、、数据存储、SQL 查询、数据加载等方面实现超大规模并行处理技术来满足存和算的要求。（1）分布式架构。由于金融数据仓库是海量数据的处理平台，首要关注性能和算力扩展性，根据技术原理和实践经验来看，MPP（大规模并行计算）+Shared Nothing+Local Storage 更适合这类型负载的数据仓库架构。26金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究（2）云原生架构。分布式架构在云基础设施上演进出 MPP+Shared Nothing+Shared Storage（分布式存储）的存算分离技术。云原生架构对数据的计算和存储进行解耦，数据持久存储在底层共

51、享磁盘上，计算和存储可以独立扩容，具有明显优势。但这种存储拉远的技术相比于本地存储的 I/O 处理的路径明显拉长，对存储设备、存储网络的带宽时延配置要求更高，在架构选择时要综合评估。（3）分布式数据存储。为了解决PB级海量数据的高性能查询和处理，可采用两层数据布局机制来利用并发度提高性能。用户在第一层可在创建表时指定数据分布策略（Hash 分布、随机分布、复制分布）。在第二层节点内部数据进一步通过用户指定的分区规则进行细分，将数据表按照指定范围划分为多个数据互不重叠的部分。（4）分布式并行 SQL 查询。采用节点间并行和节点内并行技术，尽量降低查询时节点之间数据流动，并协同各个节点的计算资源进

52、行任务分解和协作，以提升查询效率。（5）分布式数据并行加载。以充分利用所有节点的计算能力和 I/O能力以提升导入速度为核心思想，支持对指定格式（例如：CSV/TEXT格式）的外部数据进行高速、并行入库。4.4.2.高可用及容灾技术实现数据永远在线金融数据仓库是金融机构的核心分析系统，承载风险控制、监管报送、经营分析等关键业务，对可用性要求很高，金融数据仓库需要具备27金融数据仓库发展报告（白皮书）完备的高可用能力，制订高可用策略以满足业务需求和金融监管要求。从数据可用性来看，匹配金融数据仓库平台通用的分布式架构，需要保证数据的全局一致，数据多副本等；支持多种策略的数据备份，包括全量数据备份，增

53、量数据备份等，避免数据误删和不可恢复错误等。从系统可用性来看，需要支持集群内高可用，避免单节点故障，双集群容灾，以保障系统永远在线。随着数据仓库承载业务的重要性逐年提升，金融机构对数据仓库容灾集群需求也日益迫切。不同于其他系统，由于数据仓库集群具有系统规模大、成本高、网络带宽需求高、使用者众多、应用升级更新快以及应用层容灾维护成本高等特点，数据仓库容灾技术面临很大的挑战。但近年来数据仓库容灾技术也得到了快速发展，典型的双集群系统级容灾技术是在异地两个 Region分别部署数据仓库主备集群，根据 Region 间网络带宽、时延以及业务对数据延迟的容忍度，用户可自定义两集群间的同步间隔与策略。同时

54、，通过细粒度、集群级、双活容灾等三种备集群容灾形式，保护不同范围、不同级别业务连续性的数据，从而达到降低备集群的搭建成本的目的。4.4.3.动态负载管理满足多样化负载统一管理金融数据仓库集群、数据探索集群、数据集市集群是一个多任务运行28金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究的系统。数据仓库集群运行几万个作业，并发运行的作业也有上百个。数据探索集群支持上万分析师的数据任务，需要通过负载管理满足多样化负载的统一调度，实现资源的高效利用和系统的高吞吐量。负载管理主要通过业务的并发控制来均衡系统计算资源，避免业务间出现资源争抢，实现资源利用最优。通常负载管

55、理需要具备以下能力：（1）静态资源管理。以计算节点为单位实现租户的并发控制和资源管控，各计算节点分别进行内存管控和并发控制。（2）动态资源管理。用于复杂作业并发控制和内存管控，能够动态的根据系统实时可用资源进行内存管控和并发控制。（3）优先级控制。单计算节点上运行作业数超过阈值或集群内存不足时触发优先级管控，资源分配越大优先级越高，租户作业根据优先级在不同优先级队列上排队，有作业运行结束时优先唤醒优先级高的作业。优先级控制需要支持 Session 级设置，实现动态优先级控制。（4）异常管理。为避免质量不高的 SQL 长时间占用系统资源，拖慢整个系统，针对异常占用资源的 SQL 实时监控需要支持

56、设定异常规则，以保障系统的平稳运行。例如对占用内存过多、执行时间过长等异常情况执行自动查杀等干预手段。（5）快慢查询管理。针对长查询和短查询提供更为灵活的并发和资源管控机制，快查询车道针对资源消耗少、执行时间短的作业进行管控，仅29金融数据仓库发展报告（白皮书）对作业并发进行管控；慢查询车道针对资源消耗大、执行时间长的作业进行管控，采用并发和内存联合对慢车道作业进行管控。（6）容量管控。通常通过永久表空间管控、临时表空间管控以及中间计算结果集落盘空间管控等三部分实现用户空间管控。4.4.4.数据安全技术保障数据合规访问金融数据仓库中存储了金融机构最全量的用户数据、经营数据，其数据价值密度高、敏

57、感度高。为了保障数据仓库的合规访问，需要提供用户管理、基于角色的权限管理、行列访问控制等安全能力。在数据保护方面，还需要提供透明加密、数据脱敏等数据合规访问的能力。（1）透明数据加密（TDE）。通过透明数据加密（TDE）提供底层数据文件加密能力，TDE 对数据实时 I/O 加密和解密，只要打开透明加密开关，用户可正常使用而无感知。该技术对现有 SQL 语句兼容性好，仅需要在创建数据库时指定启用加密即可。（2）数据脱敏。通过数据脱敏实现数据高效共享的同时保护敏感信息安全。该技术支持以表的列为单元创建脱敏策略，针对业务中的敏感数据进行策略创建，由客户结合自身业务场景识别和界定敏感数据。与此同时，脱

58、敏数据可以参与实际运算及使用，仅在数据库服务最终返回结果时脱敏。在应用开发、测试、培训等活动中使用脱敏数据，可以匹配金融行业对数据脱敏的天然需求。30金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究（3）三权分立。将系统管理员的权限分立给安全管理员和审计管理员，从而避免系统管理员拥有过度集中的权利带来高风险。系统管理员将不再具有 CREATEROLE 属性（分给安全管理员）和 AUDITADMIN 属性（分给审计管理员）能力，即不再拥有创建角色和用户的权限，并不再拥有查看和维护数据库审计日志的权限。4.4.5.融合分析技术打通结构化与非结构化数据分析边界在 4

59、.3 章节数据仓库典型平台技术架构中，数据分析分为核心仓库和大数据区，非结构化数据往往存储在大数据区，因此，需要有融合分析技术，把核心仓库区的数据与大数据区的数据进行关联融合分析，减少数据搬迁，提升加工效率。当前用于数据处理的引擎组件种类繁多，且各自提供了丰富的接口供用户使用。但对传统数据库用户来说，SQL 语言依然是最熟悉和方便的一种接口。在一个客户端中使用 SQL 语句操作不同的数据分析组件，将极大提升使用各种大数据组件的效率。通过 SQL on Anywhere 操作 Hadoop、Spark等异构数据存储，构筑起统一的大数据计算平台。4.4.6.弹性扩展技术满足系统在线按需扩展随着金融

60、行业在数据仓库积累的数据量增长，磁盘容量和性能等方面逐步出现瓶颈，通过 scale-out 线性扩展技术可满足业务增长和利旧的诉求（将闲置的机器加入系统）。典型的弹性扩展有两种：31金融数据仓库发展报告（白皮书）（1）物理部署下资源弹性扩展。在数据本地存储的物理部署形态下，扩展节点时对原节点进行数据搬迁和数据重分布，通过在线重分布的技术实现数据搬迁不影响集群上的业务。相比于其他类型的在线扩展技术，在线重分布技术能够最快的获得扩容后计算、存储算力的提升。（2）云化部署下资源弹性扩展。在云化部署（虚拟机+分布式块存储）的情况下，不同于物理机/裸金属的物理 CPU 和本地磁盘，计算资源采用虚拟机资源

61、（如 ECS），存储资源采用分布式块存储（如 EVS），当需要扩展资源时，动态地增加计算资源或存储资源以满足业务对弹性扩展的需求。同时能更好的支持小规格的场景，很契合仓外集市的场景。在云化部署的情况下，计算资源采用裸金属/虚拟机，存储采用分布式存储如 S3、OBS 等，当计算弹性扩展时，仅需要重分布元数据，不需要搬迁存储设备上的数据，实现计算弹性，快速扩展。4.4.7.管控一体的智能运维释放运维压力金融数据仓库的集群规模大，承载多个业务部门应用的数据需求，是一个重负载的系统，出故障的概率高。由于金融业务高可用的要求，系统出故障后可容忍的修复时间短，运维压力大。通过智能运维的技术可实现全方位的监

62、控，在线运维能力，释放运维压力，关键技术包括运维监控、系统监控、智能运维、SQL 诊断等。（1）运维监控。资源监控及管控手段可以对影响作业运行的计算资源和存储资源进行分配和利用，通过对系统资源的合理分配，避免发生资源的不合理占用导致系统运行效率下降甚至引发运行问题。资源监控32金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究及管控包括资源监控、负载管理及磁盘空间管控。（2）系统监控。多个维度的监控应包括实例层，用户层与作业层。在实例层对计算节点、存储节点每个实例的实时系统资源和负载情况进行监控。在用户层监控多租户资源的使用情况。在作业层监控用户执行的每一条 s

63、ql 与对应算子在其运行中和结束后的资源消耗情况，用户可以根据这个信息对其编写的 sql 进行调整优化。（3）SQL 诊断能力。金融业务用数过程会包含大量查询，这些查询在执行计划、执行层面有什么样的问题，比如估算是否有偏差、是否存在数据倾斜、是否存在统计信息未收集并且如何收集统计信息等。SQL 自诊断提供一种更为高效易用的性能问题定位方法。帮助用户对批处理作业的SQL 调优过程进行简化，用户输入 SQL 之后能够方便的批量得到 SQL 所存在的问题和针对问题给出的调优建议。（4）在线运维。提供软件版本在线升级、在线补丁以及升级补丁回退能力，达到新特性快速发布、持续交付可靠版本，以快速响应金融业

64、务上层应用的用户需求。（5）智能运维。提供无人值守自动运维能力以实现智能运维高可用保障，实例级故障、节点级故障不中断运维执行；通过感知集群负载资源，智能调节运维任务并发降低运维影响；利用人工智能算法和专家规则，提供数据碎片自动检测与回收、数据统计信息预测与自动更新等能力，确保性能稳定和高效运行；通过亚健康检测能力、全库数据优化检测能力实现主动运维。33金融数据仓库发展报告（白皮书）5.金融数据仓库建设策略5.1.指导原则为达成建设目标、有效支持金融业务发展，金融数据仓库建设需要遵循设计力求简单、易于理解且不失精细的简洁性原则；合理抽象、便于业务和 IT 人员沟通交流的抽象性原则；确保功能组件解

65、耦、可并行开发的隔离性原则；便于高效率沟通和交互的标准化原则；随业务发展弹性伸缩的扩展性原则；保证数据和处理流程的完整性原则。5.2.建设规划策略根据金融数据仓库建设进程先后次序，大致可分为业务规划、实施规划和运营规划共三个阶段推进。如图所示：业务规划要结合业务调研结果和同业实践，制定规划及实施优先级。并参考客户管理、运营和绩效管理、财务管理、风险管理、信息管理等五大模块，结合企业愿景、整体发展战略、业务发展规划以及实际监管要求制定业务目标。金融数据仓库的应用根据不同特点、不图 11 数据仓库建设规划示意图建设规划技术架构规划数据架构规划数据模型规划访问安全规划系统容量规划数据治理规划环境建设

66、规划运维管理规划系统灾备规划持续运维规划业务规划实施规划运维规划34金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究同使用范围、不同建设方法主要分为固定报表、应用系统、灵活查询及数据挖掘共四种模式。本文不对业务规划进行详细阐述。5.2.1.实施规划结合金融关键业务对数据服务、存储、处理、质量、安全要求，并考虑到数据仓库需要面向金融机构提供全国、全球业务范围的服务，建议在数据仓库总体设计完成后，启动实施规划。实施建设规划包括技术架构、数据架构、数据模型、访问安全、系统容量以及数据治理等六个方面。一是技术架构建设规划根据数字金融快速发展带来的业务类型多、海量数据等

67、特点，梳理好采集层、存储计算层和应用层之间关系，做到技术架构规划具有先进性、前瞻性、可行性、扩展性、伸缩性；依据监管法规、应用特性，分类实施实时数据仓库、湖仓一体、双活容灾平台建设。二是数据架构建设规划的核心数据仓库平台可参照金融业务所需要的贴源数据层、整合模型层、汇总模型层、数据集市层进行落地实施；制定合理、高效的数据生命周期管理策略，拆分在线、近线、历史区，将已失效、陈旧数据推送到更经济的存储平台，保证核心数据仓库健康运行；根据数据用途差异，可拆分成核心数据仓库计算平台、分析平台、仓外集市，更好地为上层众多不同类型金融业务提供数据服务。三是数据模型建设规划应涵盖金融机构所有业务的各个层面，

68、包括交35金融数据仓库发展报告（白皮书）易数据、主数据和参考数据，提供一个完整、一致的数据集成逻辑视图；根据实际情况，不同金融机构综合应用范式建模和维度建模，其中整合模型层更多采用范式模型，主题领域及数据集市层更适合采用维度模型；范式模型中可适当增加冗余设计，保障下游易用性。四是访问安全建设规划要充分考虑金融数据商业性和保密性要求，重视整体安全设计，确保数据的真实性、保密性、完整性、可用性、可审查性；设计并落实权限管理、密码管理、认证及会话控制、安全协议、文件权限管理、网络隔离、安全审计等安全合规控制措施。五是系统容量建设规划要充分评估业务发展的数据增长需求，依据整体目标要求，梳理系统整体算力

69、和存储空间；分别对贴源数据层、整合模型层、汇总模型层、数据集市层进行数据容量规划，估算生产、测试、开发环境配置要求。六是数据治理建设规划根据数据治理实施带来的业务价值以及业务的需求紧迫程度，规划目标和实施路线图；通过数据治理建设，明确治理主体，统一数据规划和标准，提升数据质量，实现数据共享，最终实现业务战略规划；从战略、机制、专题、实现、数据认责等五个方面落地数据治理体系框架。5.2.2.运营规划金融业务复杂，不但有严格的内部管控，更要符合各监管机构的合规要求，同时要面向对私和对公客户提供直接差异化金融服务。因此，需36金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息

70、安全研究要根据金融业务服务等级对数据仓库建设提出的要求，差异化地落地数据仓库平台运营规划，建议包括环境建设规划、运维规划、系统灾备规划及持续运营规划等四方面。一是环境建设规划要确定数据仓库平台的开发(DEV)、集成测试(ST)、用户接收测试(UAT)、生产运行(PRD)四套环境建设。其中生产环境与开发测试环境要避免混用，开发和集成测试环境可合并部署以减少投资。利用 ETL 服务器、应用服务器可实现环境隔离。通过规范环境流程，可达到提高数据质量、程序质量以及数据安全性，提升数据可用性与可信度，以及保障企业的信息安全的目标。二是运维规划的整个框架由流程、组织、技术三大部分组成，涵盖数据仓库的数据集

71、成、基础平台、应用系统的运营管理。流程上需建立全流程运维保障，做好环境准备、安装部署、系统运行、系统维护、故障处理、版本变更以及应急演练。组织上需构建三级梯队运营管理团队：一线服务台值班监控、二线由数据仓库各团队成员组成处理各类运营问题、三线则由资深专家构成服务赋能二线。技术上应考虑容量规划与容量管理、性能管理、负载管理、服务级别协议等，并进行数据库系统监控、中间服务层管理（OLAP 与 BI 工具）、元数据管理、数据质量管理、数据加载服务管理（ETL）等数据仓库及周边组件全流程覆盖监控。三是系统灾备规划需根据业务和现有 IT 系统实际诉求出发，因地制宜、落地实施。建立数据仓库备份环境要考虑数

72、据备份、恢复效率，配合数据生命周期管理，做好应用 SLA 保障预案，规划备份网络，避开业务高峰周期性备份，做好异地归档、定期恢复演练。建立数据仓库容37金融数据仓库发展报告（白皮书）四是持续运营规划要能持续监控系统运行情况，周期性整改规范性约束，优化平台性能，保障运行平稳；针对已落地应用进行审视，适时合并、拆分物理环境，保障数据仓库环境健康新常态；定期阶段性回顾系统运行状况，修正平台规划差异，适时发起算力、容量扩展申请。灾环境，解决灾难发生时保证数据仓库平台业务连续性问题，同时应当考虑跨机房、跨中心、异地等部署形态，避免出现单点故障，以及定期实施对等环境容灾演练；可按照细粒度、集群级、双活容灾

73、三种形式，设计保护不同范围、不同级别业务连续性要求的容灾规划，如图所示：图 12 容灾规划的三种形式重要数据区其它数据区整体集群集群级容灾主集群容灾集群数据操作双活主集群双活数据其它数据集群A双活数据其它数据集群B数据字典同步容灾集群细粒度容灾容灾数据容灾数据Schema级容灾38金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究5.3.实施要求5.3.1.组织架构金融数据仓库建设涉及到金融机构、服务供应商等众多参与单位，且涉及到金融机构不同业务部门，为保障项目进展实施顺利，建议在项目启动之初任命职责明晰的项目组，可参考如下图的实施组织架构。其中项目领导小组是整

74、个数据仓库项目的最高领导机构，主要负责整体项目重大问题决策，建议尽可能由公司管理层牵头，以保障跨业务部门协调顺畅，高效推进项目进度；项目管理组负责项目日常管理，包括但不限于范围管理、资源协调、进度监控等；专家组负责在业务和技术层面给与专业建议和方案；业务组负责承接源业务系统及对接下游应用集市具体业务诉求；架构组负责制定数据仓库技术规范及技术架构的设计和落地；配置管理组负责数据仓库平台版本配置管理工作；模型组负责制定数据仓库模型设计规范，以及进行模式设计和开发；开发组负责数据仓库数据加工程序、BI 报表、灵活查询及数据挖掘的开发；测试组负责数据仓项目领导小组专家组项目管理运维组项目助理配置管理组

75、上线投产组开发组架构组业务组测试组模型组图 13 实施组织架构图39金融数据仓库发展报告（白皮书）库相关功能和非功能测试工作；上线投产组负责数据仓库日常具体任务的投产部署工作；运维组负责数据仓库日常运营维护工作。5.3.2.实施过程基于金融数据仓库建设规划特性，数据仓库庞大的系统性实施需要遵照“整体规划、分步实施”的方式推进建设，在每个阶段中建议可采用迭代方式执行，每个迭代周期中又需要包含需求分析、系统设计、开发测试和上线维护等四个阶段：（1）需求分析阶段：通过资料研读、调研问卷、会议访谈等方式进行业务和技术现状调研，详细了解需求范围、数据规范、数据分布等内容，并基于样本数据进行数据探查。（2

76、）系统设计阶段：进行数据仓库技术架构和模型设计。技术架构设计涵盖数据交换、调度、ETL、网络和物理部署等内容。模型设计涵盖基于通用行业模型进行主题模型、概念模型、逻辑模型和物理模型设计。（3）开发测试阶段：基于系统设计完成基础架构搭建和数据模型开发。（4）上线维护阶段：数据仓库投产及持续维护。5.3.3.规范约束数据仓库相关开发、测试、上线过程细节繁琐，为了让组织架构内40金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究各成员高效开展工作，保障项目实施质量，建议具体实施应涵盖下表所示的各项规范。表 2 数据仓库实施规范约束阶段规范说明开发测试命名规范数据库对象

77、、调度作业、应用名称规范等。流程规范开发、测试流程，环境使用规范。数据加工开发规范ETL 开发规范等。上线维护运维规范日常运维、产品升级回退流程、应急预案、异常处置、高危管理。5.3.4.实施注意事项金融数据仓库在实施过程中，除上述具体建议外，还需要关注几个事项：数据平台的设计不但要解决现有问题，同时应着眼于未来，促进一致性和跨部门整合；数据入仓的过程中应收集满足现有需要更广泛的数据，保存最原始的数据，保留事件的历史和相关内容，对于重复数据可予以删除；为了提高工具的自动化和复用度，应考虑为用户使用、使用模式和角色选择合适的工具。5.3.5.主要交付件金融数据仓库建设和使用时间较长、支撑业务广，

78、为便于项目交付过程上下游沟通顺畅，并方便回溯项目过程文档、沉淀可复制技术经验，41金融数据仓库发展报告（白皮书）表 3 数据仓库实施主要交付件阶段交付件需求分析数据仓库模型设计规范文档数据仓库 ETL 和调度规范文档系统设计数据仓库架构设计文档数据仓库模型设计文档开发测试数据仓库 ETL 脚本程序上线维护数据仓库投产部署文档数据仓库运维指导文档除项目管理文档外，建议数据仓库实施主要交付文件如表所示：42金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究6.金融数据仓库十大发展趋势在七大关注热点中，六个都是与“融合”相关。除此之外，金融机构还关注“普惠”，比如普惠

79、数据治理、普惠数据仓库周边工具。目前业界有三个比较前沿的方向：数据网格（Data Mesh）、数据编织（Data Fabric）及现代数据栈（Modern Data Stack）。综合调研和研究，最终提出金融数据仓库的十大发展趋势。通过对百余家金融机构调研提炼出金融业对数据仓库技术的七大关注热度，如图 14 所示。图 14 金融行业对数据仓库技术关注热度分布数据来源：金融信息化研究所全行业对数据仓库技术关注热度分布0.00%20.00%40.00%60.00%80.00%T+0分析数智融合(AI)湖仓一体数据共享存算分离高维分析HTAP43金融数据仓库发展报告（白皮书）表 4 金融数据仓库的十

80、大发展趋势类别名称特点融合T+0 分析融合流和批湖仓一体融合湖和仓数智融合融合数据和 AI存算分离融合数据仓库和云计算高维分析融合关系型数据和非关系型数据HTAP融合 TP 和 AP普惠Data Mesh普惠数据治理：利用“数据即产品”的思维更高效的用人Data Fabric普惠数据治理：利用“智能数据管理”技术节省更多的人力现代数据栈普惠数据仓库周边工具：Modern ETL，Modern BI 等数据共享普惠数据共享：促成金融数据仓库从“PC 时代”迈向“互联网时代”6.1.T+0 分析在一些金融业务场景中，数据分析需求正从离线分析向实时分析转变。离线分析也称“T+1”分析，可以告诉用户过

81、去 1 天或者几小时前的情况,主要支撑实时性不高的报表分析类应用。实时分析也称“T+0”分析，告诉客户目前正在发生什么，典型案例应用场景包括实时风控、实时营销、实时授信、实时运营（实时大屏）、实时运维等。另外，“T+0”分析也给数据仓库带来新的技术挑战：基于事件的处理需要实时高并发入库、入库即分析、流批一体、高性能同时要保证数据一致性等。44金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究6.2.湖仓一体金融业务产生不同类型的源数据，单一的结构化数据处理能力不能满足业务场景的需求。金融机构探索湖仓一体架构，将数据湖和数据仓库有机结合，充分融合数据仓库的高性能与

82、数据湖的低成本，实现冷热数据分级、价值密度分级，解决海量数据中结构化、半结构化及非结构化的数据处理多样性，实现“1+12”的效果。湖仓一体关键技术包括：统一访问接口、统一元数据管理、统一存储格式以及计算引擎互通等。6.3.数智融合金融机构经过电子化、信息化、数字化这几个发展阶段，当前正在向智能化转型。对金融机构而言，数智化转型已经成为关键战略，部分机构已经在智能风控、小微信贷、智能投顾、智能客服等业务场景已有具体应用。但仅依靠 SQL 的数据分析难以满足这些业务需求，需要融合数据平台和 AI 平台。数智融合的关键是能力互补，将数据仓库数据管理能力与 ML 流程生命周期管理结合。目前结合主要包括

83、两种：一是数据仓库将关系型的数据开放给 AI，并作为 AI 流程中数据准备、特征工程等强数据处理负载的分析引擎。二是非结构化数据（图像、视频、语音、文字）处理和模型训练由 AI 平台承载，训练生成的模型可45金融数据仓库发展报告（白皮书）直接部署在数据仓库中，由数据仓库来实现推理，并可以直接与数仓中关系型数据关联分析。6.4.数据共享数据已成为重要的生产要素，金融数据有序流通与共享开放是释放数据潜能的关键环节。当前各金融机构的数据仓库还处于“PC 时代”，每个数据仓库里的数据都是独立个体，不同机构数据仓库的数据实现安全合规的互联互通还存在困难。数据共享有助于发挥数据的要素价值，如何保证数据共享

84、的安全性、隐私性，以及利益的公平分配等问题至关重要。从技术角度，金融数据仓库需要具备数据共享能力可开放能力，做到细粒度权限控制、加密及隐私计算、安全合规及风险审计。6.5.存算分离目前数据仓库的架构正向云原生演进，其典型技术特征是存算分离。这种新架构可以给用户带来极致的弹性，同时降低成本和提高资源利用率。部署在私有云上的金融数据仓库，使用存算分离有如下优势：一是有别于传统的节点扩容，用户可以根据业务需要，灵活的单独扩展算力或存储，扩缩容更加便捷；二是多集群共享一份数据，避免数据冗余，46金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究不但节省存储空间，同时减少

85、数据搬运带来的网络开销。同一份数据支持多样式分析，保障数据一致性。从技术角度讲，存算分离面临两大挑战：一是数据仓库的存、算、管是深度绑定的，需要将这三者解耦，在计算层去除计算元数据、存储元数据信息，才能做到无状态。二是存算分离将数据和计算拉远，可能带来性能下降，需要利用缓存、谓词下推及数据预取等技术降低查询延时。6.6.高维分析金融机构不仅有表格数据，还有图数据、空间数据、时序数据等。如果每种数据都采用独立的分析系统，不仅使用不便，也会导致数据孤岛问题。高维分析尝试构建一套系统，能够实现不同类型数据的融合分析。为了实现这一目标，高维分析需要解决多模存储和多模计算的问题。6.7.HTAP随着金融

86、创新业务的蓬勃发展，越来越多的数据应用构建在数据仓库之上，有些应用需要对数据进行并发的增删改查。在此情况下，TP数据库需要考虑如何和金融数据仓库进行更原生的整合，从而更好的支撑这些数据应用的开发和运行。HTAP 的愿景是构建一套系统，既支持TP又支持AP能力，同时达到降低成本、减少系统运维和ETL开销的目的。金融业对 TP 和 AP 的查询性能和资源隔离要求非常高，给 HTAP 技术落地带来了很大的挑战。47金融数据仓库发展报告（白皮书）6.8.数据网格（Data Mesh）数据湖和数据仓库将所有数据集中存储，统一由数据中台部门进行治理。但随着金融机构接入的数据源越来越多，数据治理也变得愈加复

87、杂，数据中台部门压力越来越大。为了缓解数据中台部门的压力，数据网格（Data Mesh）倡导金融业务部门参与到数据治理中，这样业务部门就可以拥有相关数据的所有权，能够更敏捷、更灵活地开展新业务。当需要整合治理多个业务部门的数据时，可以利用“联邦数据治理”技术和“数据即产品”思维来实现。同时，建议金融机构可以适当培养员工“数据即产品”的思维（即：利用开发产品的思维开发数据），提升员工在做数据治理时的工作效率。6.9.数据编织（Data Fabric）数据编织（Data Fabric）和数据网格（Data Mesh）所要解决的问题是一致的，并与 Data Mesh 类似，Data Fabric 也

88、是让金融业务部门拥有一部分数据的所有权。在整合治理多个业务部门的数据时，Data Fabric 采用逻辑的方式把数据连接起来，统一元数据层，提供全局数据目录供不同部门查找所需数据，利用智能数据技术（Data Fabric 的核心理念）节省人力。随着智能技术的发展，越来越多的数据治理任务可以自动化或半自动化，最终实现普惠数据治理的愿景。6.10.现代数据栈（Modern Data Stack）金融机构探索利用现代数据栈（Modern Data Stack）从重构数据48金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究栈的角度来发挥数据仓库的最大价值。在金融机构的

89、数据栈中，数据仓库是一个核心模块，周边还有其它模块负责 ETL、BI、数据质量及数据安全等。通过降低周边工具的使用门槛，推动“人人用数”目标的实现。比如在 Modern ETL方面，有如下三方面探索：一是ETL ELT，ELT 是指先做 EL 把数据接入到数据仓库，再用数据仓库做 T，优势是EL 可以无代码完成，只需要在数据仓库写 SQL 就可以解决 T 的问题；二是数据分析师分析工程师，赋能数据分析师成为分析工程师，提供简化 DevOps 的工具，让数据分析师不需要依赖数据工程师，可以端到端完成数据分析任务；三是 Reverse ETL，利用无代码工具自动将数据分析结果从数据仓库复制到业务系

90、统（ERP、CRM 等），赋能业务发展。总体来看，可以用融合和普惠来概括金融数据仓库十大发展趋势。其中六大趋势（T+0、湖仓一体、数智融合、存算分离、高维分析、HTAP）都与融合有关，四大趋势（Data Mesh、Data Fabric、现代数据栈、数据共享）都与普惠有关。此外，通过调研我们发现国内很多金融机构在接下来 1-3 年在融合方面有比较清晰的规划，但是在普惠方面还准备不足，建议金融机构提高关注度，实现数据价值最大化。49金融数据仓库发展报告（白皮书）案例 1：工商银行企业级数据中台建设实践工商银行自 2020 年启动企业级数据中台建设，打造了数据体量大、服务场景丰富、使用人数多的企业

91、级数据中台，在各业务、技术领域取得了丰硕成果。一、案例内容工商银行数据通过搭建工银魔方、图灵为核心的大数据与人工智能技术底座，由传统软硬件一体机向自主可控的全栈大数据国产化全面转型。平台整体规模超过 4000 节点，容纳全行 50P 海量数据，成为当前金融同业最大的GaussDB(DWS)单集群（482台），覆盖实时，秒级、分钟级、小时级的全场景，为全行 100 多个业务系统、40 多家分行提供上千业务场景数据支撑。二、案例成效1.提升平台容量和性能。面向全行 5000 多名数据研发人员及 13000多名分析师提供用数服务；批量计算服务作业总数 20 万个，在线读写服务达 10 万笔每秒，实时

92、计算服务达 2 万笔每秒。2.创建“开放共建”数据生态。构建端到端的 DataOps 敏捷数据研发流水线、一站式建模工作站，创新提供“数据+BI”数样分离的用数新模式。附录：金融数据仓库行业实践50金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究3.构建多元化智能服务框架。利用 AI 及 BI 平台能力，实现种类广、数量多的算法库，覆盖主流算法数量 300+，通过 API、服务化、页面集成等多种方式，将数据智能服务嵌入业务各个环节，实现了即时数据服务的新模式，适应了企业商业智能应用的多样化需求，探索形成了金融领域的 OLAP+OLTP 服务融合新模式。案例 2

93、：交通银行建设“湖仓一体”智能数据湖实践交通银行在数据中台与业务中台的紧密配合下，结合人工智能技术，推进数字化营销、数字化授信和数字化运营，实现数据业务化、数据价值化。一、案例内容针对原有数据服务模式无法承担更大规模的计算能力、建模能力不足导致数据应用场景融合不够、T+0 时效加工覆盖度不够等问题。交通银行选用华为云 FusionInsight MRS 云原生数据湖和 GaussDB(DWS)，建立了湖仓一体新范式。围绕数据服务能力输出、数字化营运能力提升、计算架构调整等方面，推进全生命周期数据治理，提升数据质量，提升数据服务能力，赋能业务经营。湖仓一体的智能数据湖全新分布式架构提升海量数据服

94、务能力，实现升级过程无数据丢失，应用服务平滑迁移；覆盖内外部 PB 级海量数据的稳定高效存储；在业务高并发场景的巨大压力保持超高性能。51金融数据仓库发展报告（白皮书）二、案例成效1.提升监管报送质量，建设面向监管的监管数据报送管理台，将过去手工报送过程逐步自动化、可视化，提升报送效率。2.为行内各层级管理者的经营分析和决策提供全面、准确、快速的“一站式”数据服务，提供总、分、支机构的统一指标管理，将数据报表指标化、数据服务可视化、数据分析产品化。3.建设数字化、配置话、模块化的实施路径，助力实现营销中台千人千面、客户分群、定向营销的新高度，支撑交行零售业务的数字化转型，构建具有创新性、灵活性

95、的零售服务。图 1 功能架构图数据治理平台华为云平台数据采集层文件交换消息推送API接口数据库同步高速数据交换通道日批微批触发式批量临时批量实时交换数据服务数据分析服务接口分析工具租户数据区公共数据区引擎支撑MPP联机查询Hbase/Cbase明细查询多维分析Cube搜索ES集群缓存Redis集群APIBI分析规则引擎图引擎搜索引擎KylinSASSQLPYTHONBIJDBC批量文件消息订阅数据计算数据计算数据存储离线计算MPP+Hadoop批量数据贴源数据基础数据指标数据近线数据流式数据实时计算Flink+Kafka在线数据52金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论

96、与实务、信息安全研究图 2 数据仓库功能架构图2-报表集群元数据管理统一调度ETL处理1-批量集群3-探索集群4-分行集群5-备份集群全栈国产化部署人民币跨境支付报表多维分析灵活查询智能运营智能反洗钱数据挖掘智能审计智能营销阳光预警经营分析客户营销经营决策科学探索监管报送全量备份增量备份恢复策略异常告警绩效考核管理评价智慧分行人行支付报表客户营销报表统一监管报送报表客户存款报表存贷款报表风险管理报表接口规范业务状况报表.数据加载导出接口数据导出负载组策略混合负载管理数据质量核验数据管理用户管理权限管理任务管理批量调度主题模型编码规则导出编码优先级策略数据标准制定权限管理任务监控拉链算法数据清洗

97、导出策略排队策略数据安全管理角色管理调度引擎报表加工数据校验传输规范惩罚策略元数据管理日志审计抗疫模式数据加载互联互通生效策略主数据管理认证管理专场模式灵活分析批量加工案例 3：光大银行湖仓一体数据仓库大集中建设实践光大银行数据仓库于 2006 年启动建设，采用 Teradata 软硬一体数据库产品，构建以十大主题为核心的数据仓库基础数据模型，汇聚全行数据资产。2015 年引入数据库产品 Greenplum，采用软硬分离架构，将数据集市迁移到 Greenplum 集群，在提升数据处理性能、用户体验的同时，获得更高的科技和业务价值。为解决 Greenplum 集群横向扩展局限性，2019 年引入

98、华为云数据仓库 GaussDB(DWS)。一、案例内容新一代数据仓库平台并不是一次简单的产品选型和替换工作，而是53金融数据仓库发展报告（白皮书）全新的数据仓库技术架构重构工作。面对不断深化、不断融合、不断突破的数字未来，光大银行新一代数据仓库平台着力技术、数据两大方面，激发数据资产价值潜能。此外，光大银行以“湖仓”一体化打造坚实的基础数据平台。聚焦生态融合，实现湖仓一体共生，构建了以数据湖为基础的贴源数据，以数据仓库为核心的主题数据，以数据中台为中枢的共性数据，打造企业级数据服务能力，实现数据敏捷、高效、安全的交付。二、案例成效新一代数据仓库平台大集中将 Teradata 和 Greenpl

99、um 上数万个数据模型、数万个代码脚本、数百万行代码全部迁移至安全可控的数据仓库平台：1.全面提升监管报送、智能营销、智能运营、智能风控等业务领域的数字化经营水平：集群规模 627 台，算力提升 3 倍，批量时间缩短 10小时，数据查询效率提升 6 倍。2.采用集中化建设模式，全行数据统一加工、模型统一设计、开发统一规范、任务统一调度、资源统一管理，从而降低系统管理成本、技术复杂度，提升资源配置效率、数据一致性。3.设计标准化的作业流程指导数十个系统有序迁移，并在迁移过程中，正常承接开发需求、产能不降低，达到了“成本可控、时间可控、风险可控、质量可控、复杂度可控”的效果。54金融信息化研究所(

100、FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究案例 4：招商银行大规模金融云数据仓库建设实践随着数字化转型的快速推进，数据采集处理规模大幅增长，逐步呈现“人人用数，人人都是数据分析师”的数据应用模式，招商银行构建了具有自身特色的云数仓平台。一、案例内容传统数据仓库一体机技术方案存在着生态环境封闭、维护成本高、硬件故障维修复杂、扩容停机时间长等诸多问题，已不能满足快速、平滑的扩容需求。招商银行突破封闭技术路线，引入灵活扩展架构，采用华为云 GaussDB(DWS)建设新一代数据仓库提升平台性能。二、案例成效招商银行业务用户享受到了更轻盈的用数体验：1.查询速度快人一步。批量数据

101、处理完成进度整体提前 2 小时以上，业务用户查询时长缩短 75%，数据仓库服务效能显著提升；2.用数不间断，人人都是 VIP。集群扩容停机时长由 12-24 小时降至2-4小时，停机追批时长由1-2天降至业务零感知，平台运维能力大幅提升，用户随时取数用数，不再受维护和跑批的影响；3.数据丝滑迁移，替换无感。5千万业务代码搬迁量在新旧数据仓库替换过程中的并行期，通过自研工具实时数据校验，缩短数据核对间歇，实现一分钟内完成重要数据在新旧平台中的数据核对，让用户对替换过程无感知。55金融数据仓库发展报告（白皮书）4.资源弹性管理和按需扩展。在线扩容的重分布速度由 20TB/h 提速至 65TB/h，

102、在线备份速度由 37TB/h 提速至 150TB/h,缩短平台操作时间窗口，业务快速享用平台扩展后的更高算力。5.分布式优化技术，全面提升集群处理性能。实现高并发交互式查询秒级响应，并支撑业务上千并发联机查询。案例 5：中信银行新一代基础数据平台建设实践中信银行数据仓库始建于 2014 年，承担全行业务分析、数据挖掘以及监管报送的数据支撑重任。随着业务规模化用数需求爆发式增长，原有平台在性能、扩展性、开放性及服务能力等多个方面均略显疲态，业务数据供给的时效性问题逐步成为制约数字化转型的关键因素。一、案例内容2020 年中信银行启动新一代数据平台建设，对原有数据仓库进行重构改造，由一体机下移至分

103、布式服务器，并完成配套研发、管控、运维及测试工艺体系建设，形成基于 GaussDB(DWS)的新一代数据仓库平台生态，进一步提高数据仓库存算能力及数据服务能力。作为行内最重要的数据整合点，新一代数据仓库为全行各业务部门提供数据服务，包括总行、37 家分行、3 家海外分行、信银国际及 1 家村镇银行，涉及下游100 多个应用，涵盖所有业务条线。二、案例成效1.新平台有效解决数据时效性问题，使能业务高效增长。已稳定56金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究运行 1 年以上，重点作业准时率 99%以上，总分行接口下发时效性平均提前 5 小时以上，自助分析响

104、应时间减少 60%以上。2.以自研 B/S 研发平台为载体，全面建设工具化、线上化、规范化的敏捷研发系统，全链路优化传统数据仓库研发工艺。3.建立事前、事中、事后的全链路管控体系，提前发现并解决问题，最大限度减少生产环境的资源损耗，保证平台稳定运行。4.建立开发团队二线运维能力，提升运维团队大数据技术沉淀；借助移动端预警工具，团队应急模式由“被动告知”转变为“主动发现”。案例 6：民生银行融合型湖仓平台项目建设实践民生银行数据仓库是全行数据体系的关键基础数据平台，面向全行业务用户提供企业级数据应用支撑能力，具有同城对等双活的特点。随着数字化转型快速推进，单一数仓无法满足数据存储的多样性和灵活性

105、，数据应用的多领域（BI、AI、BI+AI）、多生态（SQL 生态、Hadoop 生态、Python 生态）融合的需求，民生银行同步启动了新一代数据仓库平台和湖仓平台建设。一、案例内容基于华为 FusionInsight MRS 和 GaussDB(DWS)，民生银行以一体化开发、一体化运维、一体化应用、一体化管理为建设目标，启动融合型湖仓平台项目建设。57金融数据仓库发展报告（白皮书）当前数据湖和数据仓库平台均完成基础资源部署，形成民生银行新一代湖仓平台雏形。根据实施规划，要素迁移从策略上按照各类数据模型的特性，自底向上分层分域方式逐层开展迁移，各分层采用差异化方式向数据湖和数据仓库迁移实施

106、。二、案例成效1.自动化迁移，提质增效。利用 Data0ps 能力，将代码迁移开发、各要素（DDL、脚本代码、数据等要素）的迁移实施、数据一致性检核以及迁移后异构并行下的部署管理和日常运行管理等功能进行工具集成。2.湖仓协同，降本增效。充分利用华为产品互联互通的特性，将湖与仓两种不同技术栈在数据层面、应用层面打通，通过无缝、高速跨源数据同步技术，降低数据流转成本；通过联邦 SQL 技术，将湖仓数据关联运用，支持用户跨源灵活探索，为数据应用降本增效。3.取长补短，开放兼容。利用湖的多租户管理能力和湖仓融合后的一体化数据资源，满足敏捷 BI、AI、BI+AI 等数据应用场景诉求，为数据赋能业务夯实

107、工作基础。案例 7：华夏银行湖仓一体化数据中台建设实践华夏银行数据仓库自 2014 年启动，经过多年迭代建成完备的数据体系，形成数据应用双驱动，统一调度的特色基础平台。随着业务快速发展，原数据仓库平台从时效性、扩展能力等方面无法满足业务应用需求。58金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究一、案例内容华夏银行启动数字化流程再造工程，选择 GaussDB(DWS)作为新一代数据仓库系统平台,并规划搭建湖仓一体化数据中台，按照统一数据模型和实施工艺，对内外部数据进行全域数据整合，实现数据全方位链接和融通。充分发挥“数据+模型+技术”主导作用，有效提升业务支

108、撑和风险识别能力。二、案例成效1.整合原数据仓库、仓外数据集市架构，形成统一数据处理平台，缩短了数据加工链路，提升了数据加工时效。图 3 数据中台目标架构BI及数据查询自助数据探索数据平台数据仓库数据湖数据科学与AI平台数据采集交换报表决策仪表盘开放层引擎层数据访问层AI及分析模型客户体验分行数据服务预测分析建模在线圈人多维数据即席查询元数据管理数据资产目录离线开发实时开发算法开发服务开发数据信息中台访问计算数据底座领域集市整合层数据资产运营数据资产监控数据资产评价数据标准管理数据质量管理数据安全与隐私API接口（联机）ODBC批量精准营销中心智慧运营中心智能风控中心监管合规中心分行特色中心一

109、致性难度应用维度交易事实分布式检索引擎外部数据整合区实时计算数据区贴源数据区历史数据区探索数据区机器学习深度学习图分析非结构化数据处理区客户风险运营合规分行公共汇总数据主题数据区自动服务引擎图计算引擎标签引擎指标引擎消息列队59金融数据仓库发展报告（白皮书）2.灵活扩展性方面具有较大优势，计算能力、存储规模相对原平台都有较大提升。3.未来将数据仓库、数据湖、实时数据等数据资产，按照多种技术模式、多种数据形态进行统一封装，实现数据成果的直达共享。案例 8：兴业银行数据服务“核心系统”迭代升级实践自 2006 年建设至今，兴业银行企业级数据仓库系统已为 120 个总行系统，43家分行及3个子公司提

110、供数据类服务，服务领域涵盖零售、企金、同业、金融市场、风险、计财、监管等。随着行内业务数据体量急速增长，原有平台无法满足应用快速发展的诉求，2021 年兴业银行启动了数据科创平台项目。一、案例内容基于华为云 GaussDB(DWS)建设新一代数字底座 MPP 基础平台，构建一套包括数据整合加工、平台运营监控、数据灵活查询、API服务等功能的综合数据服务体系，助力实现最佳生态赋能银行。当前项目已完成一阶段上线，初步形成了新一代数据处理平台的雏形。2022年底将完成整体建设工作，极大提升我行未来数据处理平台的高扩展性和可用性，同时拥有批量、实时、时序三大数据服务能力，且充分满足用户对平台的性能要求

111、。二、案例成效1.全栈信创，自主掌控：核心技术自有化，保障数据安全、网络安全和信息安全，提升金融业务数字化的稳定安全水平。60金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究2.能力融合，横向扩展：节点数增长 1200%，高可用空间增长2100%，点查询单集群并发能力增长 2400%。3.一站服务，智能运维：形成一套合理、高效、创新的数据平台管理方案，以数智化技术与业务流程为数据使用、数据治理、运行维护、业务发展赋能。4.全面开放，助力转型：以租户方式向全集团开发数据存储与计算能力，实现按租户隔离系统资源，打造绿色、安全、智简、敏捷的数据生态，赋能集团业务发展

112、。案例 9：中原银行融合数据湖建设实践与成效随着国内银行业数字化转型进程的加快，以及数据驱动战略在银行的落地实践，2019 年中原银行围绕着分布式数据仓库与大数据技术，以自主研发架构为主，构建了一套满足一站式数据集成、存储、整合、计算与开发的数据技术中台。一、案例内容中原银行融合数据湖方案涵盖了分布式存储、大数据、数据仓库等主流技术方案，通过构建湖仓与数据类服务的一体化方案，实现数据在其间按需高效流转与统一管理，满足全行不同业务条线的个性化多维度的数据统计分析需求。二、案例成效1.成本节约。支持多类型数据管理和 PB 级海量数据存储，通过采61金融数据仓库发展报告（白皮书）图 4 功能架构图智

113、慧零售智慧公司智慧风险智慧运营开发工具云原生数据湖云原生数据仓库数据采集交换平台外部数据核心系统信贷系统手机银行行为日志数据开发平台一站式数据分析平台冷数据自动迁移代码智能审核平台冷数据整合集群应用集群非结构数据贴源层数据用数据智能分层存储策略，有效降低行内数据单位存储成本 20%以上。同时也与行内模型管理平台、反欺诈平台完成对接，支撑了各类平台对图片数据的存储与使用需求。2.效率提升。通过 Openlookeng 提供的湖仓协同分析能力，有效避免不必要的 ETL，减少 50%以上的数据搬迁，并基于算子下推、元数据缓存、数据缓存等技术，支持数据湖查询秒级响应。3.研发高效。支持湖仓任务的协同开

114、发与调度，为全行 60+个项目组提供稳定高效的数据开发服务。案例 10：威海市商业银行湖仓一体数据中台建设实践威海市商业银行于 2012 年开展数据仓库建设，按需实现数据集中接62金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究图 5 威海市商业银行数据架构图数据消费者业务分析人员管理决策人员监管报送人员业务分析系统贷后风险平台智能营销内部数据STA(数据采集与交换)外部数据统一管控平台实时数据开发平台DWS（数据仓库、数据集市）MRS（数据湖）外部数据实时数据数据产生数据规划数据建设数据治理数据智能数据使用联盟数据源自有数据源管理驾驶舱BI&报表数据服务运营

115、平台及门户标签管理平台统一监管报送平台第三方API外部批次数据源埋点数据流日志数据流现有系统数据平台数据集市数据工具内部数据流外部数据流外部数据实时流实时数据流访问信息流数据资产管理平台统一数据开发平台数据应用入口数据服务网关TMP 数据临时区ODS 贴源数据区DWS（数据仓库）DM（数据集市）LDS 逻辑加工区RTL 零售集市CORP 对公集市RSK 风险集市HR 人力集市FM 财务集市FMKT 金市集市OPT 运营集市FR 监管集市RPT 报表集市HDS 历史数据区EDS 外部数据区SDS 实验数据区RDS 实时数据区UDS 非结构数据区数据输入区临时加工区数据输出区基础主题区汇总主题区公

116、共访问区FDSADSPDSINPUTMIDD OUTPUT入和应用系统数据供给，支撑全行共性数据加工和报表统计查询。伴随行内信息化进程加快，数据孤岛、开发周期较长、数据冗余、快速数据服务支撑能力弱、数据架构扩展性差和数据集群算力低等不足亟需解决。一、案例内容2022 年，威海市商业银行基于 FusionInsight MRS 和 GaussDB(DWS)启动湖仓一体的数据中台项目，项目正在持续建设中。目前已经完成全行数据入湖，支撑贷后管理、智慧运营、关联交易等应用。63金融数据仓库发展报告（白皮书）新一代分布式数据仓库构建基础主题模型，实现行内数据统一整合，构建零售和对公等 9 大业务主题集市

117、，在满足日常监管报送、数据自助分析等核心业务应用基础上，支撑业务中台、智慧营销和管理驾驶舱业务应用。二、案例成效1.通过基于湖仓一体集群高性能、高扩展、多模融合等特性，日终批量时间可缩短 3 小时，算力提升 3 倍。2.报表查询实现秒级响应，查询速度提升 3 倍，数据查询支持 7*24小时服务，实现 T+0 应用场景。3.集群故障率减少 80%，资源利用率提升 30%。案例 11：江南农村商业银行融合数据湖建设实践江南农村商业银行原数据仓库采用一体机进行数据加工、清洗、整合以及查询。随着国外厂商产品迭代，跨代升级产品和硬件更换的费用高昂，同时原大数据相关组件多年未更新版本，大数据组件中的各种外

118、部数据、非结构化数据与数据仓库进行关联分析有较大技术障碍，存在一定的数据孤岛问题。一、案例内容随着分布式数据库、云原生、湖仓一体等技术的不断演进，江南农村商业银行启动湖仓一体的融合数据湖建设。若干个独立的物理数据平台形成一个虚拟数据湖，汇聚多种格式数据源，并通过严格的数据权限和资源管控给各种使用者开放数据和算力。64金融信息化研究所(FITI)专注金融科技发展战略、金融科技理论与实务、信息安全研究二、案例成效1.提供统一的多维加密体系，支持统一安全分析、安全处置、安全态势感知等高级安全能力，实现信息安全防护与自主可控。2.通过 HetuEngine 实现湖仓联合查询分析，连接行内所有系统，打通

119、行内所有数据，覆盖行内所有人员，强化对全行数字化转型工作的支撑。3.实时计算能力和标签加工能力，全面覆盖我行 12 大交易渠道（手机银行、网银等）的 56 个业务场景，实现实时预警交易风险和阻断欺诈交易，全面防控我行三农客户免受金融欺诈风险。图 6 功能架构图DWS统一数据平台交互式应用江南融合数据湖数据源搜索应用关系型数据日志数据批/微批实时/准实时外部数据归档日志(CDC)数据科学批处理实时处理HBaseElasticSearchRedisFlinkSparkHiveHetuEngine U-SQL实时报表实时决策MRS湖仓一体版CarbonDataKafkaHDFS65金融数据仓库发展报

120、告（白皮书）本报告是金融信息化研究所联合金融机构和华为云针对金融数据仓库开展联合研究的成果，报告基于行业广泛调研结果、采用 FITI PIGTH 分析法，数易其稿，终于面世。报告编制得到中国人民银行科技司有关领导和部门的指导，得到金融机构和科技公司的大力支持；受到中国金电集团公司领导的高度重视，也得到金电信科、国金认证、生态实验室、金融电子化杂志社等兄弟公司的大力支持。报告完成后，广泛征集了行业专家的意见，并邀请行业数据库专家宋瑞、刘文涛、孙科等为报告评审把关，进一步提升报告质量。在此，对上述机构的领导和专家们一并表示感谢。稳妥发展金融科技，深入推进金融业数字化转型，有难题找 FITI！我们一起携手并肩，为金融业务数字技术解决方案贡献力量！致 谢网站：邮箱：更多详情，欢迎前往金融信息化研究所公众号FITI 金科智库，一揽子解决金科难题金融信息化研究所中国金电集团FTPC 金科智库