云原生产业联盟：云原生湖仓一体白皮书（2022年）（45页）.pdf

《云原生产业联盟：云原生湖仓一体白皮书（2022年）（45页）.pdf》由会员分享，可在线阅读，更多相关《云原生产业联盟：云原生湖仓一体白皮书（2022年）（45页）.pdf（45页珍藏版）》请在三个皮匠报告文库上搜索。

1、云云原生原生湖仓一体白皮书湖仓一体白皮书 （2022022 2 年）年）云云原生原生产业联盟产业联盟 Cloud Native Industry AllianceCloud Native Industry Alliance，CNIACNIA 20222022 年年 1212 月月 版权申明版权申明 本白皮书本白皮书版权属于版权属于云原生产业联盟云原生产业联盟，并受法律保护，并受法律保护。转载、摘编转载、摘编或利用其它方式使用或利用其它方式使用本白皮书文字或者观点的，应本白皮书文字或者观点的，应注明注明“来源：来源：云原云原生产业联盟”生产业联盟”。违反上述声明者，本。违反上述声明者，本院院将追

2、究其相关法律责任。将追究其相关法律责任。编编 制制 说说 明明 牵头编写单位牵头编写单位：中国信息通信研究院 参与编写单位参与编写单位：北京偶数科技有限公司、中国联合网络通信集团有限公司、中信建投证券股份有限责任公司、中国人寿保险股份有限公司。编写组编写组：中国信息通信研究院：刘如明、魏博锴、杜岚、周丹颖、蔡钰、李永欣 北京偶数科技有限公司：常雷、苏景志、陈超峰、杨哲、丁冉、张立群、钟彧恒、赵德攀 中国联合网络通信集团有限公司：刘洪波 中信建投证券股份有限责任公司：马丽霞、李可、李海伟、许哲 中国人寿保险股份有限公司：陈宗坚、林志鹏、彭晓刚、陈学亮、郑晓勇 前前 言言 近年来，数据产业总体保持

3、较快发展，国家先后出台了多项政策促进数据基础设施、关键技术、应用治理等方面的健康有序发展。伴随着行业用户对于数据价值的深入挖掘，数据平台和产品正在发挥着不可替代的创新引领作用。本白皮书首先介绍了数据平台发展的三个重要阶段，通过对于发展历程的总结，引出了行业用户在进行数据分析和处理中面临的瓶颈难题，并且重点从主要架构、关键技术、方案特征、应用价值等方面介绍了云原生湖仓一体最佳解决方案。之后，通过对于湖仓生态版图、代表厂商和代表解决方案的分析，力求反应现阶段国内湖仓生态现状。最后，从银行、保险、证券用户单位的不同角度出发，开展了较为详实的场景化应用分析，并进行了总结与展望。目目 录录 一、云原生湖

4、仓一体发展历程.1(一)萌芽期：数据仓库初探数据价值.1(二)上升期：大数据平台挖掘数据价值.3(三)成熟期：湖仓一体全面展现数据价值.5 二、云原生湖仓一体方案概述.7(一)行业用户数据处理五大难题.7(二)解决数据处理瓶颈的最佳方案.11(三)云原生湖仓一体主要技术路线.23(四)云原生湖仓一体方案应用价值.25 三、云原生数据湖仓生态现状.28(一)国内湖仓生态版图.28(二)国际湖仓典型应用.29 四、云原生湖仓一体实践案例.31(一)中国建设银行从湖到湖仓一体的演进之路.32(二)中国人寿湖仓一体总体规划的研究之路.34(三)中信建投数据仓库与数据湖的融合探索之路.34 五、总结与展

5、望.36 附录：湖仓一体典型解决方案.37 1 一、云原生湖仓一体发展历程 在全球数据产业蓬勃发展的背景下，数据系统正在发挥关键的支撑赋能作用，对于数据价值挖掘和业务创新发展起到重要影响。为了应对各类用户需求，衍生出了聚焦联机事务处理、联机分析计算、事务分析混合等不同场景的数据平台。数据平台作为企业数字化转型的重要基础设施，决定了企业对数据这一新兴生产要素的应用能力，对企业数字化转型的成败起到了至关重要的作用，其发展经历了三个时期。(一)萌芽期：数据仓库初探数据价值 1.发展背景 上世纪 50-60 年代，数据管理工具以“数据库”的形式首次问世，先后基于网状模型、层次模型、关系模型等不同的数据

6、结构，出现了IDS、IMS、DB2、Sybase、Oracle 和 SQLServer 等各类产品。其中最具代表性的传统关系型数据库，本质上是通过结构化查询语句，对数据进行增、删、改、查操作，以实现在 OLTP 联机事务处理场景下对于关系型表结构数据的存储和利用。随着业务规模和类别的不断丰富，累积的历史数据越来越多，对业务数据库产生负载，导致业务系统运行速度降低。在日益激烈的市场竞争中，企业需要对积累的数据进行分析，获取更加准确的决策信息来完成市场推广、运营管理等工作。由此，提出将历史数据存储到 2 数据仓库(OLAP)解决方案，在改善业务系统数据库性能的同时，可以更专注的提升数据分析效率，辅

7、助企业决策。2.技术特性 传统关系型数据库的技术架构，尤其是 OLTP 数据库在海量数据的存储、查阅以及分析方面出现了明显的性能瓶颈。随着分布式技术的产生和发展，出现了以 Teradata 为代表的 MPP 一体机数据库，以及 Greenplum 和 Vertica 等软硬件分离的 MPP 数据库，采用无共享架构(Share-nothing)以支持数据仓库的建设。这个阶段的主要任务是数据分析和决策支持类系统的建设，如数据仓库、ODS、数据集市、应用数据库、历史数据库以及报表、分析报告、数据挖掘、客户标签画像等。图 1：OLAP 系统建设 3.阶段特点 该阶段早期，不少企业直接采用了共享存储（s

8、hare-disk）架构的Oracle 和 DB2，或是采用 MPP 无共享（Share-nothing）架构的 Teradata等产品，通常基于软硬一体的专有服务器和昂贵的存储，后虽然引入 3 了基于通用 X86 服务器的解决方案，但架构依然是“无共享”的，特点体现为：数据以结构化为主，集群的扩展能力有限。图 2：数据仓库架构图 然而，随着用户数据量的指数级增加，丰富的数据源接入，数据开始呈现出海量、异构、多源等特点，传统数据仓库扩容困难、处理数据类型单一的缺点开始逐渐暴露出来，也无法支撑越来越丰富的业务分析需求。(二)上升期：大数据平台挖掘数据价值 1.发展背景 21 世纪初期，随着互联网

