湖仓一体架构：数字化的终局之选！

大家好，我是梦想家Alex ~ 之前我已经分享过不少有关数据湖，数据仓库，数据中台的文章，但今天想为大家介绍的是被誉为“数字化终局之选” 的湖仓一体架构，希望对大家有所启发，欢迎转发收藏！

参与文末留言，还有机会获取大数据架构，中台相关书籍！

下图是一张非常经典的数据分析技术演进图，从中可一窥整体发展历程。本文将按时间顺序盘点下各阶段产品及技术特点，并预测下未来发展方向。



1 简单可用阶段：数据库（DataBase）
早在1980年代初中期，是没有专门面向数据分析场景的产品。当时还是以面向事务交易场景为主，数据分析仅作为附带提供的场景。主要是面对管理层提供固定报表，满足宏观管理决策。

作为底层数据库，通过标准SQL提供数据分析能力。这一架构在面对数据分析场景的缺点很明显，扩展性差，很难支持大规模数据分析，性能也无法满足需求。这也催生专门解决数据分析的产品出现，即后面出现的数据仓库。

02 规范标准阶段：数仓（Data Warehouse）

到了1980年代中后期，为解决数据库面对数据分析的不足，孕育出新一类产品数据仓库。

让我们先来看下数据仓库的定义，数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策和信息的全局共享。上图是数据仓库的应用架构，从中可见其做了若干阶段划分，简单可分为数据集成（装载）、数据加工（ETL）、数据汇聚、数据展示及挖掘。

数据经过这一过程，被抽取到数据仓库中，并严格按照预先定义的模式被装载进来，经过多层加工形成数据集市，并最终提供给终端应用或进一步供挖掘使用。在技术实现上，主流采用MPP无共享存储架构，基于标准X86服务器，可实现数百节点的扩展。其对外提供标准的SQL能力和ACID特性，整体计算性能可在一定程度上随节点扩展可提升。


数据仓库架构非常经典，在一定时期内满足了数据分析需求，也促进数据分析场景的演进发展。从上图我们看到数据仓库的发展，经历了多个阶段。从固定报表，满足T+1时效性即可；到分析型需求增加，需提供灵活深度查询能力；到预测型需求，需满足多维度分析预测能力；到运营型数仓，不再局限在后台提供服务，而强调实时变化、分析学习、反馈控制；再到智慧型数仓，强调人工智能全面感知能力。

可以说，数据仓库一路走来，不断演进变化，大大促进了数据在企业内的应用水平，直到今日仍然是很多企业应对数据分析的不二之选。

当然，随着数据在企业内角色愈发重要，对其分析的要求不断提高。传统的数据仓库架构也面临很多的挑战。例如，随着数据规模扩大，对数据承载能力（容量、算力）的要求也不断增大，数仓架构的扩展能力急需考验；上述规模的扩展会面临大量资源的投入，硬件资源缺乏弹性，会导致高峰时资源不足，低谷时资源闲置浪费问题；随着对数据鲜活程度要求提高，对数据处理时长有着更为严格的要求，否则将无法指导业务运营；针对数据类型，也不再局限于结构化数据，更多半结构化、非结构化数据被更多利用起来；此外，在数据价值挖掘、数据安全等方面都提出了更高的要求。针对上述难点，也催生了一系列技术的发展，例如HTAP、大数据分析等，也包括后面重点谈到的数据湖。

03 开放自由阶段：数据湖（Data Lake）

Data Lake，是在2011年由James Dixon提出，其与数据仓库的主要区别在于数据仓库中数据在进入仓库之前是需要实现归类，而数据库是把大量原始数据通过廉价存储保存下来。数据仓库具有高度结构化的架构，用户可直接获得分析数据；而数据湖是将数据直接加载到湖中，然后根据分析的需求再转换数据。

数据湖架构的特点可总结为：低成本、原始数据、需灵活可使用、面向任务数据绑定、不提前定义数据模型。在实现技术上面，多采用基于Hadoop生态的产品，兼具有MPP、Hive/Spark、NoSQL、Stream/Batch能力。具备良好的扩展能力，可支持数千节点的超大规模集群。但对SQL支持偏弱、ACID特性支持差，较难从传统数据仓库迁移过来。业务上更为强调数据资产管理与数据服务。

这里我们对数据仓库和数据湖做个简单对比，可以看出两者差异很多。基本上属于互补关系，各有其适合覆盖场景。前者更多是解决固定的、明确的数据问题；后者则为应对随机性、探索式的数据问题。下图可以更为准确地描述两者差异。


04 融合共享阶段：湖仓一体（LakeHouse）
提到湖仓一体，就不得不从上世纪80年代说起。当时市场还是数据仓库的天下，主要用来处理BI、仪表盘、报表等结构化数据，用于分析企业的内部的业务数据。

这种状态一直持续到2010年前后，越来越多企业产生对语音、视频等数据的处理分析需求，非结构化数据、半结构化数据的增长促使企业提升了高多样性，高速度和高容量的数据分析要求，数据仓库慢慢不能满足用户的需求。

