2022年云原生湖仓一体白皮书.pdf

云云原生原生湖仓一体白皮书湖仓一体白皮书 （2022022 2 年）年）2022 年 12 月 2022 年 12 月 前前 言言 近年来，数据产业总体保持较快发展，国家先后出台了多项政策促进数据基础设施、关键技术、应用治理等方面的健康有序发展。伴随着行业用户对于数据价值的深入挖掘，数据平台和产品正在发挥着不可替代的创新引领作用。本白皮书首先介绍了数据平台发展的三个重要阶段，通过对于发展历程的总结，引出了行业用户在进行数据分析和处理中面临的瓶颈难题，并且重点从主要架构、关键技术、方案特征、应用价值等方面介绍了云原生湖仓一体最佳解决方案。之后，通过对于湖仓生态版图、代表厂商和代表解决方案的分析，力求反应现阶段国内湖仓生态现状。最后，从银行、保险、证券用户单位的不同角度出发，开展了较为详实的场景化应用分析，并进行了总结与展望。目目 录录 一、云原生湖仓一体发展历程.1(一)萌芽期：数据仓库初探数据价值.1(二)上升期：大数据平台挖掘数据价值.3(三)成熟期：湖仓一体全面展现数据价值.5 二、云原生湖仓一体方案概述.7(一)行业用户数据处理五大难题.7(二)解决数据处理瓶颈的最佳方案.11(三)云原生湖仓一体主要技术路线.23(四)云原生湖仓一体方案应用价值.25 三、云原生数据湖仓生态现状.28(一)国内湖仓生态版图.28(二)国际湖仓典型应用.29 四、云原生湖仓一体实践案例.31(一)中国建设银行从湖到湖仓一体的演进之路.32(二)中国人寿湖仓一体总体规划的研究之路.34(三)中信建投数据仓库与数据湖的融合探索之路.34 五、总结与展望.36 附录：湖仓一体典型解决方案.37 1 一、云原生湖仓一体发展历程 在全球数据产业蓬勃发展的背景下，数据系统正在发挥关键的支撑赋能作用，对于数据价值挖掘和业务创新发展起到重要影响。为了应对各类用户需求，衍生出了聚焦联机事务处理、联机分析计算、事务分析混合等不同场景的数据平台。数据平台作为企业数字化转型的重要基础设施，决定了企业对数据这一新兴生产要素的应用能力，对企业数字化转型的成败起到了至关重要的作用，其发展经历了三个时期。(一)萌芽期：数据仓库初探数据价值 1.发展背景 上世纪 50-60 年代，数据管理工具以“数据库”的形式首次问世，先后基于网状模型、层次模型、关系模型等不同的数据结构，出现了IDS、IMS、DB2、Sybase、Oracle 和 SQLServer 等各类产品。其中最具代表性的传统关系型数据库，本质上是通过结构化查询语句，对数据进行增、删、改、查操作，以实现在 OLTP 联机事务处理场景下对于关系型表结构数据的存储和利用。随着业务规模和类别的不断丰富，累积的历史数据越来越多，对业务数据库产生负载，导致业务系统运行速度降低。在日益激烈的市场竞争中，企业需要对积累的数据进行分析，获取更加准确的决策信息来完成市场推广、运营管理等工作。由此，提出将历史数据存储到 2 数据仓库(OLAP)解决方案，在改善业务系统数据库性能的同时，可以更专注的提升数据分析效率，辅助企业决策。2.技术特性 传统关系型数据库的技术架构，尤其是 OLTP 数据库在海量数据的存储、查阅以及分析方面出现了明显的性能瓶颈。随着分布式技术的产生和发展，出现了以 Teradata 为代表的 MPP 一体机数据库，以及 Greenplum 和 Vertica 等软硬件分离的 MPP 数据库，采用无共享架构(Share-nothing)以支持数据仓库的建设。这个阶段的主要任务是数据分析和决策支持类系统的建设，如数据仓库、ODS、数据集市、应用数据库、历史数据库以及报表、分析报告、数据挖掘、客户标签画像等。图 1：OLAP 系统建设 3.阶段特点 该阶段早期，不少企业直接采用了共享存储（share-disk）架构的Oracle 和 DB2，或是采用 MPP 无共享（Share-nothing）架构的 Teradata等产品，通常基于软硬一体的专有服务器和昂贵的存储，后虽然引入 3 了基于通用 X86 服务器的解决方案，但架构依然是“无共享”的，特点体现为：数据以结构化为主，集群的扩展能力有限。图 2：数据仓库架构图 然而，随着用户数据量的指数级增加，丰富的数据源接入，数据开始呈现出海量、异构、多源等特点，传统数据仓库扩容困难、处理数据类型单一的缺点开始逐渐暴露出来，也无法支撑越来越丰富的业务分析需求。(二)上升期：大数据平台挖掘数据价值 1.发展背景 21 世纪初期，随着互联网行业线上业务的快速发展，数据规模呈几何倍数增长，数据种类也变得更加丰富。传统数据仓库侧重结构化数据，建模路径较长，无法满足企业对于非结构化数据的处理以及数据处理时效性的需求，由此带来了海量异构数据存储和处理等的诸多问题。基于谷歌“三驾马车”论文，形成了 Hadoop 大数据解决方案，4 大数据平台开始受到关注，尤其受互联网行业迅速发展的影响，大数据平台迎来快速发展期。2.技术特性 Hadoop 平台使用 HDFS 实现数据的分布式存储，有效解决海量数据的存储问题。与传统数据仓库相比，HDFS 在支持存储结构化数据的同时还实现了非结构化数据的存储。HDFS 不是一个单机文件系统，而是分布在多个集群节点上的文件系统。当存储文件时，文件的数据将分布在多个节点上。读取文件时，数据从多个节点读取。Hadoop 平台使用 MapReduce、Spark 等组件实现分布式计算，并且可以对存储的数据进行大规模并行处理。通过切片将大量复杂的任务分解成多个少量简单的任务进行处理，再对处理完成后的任务结果进行汇总分类。3.阶段特点 Hadoop 发展初期仅有 HDFS 和 MapReduce 两个组件，随着数据量的不断增大以及对于数据处理时效性的需求不断升高。计算和存储组件也在不断的变化，以适应不同场景的数据存储与处理需求。大数据平台底层存储经过了十余年发展，一直是 HDFS 一枝独秀。大数据平台在计算方面发展迅速，由于最初的 MapReduce 大规模批处理无法满足海量数据处理的实时性，业界在计算方面设计了Spark 快速批处理、Flink 实时数据处理等计算框架。配合这些计算框 5 架的，还有像 Sqoop 这样的数据流转采集组件。在大数据分析和处理领域，Hadoop 兼容体系已经成为一个非常成熟的生态圈。图 3：Hadoop 生态系统重要组件 Hadoop 的诞生改变了企业对数据的存储、处理和分析的过程，加速了大数据的发展，受到广泛的应用，给整个行业带来了变革。随着云计算时代的到来，企业开始对 Hadoop 的架构进行从基于物理集群到云原生化的改造。(三)成熟期：湖仓一体全面展现数据价值 1.发展背景 经过前两个阶段的尝试，更多的企业发现独立构建大数据平台与数据仓库平台的技术架构，已经无法满足某些场景下的业务需求。企业在构建数据湖和数据仓库的同时，通过ETL操作实现数据的汇聚，完成湖仓独立部署，这就是业内常说的“Hadoop+MPP”模式,我们称之为湖仓分体模式。湖仓分体模式最大的问题就是数据孤岛和业务实时数据分析能力不足，因此面临着数据多集群冗余存储、集群规模受 6 限、业务的实时性不足、业务应用开发敏捷需求不足等问题，这些需求和痛点促进了湖仓一体技术的发展。2技术特性 湖仓一体方案应该在数据和查询层面形成一体化架构，彻底解决实时性和并发度，以及集群规模受限、非结构化数据无法整合、建模路径冗长、数据一致性弱、性能瓶颈等问题，有效降低 IT 运维成本和数据管理的技术门槛。所以，新时代需求的湖仓一体方案应具备实时处理、数据共享、高并发、云原生等特性。3.阶段特点 云的普及让业务上云成为趋势，为了实现数据湖的灵活性和数仓的易用性、规范性、高性能结合起来的融合架构，并且保证存储和计算可以独立的弹性扩展和伸缩，数据平台的设计出现了一个崭新的架构，即存算分离架构。在此阶段，Snowflake、Amazon、阿里云、偶数等企业相继突破了传统 MPP 和 Hadoop 的局限性，实现了存算分离。从市场发展角度出发，“湖仓一体”架构是技术发展的必经之路，优势明显，缺点也同样突出，而更为先进的“湖仓原生一体”架构在未来将更加契合用户对于数据价值挖掘的诉求。7 二、云原生湖仓一体方案概述(一)行业用户数据处理五大难题 2000 年以来，随着大数据技术的广泛使用，金融行业的运营管理人员每天都会采用报表数据来指导决策，由于业务的不断增长，采集的数据复杂度越来越高，管理者希望能第一时间掌握市场动态，以便及时做出有利于业务发展的决策。为了满足业务应用发展要求，数据处理通常会遇到各种挑战。数据加工过程中，需要耗费大量时间，完成各种业务数据加工处理和汇总统计；数据开发过程中，需要耗费大量人力，借助各类数据工具，从多个数据源系统中采集搬运数据并进行分析；数据管理过程中，需要充分考虑安全因素，避免由于不同使用者的修改，或者系统故障，造成数据不一致，从而影响数据分析结果；数据应用过程中，需要保障消费者的使用体验，面对海量的历史数据，所有的信息查询都要通过各种条件限制，以控制查询的数据规模；数据系统升级过程中，需要停止业务操作，影响业务连续性等。我们据此总结出了现阶段数据处理瓶颈的五大难题。1.数据处理面临数据孤岛的难题 很多企业的数据平台都是经过多次系统迭代和技术升级后建设而成的，在这个过程中随着技术的发展、组织管理结构变化，导致企业的数据平台往往存在多个数据库集群，每个数据库就是一个数据孤 8 岛和烟囱，甚至因数据库产品的扩展性，还可能导致 MPP 和 Hadoop集群建设多套的情况，形成更多的孤岛和烟囱。图 4：数据孤岛 这些数据孤岛和烟囱的出现在存储、开发、运维、治理等多个方面带来了影响。数据存储方面，多个独立数据库集群中都放了同样的数据，大约可以造成 3 倍-5 倍的数据冗余，相当于占用了大约 3 倍-5倍存储空间，这就意味着造成了大约 3 倍-5 倍的资源成本的浪费。数据开发方面，多个数据库集群，意味着，数据平台整体的架构相对复杂，不同集群之间的时序、数据同步流程多。这种情况会导致数据库产品技术门槛多，对于技术人员的素质要求高；集群之间需要大量的数据同步，一般情况下同步作业占到总作业量 50%左右，对于一项数据开发的总体工作量大约增加了 1 倍左右。从项目管理的角度看大约增加了 1 倍的成本；同时，作业的链路延长，大大降低了数据时效。技术运维方面，和开发面临的情况基本类似，对于运维人员的素质要求较高，需要精通多个数据库产品，日常运维管理的数据作业任务也比较多。数据治理方面，基于多份数据进行维护，可能会导致数据不一致，数据质量等问题，数据治理难度大，浪费的成本难以估量。9 2.数据处理面临性能瓶颈的难题 传统数据平台的计算性能不能满足业务需求，大体上有两种情况：一方面因数据平台的数据处理、业务查询时间长，性能慢，无法满足业务需求，需要在业务流程和用户端进行规避，导致用户体验很差。另一方面部分企业为了提高性能，在数据平台之上架设一个或多个内存查询引擎，这种方式牺牲了 ACID 和兼容性。性能不足的问题影响运营、决策效率、无法支撑业务运行对时延的要求；部分计算引擎为了提升计算效率，牺牲了事务一致性，牺牲语法兼容性；部分计算引擎只支持简单查询，缺少复杂关联分析能力。3.数据处理面临高并发复杂查询的难题 随着移动互联网的发展，很多业务逐步开放至更多的人员参与，出现了很多需要数千查询并发的场景，例如：明细数据查询，数据集市查询；保险销售员查询业绩，客户查询权益视图；证券研究员查询上市公司数据等各类场景。但是传统数仓、Hadoop 仅支持几十并发，导致分库、分表，限制业务部门使用，限制查询，对很多新型的业务没有很好的支撑。为了保证各类查询同时进行，采用很多计算引擎分流的方式实现，如：实时计算、批处理、固定报表、即席查询等厂家分别由不同计算引擎来支撑，无法统一查询，数据平台采用的数据库产品无法同时支撑多业务场景。4.数据处理面临实时处理的难题 10 Gartner 定义的实时数据处理的包括三个阶段：第一阶段，Real-Time Continuous Intelligence：对事件做出实时处理响应，包括指标对比，告警，趋势分析，自动决策；第二阶段，Real-Time,On-Demand Intelligence：生成报告，支持即席查询，延伸数据探索，记录操作流程；第三阶段，Offline On-Demand Intelligence：离线任务，包括报告，即席查询，实时决策，建模及长期决策；对应的在实时分析处理中按照事件的发生时间长短可以总结为：事件发生同时的实时流处理、事件发生短时间内的实时按需分析、事件发生后较长时间的离线分析。图 5：实时分析场景 传统数据处理平台不能完全满足实时数据分析需求，存在以下问题：实时数据与批量数据的关联查询，有实时数据与维表关联查询，有实时数据与事实数据关联查询，离线数据量大现有平台难以支撑；多库数据无法实时归集，按需查询需求无法满足；交易型数据库无法支持频繁、复杂的查询，为保证数据库的稳定，只能限制查询；现有 11 基于 Flink 和 Kafka 的流处理平台，不支持数据血缘，不能支持即席按需查询分析等。5.数据处理面临资源弹性伸缩的难题 传统数据平台因技术架构的局限性，对敏捷弹性资源管理支持度不高，在升级维护时需要暂停服务，对业务造成极大的影响。资源敏捷管理难题基本可以分为敏捷应用响应难题、如何实现资源弹性合理调配使用。敏捷应用响应难题主要体现为：传统 MPP 上线新应用的资源分配周期长，无法满足业务端快速试错、快速布局的诉求；超过集群规模上限时，性能不增反减，约减少 50%以上；集群扩容耗时很长，停机维护影响业务等。资源无法弹性调度，波峰波谷资源不能合理有效分配和使用，主要体现为：在非云环境，资源不能共享，资源以独占的方式使用，利用率很低；资源不够时无法弹性扩展，资源空闲时无法分配给需要的用户，无法做到削峰填谷，提高资源利用率。(二)解决数据处理瓶颈的最佳方案 通过对于现阶段数据分析存在的瓶颈和难题进行深入分析，我们发现，为了解决数据孤岛、性能不足、高并发、实时处理和资源弹性问题，可以尝试以下的解决方案：数据孤岛 需要数据平台架构支持存算分离，实现单一数据集群能支持数千上万节点，这样避免由于单一集群规模限制产生数据孤岛；12 性能不足 大数据平台的计算引擎相比 MPP 存在较大差距，需要引入基于MPP 技术的高性能解决方案，提升计算引擎的处理能力；高并发 传统的 MPP 技术或者大数据平台技术都只能支持数十并发，需要引入多主节点技术实现分析型数据平台上的高并发，将并发从目前的数十可以提升到数千或者上万；实时处理 目前的实时处理只能处理实时场景，无法同时处理实时和数据规模比较大的历史数据相结合的实时业务场景，需要引进支持海量数据下实现高性能高并发以及具备资源隔离的支持多租户技术的数据平台，才能满足所有实时业务场景的需求；资源弹性 当前数据平台在资源横向扩展时，无法做到计算和存储资源的各自独立扩展，同时，对于资源的使用无法实现根据业务需要进行设置，导致资源利用率不高，使用成本很高，需要引入存算分离的架构，并且支持虚拟计算资源的管理方式，实现业务按需进行计算资源的分配调度管理。同时考虑到以上计算存储分离、弹性可扩展架构、ACID 特性、SQL 标准支持、高性能并行执行等方面的能力，基于云原生技术架构的云原生湖仓一体产品，可以通过云平台构建、部署和交付的数据服务，提供可扩展的、高可靠的数据解决方案。1.云原生湖仓一体典型架构 Gartner 认为湖仓一体是将数据湖的灵活性和数仓的易用性、规范性、高性能结合起来的融合架构，无数据孤岛。云原生湖仓一体就 13 是将数据湖和数据仓库两个平台合为一个平台，并依托云原生的特性，支持基于数据湖的普通存储硬件和存储引擎以及数据仓库的多功能高性能分析引擎，实现对海量原始数据（结构化、非结构化、流式数据、图数据）以及洁净数据（对原始数据进行治理和分析后的数据）统一存储、分析、管理，集群可在线扩容到几千节点。支持数据仓库的丰富功能及高性能，支持配套的高性能 ETL、数据治理及数据资产管理工具等。支持数据科学和自动化机器学习，支持无代码/低代码数据加工，支持自助式 BI。图 6：云原生湖仓一体典型架构 2.云原生湖仓一体关键技术（1）存算分离技术 在云原生数据库出现之前，由于单机吞吐量和集群网络带宽限制等因素，数据库集群部署都是存储和计算在一起，让计算靠近数据，而不是将数据传输到计算节点，这种方式可以产生更少的数据迁移，降低机器间、机柜间的网络带宽消耗。随着数据量的增长，无论是计 14 算还是存储先达到瓶颈，都必须同时对计算和扩展进行扩展，因此就会存在不少浪费，并且扩展需要大量数据移动，非常不方便。计算与存储的解耦，可以让我们更加方便的管理计算与存储资源。在大规模数据处理场景下，管理员可以快速的单独扩展计算或存储资源，并且性能可以随着节点的增加线性增长。存算分离后，数据实现了统一存储，可以被多种计算引擎所共享。因此，存算分离是湖仓一体平台必备的技术之一。然而，存算分离也带来了挑战，比如存算解耦以后，如何管理计算层与存储层的映射关系，节点异常处理、如何保证读写一致等问题。此外，存算分离需要万兆甚至更快的网络带宽。因此，存算分离架构通常是云原生数据库的重要特性之一。（2）高性能计算引擎技术 存算分离以后势必带来更多的网络开销，影响数据库集群的整体性能。因而需要通过其他方面的增强来弥补这一损耗。其中一个重要的途径就是通过优化计算引擎来增强性能。采用基于代价的优化器（CBO），通过算法来动态选择每个 SQL的最优查询计划，弹性的执行引擎可以动态调整计算单元，使得资源使用更加合理和高效。在计算层通过使用向量化执行器可以大大提升SQL 的执行速度，由于存算分离会带来额外的网络开销，因此计算层采用分布式的缓存服务，采用基于 LRU 协议的缓存管理机制，用户还可根据情况动态配置缓存空间的大小，缓存支持使用内存和计算节 15 点的本地磁盘空间。节点之间的通讯协议，改为采用 UDP 的互联协议，可以大大提升通讯效率。性能的提升意味着在单位时间内云原生湖仓一体平台可以处理更多的数据。（3）多活主节点支持超高并发 云原生湖仓一体平台的主节点采用多活主节点集群部署，主节点采用无状态设计，各主节点之间没有相互依赖关系，不存储任何元数据。用户可以非常方便的对主节点集群进行扩展，以处理更多的连接请求(JDBC/ODBC)。主节点可以在线增减，实现资源的动态调度。例如当用户请求越来越多时，用户可以根据情况随意增加一个或多个主节点，反之则可以减少一个或多个主节点。主节点的动态增减不会影响数据库的服务。当主节点集群中某个节点出现故障时，也不会影响整个集群的可用性。支持用户可视化的方式轻松完成扩容。图 7：多主节点架构（4）元数据集群高可用 元数据集群架构采用 P2P 去中心化完全对等网络架构，集群内无固定主节点，通过一致性协议算法实现节点的数据同步，当某一节点 16 宕机时，集群内部可自动实现服务的漂移而无须人工干预，实现了集群的高可用。元数据采用多副本机制，均匀的分布在各个节点上，确保了元数据的安全。各个主节点将同时并发连接每个元数据节点，因此，元数据集群内不存在单点瓶颈，实现了元数据读写的负载均衡。（5）多虚拟计算集群支持混合负载 在存算分离基础上，多虚拟计算集群支持对用户访问的 CPU 和内存资源的物理隔离。多虚拟计算集群（Virtual Cluster）可以将一个超大规模计算节点根据负载情况划分为多个虚拟计算子集群。数据库管理员可通过配置，将用户与某个 VC 进行绑定。当用户发起执行请求后，主节点只会调度该用户对应的 VC 资源来执行，当 VC 资源不够时，管理员可快速增加从其他 VC 中调度计算资源来给 VC 进行扩容，并且是在线秒级扩容。用户可根据自己的业务场景划分多个 VC，来支持不同的业务部门或机构。同时，因为快速的进行资源调度，可以大大提高资源利用率，从而减少硬件资源的投入。图 8：多虚拟计算集群 17 （6）可插拔存储框架 可插拔存储框架实现计算资源可同时访问不同类型的存储，如：HDFS 存储、基于 S3 协议的对象存储以及分布式表存储。通过可插拔的存储框架，可以实现在线的存储扩容，例如，管理员可以方便的通过配置，新增一套或多套存储系统，并且这种异构的存储对于用户访问是透明的，即用户无需知道数据存放在哪种存储上，而是直接通过表名读写数据。可插拔存储框架还可以支持二次开发，用户可通过二次开发使得计算引擎对接未来新出现的存储系统。如下图所示，通过可插拔存储框架的支持，使得云原生湖仓一体平台可以对接多套 HDFS，并且对用户无感。图 9：可插拔存储架构（7）多虚拟存储集群实现磁盘 IO 的隔离 上述的可插拔存储框架实现了计算资源与存储的对接，但是在实际使用中，依然存在着存储中磁盘 IO 资源的竞争，因此多虚拟存储的功能实现类似于 HDFS 的联邦功能。多虚拟存储集群支持用户将多 18 套 HDFS 集群或分布式表存储集群划分为一套虚拟存储集群（Virtual Storage Cluster）。开发人员在进行数据建模时，可以根据磁盘 IO 的负载情况，将不同负载的表建在不同的 VSC 中，就可实现负载的隔离，用户在使用时不会感知 VSC 的存在，并且 VSC 与计算阶段没有绑定关系，可以被任意的计算资源访问，保证了数据的共享。同时，云原生湖仓一体平台根据使用量自动将不同的表分布到统一 VSC 中的不同 HDFS 集群或分布式表存储集群中，从而实现数据的均匀分布。基于这个特性，用户在进行存储扩容时就实现在线的秒级扩容而无须进行数据重分布。当某一 VSC 存储空间不够时，用户可以新部署一套 HDFS 集群加入到 VSC 中，即实现了存储空间的扩容，又无须进行人工干预。图 10：多虚拟存储集群（8）高性能分布式表存储支持实时数据读写 在实时场景中，数据往往是逐条进行插入、更新或删除，这种对数据的操作特性与交易场景非常接近，而 HDFS 或对象存储仅适合对 19 数据进行批量操作，并且原生并不支持数据的更新，无法满足实时场景的业务需求。因此，云原生湖仓一体平台需要引入分布式表存储支持高并发、事务以及提供索引，并且原生支持数据更新和删除。在云原生湖仓一体平台的架构中，分布式表存储与HDFS、对象存储平行，是能够独立运行的存储系统，不依赖第三方组件。分布式表存储的主要特性有：采用完全点对点(P2P)无中心分布式存储（相比主从架构更容易管理更容易扩展）结构化数据定义存储（不是简单键值对形式存储）支持数据的增删改查（提供真正的 INSERT UPDATE DELETE功能）支持基于 Raft 协议数据复制实现数据存储和访问服务的高可用 支持基于多版本 MVCC 的分布式事务特性 目前提供针对分析型负载的高性能数据查询能力（行列混合存储格式）支持数据索引功能（包括主键索引，非主键索引）整合数据预处理技术提升数据查询性能（非纯粹的数据存储实现，具有内建计算能力）便捷的集群动态扩展 自动集群容错和负载均衡能力 20 图 11：高性能分布式数据读写 从读写性能的角度比较，分布式表存储的性能优于 HDFS，HDFS的性能优于对象存储。因此，在实际使用中通常会把 T+0 的实时数据写入分布式表存储，T+1 的批量数据写入 HDFS，而对象存储由于更加低廉，但是性能最慢，所以一般只用来存储三年以上的历史归档数据。从用户视角看，开发人员需要基于不同使用场景把不同的表建立到不同的存储中，在之后的使用中则不再感知异构的存储，也就是说用户直接通过表名即可查询各种类型存储中的数据，也可以把存储在不同类型存储中的数据进行关联查询、计算、比较等不同的操作。如下图所示：21 图 12：高性能分布式 SQL 查询（9）Hadoop 生态兼容能力 云原生湖仓一体平台可以直接使用 Hadoop 生态普遍使用的HDFS 来作为数据存储，同时存储格式使用开源社区比较通用的 orc和 Parquet 格式，此外还支持 CSV、TEXT 等类型。支持直接读写 Hive数据，无须预先创建外表，更无需搬迁数据，云原生湖仓一体平台管理的数据表也同样可以被 Hive 访问。在实时场景下，源数据主要有两类：一类是流计算引擎处理的过程或结果数据，另一类是通过 CDC 工具采集的实时变化的数据。云原生湖仓一体平台支持这两类数据的同时读写。例如：Flink 可直接连接分布式表存储，将流处理结果直接写入分布式表存储中，用户可使用 SQL 直接查询。此外，云原生湖仓一体平台支持使用 Hudi、Iceberg 开源数据湖格式，用户也可以选择将实时数据直接写为 Hudi 22 或 Iceberg 格式，这样可以将数据统一存储到 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）：支持关系表、文本、图像、视频等结构化数据和非结构化数据存储。云原生（Native on Cloud）：适合云环境，自由增减计算和存储资源，按用量计费，节约成本，不再有数据孤岛存在。数据一致性（Consistency）：通过完善的事务机制，保障不同用户同时查询和更新同一份数据时的一致性。超高并发（High Concurrency）：支持数十万用户使用复杂分析查询并发访问同一份数据。一份数据（One Copy of Data）：所有用户（BI 用户、数据科学家等）可以共享同一份数据，避免数据孤岛。实时 T+0（Real-Time）：通过全量数据 T+0 的流处理和实时按需查询，满足基于数据的事前预测、事中判断和事后分析。23 (三)云原生湖仓一体主要技术路线 1.主要技术路线对比分析 目前，常见的湖仓一体技术方案主要有两大类型：基于传统Hadoop 架构的方案，以及基于云原生数据仓库架构的方案。基于传统 Hadoop 的方案主要从事务特性出发进行优化，基于HDFS 或 S3 实现一个支持事务的存储层，其他方面与 Hadoop 区别不大。而云原生数据仓库，其存算分离特性更具有技术前瞻性，该架构将是未来的发展趋势。维度维度 参数参数 云原生湖仓一云原生湖仓一体平台体平台 传统数据仓库传统数据仓库平台平台 传统数据湖平传统数据湖平台台 技术先进性技术先进性 技术架构 云原生、存算分离 非云原生、存算耦合 非云原生、存算耦合 性能性能&并发并发 性能 高 中 低 并发 高 低 低 功能功能 支持事务 完整支持事务ACID 完整支持事务ACID 事务支持差 集群规模 100000 1000 SQL 标准 完善兼容 SQL标准 完善兼容 SQL标准 部分兼容 SQL 数据类型 结构/半结构/非结构化 结构化 结构/半结构/非结构化 存储引擎 可插拔存储：HDFS/S3/Magma 本地表私有存储 HDFS/S3 24 存储格式 ORC，Parquet，Hudi 等 私有格式 ORC，Parquet 全实时 支持 否 否 湖仓一体 支持，OushuDB 支持 HTAP 否 否 开发开发 数据共享 共享同一份数据 数据孤岛、共享困难 数据孤岛、共享困难 数据治理 简单 复杂 十分复杂 实施难度 低 低 高 运维运维 运维难度 低 低 高 2.云原生湖仓一体的建设路径 从云原生湖仓一体平台的建设方式上，企业可以结合业务情况、已有数据平台情况等方面出发进行建设路径的规划，主要有以下三种建设途径：从数据仓库到云原生湖仓一体 企业目前数据类应用主要集中在数据仓库，而且总体数据量也不大的情况下，可以考虑从数据仓库向数据湖方向建设，最终实现云原生的湖仓一体平台建设。首先从数据仓库开始进行技术平台的升级，选择云原生的数据库产品进行数据仓库的迁移替换，将底层“仓”的存储和“湖”的存储实现数据打通，建立统一的数据模型。从数据湖到云原生湖仓一体 一般情况下，因数据湖中的数据体量较大，为了避免数据的搬迁采用从数据湖到湖仓一体的建设方式，最终实现云原生湖仓一体平台。25 在现有的数据湖上进行技术平台升级，在湖上增加具备数据仓库计算能力的组件并将新的业务应用部署到湖仓一体平台上，逐步将原有的数据仓库和集市的数据和应用都迁移到湖仓一体平台上。数据湖和数据仓库融合建设 湖仓融合的建设方式要求：不再有独立的数据湖和数据仓库，湖仓融合为一个产品的解决方案，底层的数据产品均具备云原生特性、计算存储分离弹性可扩展架构、强 ACID 特性、强 SQL 标准支持、高性能并行执行能力。首先，进行平台技术能力升级，将原来的数据湖和数据仓库底层的数据产品的元数据打通，共享一份元数据，数据湖和数据仓库共同使用一个入口，并保证强事务一致性。其次，构建统一的数据模型，将数据湖和数据仓库的数据纳入统一的数据模型进行管理，并只保留一份。最后，完善数据处理工艺，制定统一的数据接入标准，数据处理工序，数据存储原则等。最终完成云原生湖仓一体平台的建设。(四)云原生湖仓一体方案应用价值 1.用户体验的提升 云原生湖仓一体平台能够大大提升用户的数据服务体验：管理人员：一个湖仓一体的平台可以统一运营企业内所有应用的数据，不需要单独考虑不同数据平台产品的部署、招标采购、扩容等问题，提升了管理决策的效率，降低了管理运营的成本。26 运维人员：仅需要运维管理一个平台，技术架构简洁，运维门槛降低。而且湖仓一体平台存算分离的架构，支持计算资源与存储资源的单独横向扩容和缩容，给日常的升级维护带来极大的便利。业务人员：湖仓一体平台实现超高的并发，一个平台支撑所有数据存储、计算、分析的需求，并提供面向业务部门的自助数据分析服务，在实际工作中不需要切换平台进行业务实现；数据底层共用一份数据，用户之间可以很方便地共享数据。2.数据平台运营成本下降 云原生湖仓一体平台支持资源物理隔离，按照业务需求分配资源，大大提升资源利用率、硬件资源池按需建设，采购规模下降、折旧减少。通过湖仓一体平台可以有效降低数据平台运营成本，主要体现在以下几方面：湖仓一体平台完成了数据仓库、数据集市和数据湖的数据整合，实现一份数据，融合共享，避免了多份数据存储，可以节省大约 3 倍-5 倍存储空间和资源成本。平台基于一份数据，避免了不同数据平台间的数据传输和拷贝，一般在数据处理任务中数据同步作业占到总作业量 50%左右。开发工作量可以节省 1 倍左右、平台算力资源节省 1倍左右；同时，避免了作业的链路延长，数据时效降低。27 湖仓一体平台基于云平台进行部署，不再依赖底层单节点的计算和存储资源，由云平台统一进行合理的安排和管理。不同配置的服务器都可以通过云平台提供算力资源和存储资源。3.管理、开发和运维的效率提升 云原生湖仓一体平台启用以后，可以大大提升管理，开发，运维和业务部门的协同工作效率，降低管理成本，具体体现在以下方面：管理人员相比原来的平台可以近乎实时的了解企业业务现状，第一时间做出决策；运维人员仅需维护和管理一个平台，极大地减少了运维压力和成本。湖仓一体平台能够超高并发的处理多业务场景，不需要额外学习其他产品，有效地降低了技术开发门槛。平台基于一份数据，还降低了数据治理难度。降低了数据治理类项目成本投入；避免了数据同步作业开发，开发工作量节省 1 倍左右、减少 1 倍左右的项目成本；同时，作业的链路延长，数据时效降低。云原生湖仓一体平台具备的实时特性支持业务创新，增强用户体验，可以让用户与金融行业的企业之间互动更加频繁，带来最佳用户体验，形成业务发展的新模式，带来新价值。28 三、云原生数据湖仓生态现状(一)国内湖仓生态版图 当前，湖仓一体技术架构正处于发展早期，头部企业纷纷尝试构建自己的湖仓一体数据平台。以金融行业为例，“湖仓一体”的应用覆盖银行、券商、保险等细分领域，可以帮助企业应对数字化转型过程中的创新难题。图 13：国内湖仓生态版图 2020 年，大数据 DataBricks 公司首次提出了湖仓一体（Data Lakehouse）概念，希望将数据湖和数据仓库技术合而为一，此概念一出就得到众多厂商的推崇。湖仓一体技术依托硬件层提供的计算、存储、网络能力，实现数据采集、汇聚、计算、分析，是整个“湖仓一体”的生态基石。湖仓一体通过基础软件层的技术创新，打破了数据湖与数据仓库在存储、计算、网络三个层面割裂的体系，并将数据湖的灵活性、生态丰富能力与数据仓库的企业级部署能力进行融合，构建了数据湖和 29 数据仓库相融合的数据管理平台。“湖仓一体”继承了数据仓库的数据处理和管理优势，打通了数据湖和数据仓库两套体系，让数据和计算在湖和仓之间自由流动，既能面向业务实现高并发、精准化、高性能的数据实时查询服务，又能承载分析报表、批处理、数据挖掘等分析型业务。软件层面，企业在数据接入、数据存储、数据管理、数据分析等不同技术方向做出了新的尝试。在服务层面，根据不同行业场景的具体应用需求，各大厂商纷纷为用户提供行业定制化的解决方案，帮助企业解决数据孤岛、实时数据分析、高性能处理、高并发查询、资源弹性伸缩等难题。为企业提供安全可靠的“湖仓一体解决方案”，构建融合创新的新一代数据平台。(二)国际湖仓典型应用 1.Lambda 数据框架 Lambda 数据处理框架由 Storm 的作者 NathanMarz 首次提出，目标是设计出一个能满足实时大数据系统关键特性的架构，整合离线计算和实时计算，读写分离和复杂性隔离等，可集成 Hadoop，Kafka，Storm，Spark，Hbase 等各类大数据组件。Lambda 架构通过把数据分解为服务层（ServingLayer）、速度层（SpeedLayer，亦即流处理层）、批处理层（BatchLayer）三层来解决不同数据集的数据需求。在批处理层主要对离线数据进行处理，将接 30 入的数据进行预处理和存储，查询直接在预处理结果上进行，不需再进行完整的计算，最后以批视图的形式提供给业务应用。图 14：Lambda 架构逻辑图 由于服务层通常使用 MySQL，HBase 等实现，供业务应用查询使用，此处的批视图就是 MySQL 或 HBase 中的表，这些表存储着批处理作业产生的结果；流处理层主要是对实时增量数据进行处理，新数据通过流计算不断的更新实时视图，例如在实时大屏场景，实时视图通常就是 MySQL 中的表信息，流处理作业在新数据到来后不停更新实时视图提供给到业务层；服务层主要是响应用户的请求，根据用户需求把批处理层和流处理层产生的数据合并到一起得到最终的数据集。图 15：Lambda 架构部署图 2.Kappa 数据框架 Kappa 架构在 Lambda 架构的基础上移除了批处理层，利用流计算的分布式特征，增加流数据的时间窗口，统一批处理和流处理，处理后的数据可以直接提供至业务层使用。因为在 Kappa 架构下，作业 31 处理的对象是所有历史数据和当前数据，其产生的结果我们称之为实时批视图（Realtime_Batch_View）。图 16：Kappa 架构逻辑图 在 Kappa 架构中，输入数据在采集后通常存储在 Kafka 中，在流处 理 程 序 需 要 升 级 迭 代 时，会 启 动 一 个 新 版 本 作 业（StreamJob_Version_N+1）,该作业会从 Kafka 中读取所有历史数据和新增数据，直到追上旧版本作业（StreamJob_Version_N），旧的作业版本才会停止。Kappa 架构通过这种方法升级流处理程序，架构的流处理系统通常使用 SparkStreaming 或者 Flink 等实现，服务层通常使用 MySQL 或 HBase 等实现。图 17：Kappa 架构部署