9、行业线上业务的快速发展，数据规模呈几何倍数增长，数据种类也变得更加丰富。传统数据仓库侧重结构化数据，建模路径较长，无法满足企业对于非结构化数据的处理以及数据处理时效性的需求，由此带来了海量异构数据存储和处理等的诸多问题。基于谷歌“三驾马车”论文，形成了 Hadoop 大数据解决方案，4 大数据平台开始受到关注，尤其受互联网行业迅速发展的影响，大数据平台迎来快速发展期。2.技术特性 Hadoop 平台使用 HDFS 实现数据的分布式存储，有效解决海量数据的存储问题。与传统数据仓库相比，HDFS 在支持存储结构化数据的同时还实现了非结构化数据的存储。HDFS 不是一个单机文件系统，而是分布在多个集

10、群节点上的文件系统。当存储文件时，文件的数据将分布在多个节点上。读取文件时，数据从多个节点读取。Hadoop 平台使用 MapReduce、Spark 等组件实现分布式计算，并且可以对存储的数据进行大规模并行处理。通过切片将大量复杂的任务分解成多个少量简单的任务进行处理，再对处理完成后的任务结果进行汇总分类。3.阶段特点 Hadoop 发展初期仅有 HDFS 和 MapReduce 两个组件，随着数据量的不断增大以及对于数据处理时效性的需求不断升高。计算和存储组件也在不断的变化，以适应不同场景的数据存储与处理需求。大数据平台底层存储经过了十余年发展，一直是 HDFS 一枝独秀。大数据平台在计算

11、方面发展迅速，由于最初的 MapReduce 大规模批处理无法满足海量数据处理的实时性，业界在计算方面设计了Spark 快速批处理、Flink 实时数据处理等计算框架。配合这些计算框 5 架的，还有像 Sqoop 这样的数据流转采集组件。在大数据分析和处理领域，Hadoop 兼容体系已经成为一个非常成熟的生态圈。图 3：Hadoop 生态系统重要组件 Hadoop 的诞生改变了企业对数据的存储、处理和分析的过程，加速了大数据的发展，受到广泛的应用，给整个行业带来了变革。随着云计算时代的到来，企业开始对 Hadoop 的架构进行从基于物理集群到云原生化的改造。(三)成熟期：湖仓一体全面展现数据价

12、值 1.发展背景 经过前两个阶段的尝试，更多的企业发现独立构建大数据平台与数据仓库平台的技术架构，已经无法满足某些场景下的业务需求。企业在构建数据湖和数据仓库的同时，通过ETL操作实现数据的汇聚，完成湖仓独立部署，这就是业内常说的“Hadoop+MPP”模式,我们称之为湖仓分体模式。湖仓分体模式最大的问题就是数据孤岛和业务实时数据分析能力不足，因此面临着数据多集群冗余存储、集群规模受 6 限、业务的实时性不足、业务应用开发敏捷需求不足等问题，这些需求和痛点促进了湖仓一体技术的发展。2技术特性 湖仓一体方案应该在数据和查询层面形成一体化架构，彻底解决实时性和并发度，以及集群规模受限、非结构化数据

13、无法整合、建模路径冗长、数据一致性弱、性能瓶颈等问题，有效降低 IT 运维成本和数据管理的技术门槛。所以，新时代需求的湖仓一体方案应具备实时处理、数据共享、高并发、云原生等特性。3.阶段特点 云的普及让业务上云成为趋势，为了实现数据湖的灵活性和数仓的易用性、规范性、高性能结合起来的融合架构，并且保证存储和计算可以独立的弹性扩展和伸缩，数据平台的设计出现了一个崭新的架构，即存算分离架构。在此阶段，Snowflake、Amazon、阿里云、偶数等企业相继突破了传统 MPP 和 Hadoop 的局限性，实现了存算分离。从市场发展角度出发，“湖仓一体”架构是技术发展的必经之路，优势明显，缺点也同样突出

14、，而更为先进的“湖仓原生一体”架构在未来将更加契合用户对于数据价值挖掘的诉求。7 二、云原生湖仓一体方案概述(一)行业用户数据处理五大难题 2000 年以来，随着大数据技术的广泛使用，金融行业的运营管理人员每天都会采用报表数据来指导决策，由于业务的不断增长，采集的数据复杂度越来越高，管理者希望能第一时间掌握市场动态，以便及时做出有利于业务发展的决策。为了满足业务应用发展要求，数据处理通常会遇到各种挑战。数据加工过程中，需要耗费大量时间，完成各种业务数据加工处理和汇总统计；数据开发过程中，需要耗费大量人力，借助各类数据工具，从多个数据源系统中采集搬运数据并进行分析；数据管理过程中，需要充分考虑安

15、全因素，避免由于不同使用者的修改，或者系统故障，造成数据不一致，从而影响数据分析结果；数据应用过程中，需要保障消费者的使用体验，面对海量的历史数据，所有的信息查询都要通过各种条件限制，以控制查询的数据规模；数据系统升级过程中，需要停止业务操作，影响业务连续性等。我们据此总结出了现阶段数据处理瓶颈的五大难题。1.数据处理面临数据孤岛的难题 很多企业的数据平台都是经过多次系统迭代和技术升级后建设而成的，在这个过程中随着技术的发展、组织管理结构变化，导致企业的数据平台往往存在多个数据库集群，每个数据库就是一个数据孤 8 岛和烟囱，甚至因数据库产品的扩展性，还可能导致 MPP 和 Hadoop集群建设

16、多套的情况，形成更多的孤岛和烟囱。图 4：数据孤岛 这些数据孤岛和烟囱的出现在存储、开发、运维、治理等多个方面带来了影响。数据存储方面，多个独立数据库集群中都放了同样的数据，大约可以造成 3 倍-5 倍的数据冗余，相当于占用了大约 3 倍-5倍存储空间，这就意味着造成了大约 3 倍-5 倍的资源成本的浪费。数据开发方面，多个数据库集群，意味着，数据平台整体的架构相对复杂，不同集群之间的时序、数据同步流程多。这种情况会导致数据库产品技术门槛多，对于技术人员的素质要求高；集群之间需要大量的数据同步，一般情况下同步作业占到总作业量 50%左右，对于一项数据开发的总体工作量大约增加了 1 倍左右。从项

