1、数据仓库

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。
早期系统采用关系型数据库来存放管理数据，但是随着大数据技术的兴起，人们对于多方面数据进行分析的需求愈加强烈，这就要求建立一个能够面向分析、集成保存大量历史数据的新型管理机制，这一机制就是数据仓库。
在这里插入图片描述
数据仓库通常存储来自不同源的数据，集成源数据以提供统一的视图。这些资源可以包括事务系统、应用程序日志文件、关系数据库等等。

数据仓库的特征

数据仓库之父Bill Inmon在1991年出版的Building the Data Warehouse 一书中首次提出了被广为认可的数据仓库定义。Inmon将数据仓库描述为一个面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理者的决策过程。这个定义有些复杂并且难以理解，针对定义中的关键词，我们分别来看看数据仓库所具备的特点。

数据仓库的数据是面向主题的
与传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。在较高层次上完整、统一地刻划各个分析对象所涉及的企业各项数据，以及数据之间的联系。
数据仓库的数据是集成的
数据仓库的数据是从原有的分散的数据库数据中抽取得来。数据进入数据仓库之前，必然要经过统一与综合处理。
数据仓库的数据是随时间不断变化的
为了发现业务变化的趋势、存在的问题，或者新的机会，需要分析大量的历史数据。换句话说，数据仓库中的数据是反映了某一历史时间点的数据快照，这也就是术语“随时间变化”的含义。同时，在从数据集成输入数据仓库开始到最终被删除，数据又是有生存周期的。
数据仓库的数据是非易失的
非易失指的是，一旦进入到数据仓库中，数据就不应该再有改变。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一般情况下并不进行修改操作。

2、数据湖

随着当前大量信息化发展和电子设备产品普及，产生大量的照片、视频、文档等非结构化数据，人们也想通过大数据技术找到这些数据的关系。随之而来的数据湖就产生了。

数据湖的概念首次于2010年被James Dixon在其博客帖子（Pentaho, Hadoop, and Data Lakes | James Dixon’s Blog）中提及：

如果将数据集市视为瓶装水的商店——经过清洁、包装和结构化以便于饮用——那么数据湖就是处于更自然状态的一大片水体。数据湖的内容从源头流入，填满湖，湖的各种用户可以来检查、潜入或取样。

维基百科对数据湖的定义是：数据湖（Data Lake）是一个以原始格式存储数据的存储库或系统，它按原样存储数据，而无需事先对数据进行结构化处理。一个数据湖可以存储结构化数据（如关系型数据库中的表），半结构化数据（如CSV、日志、XML、JSON），非结构化数据（如电子邮件、文档、PDF）和二进制数据（如图形、音频、视频）。
在这里插入图片描述

也就是说，数据湖中的数据在从源获取时不受数据结构的约束，在需要时应用“读取”模式来促进数据分析。数据湖的本质，是由“数据存储架构+数据处理工具”组成的解决方案，而不是某个单一独立产品。

数据湖的特征

数据湖具有以下特点：

容量大
数据湖汇聚吸收各个业务数据源流，容纳散落在各处的数据，理论上，存储空间巨大。
格式多
数据湖架构面向多数据源的信息存储，可以快速高效地采集、存储、处理大量来源不同、格式不同的原始数据，这其中包括文本、图片、视频、音频、网页等各类无序的非结构化数据，能把不同种类的数据汇聚存储在一起，并对汇聚后的数据进行管理，建立数据之间的关联关系，具有很强的兼容性。
处理速度快
数据湖技术能将各类原始数据快速转化为可以直接提取的、分析、使用的标准格式，统一优化数据结构并对数据进行分类存储，根据业务需求，对存储的数据进行快速的查询、挖掘、关联和处理，并实时传输给末端用户。
体系结构
由于Hadoop也能基于分布式文件系统来存储处理多类型数据，因此许多人认为Hadoop的工作机理就是数据湖的处理机制。当然，Hadoop基于其分布式、可横向扩展的文件系统架构，可以管理和处理海量数据，但是它无法提供数据湖所需要的复杂元数据管理功能，最直观的表现是，数据湖的体系结构表明数据湖是由多个组件构成的生态系统，而Hadoop仅仅提供了其中的部分组件功能。