随着数据仓库局限性的逐步显现，数据湖的概念也随之衍生出来，它能够存储各式各样的原始数据，解决了数据仓库的局限性。但相比于优势来讲，湖的短板也同样明显，比如不支持事务，SQL性能差，无法支撑报表需求。虽然数据湖和数据仓都各自有各自的优势和不足，但不难发现，二者在某些层面是非常互补的。

于是乎，是否有一种能兼具两者优点的架构出现，于是诞生了“湖仓一体”。

湖仓一体1.0

早期的湖仓一体，更多是一种处理思想，处理上直接将数据湖和数据仓库互相“打通”。数据湖从各类数据源获得原始数据，存储在廉价存储上，永久不删除。数据保持原始简单格式、机构，无数据治理，也没有数仓丰富的功能及高性能统一数据模型。当需要支持分析场景在成熟时从数据湖到数据仓库的迁移。

这种架构优点在于可充分利用先前的数据湖和数据仓库资源，利用ETL将二者“打通”，数据湖用来存储各种原始数据，分析报表交给数据仓库来完成，这也可以算是湖仓一体的一个雏形，但湖和仓基本上还是处于各自一体的状态，架构仍然较为复杂，在满足需求的同时也持续提高了企业的运维成本。

湖仓一体2.0

为了解决湖仓一体1.0的诸多问题，2.0应运而生。目前这一架构还在快速发展之中，尚无明确统一的技术框架。

总的来说，可按照上图划分多层次，并在每层解决对应问题。从底层数据源，需对接多种数据源（包括结构化、半结构化及非结构化数据）。之上的数据集成需提供针对不同特征数据的集成能力（包括批量、流式）。处理过后的数据放入统一存储层，为面对不同结构的数据，需提供多模态存储能力，甚至为满足性能要求提供不同存储引擎。再之上是统一的元数据、安全、管控层，通过对全局数据的完整视角管理。为满足不同加工需求的统一处理层，层内提供多种加工能力。最上面是数据应用层。

从技术上看，云原生数据仓库，为湖仓一体2.0提供有利支持，其技术上天然具备的存算分离、弹性扩展、多租户、可插拔存储、多计算引擎、分级资源管理等众多特性可满足上述要求。功能上兼具数据仓库的标准SQL、ACID能力，数据湖的大规模原始数据存储等。对上提供多种接入方式，包括标准数据库接入方式，支持高并发读写；对下支持多云、混合云及跨云部署，防止厂商绑定。其技术架构可简化为类似如下架构：


展开说明下，其底层依旧是低成本、开放的存储，上层基于类似 Delta lake/ Iceberg/ Hudi 建设数据系统，提供数据管理特性和高效访问性能，支持多样数据分析和计算，综合了数据仓库以及数据湖的优点形成了新的架构。

存算分离架构可以进行灵活扩展；减少数据搬迁，数据可靠性、一致性和实时性得到了保障；支持丰富的计算引擎和范式；此外，支持数据组织和索引优化，查询性能更优。当前湖仓一体还处于快速发展期，关键技术迭代快且成熟的产品和系统少。与之前架构的对比，这里借用《DataFunCon 2021》大会上的一张图片加以说明。


未来趋势、终极之选：湖仓一体2.0
湖仓一体2.0，当前仍处于相对早期的阶段，它已经不只是一个纯粹的技术概念，而是被赋予了更多与厂商产品层面相关的含义。在湖仓一体越来越火的同时，不同厂商也为它做出了各自的解读。这其中比较有代表性的产品是Snowflake和国内的偶数科技等。作为2020年的现象级产品-Snowflake，无疑是标杆型企业，其核心产品思想可参考下图。


国内的偶数科技的技术路线与Snowflake在湖仓一体的思路非常相似。主要是依托云原生特性、存算分离架构、强事务特性、完整SQL标准、高性能并行执行等技术能力，实现高弹性、高性能、强扩展性、强兼容性以及上层支持机器学习等，帮助企业有效应对大规模、强敏态、高时效、智能化发展趋势。其产品技术架构可参考如下：


在这一架构中，偶数科技通过自研的新一代存算分离架构产品，实践湖仓一体2.0理念。其中核心技术亮点众多。包括功能强大的基于代价的优化器，实现系统自动选择最优执行计划；可充分利用最新CPU特性SIMD单指令多数据流，能做到指令内并行的新一代执行器引擎；多级资源队列，可通过DDL方便地定义和修改资源队列；原生Magma存储引擎与S3、HDFS混合使用，解决高性能与低成本的存储问题；多种优化存储格式，包括AO、Parquet、ORC等等。下图简单对比了包括Snowflake、偶数科技产品与传统数仓产品。


写在最后：任重道远，无限潜能
随着数据在数字化转型中发挥着愈发重要的作用，如何挖掘、利用、提升数据价值成为核心重点。湖仓一体的出现，突破了原有数据仓库架构和数据湖架构的局限，兼具两者之优点。为企业提供功能完整、可扩展、低成本、高收益的数据分析能力。相信，随着这一技术不断演进发展，必将加速企业数字化进程，享受到更多数据红利。也期待有更多的厂商、产品诞生，助力企业数字化转型！

作者：韩锋频道 | 责编：大数据梦想家




作者：韩锋频道Alex

欢迎关注：大数据梦想家