17、目管理的角度看大约增加了 1 倍的成本；同时，作业的链路延长，大大降低了数据时效。技术运维方面，和开发面临的情况基本类似，对于运维人员的素质要求较高，需要精通多个数据库产品，日常运维管理的数据作业任务也比较多。数据治理方面，基于多份数据进行维护，可能会导致数据不一致，数据质量等问题，数据治理难度大，浪费的成本难以估量。9 2.数据处理面临性能瓶颈的难题 传统数据平台的计算性能不能满足业务需求，大体上有两种情况：一方面因数据平台的数据处理、业务查询时间长，性能慢，无法满足业务需求，需要在业务流程和用户端进行规避，导致用户体验很差。另一方面部分企业为了提高性能，在数据平台之上架设一个或多个内存查询

18、引擎，这种方式牺牲了 ACID 和兼容性。性能不足的问题影响运营、决策效率、无法支撑业务运行对时延的要求；部分计算引擎为了提升计算效率，牺牲了事务一致性，牺牲语法兼容性；部分计算引擎只支持简单查询，缺少复杂关联分析能力。3.数据处理面临高并发复杂查询的难题 随着移动互联网的发展，很多业务逐步开放至更多的人员参与，出现了很多需要数千查询并发的场景，例如：明细数据查询，数据集市查询；保险销售员查询业绩，客户查询权益视图；证券研究员查询上市公司数据等各类场景。但是传统数仓、Hadoop 仅支持几十并发，导致分库、分表，限制业务部门使用，限制查询，对很多新型的业务没有很好的支撑。为了保证各类查询同时进

19、行，采用很多计算引擎分流的方式实现，如：实时计算、批处理、固定报表、即席查询等厂家分别由不同计算引擎来支撑，无法统一查询，数据平台采用的数据库产品无法同时支撑多业务场景。4.数据处理面临实时处理的难题 10 Gartner 定义的实时数据处理的包括三个阶段：第一阶段，Real-Time Continuous Intelligence：对事件做出实时处理响应，包括指标对比，告警，趋势分析，自动决策；第二阶段，Real-Time,On-Demand Intelligence：生成报告，支持即席查询，延伸数据探索，记录操作流程；第三阶段，Offline On-Demand Intelligence：

20、离线任务，包括报告，即席查询，实时决策，建模及长期决策；对应的在实时分析处理中按照事件的发生时间长短可以总结为：事件发生同时的实时流处理、事件发生短时间内的实时按需分析、事件发生后较长时间的离线分析。图 5：实时分析场景 传统数据处理平台不能完全满足实时数据分析需求，存在以下问题：实时数据与批量数据的关联查询，有实时数据与维表关联查询，有实时数据与事实数据关联查询，离线数据量大现有平台难以支撑；多库数据无法实时归集，按需查询需求无法满足；交易型数据库无法支持频繁、复杂的查询，为保证数据库的稳定，只能限制查询；现有 11 基于 Flink 和 Kafka 的流处理平台，不支持数据血缘，不能支持即

21、席按需查询分析等。5.数据处理面临资源弹性伸缩的难题 传统数据平台因技术架构的局限性，对敏捷弹性资源管理支持度不高，在升级维护时需要暂停服务，对业务造成极大的影响。资源敏捷管理难题基本可以分为敏捷应用响应难题、如何实现资源弹性合理调配使用。敏捷应用响应难题主要体现为：传统 MPP 上线新应用的资源分配周期长，无法满足业务端快速试错、快速布局的诉求；超过集群规模上限时，性能不增反减，约减少 50%以上；集群扩容耗时很长，停机维护影响业务等。资源无法弹性调度，波峰波谷资源不能合理有效分配和使用，主要体现为：在非云环境，资源不能共享，资源以独占的方式使用，利用率很低；资源不够时无法弹性扩展，资源空闲

22、时无法分配给需要的用户，无法做到削峰填谷，提高资源利用率。(二)解决数据处理瓶颈的最佳方案 通过对于现阶段数据分析存在的瓶颈和难题进行深入分析，我们发现，为了解决数据孤岛、性能不足、高并发、实时处理和资源弹性问题，可以尝试以下的解决方案：数据孤岛 需要数据平台架构支持存算分离，实现单一数据集群能支持数千上万节点，这样避免由于单一集群规模限制产生数据孤岛；12 性能不足 大数据平台的计算引擎相比 MPP 存在较大差距，需要引入基于MPP 技术的高性能解决方案，提升计算引擎的处理能力；高并发 传统的 MPP 技术或者大数据平台技术都只能支持数十并发，需要引入多主节点技术实现分析型数据平台上的高并发

23、，将并发从目前的数十可以提升到数千或者上万；实时处理 目前的实时处理只能处理实时场景，无法同时处理实时和数据规模比较大的历史数据相结合的实时业务场景，需要引进支持海量数据下实现高性能高并发以及具备资源隔离的支持多租户技术的数据平台，才能满足所有实时业务场景的需求；资源弹性 当前数据平台在资源横向扩展时，无法做到计算和存储资源的各自独立扩展，同时，对于资源的使用无法实现根据业务需要进行设置，导致资源利用率不高，使用成本很高，需要引入存算分离的架构，并且支持虚拟计算资源的管理方式，实现业务按需进行计算资源的分配调度管理。同时考虑到以上计算存储分离、弹性可扩展架构、ACID 特性、SQL 标准支持、

24、高性能并行执行等方面的能力，基于云原生技术架构的云原生湖仓一体产品，可以通过云平台构建、部署和交付的数据服务，提供可扩展的、高可靠的数据解决方案。1.云原生湖仓一体典型架构 Gartner 认为湖仓一体是将数据湖的灵活性和数仓的易用性、规范性、高性能结合起来的融合架构，无数据孤岛。云原生湖仓一体就 13 是将数据湖和数据仓库两个平台合为一个平台，并依托云原生的特性，支持基于数据湖的普通存储硬件和存储引擎以及数据仓库的多功能高性能分析引擎，实现对海量原始数据（结构化、非结构化、流式数据、图数据）以及洁净数据（对原始数据进行治理和分析后的数据）统一存储、分析、管理，集群可在线扩容到几千节点。支持数

