2023数据库、数据湖、数据仓库、湖仓一体、智能湖仓概念

哈信没啊

玲疣意传r

索性我们就来个专题，聊透数据库、数据仓库、数据湖以及风头正劲的“Lake

----湖仓一1体化。

数据仓库是

个啥？和数据库有什么不同？

数据库的基本概念，大家应该都不陌生。如今但凡是个业务系统，都或多或少需要用到数

据库。

即便我们不直接跟数据库打交道，它们也在背后默默滴为我们服务，比如刷个卡、取个钱,

后台都是数据库们在扛着。

我读读读~

我写写写~

我提交喽~

数据库主要用于「事务处理」，存取款这种算是最典型的，特别强调每秒能干多少事儿:

QPS（每秒查询数）、TPS（每秒事务数）、IOPS（每秒读写数）等等。

不光要跑得快

但要是说起数据仓库，吃瓜群众还真很少接触到。

通常是业务发展到一定规模后，业务分析师、CIO,决策者们，希望从大量的应用系统、

业务数据中，进行关联分析，最终整点“干货”出来。

比如为啥利润会下滑？为啥库存周转变慢了？向数据要答案，整点报告、图表出来给老

板汇报，辅助经营决策。

1麻利点，我要结论!

可是，数据库“脑容量不足”，擅长事务性工作，不擅长分析型的工作，于是就产生了数

据仓库。

虽然现在HTAP的概念很盛行，也就是混合事务/分析处理，用一套数据库架构来同时

支持事务（。匚TP）和分析（OLAP）两种需求，但真正大规模的分析和洞察，还是离不开

数据仓库。

数据仓库相当于一个集成化数据管理的平台，从多个数据源抽取有价值的数据，在仓库

内转换和流动，并提供给引等分析工具来输出干货。

因为分析型业务需要大量的“读”操作，所以数据仓库通过"DchorMa/izcd-化的方式优

化表结构，减少表间联接，牺牲空间来换取读性能。（一张表里的冗余数据增加了，但

查询起来却更快了），并使用列式存储优化，来进一步提高查询速度、降低开销。

再结合面向分析场景的SeMema设计，数据仓库就可以高效率、全方位、多维度的扛

起“联机分析”重任了。

关于数据库和数据仓库的区别，我们再总结一下J

特性物据库数据仓库

适合干啥活儿事务处理分析、报告、大数据

数据从哪儿来从单个来源“捕获”从多个来源抽取和标准化

数据标准化高度标准化的静态Schema非标准化Schema

数据如何写针对连续写入操作进行优化按批处理计划进行批量写入操作

针对单行型物理块的高吞吐写使用列式存储进行了优化，便于实

数据怎么存

操作，进行了优化现高速查询和低开销访问

数据怎么读大量小型读取操作为最小化I/O且最大化吞吐而优化

襁根魅蚂逊廓鼓g啜帆

数据湖又是个啥?

数据库负责干事务处理相关的事，数据仓库负责干业务分析相关的事，还有新兴的

HTAP数据库既干事务又干分析，都已经这么内卷了，还要数据湖来干个毛线？

说白了，还是企业在持续发展，企业的数据也不断堆积，虽然“含金量”最高的数据都存

在数据库和数仓里，支撑着企业的运转。

存放在企业其它的数据

数据库/数仓中的数据日志、文档、图片、视频

沙中淘金

但是，企业希望把生产经营中的所有相关数据，历史的、实时的，在线的、离线的，内部

的、外部的，结构化的、非结构化的，都能完整保存下来，方便“沙中淘金”。

数据库和数据仓库都干不了这活儿，怎么办呢？

挖个大坑，修个湖，把各种数据一滚脑灌进去囤起来，而且要持续灌，持续囤。这就是数

据湖啦！

数据湖的本质，是由“❶数据存储架构+❷数据处理工具”组成的解决方案，而不是某个

单一独立产品。

❶数据存储架构，要有足够的扩展性和可靠性，要满足企业能把所有原始数据都“囤"

起来，存得下、存得久。

一般来讲，各大云厂商都喜欢用对象存储来做数据湖的存储底座，比如

AmazonWebServices（亚马逊云科技），修建“湖底"用的“砖头”，就是S3云对

象存储。

•;京乖湖・

❷数据处理工具，则分为两大类I

第一类工具，解决的问题是如何把数据“搬到”湖里，包括定义数据源、制定数据访问策

略和安全策略，并移动数据、编制数据目录等等。