数据仓库和数据湖的对比

	数据仓库	数据湖
数据	来自事务系统、运营数据库和业务线应用程序的关系数据	来自 IoT设备、网站、移动应用程序、社交媒体和企业应用程序的非关系和关系数据
模式	写时模式，数据写入前已经定义好schema，更改schema成本较高	读时模式，数据在利用的时候再定义schema，灵活方便
使用思维	先有报表需求，根据报表确定数仓shcema，然后通过ETL过程将数据导入	并不需要根据需求来开发数据业务，数据集中存储，需要的时候再利用。保留了数据的完整性
存储容量	数据仓库对存储的数据更有选择性，一般比数据湖要小，但与传统数据库相比仍然很大	由于包含所有数据，通常是PB级别的
性价比	起步成本高，使用本地存储以获得最快查询结果	起步成本低，计算存储分离
产品形态	数据仓库可以是独立的标准化产品	数据湖则是一种架构，通常是围绕对象存储为“湖底座”的大数据管理方案组合
用户	结构化数据，使用非常方便，主要的使用对象是数据分析师、数据工程师、运营人员等等。	作为原始数据，非结构化数据的数据库，数据湖的主要使用对象是数据科学家。

从数据含金量来比，数据仓库里的数据价值密度更高一些，数据的抽取和Schema的设计，都有非常强的针对性，便于业务分析师迅速获取洞察结果，用与决策支持。

而数据湖更有一种“兜底”的感觉，甭管当下有用没有/或者暂时没想好怎么用，先保存着、沉淀着，将来想用的时候，尽管翻牌子就是了，反正都原汁原味的留存了下来。
数据仓库数据湖

3、湖仓一体

数据湖虽然适合数据的存储，但又缺少一些关键功能，比如不支持事务、缺乏一致性/隔离性、不保证执行数据质量等，这样的短板决定了，让数据湖来承载读写访问、批处理、流作业是不现实的。而且，数据湖缺乏结构性，一旦没有被治理好，就会变成数据沼泽。
在这里插入图片描述

既然都是拿数据为业务服务，数据湖和数仓作为两大“数据集散地”，能不能彼此整合一下，让数据流动起来，少点重复建设呢？，于是，Databricks率先提出了湖仓一体（Data Lakehouse）的概念。

湖仓一体是一种结合了数据湖灵活性和数据仓库规范性优势的新范式，在基于数据湖的低成本存储上，实现与数据仓库中类似的数据结构和数据管理功能。

Data Lakehouse的概念是由Databricks提出的，其联合创始人兼首席执行官 Ali Ghodsi 说：“从长远来看，所有数据仓库都将被纳入数据湖仓，这不会在一夜之间发生——这些东西会共存一段时间——但这个官方的世界纪录清楚地证明，在价格和性能上，数据湖仓完胜数据仓库。”

现在大多数企业都还没有用到湖仓一体的新架构，他们要么选择了数据湖方案，要么选择了数仓方案。但大方向之下，特别是随着 AI 的兴起，完全纯数仓的二维关系表已经无法承接半 / 非结构化数据的处理，AI 引擎不可能只跑在纯数仓模型上。所以湖仓一体一定是未来的发展趋势。

Data Lakehouse的出现试图去融合数仓和数据湖这两者之间的差异，通过将数仓构建在数据湖上，使得存储变得更为廉价和弹性，同时lakehouse能够有效地提升数据质量，减小数据冗余。
在这里插入图片描述
在lakehouse的构建中，ETL起了非常重要的作用，它能够将未经规整的数据湖层数据转换成数仓层结构化的数据。

湖仓一体的特征