25、据仓库的丰富功能及高性能，支持配套的高性能 ETL、数据治理及数据资产管理工具等。支持数据科学和自动化机器学习，支持无代码/低代码数据加工，支持自助式 BI。图 6：云原生湖仓一体典型架构 2.云原生湖仓一体关键技术（1）存算分离技术 在云原生数据库出现之前，由于单机吞吐量和集群网络带宽限制等因素，数据库集群部署都是存储和计算在一起，让计算靠近数据，而不是将数据传输到计算节点，这种方式可以产生更少的数据迁移，降低机器间、机柜间的网络带宽消耗。随着数据量的增长，无论是计 14 算还是存储先达到瓶颈，都必须同时对计算和扩展进行扩展，因此就会存在不少浪费，并且扩展需要大量数据移动，非常不方便。计算与

26、存储的解耦，可以让我们更加方便的管理计算与存储资源。在大规模数据处理场景下，管理员可以快速的单独扩展计算或存储资源，并且性能可以随着节点的增加线性增长。存算分离后，数据实现了统一存储，可以被多种计算引擎所共享。因此，存算分离是湖仓一体平台必备的技术之一。然而，存算分离也带来了挑战，比如存算解耦以后，如何管理计算层与存储层的映射关系，节点异常处理、如何保证读写一致等问题。此外，存算分离需要万兆甚至更快的网络带宽。因此，存算分离架构通常是云原生数据库的重要特性之一。（2）高性能计算引擎技术 存算分离以后势必带来更多的网络开销，影响数据库集群的整体性能。因而需要通过其他方面的增强来弥补这一损耗。其中

27、一个重要的途径就是通过优化计算引擎来增强性能。采用基于代价的优化器（CBO），通过算法来动态选择每个 SQL的最优查询计划，弹性的执行引擎可以动态调整计算单元，使得资源使用更加合理和高效。在计算层通过使用向量化执行器可以大大提升SQL 的执行速度，由于存算分离会带来额外的网络开销，因此计算层采用分布式的缓存服务，采用基于 LRU 协议的缓存管理机制，用户还可根据情况动态配置缓存空间的大小，缓存支持使用内存和计算节 15 点的本地磁盘空间。节点之间的通讯协议，改为采用 UDP 的互联协议，可以大大提升通讯效率。性能的提升意味着在单位时间内云原生湖仓一体平台可以处理更多的数据。（3）多活主节点支持

28、超高并发 云原生湖仓一体平台的主节点采用多活主节点集群部署，主节点采用无状态设计，各主节点之间没有相互依赖关系，不存储任何元数据。用户可以非常方便的对主节点集群进行扩展，以处理更多的连接请求(JDBC/ODBC)。主节点可以在线增减，实现资源的动态调度。例如当用户请求越来越多时，用户可以根据情况随意增加一个或多个主节点，反之则可以减少一个或多个主节点。主节点的动态增减不会影响数据库的服务。当主节点集群中某个节点出现故障时，也不会影响整个集群的可用性。支持用户可视化的方式轻松完成扩容。图 7：多主节点架构（4）元数据集群高可用 元数据集群架构采用 P2P 去中心化完全对等网络架构，集群内无固定主

29、节点，通过一致性协议算法实现节点的数据同步，当某一节点 16 宕机时，集群内部可自动实现服务的漂移而无须人工干预，实现了集群的高可用。元数据采用多副本机制，均匀的分布在各个节点上，确保了元数据的安全。各个主节点将同时并发连接每个元数据节点，因此，元数据集群内不存在单点瓶颈，实现了元数据读写的负载均衡。（5）多虚拟计算集群支持混合负载 在存算分离基础上，多虚拟计算集群支持对用户访问的 CPU 和内存资源的物理隔离。多虚拟计算集群（Virtual Cluster）可以将一个超大规模计算节点根据负载情况划分为多个虚拟计算子集群。数据库管理员可通过配置，将用户与某个 VC 进行绑定。当用户发起执行请求

30、后，主节点只会调度该用户对应的 VC 资源来执行，当 VC 资源不够时，管理员可快速增加从其他 VC 中调度计算资源来给 VC 进行扩容，并且是在线秒级扩容。用户可根据自己的业务场景划分多个 VC，来支持不同的业务部门或机构。同时，因为快速的进行资源调度，可以大大提高资源利用率，从而减少硬件资源的投入。图 8：多虚拟计算集群 17 （6）可插拔存储框架 可插拔存储框架实现计算资源可同时访问不同类型的存储，如：HDFS 存储、基于 S3 协议的对象存储以及分布式表存储。通过可插拔的存储框架，可以实现在线的存储扩容，例如，管理员可以方便的通过配置，新增一套或多套存储系统，并且这种异构的存储对于用户

31、访问是透明的，即用户无需知道数据存放在哪种存储上，而是直接通过表名读写数据。可插拔存储框架还可以支持二次开发，用户可通过二次开发使得计算引擎对接未来新出现的存储系统。如下图所示，通过可插拔存储框架的支持，使得云原生湖仓一体平台可以对接多套 HDFS，并且对用户无感。图 9：可插拔存储架构（7）多虚拟存储集群实现磁盘 IO 的隔离 上述的可插拔存储框架实现了计算资源与存储的对接，但是在实际使用中，依然存在着存储中磁盘 IO 资源的竞争，因此多虚拟存储的功能实现类似于 HDFS 的联邦功能。多虚拟存储集群支持用户将多 18 套 HDFS 集群或分布式表存储集群划分为一套虚拟存储集群（Virtual

32、 Storage Cluster）。开发人员在进行数据建模时，可以根据磁盘 IO 的负载情况，将不同负载的表建在不同的 VSC 中，就可实现负载的隔离，用户在使用时不会感知 VSC 的存在，并且 VSC 与计算阶段没有绑定关系，可以被任意的计算资源访问，保证了数据的共享。同时，云原生湖仓一体平台根据使用量自动将不同的表分布到统一 VSC 中的不同 HDFS 集群或分布式表存储集群中，从而实现数据的均匀分布。基于这个特性，用户在进行存储扩容时就实现在线的秒级扩容而无须进行数据重分布。当某一 VSC 存储空间不够时，用户可以新部署一套 HDFS 集群加入到 VSC 中，即实现了存储空间的扩容，又无

