存储原始数据，这些原始数据的来源非常丰富结构化数据半结构化数据非结构化数据二进制数据（图片等）

支持多种计算模型批处理流计算交互式分析机器学习

有完善的数据管理能力能做到多种数据源接入时间不同数据之间的连接支持 Schema 管理支持权限管理

灵活的底层存储一般用 S3/OSS/HDFS 这种廉价的分布式文件系统支持 Parquet/Avro/Orc 文件格式支持数据缓存加速满足对应场景的数据分析需求

简单来说，“湖泊”描述了一块土地，它作为来自不同来源的水的蓄水池，如河流、雨水、冰川等。在大数据的世界中，从大自然中汲取灵感，我们有一个类似的我将在本文中在大数据的背景下讨论称为数据湖的概念。

大数据背景？为什么它很大？

为了描述通俗地说大数据，它是这样一个数据的大量被在生产这样的高速度是存储，组织，并与传统方法分析它不能有任何帮助。它不是几 GB 或 TB 的数据，而是一天内生成和存储的 PB 级数据，并且数据呈指数级增长。

如此大量的数据是如何产生的，我们似乎无法处理？答案就在我们身边。我们使用的所有智能设备都会生成大量数据。同样，社交媒体是这一海量数据的重要贡献者（仅 Facebook 一天就产生 550 TB 的数据）。全球的银行和证券交易所是造成这一数据问题的其他因素。

今天的大数据技术帮助我们有效地存储和分析这些海量数据，同时控制成本。大数据已成为组织成功的关键因素，他们一直在投资大数据技术和流程，以提供对相关数据的即时访问，根据可用数据提高客户满意度，进行有效的风险管理和分析，并增加他们的服务效率。

数据是新的石油。~克莱夫·汉比。

什么是数据仓库？

简单来说，数据仓库 (DWH) 有点像*存储库，其中集成和存储来自异构源的数据，用于商业智能和决策制定。它是一个非常大、非常优化且非常结构化的“分析 数据库”，旨在为决策者提供经过精心挑选和适当转换的当前和历史数据，用于分析处理和报告目的，例如客户分析、运营分析，制定生产流程等。

为了构建 DWH，数据是从多个数据源中提取的，例如其他数据库、平面文件、CSV/XML 文件、CRM/ERP 系统或其他一些 OLTP 应用程序。提取的数据经过清理，转换为特定的格式/结构，然后加载到 DWH 中。这个过程通常被称为“ ETL ”提取、转换和加载。一旦数据加载到我们的 DWH 中，我们的消费者应用程序就可以开始查询 DWH 以进行所需的任何类型的分析处理。例如，销售部门（消费者）可能有兴趣比较 2020 年所有季度的销售额，并向利益相关者提供有关当前财年销售额的预测。

没有数据，你只是另一个有意见的人。~ W.Edwards Deming

什么是数据湖？

数据湖也是一个*存储库，用于将我们所有与业务相关的数据存储在一个地方，以便访问我们所有的消费者应用程序。乍一看，它似乎有点类似于数据仓库，但两者都在完全不同的上下文中使用。在数据湖中，我们以任何规模存储所有结构化和“非结构化”数据。数据湖中的数据可以是任何东西、文件、来自关系数据库的数据、社交媒体数据、流数据、音频、图像、文档、视频等等。

数据湖的架构由以下重要组件组成：

数据源——由任何类型的数据（平面文件、流数据、社交媒体数据、物联网数据、多媒体数据）组成。
数据摄取——数据摄取层负责将数据从源复制到数据湖的登陆区。
登陆区——登陆区是所有原始数据由摄取作业累积的地方。在这个区域，数据根据需要进行 ETL 和策划（清理、转换、结构化）。
暂存区 -从着陆区，策划的数据被发送到暂存区。暂存区由结构良好的数据组成，这充当分析区的消耗源。
分析区 —也称为“分析沙盒”。来自暂存区的精选数据适用于不同类型的高级分析用例，例如数据探索、大数据分析、数据科学探索（例如预测建模）等。
表示层 —这是对分析区中的精选数据执行的分析所获得的结果的生产层。生产层主要用于报告、仪表盘和 BI 或 DWH 中的进一步存储。