事务支持：Lakehouse可以处理多条不同的数据管道。这意味着它可以在不破坏数据完整性的前提下支持并发的读写事务。
Schemas：数仓会在所有存储其上的数据上施加Schema，而数据湖则不会。Lakehouse的架构可以根据应用的需求为绝大多数的数据施加schema，使其标准化。
报表以及分析应用的支持：报表和分析应用都可以使用这一存储架构。Lakehouse里面所保存的数据经过了清理和整合的过程，它可以用来加速分析。同时相比于数仓，它能够保存更多的数据，数据的时效性也会更高，能显著提升报表的质量。
数据类型扩展：数仓仅可以支持结构化数据，而Lakehouse的结构可以支持更多不同类型的数据，包括文件、视频、音频和系统日志。
端到端的流式支持：Lakehouse可以支持流式分析，从而能够满足实时报表的需求，实时报表在现在越来越多的企业中重要性在逐渐提高。
计算存储分离：我们往往使用低成本硬件和集群化架构来实现数据湖，这样的架构提供了非常廉价的分离式存储。Lakehouse是构建在数据湖之上的，因此自然也采用了存算分离的架构，数据存储在一个集群中，而在另一个集群中进行处理。
开放性：Lakehouse在其构建中通常会使Iceberg，Hudi，Delta Lake等构建组件，首先这些组件是开源开放的，其次这些组件采用了Parquet，ORC这样开放兼容的存储格式作为下层的数据存储格式，因此不同的引擎，不同的语言都可以在Lakehouse上进行操作。

湖仓一体的优势

减少数据冗余：如果一个组织同时维护了一个数据湖和多个数据仓库，这无疑会带来数据冗余。在最好的情况下，这仅仅只会带来数据处理的不高效，但是在最差的情况下，它会导致数据不一致的情况出现。湖仓一体的结合，能够去除数据的重复性，真正做到了唯一。
降低存储成本：数据仓库和数据湖都是为了降低数据存储的成本。数据仓库往往是通过降低冗余，以及整合异构的数据源来做到降低成本。而数据湖则往往使用大数据文件系统和Spark在廉价的硬件上存储计算数据。湖仓一体架构的目标就是结合这些技术来最大力度降低成本。
拉通数据应用团队：数据科学倾向于与数据湖打交道，使用各种分析技术来处理未经加工的数据。而报表分析师们则倾向于使用整合后的数据，比如数据仓库或是数据集市。而在一个组织内，往往这两个团队之间没有太多的交集，但实际上他们之间的工作又有一定的重复和矛盾。而当使用湖仓一体架构后，两个团队可以在同一数据架构上进行工作，避免不必要的重复。
避免数据沼泽：在数据湖中，数据停滞是一个最为严重的问题，如果数据一直无人治理，那将很快变为数据沼泽。我们往往轻易的将数据丢入湖中，但缺乏有效的治理，长此以往，数据的时效性变得越来越难追溯。湖仓一体的引入，对于海量数据进行治理，能够更有效地帮助提升分析数据的时效性。
预防兼容风险：数据分析仍是一门兴起的技术，新的工具和技术每年仍在不停地出现中。一些技术可能只和数据湖兼容，而另一些则又可能只和数据仓库兼容。湖仓一体的架构意味着为两方面做准备。

智能湖仓

把数据湖和数据仓库集成起来只是第一步，还要把湖、仓以及所有其他数据处理服务组成统一且连续的整体，这就是Amazon Web Services提出的“智能湖仓”。

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

这套架构，以数据湖为中心，把数据湖作为中央存储库，再围绕数据湖建立专用“数据服务环”，环上的服务包括了数仓、机器学习、大数据处理、日志分析，甚至RDS和NOSQL服务等等。
智能湖仓
大家“环湖而饲”，既可以直接操纵湖内数据，也可以从湖中摄取数据，还可以向湖中回注数据，同时环湖的服务彼此之间也可以轻松交换数据。