33、须进行人工干预。图 10：多虚拟存储集群（8）高性能分布式表存储支持实时数据读写 在实时场景中，数据往往是逐条进行插入、更新或删除，这种对数据的操作特性与交易场景非常接近，而 HDFS 或对象存储仅适合对 19 数据进行批量操作，并且原生并不支持数据的更新，无法满足实时场景的业务需求。因此，云原生湖仓一体平台需要引入分布式表存储支持高并发、事务以及提供索引，并且原生支持数据更新和删除。在云原生湖仓一体平台的架构中，分布式表存储与HDFS、对象存储平行，是能够独立运行的存储系统，不依赖第三方组件。分布式表存储的主要特性有：采用完全点对点(P2P)无中心分布式存储（相比主从架构更容易管理更容易扩展

34、）结构化数据定义存储（不是简单键值对形式存储）支持数据的增删改查（提供真正的 INSERT UPDATE DELETE功能）支持基于 Raft 协议数据复制实现数据存储和访问服务的高可用 支持基于多版本 MVCC 的分布式事务特性 目前提供针对分析型负载的高性能数据查询能力（行列混合存储格式）支持数据索引功能（包括主键索引，非主键索引）整合数据预处理技术提升数据查询性能（非纯粹的数据存储实现，具有内建计算能力）便捷的集群动态扩展 自动集群容错和负载均衡能力 20 图 11：高性能分布式数据读写 从读写性能的角度比较，分布式表存储的性能优于 HDFS，HDFS的性能优于对象存储。因此，在实际使用

35、中通常会把 T+0 的实时数据写入分布式表存储，T+1 的批量数据写入 HDFS，而对象存储由于更加低廉，但是性能最慢，所以一般只用来存储三年以上的历史归档数据。从用户视角看，开发人员需要基于不同使用场景把不同的表建立到不同的存储中，在之后的使用中则不再感知异构的存储，也就是说用户直接通过表名即可查询各种类型存储中的数据，也可以把存储在不同类型存储中的数据进行关联查询、计算、比较等不同的操作。如下图所示：21 图 12：高性能分布式 SQL 查询（9）Hadoop 生态兼容能力 云原生湖仓一体平台可以直接使用 Hadoop 生态普遍使用的HDFS 来作为数据存储，同时存储格式使用开源社区比较通

36、用的 orc和 Parquet 格式，此外还支持 CSV、TEXT 等类型。支持直接读写 Hive数据，无须预先创建外表，更无需搬迁数据，云原生湖仓一体平台管理的数据表也同样可以被 Hive 访问。在实时场景下，源数据主要有两类：一类是流计算引擎处理的过程或结果数据，另一类是通过 CDC 工具采集的实时变化的数据。云原生湖仓一体平台支持这两类数据的同时读写。例如：Flink 可直接连接分布式表存储，将流处理结果直接写入分布式表存储中，用户可使用 SQL 直接查询。此外，云原生湖仓一体平台支持使用 Hudi、Iceberg 开源数据湖格式，用户也可以选择将实时数据直接写为 Hudi 22 或 I