Ť他的世界是一个大数据的问题。~ 安德鲁迈克菲

数据湖与数据仓库——主要区别

看看数据湖和 DWH 服务的用例，人们可能会争辩说两者本质上是相同的。看起来确实如此，但实际上并非如此。下面列出了一些主要差异：

专为读取模式设计——数据湖的主要目的是允许提供“读取模式”。Schema-on-read 允许我们以“原始”形式保存数据，并仅在实际需要时执行数据管理。相反，DWH 完全基于“写入时模式”模型，只有感兴趣且符合 DWH 模式的数据才会存储在 DWH 中。
数据质量和处理需求——如前所述，数据湖将存储所有类型的数据，与 DWH 不同，DWH 只存储高度策划和结构化的数据。存储数据湖中的数据是为了在未来的某个时间使用它，因为目前不存在需求，但对于 DWH，所有存储的数据仅用于处理定义明确的用例明确定义的要求，很容易需要用于分析的数据。
灵活性、性能、安全性——与 DWH 相比，数据湖更加灵活和敏捷，可以轻松满足不断变化的配置需求，后者不容易允许此类更改。在性能方面，DWH 在查询结果方面更好，但会为大量数据带来额外成本，而数据湖为大量数据提供低成本，但与 DWH（查询）相比，性能效率可能不高数据湖的性能每天都在提高）。由于数据湖仍然是一个不断发展的概念，“安全实践” 与已经使用了很长时间并具有非常完善和成熟的安全实践的传统 DWH 相比，数据湖尚未成熟。
最终用户——由于数据湖中的数据是未经整理的，因此需要大量的技术知识来根据需要整理数据。因此，数据湖通常会发现其用户群是技术人员，例如开发人员和数据科学家，而对于 DWH，由于数据已经处于策划形式，因此非常适合业务和数据分析师。

数据湖和数据仓库的对比

数据湖和数据仓库都是设计模式，但它们是对立的。

数据仓库为了高并发的质量、一致性、重用和性能而构建和打包数据。

数据湖通过一种设计模式补充了仓库，该模式侧重于原始原始数据保真度和低成本长期存储，同时提供一种新形式的分析敏捷性。

大数据刚兴起的时候，数据主要用途是 BI 、报表、可视化。因此数据需要是结构化的，并且需要 ETL 对数据进行预处理。这个阶段数据仓库更适合完成这样的需求，所以企业大部分需要分析的数据都集中到数据仓库中。而机器学习的兴起对数据的需求更加灵活，如果从数据仓库中提数会有一些问题。

比如：数据都是结构化的；数据是经过处理的可能并不是算法想要的结果；算法同学与数仓开发同学沟通成本较大等。我在工作中就遇到这种情况，做算法的同学需要经常理解我们的数仓模型，甚至要深入到做了什么业务处理，并且我们的处理可能并不是他们的想要的。基于上面遇到的各种问题，数据湖的概念应运而生。下面的表格对比一下数据湖和数据仓库的区别，主要来自 AWS 。

数据湖 vs 数据仓库

比较数据来源于 AWS。

特性	数据仓库	数据湖
数据	来自事务系统、运营数据库和业务线应用程序的关系数据	来自 IoT设备、网站、移动应用程序、社交媒体和企业应用程序的非关系和关系数据
Schema	设计在数据仓库实施之前（写入型Schema）	写入在分析时（读取型Schema）
性价比	更快查询结果会带来较高存储成本	更快查询结果只需较低存储成本
数据质量	可作为重要事实依据的高度监管数据	任何可以或无法进行监管的数据（例如原始数据）
用户	业务分析师	数据科学家、数据开发人员和业务分析师（使用监管数据）
分析	批处理报告、BI和可视化	机器学习、预测分析、数据发现和分析

数据湖中的价值

数据湖满足了经济地利用爆炸式数据量并从中获取价值的需求。这些来自新来源（网络、移动、连接设备）的“暗”数据在过去经常被丢弃，但它包含有价值的洞察力。海量数据以及新形式的分析需要一种新的方式来管理数据并从中获取价值。