如果没有这些数据管理/治理工具，元数据缺失，湖里的数据质量就没法保障，“泥石俱

下”，各种数据倾泻堆积到湖里，最终好好的数据湖，慢慢就变成了数据沼泽。

因此，在一个数据湖方案里，数据移动和管理的工具非常重要。

比如，AmazonWebServices提供“LakeFomnati。八”这个工具，帮助客户自动化

地把各种数据源中的数据移动到湖里，同时还可以调用AmazonGlue来对数据进行

ETL,编制数据目录，进一步提高湖里数据的质量。

Ahvazon,

LakeFormation

AmazonS3

数据湖存储

第二类工具，就是要从湖里的海量数据中“淘金”。

数据并不是存进数据湖里就万事大吉，要对数据进行分析、挖掘、利用，比如要对湖里的

数据进行查询，同时要把数据提供给机器学习、数据科学类的业务，便于“点石成金

我们继续拿AmazonVJebServices来举例子，基于AmazonAthena这个服务，就

可以使用标准的SQL来对S3（数据湖）中的数据进行交互式查询。

再比如使用AmazonSageMaker机器学习服务，导入数据湖中的数据进行模型训练,

这些都是常规操作。

小结一下，数据湖不只是个“囤积”数据的“大水坑”，除了用存储技术构建的湖底座以

外，还包含一系列的数据入湖、数据出湖、数据管理、数据应用工具集，共同组成了数据

湖解决方案。

数据湖和数据仓库区别在哪儿?

这个问题其实不难回答，我们先看下面这张对比表。

特性擞据仓库物据湖

结构化数据，抽取自事务系统、所有类型的数据，结构化、半结构

放啥数据

运营数据库和业务应用系统化和非结构化

通常在数仓实施之前设计

在分析时编写

Schema但也可在分析时编写

起步成本高，使用本地存储

性价比咋样起步成本低，计算存储分离

以获得最快查询结果

数据质量如何可作为重要事实依据的数据包含原始数据在内的任何数据

最适合谁用业务分析师为主数据科学家、数据开发人员为主

机器学习、探索性分析、数据发现、

具体能干啥批处理报告、可视化分析

BK流处理、大数据与特征分析

从数据含金量来比，数据仓库里的数据价值密度更高一些，数据的抽取和Sckewva的

设计，都有非常强的针对性，便于业务分析师迅速获取洞察结果，用与决策支持。

而数据湖更有一种“兜底”的感觉，甭管当下有用没有/或者暂时没想好怎么用，先保存

着、沉淀着，将来想用的时候，尽管翻牌子就是了，反正都原汁原味的留存了下来。

数据精挑细选数据照单全收

*辖湖：

1*幅令库:为当下把脉为明日画饼

而从产品形态看，数据仓库可以是独立的标准化产品，拿云上数仓来举例，AMQ。八

Redshift,就是一款“数仓产品”。

数据湖则是一种架构，通常是围绕对象存储为“湖底座”的大数据管理方案组合。比如，

AmazonWebServices并没有哪个产品叫“数据湖"，而是以S3为基础，结合一系列

数据管理工具，帮助客户构建云上“数据湖乜

幽找W麴瑜这忖坑是彭挖/

回想以前科普AmazonWebServices数据湖的插画，可以看到，以“湖"为基础，“A

厂”准备了各式各样的工具和服务，它们紧密集成在一起。这里应该狠狠一下，读

到后面你会发现，“A厂”设计数据湖架构的初衷，就是奔着“湖仓架构”去的。

为什么要把"湖"和"仓”糅到一起?

曾经，数据仓库擅长的131.数据洞察离业务更近、价值更大，而数据湖里的数据，更

多的是为了远景画饼。

随着大数据和A1的上纲上线，原先的“画的饼”也变得炙手可热起来，为业务赋能，价

值被重新定义。

而因为数仓和数据库的出发点不同、架构不同，企业在实际使用过程中，“性价比”差异

很大。

（数据体・）

数据湖起步成本很低，但随着数据体量增大，成本会加速飙升，数仓则恰恰相反,

前期建设开支很大。

总之，一个后期成本高，一个前期成本高，对于既想修湖、又想建仓的用户来说，仿佛

玩了一个金钱游戏。

于是，人们就想，既然都是拿数据为业务服务，数据湖和数仓作为两大“数据集散地”,

能不能彼此整合一下，让数据流动起来，少点重复建设呢？

比如，让“数仓”在进行数据分析的时候，可以直接访问数据湖里的数据（Amazon