37、ceberg 格式，这样可以将数据统一存储到 HDFS 中，实现数据的物理统一。3.云原生湖仓一体六大特性 对于上述云原生湖仓一体的关键技术，我们从用户角度概括成六个代表字母的 ANCHOR 特性。A(All Data Types:支持多类型数据）、N(Native on Cloud:云原生）、C(Consistency:数据一致性）、H(High Concurrency:超高并发）、O(One Copy of Data:一份数据）、R(Real-Time:实时 T+0）。支持多类型数据（All Data Types,Structured&Unstructured）：支持关系表、文本、图像、视

38、频等结构化数据和非结构化数据存储。云原生（Native on Cloud）：适合云环境，自由增减计算和存储资源，按用量计费，节约成本，不再有数据孤岛存在。数据一致性（Consistency）：通过完善的事务机制，保障不同用户同时查询和更新同一份数据时的一致性。超高并发（High Concurrency）：支持数十万用户使用复杂分析查询并发访问同一份数据。一份数据（One Copy of Data）：所有用户（BI 用户、数据科学家等）可以共享同一份数据，避免数据孤岛。实时 T+0（Real-Time）：通过全量数据 T+0 的流处理和实时按需查询，满足基于数据的事前预测、事中判断和事后分析。2

39、3 (三)云原生湖仓一体主要技术路线 1.主要技术路线对比分析 目前，常见的湖仓一体技术方案主要有两大类型：基于传统Hadoop 架构的方案，以及基于云原生数据仓库架构的方案。基于传统 Hadoop 的方案主要从事务特性出发进行优化，基于HDFS 或 S3 实现一个支持事务的存储层，其他方面与 Hadoop 区别不大。而云原生数据仓库，其存算分离特性更具有技术前瞻性，该架构将是未来的发展趋势。维度维度 参数参数 云原生湖仓一云原生湖仓一体平台体平台 传统数据仓库传统数据仓库平台平台 传统数据湖平传统数据湖平台台 技术先进性技术先进性 技术架构 云原生、存算分离 非云原生、存算耦合 非云原生、存

40、算耦合 性能性能&并发并发 性能 高 中 低 并发 高 低 低 功能功能 支持事务 完整支持事务ACID 完整支持事务ACID 事务支持差 集群规模 100000 1000 SQL 标准 完善兼容 SQL标准 完善兼容 SQL标准 部分兼容 SQL 数据类型 结构/半结构/非结构化 结构化 结构/半结构/非结构化 存储引擎 可插拔存储：HDFS/S3/Magma 本地表私有存储 HDFS/S3 24 存储格式 ORC，Parquet，Hudi 等 私有格式 ORC，Parquet 全实时 支持 否 否 湖仓一体 支持，OushuDB 支持 HTAP 否 否 开发开发 数据共享 共享同一份数据

41、数据孤岛、共享困难 数据孤岛、共享困难 数据治理 简单 复杂 十分复杂 实施难度 低 低 高 运维运维 运维难度 低 低 高 2.云原生湖仓一体的建设路径 从云原生湖仓一体平台的建设方式上，企业可以结合业务情况、已有数据平台情况等方面出发进行建设路径的规划，主要有以下三种建设途径：从数据仓库到云原生湖仓一体 企业目前数据类应用主要集中在数据仓库，而且总体数据量也不大的情况下，可以考虑从数据仓库向数据湖方向建设，最终实现云原生的湖仓一体平台建设。首先从数据仓库开始进行技术平台的升级，选择云原生的数据库产品进行数据仓库的迁移替换，将底层“仓”的存储和“湖”的存储实现数据打通，建立统一的数据模型。从

42、数据湖到云原生湖仓一体 一般情况下，因数据湖中的数据体量较大，为了避免数据的搬迁采用从数据湖到湖仓一体的建设方式，最终实现云原生湖仓一体平台。25 在现有的数据湖上进行技术平台升级，在湖上增加具备数据仓库计算能力的组件并将新的业务应用部署到湖仓一体平台上，逐步将原有的数据仓库和集市的数据和应用都迁移到湖仓一体平台上。数据湖和数据仓库融合建设 湖仓融合的建设方式要求：不再有独立的数据湖和数据仓库，湖仓融合为一个产品的解决方案，底层的数据产品均具备云原生特性、计算存储分离弹性可扩展架构、强 ACID 特性、强 SQL 标准支持、高性能并行执行能力。首先，进行平台技术能力升级，将原来的数据湖和数据仓

43、库底层的数据产品的元数据打通，共享一份元数据，数据湖和数据仓库共同使用一个入口，并保证强事务一致性。其次，构建统一的数据模型，将数据湖和数据仓库的数据纳入统一的数据模型进行管理，并只保留一份。最后，完善数据处理工艺，制定统一的数据接入标准，数据处理工序，数据存储原则等。最终完成云原生湖仓一体平台的建设。(四)云原生湖仓一体方案应用价值 1.用户体验的提升 云原生湖仓一体平台能够大大提升用户的数据服务体验：管理人员：一个湖仓一体的平台可以统一运营企业内所有应用的数据，不需要单独考虑不同数据平台产品的部署、招标采购、扩容等问题，提升了管理决策的效率，降低了管理运营的成本。26 运维人员：仅需要运维

44、管理一个平台，技术架构简洁，运维门槛降低。而且湖仓一体平台存算分离的架构，支持计算资源与存储资源的单独横向扩容和缩容，给日常的升级维护带来极大的便利。业务人员：湖仓一体平台实现超高的并发，一个平台支撑所有数据存储、计算、分析的需求，并提供面向业务部门的自助数据分析服务，在实际工作中不需要切换平台进行业务实现；数据底层共用一份数据，用户之间可以很方便地共享数据。2.数据平台运营成本下降 云原生湖仓一体平台支持资源物理隔离，按照业务需求分配资源，大大提升资源利用率、硬件资源池按需建设，采购规模下降、折旧减少。通过湖仓一体平台可以有效降低数据平台运营成本，主要体现在以下几方面：湖仓一体平台完成了数据

45、仓库、数据集市和数据湖的数据整合，实现一份数据，融合共享，避免了多份数据存储，可以节省大约 3 倍-5 倍存储空间和资源成本。平台基于一份数据，避免了不同数据平台间的数据传输和拷贝，一般在数据处理任务中数据同步作业占到总作业量 50%左右。开发工作量可以节省 1 倍左右、平台算力资源节省 1倍左右；同时，避免了作业的链路延长，数据时效降低。27 湖仓一体平台基于云平台进行部署，不再依赖底层单节点的计算和存储资源，由云平台统一进行合理的安排和管理。不同配置的服务器都可以通过云平台提供算力资源和存储资源。3.管理、开发和运维的效率提升 云原生湖仓一体平台启用以后，可以大大提升管理，开发，运维和业务

46、部门的协同工作效率，降低管理成本，具体体现在以下方面：管理人员相比原来的平台可以近乎实时的了解企业业务现状，第一时间做出决策；运维人员仅需维护和管理一个平台，极大地减少了运维压力和成本。湖仓一体平台能够超高并发的处理多业务场景，不需要额外学习其他产品，有效地降低了技术开发门槛。平台基于一份数据，还降低了数据治理难度。降低了数据治理类项目成本投入；避免了数据同步作业开发，开发工作量节省 1 倍左右、减少 1 倍左右的项目成本；同时，作业的链路延长，数据时效降低。云原生湖仓一体平台具备的实时特性支持业务创新，增强用户体验，可以让用户与金融行业的企业之间互动更加频繁，带来最佳用户体验，形成业务发展的

47、新模式，带来新价值。28 三、云原生数据湖仓生态现状(一)国内湖仓生态版图 当前，湖仓一体技术架构正处于发展早期，头部企业纷纷尝试构建自己的湖仓一体数据平台。以金融行业为例，“湖仓一体”的应用覆盖银行、券商、保险等细分领域，可以帮助企业应对数字化转型过程中的创新难题。图 13：国内湖仓生态版图 2020 年，大数据 DataBricks 公司首次提出了湖仓一体（Data Lakehouse）概念，希望将数据湖和数据仓库技术合而为一，此概念一出就得到众多厂商的推崇。湖仓一体技术依托硬件层提供的计算、存储、网络能力，实现数据采集、汇聚、计算、分析，是整个“湖仓一体”的生态基石。湖仓一体通过基础软件

48、层的技术创新，打破了数据湖与数据仓库在存储、计算、网络三个层面割裂的体系，并将数据湖的灵活性、生态丰富能力与数据仓库的企业级部署能力进行融合，构建了数据湖和 29 数据仓库相融合的数据管理平台。“湖仓一体”继承了数据仓库的数据处理和管理优势，打通了数据湖和数据仓库两套体系，让数据和计算在湖和仓之间自由流动，既能面向业务实现高并发、精准化、高性能的数据实时查询服务，又能承载分析报表、批处理、数据挖掘等分析型业务。软件层面，企业在数据接入、数据存储、数据管理、数据分析等不同技术方向做出了新的尝试。在服务层面，根据不同行业场景的具体应用需求，各大厂商纷纷为用户提供行业定制化的解决方案，帮助企业解决数

49、据孤岛、实时数据分析、高性能处理、高并发查询、资源弹性伸缩等难题。为企业提供安全可靠的“湖仓一体解决方案”，构建融合创新的新一代数据平台。(二)国际湖仓典型应用 1.Lambda 数据框架 Lambda 数据处理框架由 Storm 的作者 NathanMarz 首次提出，目标是设计出一个能满足实时大数据系统关键特性的架构，整合离线计算和实时计算，读写分离和复杂性隔离等，可集成 Hadoop，Kafka，Storm，Spark，Hbase 等各类大数据组件。Lambda 架构通过把数据分解为服务层（ServingLayer）、速度层（SpeedLayer，亦即流处理层）、批处理层（BatchLa

50、yer）三层来解决不同数据集的数据需求。在批处理层主要对离线数据进行处理，将接 30 入的数据进行预处理和存储，查询直接在预处理结果上进行，不需再进行完整的计算，最后以批视图的形式提供给业务应用。图 14：Lambda 架构逻辑图 由于服务层通常使用 MySQL，HBase 等实现，供业务应用查询使用，此处的批视图就是 MySQL 或 HBase 中的表，这些表存储着批处理作业产生的结果；流处理层主要是对实时增量数据进行处理，新数据通过流计算不断的更新实时视图，例如在实时大屏场景，实时视图通常就是 MySQL 中的表信息，流处理作业在新数据到来后不停更新实时视图提供给到业务层；服务层主要是响应

51、用户的请求，根据用户需求把批处理层和流处理层产生的数据合并到一起得到最终的数据集。图 15：Lambda 架构部署图 2.Kappa 数据框架 Kappa 架构在 Lambda 架构的基础上移除了批处理层，利用流计算的分布式特征，增加流数据的时间窗口，统一批处理和流处理，处理后的数据可以直接提供至业务层使用。因为在 Kappa 架构下，作业 31 处理的对象是所有历史数据和当前数据，其产生的结果我们称之为实时批视图（Realtime_Batch_View）。图 16：Kappa 架构逻辑图 在 Kappa 架构中，输入数据在采集后通常存储在 Kafka 中，在流处 理 程 序 需 要 升 级

52、迭 代 时，会 启 动 一 个 新 版 本 作 业（StreamJob_Version_N+1）,该作业会从 Kafka 中读取所有历史数据和新增数据，直到追上旧版本作业（StreamJob_Version_N），旧的作业版本才会停止。Kappa 架构通过这种方法升级流处理程序，架构的流处理系统通常使用 SparkStreaming 或者 Flink 等实现，服务层通常使用 MySQL 或 HBase 等实现。图 17：Kappa 架构部署图 四、云原生湖仓一体实践案例 当前各行各业的云原生湖仓一体建设刚起步，本次白皮书重点介绍金融行业场景，选择了中国建设银行、中国人寿、中信建投等金融机构，分

53、析最近 3 年在云原生湖仓一体技术上的研究成果和实践探索。当前，金融行业普遍存在数据仓库和大数据平台两套数据平台各司其职的情况。在湖仓一体建设思路上，由于历史包袱沉重，多数企 32 业规划将两套数据平台体系通过统一的云平台以及软件工具实现一定程度的资源共享和数据互访。但是，数据平台的五大难题依然存在。从云原生湖仓一体建设的六大特性来看，企业选择转型为云原生湖仓一体可以为企业带来巨大的经济效益和社会效益。因此，我们建议企业可以将云原生湖仓一体平台的建设确定为企业数据平台建设的主要方向。在具体建设方法上，为了保护企业多年来的投资价值，保证数据平台的平稳过渡，可以考虑将业务部门的新业务、传统领域中的

54、创新业务，以及传统业务中对性能要求高、对数据共享能力要求高的业务迁移到新建的云原生湖仓一体平台上，以实现企业云原生湖仓一体平台价值的最大化，并在后续的运营中形成符合企业独有特色的云原生湖仓一体平台。(一)中国建设银行从湖到湖仓一体的演进之路 中国建设银行在多年的数据平台建设中，逐步汇聚了多种数据平台的技术栈，积累了 PB 级的海量数据，同时也带来了数据冗余、加工流程复杂、数据服务效率无法满足业务需求等一些亟待解决的问题。建行于 2019 年提出了关于“数据供应链的时效性和可用性”的要求，确定了加快推进“数据湖建设”的决议。同年，启动了数据湖建设技术路线的研究工作，并确定了云原生、高性能、稳定安

55、全、自主可控的技术原则。33 在技术选型上，建行对比了 Apache hudi、Apache HAWQ 等多种开源的数据湖方案。经过多轮全面的测试和对比确定了以 Apache HAWQ 作为建行未来湖仓一体建设的基础技术方案，打造建行自主可控的云原生数据库产品 CHAWQ 作为建行湖仓一体数据平台建设的整体解决方案。2020 年随着 CHAWQ 产品在行内部署上线，建行启动将多个业务应用迁移到湖仓一体平台上，由此相比原来的业务运维工作，大大降低了每天的数据搬迁工作，减少了数据冗余，降低了运营成本。由此，建行基于云原生数据库产品 CHAWQ 走出了一条适合建行发展的湖仓一体技术发展之路。图 18

56、：建设银行湖仓一体架构 截至 2022 年底，建行湖仓一体平台可供数据湖上数百个分析类应用场景使用，包括营销、风险管理等，支撑了万亿级别的交易明细 34 数据查询在线应用，毫秒级响应延迟。数据冗余减少了大约 2 倍，作业数量减少了近十万，大大降低了数据平台运营成本。(二)中国人寿湖仓一体总体规划的研究之路 中国人寿作为国家大型金融保险企业，2018 年集团公司合并营业收入 7684 亿元，合并保费收入 6463 亿元，合并总资产近 4 万亿元。集团公司下设 8 家一级子公司、1 家全国性股份制银行，业务范围全面涵盖寿险、财险、企业和职业年金、银行、基金、资产管理、财富管理、实业投资、海外业务等

57、多个领域多家公司和机构。集团目前采用了 SQLSERVER 数据库采集各个省级分公司的数据，并建立了数据仓库平台用于报表的汇总统计分析。业务创新的需求驱动下，国寿推出用户权益视图的数据服务，对数据平台的实时采集能力、海量历史数据的流批一体实时计算能力，以及高并发高性能的秒级响应查询能力提出了更高的技术能力要求。经过充分的研究和必选，最终确定了云原生湖仓一体的技术方向，通过与相关厂商开展深入探索和测试，对未来云原生湖仓一体的平台建设进行了架构规划设计，并从业务角度进行创新设计，逐步发挥云原生湖仓一体平台在业务领域的巨大价值。(三)中信建投数据仓库与数据湖的融合探索之路 中信建投证券在“科技赋能、

58、运营升级，以数字化转型助推客户服务体系建设”的战略目标指引下，持续进行数据平台的升级和建设，逐步建设了基于 GP 的数据仓库、基于 Hadoop 的数据湖和基于 35 Flink+kafka 的实时数仓，支撑了公司从各业务线到管理的所有应用。然而，由于底层技术的局限，导致数据仓库与数据湖的建设较为割裂，平台内存在多个数据孤岛，造成大量的数据冗余，从而不断推升了运营成本。同时分散的数据也给数据管理带来了巨大的挑战，为了维护数据的质量通常需要花费大量的人力和物力成本，并且收效甚微，数据质量难以保障。进入 2022 年，中信建投紧跟国家信创战略的发展方向，使用国产的云原生数据库替换现有数据仓库集群，

59、实现数仓应用的平滑过渡，由于云原生数据库可直接访问并使用数据湖进行数据存储，从而实现了数据仓库与数据湖的完美打通，业务数据不再分别存储，而是统一存储，数据应用可根据业务需求选择使用 SQL 引擎、机器学习引擎或流处理引擎来加工处理所需要的数据，各引擎之间可共享一份业务数据，数据不再需要跨集群流动，从而大大增加了数据处理的效率，同时也减少了数据冗余。下一步，中信建投证券将继续探索数据仓库与数据湖的融合，优化数据开发体系，缩短数据加工链路，提升数据供给效率，从而加速数据这一生产要素在企业内部的应用和流动。36 图 19：中信建投湖仓融合架构 五、总结与展望 历经多年发展，云原生技术生态日趋完善，行

60、业用户接纳度急速提升，资本市场热潮涌动。中国信息通信研究院数据显示，2021 年我国公有云 IaaS 市场规模达 1614.7 亿元，同比增长 80.4%；PaaS 市场规模达 196 亿元，同比增长 90.7%。SaaS 市场规模达 370.4 亿元，同比增长 32.9%。可以预见我国云原生产业即将进入高景气周期。在大数据领域，随着容器、微服务、无服务器、服务网格等技术的发展成熟，云原生的技术价值已经得到了行业的充分认可，为了满足大数据时代快速变化的用户需求，机构需要充分利用云原生能力实现数据系统的“云原生”转型。基于云原生技术实现的湖仓一体解决方案，凭借存算分离、弹性扩缩、统一编排、灵活调

61、度、无服务化等特性，为数据价值的挖掘提供便捷部署和管理的同时，更可以实现海量数据的高效存储、便捷访问、决策分析，将成为企业数字化转型和创新发展的重要基石。37 附录：湖仓一体典型解决方案 华为云华为云 FusionInsightFusionInsight 华为云 FusionInsight 智能数据湖涵盖了分布式存储、大数据、数据仓库、数据治理等方面,主要基于 Lakehouse 湖仓一体架构，实现存算分离和多样化数据分析,基于相同架构可以同时支持 SQL、BI 和 AI等不同场景。图 20：华为云 FusionInsight 全景图 华为云 FusionInsight 基于云原生数据湖 MR

62、S、数据湖探索 DLI、云数据仓库 GaussDB、云数据迁移 CDW、数据接入服务 DIS、对象存储 OBS，以及数据湖治理中心 DGC 和数据可视化 DLV 等服务，实现一站式大数据平台、全托管大数据服务、数据治理、数据迁移和实时处理等场景需求，具有流批交互式一体、千万级 TPS、毫秒级随机读写、百万并发等优势。38 华为云 FusionInsight 采用计算和存储分离架构，支持按需扩缩，资源灵活配比，可自由选择鲲鹏、x86、AMD 等异构算力。同时，具有统一的数据安全保护中心和完备的隐私保护机制，让数据使用安全、合规，让数据流通可信、可审计；多元分析、多源接入、统一存储和统一管理，简化

63、大数据系统复杂性，提升面向未来演进的灵活性。阿里云阿里云 MaxComputeMaxCompute MaxCompute是 适 用 于 数 据 分 析 场 景 的 企 业 级SaaS（SoftwareasaService）模式云数据仓库，以 Serverless 架构提供快速、全托管的在线数据仓库服务，消除了传统数据平台在资源扩展性和弹性方面的限制，最小化用户运维投入，使用户可以经济并高效地分析处理海量数据。随着数据收集手段不断丰富，行业数据大量积累，数据规模已增长到了传统软件行业无法承载的海量数据（TB、PB、EB）级别。MaxCompute 提供离线和流式数据的接入，支持大规模数据计算及查

64、询加速能力，提供面向多种计算场景的数据仓库解决方案及分析建模服务。MaxCompute 还可以提供完善的数据导入方案以及多种经典的分布式计算模型，用户不必关心分布式计算和维护细节，便可轻松完成大数据分析。MaxCompute 适用于 100GB 以上规模的存储及计算需求，最大可达 EB 级别，并且 MaxCompute 已经在阿里巴巴集团内部得到大规模应用。MaxCompute 适用于大型互联网企业的数据仓库和 BI 分析、网 39 站日志分析、电子商务交易分析、用户特征和兴趣挖掘等。详细发展历程、产品荣誉及客户案例请参见发展历程和客户案例。图 21：MaxCompute 的产品架构 MaxC

65、ompute 还深度融合了阿里云如下产品：DataWorks基于 DataWorks 实现一站式的数据同步、业务流程设计、数据开发、管理和运维功能。机器学习 PAI基于机器学习平台的算法组件实现对MaxCompute 数据进行模型训练等操作。QuickBI基于 QuickBI 对 MaxCompute 数据进行报表制作，实现数据可视化分析。偶数偶数科技的云原生湖仓一体平台科技的云原生湖仓一体平台 SkylabSkylab 偶数科技推出的湖仓一体解决方案，基于新一代云数据平台Skylab、云数据库 OushuDB 等产品，为用户提供极速性能、弹性伸缩、计算资源按需分配、全量数据单一存储、混合负载

66、等相关能力。偶数科技的湖仓一体方案采用了 Omega 全实时数据处理架构，其能够为用户提供批流一体处理能力，基于目前全球最快的新一代云数据 40 库OushuDB，可以实现PB级大数据交互式查询；将计算与存储分离，让计算集群之间数据可以方便共享；弹性扩展架构，可以扩张到上千节点；其支持 Hadoop 生态，用户可以快速实现扩展；数据管理平台Lava 可以实现统一数据资产管理、统一数据标准、统一数据服务、统一机器学习及深度学习建模，这些技术特点使得各种复杂的金融业务场景的数据处理通过湖仓一体平台实现最佳用户体验，并实现业务快速增值和业务的持续创新。图 22：偶数科技 Skylab 湖仓一体解决方案架构