数据湖是长期数据容器的集合，可大规模捕获、优化和探索任何形式的原始数据。它由多个下游设施可以利用的低成本技术实现，包括数据集市、数据仓库和推荐引擎。

来自非策划数据的见解

在大数据趋势出现之前，数据集成以某种持久性（例如数据库）形式标准化了信息，从而创造了价值。仅此一项已不足以管理企业中的所有数据，并且试图将其全部构建会破坏其价值。这就是为什么数据库中很少捕获暗数据的原因，但数据科学家经常挖掘暗数据以找到一些值得重复的事实。

新形式的分析

云时代催生了新的分析形式。Apache Hadoop、Spark 和其他创新技术支持过程编程语言的并行化，从而实现了全新的分析类型。这些新形式的分析可以大规模有效地进行处理，例如获得答案的图形、文本和机器学习算法，然后将该答案与下一条数据进行比较，依此类推，直到达到最终输出。

企业记忆保留

归档长时间未使用的数据，可以节省数据仓库的存储空间。在数据湖设计模式出现之前，除了高性能数据仓库或离线磁带备份之外，没有其他地方可以放置较冷的数据以供偶尔访问。借助虚拟查询工具，用户可以通过一次查询，轻松地将冷数据与数据仓库中的温热数据结合起来访问。

数据集成的新方法

在如何最好地压缩数据转换成本方面，该行业已经轮回。数据湖以更低的成本提供比传统 ETL（提取、转换、加载）服务器更大的可扩展性。采用最佳实践的组织正在重新平衡数据湖、数据仓库和 ETL 服务器中的数百个数据集成工作，因为每个工作都有自己的能力和经济性。

数据湖的常见陷阱

从表面上看，它们看起来很简单——提供了一种管理和利用大量结构化和非结构化数据的方法。但是，它们并不像看起来那么简单，失败的数据湖项目在许多类型的行业和组织中并不少见。早期项目面临挑战，因为最佳实践尚未出现。现在，缺乏可靠的设计是它们无法实现全部价值的主要原因。

数据孤岛和集群扩散。

有一种观点认为，数据湖的进入门槛很低，可以在云中临时完成。这导致冗余数据和不一致，没有两个湖协调，以及同步问题。

缺乏最终用户的采用。

用户有一种看法——无论对错——从数据湖中获取答案太复杂了，因为它需要高级编码技能，或者他们无法在数据大海捞针中找到所需的针头。

有限的商业现成工具。

许多供应商声称可以连接到 Hadoop 或云对象存储，但这些产品缺乏深度集成，而且这些产品中的大多数都是为数据仓库而不是数据湖构建的。

数据访问的冲突目标。

在确定安全措施的严格程度与敏捷访问之间存在平衡。需要制定使所有利益相关者保持一致的计划和程序。

开源数据湖架构

那么开源数据湖架构一般是啥样的呢？这里我画了一个架构图，主要分为四层：

数据湖: 只是一个新名字? 从哪里来, 往那里去

最底下是分布式文件系统，云上用户 S3 和 oss 这种对象存储会用的更多一些，毕竟价格便宜很多；非云上用户一般采用自己维护的 HDFS。

第二层是数据加速层。数据湖架构是一个存储计算彻底分离的架构，如果所有的数据访问都远程读取文件系统上的数据，那么性能和成本开销都很大。如果能把经常访问到的一些热点数据缓存在计算节点本地，这就非常自然的实现了冷热分离，一方面能收获到不错的本地读取性能，另一方面还节省了远程访问的带宽。这一层里面，我们一般会选择开源的 alluxio，或者选择阿里云上的 Jindofs。

第三层就是 Table format 层，主要是把一批数据文件封装成一个有业务意义的 table，提供 ACID、snapshot、schema、partition 等表级别的语义。一般对应这开源的 Delta、Iceberg、Hudi 等项目。对一些用户来说，他们认为Delta、Iceberg、Hudi 这些就是数据湖，其实这几个项目只是数据湖这个架构里面的一环，只是因为它们离用户最近，屏蔽了底层的很多细节，所以才会造成这样的理解。

最上层就是不同计算场景的计算引擎了。开源的一般有 Spark、Flink、Hive、Presto、Hive MR 等，这一批计算引擎是可以同时访问同一张数据湖的表的。