大数据架构系列：如何理解湖仓一体？

news2024/12/26 9:32:53

转载：如有侵权，告知即删除

引言

这十多年大数据技术蓬勃发展，从市场的表现来看基于大数据的数据存储和计算是非常有价值的，其中以云数据仓库为主打业务的公司Snowflake市值最高（截止当前449亿美元），另一家以湖仓一体为方向公司Databricks估值或达380亿美元；各大伺机而动的云厂商也纷纷推出自己的数据湖、云数据仓库、湖仓一体产品。

大数据领域概念（术语）还是非常多的，大多数时候都是先射箭再画靶，先有的需求大家搞了一段时间，然后由一些权威人士提出一些概念（术语）用于描述，所以不能严格用数学的定义方式去框定这些概念（术语）的边界；且很多时候一个术语“形象”比“准确”更易传播，形象意味着易懂，准确意味着信息量巨大（参考数学定义）。建议可以从需求的角度去切入理解这些大数据概念和技术，不要过于追求准确的定义。

无论是数据湖还是数据仓库最后还是面向于解决用户的问题，用户要的其实是数据里的信息，依赖于湖和仓的数据摄取、存储、计算能力主要是因为海量多元的数据，如果用户数据小业务简单完全可以用本地Excel导入数据进行各种有效分析。以下讨论数据湖、数据仓库、湖仓一体都是基于用户的数据是海量且复杂多元的。

数据流程

如上图，在一个复杂场景里，数据分析人员需要进行业务建模、数据建模；技术人员需要进行数据架构的设计、开发、维护；用户可以使用业务模型、数据模型后产生业务价值；App根据算法、模型、用户画像等提供功能和推荐。

What: 什么是数据湖、数据仓库？

说明一下，当前主流的数据湖技术对二进制数据（图片、音频等）不友好，文章上下文说的都是分析型（结构化、半结构化）数据。

只要业务场景复杂数据多元化，无论是你基于任何一个存储框架也得存储各种各样的数据，然后你得有计算引擎可以计算这些数据；同时由于业务要求，你需要对数据进行实时分析。数据湖技术把上述的过程集成化、标准化了；在数据入湖一开始就对数据按照指定标准进行组织，支持流批一体，不同框架有不同的组织方式（对特定场景有优化），但是目的都差不多；入湖后，提供标准化的数据读取方式，支持各种MPP引擎的计算；因为数据提前组织过，所以写入性能下降，查询性能提升。所以你可能之前一直在用数据湖，只是没用到数据湖技术。

数据仓库在入库之前，一般需要进行数据建模；接着按照表的格式对数据进行标准化和表指定的存储引擎进行数据组织，此时可能会损失掉一些信息；计算层通常都会对存储引擎的数据结构进行优化，以此来获得极致的查询体验。日常我们在进行大数据架构的设计实现时，一般会做的比数据仓库限定的范围多，但是我们还是称为数据仓库，所以还是再次提一下，不要太追求准确的定义。

湖仓对比

（以上图片来自阿里云）

Why：业界为什么要做湖仓一体？

我来形象地描述一下：集合两者的优势，像数据仓库一样管理的数据湖，像数据湖一样开放的数据仓库。

从What描述中数据湖和数据仓库的描述可以看出，业内常用的大数据架构基本上就是湖仓一体，即拓宽的数据仓库的功能，也会主动的规范数据的存储和使用。业内目前分享出来的信息来看，主要还是为了替换掉老的Lambda和Kappa架构，想通过一个相对简单的架构进行降本提效。

湖仓价值的交点

（以上图片来自阿里云）

How：业界怎么做湖仓一体？

目前业内的湖仓一体的架构一般都叫基于某某数据仓库的湖仓一体架构，用户会把热数据（频繁查询）放在数据仓库中，无论在存储和计算上都有大量的优化，计算速度快、成本高；冷数据放在数据湖中，计算慢、成本低，当用户要查询时，直接通过数据仓库的计算层来远程访问数据湖格式的数据，许多架构中还会来临时扩容弹性计算节点来计算冷数据，避免热数据的高效查询受影响。