Red^iftSpectra是这么干的）。再比如，让数据湖在架构设计上，就“原生”支持

数仓能力（DHtaLake是这么干）。

正是这些想法和需求，推动了数仓和数据湖的打通和融合，也就是当下炙手可热的概念:

LakeHouse。

到底什么才是真正的LakeHouse?

LakeHouse,坊间通常称之为"湖仓一体"，而AMAZ。八WebServices则叫做"智能

湖仓”。

LakeHouse架构最重要的一点，是实现"湖里"和“仓里”的数据/元数据能够无缝打通,

并且“自由”流动。

湖里的“新鲜”数据可以流到仓里，甚至可以直接被数仓使用，而仓里的“不新鲜”数据,

也可以流到湖里，低成本长久保存，供未来的数据挖掘使用。

为了实现这个目标，AmazonWebServices推出了RedshiftSpectrum,打通了数

仓对数据湖的直接访问，能够高效查询S3数据湖当中的级数据。

我从湖里

捞点儿干货!

“Spectrum”是智能湖仓的核心组件,被称为M^akeHouse引擎］它可以在

湖与仓之间架起数据流动的管道IO可以将数据湖中最近几个月的“热数据”摄取到数仓中;

❷反过来，也可以轻松将大量冷门历史数据从数仓转移至成本更低廉的数据湖内，同时这些移到湖里的数据，仍然可以被

Redskift数仓查询使用;

❸处理数仓内的热数据与数据湖中的历史数据，生成丰富的数据集，全程无需执行任何数据移动操作;

❹生成的新数据集可以插入到数仓中的表内，或者直接插入由数据湖托管的外部表中。

做到这一步，基本上算是get到了LakeHouse的精髓，“湖仓一体”初见端倪。

但是，在实际业务场景下，数据的移动和访问，不仅限于数仓和数据湖之间，搜索引擎服

务、机器学习服务、大数据分析服务……，都涉及到数据在本地（本系统）和数据湖之

间的移动，以及数据在不同服务之间的移动。

数据积累得越多，移动起来就越困难，这就是所谓的“数据重力”。

所以，LakeHouse不仅要把湖、仓打通，还要克服“数据重力”，让数据在这些服务之

间按需来回移动：入湖、出湖、环湖……

把数据湖和数据仓库集成起来只是第一步，还要把湖、仓以及所有其他数据处理服务组

成统一且连续的整体，这就是AmazonWebServices为何把自家的LnkeHouse架

构称为“智能湖仓"，而非“湖仓一体”。

湖仓一体”只是开局，智能湖仓才是终极

智能湖仓并非单一产品，它描述的是一种架构。

这套架构，以数据湖为中心，把数据湖作为中央存储库，再围绕数据湖建立专用“数据

服务环”，环上的服务包括了数仓、机器学习、大数据处理、日志分析，甚至RDS和

NOSQL服务等等。

大家“环湖而饲”，既可以直接操纵湖内数据，也可以从湖中摄取数据，还可以向湖中回注

数据，同时环湖的服务彼此之间也可以轻松交换数据。

任何热门的数据处理服务，都在湖边建好了，任何对口的数据都能召之即来、挥之则去。依

靠这种无缝集成和数据移动机制，用户就能从容地用对的工具从对的数据中，挖出干货！

智能湖仓架构

美系鹏数据小

Amazon

卜）Aurora

人数据处呼QPNoSQI数按m

Am部/矮X___（AAmazon

瓯、IjDynamoDB

：7/（^.

必露Aan

Amazonf—

ElasticsearchVUDtjNy1.）SageMaker

ServiceN-----//犷’

数据仓记（g

Amazon'〜

Redshift

上面这张图看着就更加明白一些，中间是湖，周边集成了全套的云上数据服务，然后还

有LakeForwtion、G/ue、Athena以及前面重点提到的Redshift:Spectvnw^这些

工具，来实现数据湖的构建、数据的管理、安全策略以及数据的移动。

如果我们再从数据获取到数据应用的完整流程来看，这些产品又是如何各司其职的呢？

AmazonWebServices官方给出了智能湖仓的参考架构J

数据Redshift

with统

消费层.Spectrum

QuickSightSageMaker

3

EMRGlue"嫦整Sparkstreaming

数据

处理层

oooo^^

基于SQL的ELT大数据处理近实时ETL

LakeFormation

料，

目录层今,匕

口匕

生成通用数据目录

湖

RedshiftS3

仓rE原生集成策划区

pu受信区

存储层一,do

存s原始区

0登陆区