数据湖比数据仓库香在哪？

上图是我拍摄于2016年冬天的大理洱海

大家好，我是一哥，昨天分享了老彭的一篇关于数据湖引擎干货文章《数仓的未来到底是什么？》，有小伙伴留言问了下面的问题：

碰巧的是，昨天下午刚好面试一个同学，简历中他提到了数据湖，我就问了一下，发现他做的其实是数仓，应该只是凑个技术热度……。

想要解决上面读者留言的这个问题就要理解数据湖到底是能干什么的以及数据湖相比数据仓库的好处在哪？

一哥早期看过一篇外文，讲的不错，今天给给大家分享一下。

数据湖引擎是一种开源软件解决方案或云服务，它通过一组统一的api和数据模型为分析工作负载的各种数据源提供关键功能。数据湖引擎解决了快捷访问、加速分析处理、保护和屏蔽数据、管理数据集以及提供跨所有数据源的统一数据目录等方面的关键需求。

数百万数据消费者使用的工具，如BI工具、数据科学平台和仪表板工具，假设所有数据都存在于一个高性能的关系数据库中，当数据在多个系统中，或者在非关系存储(如ADLS、Amazon S3、Hadoop和NoSQL数据库)中，这些工具的能力就会受到影响。因此，它的任务是将这些数据转移到关系环境中，创建多维数据集，并为不同的分析工具生成专用视图。数据湖引擎简化了这些挑战，允许公司将数据存放在任何地方。

数据湖引擎介于管理数据系统、分析可视化和数据处理工具之间。数据湖引擎不是将数据从数据源移动到单个存储库，而是部署在现有数据源和数据使用者的工具(如BI工具和数据科学平台)之上。

从这些工具的角度来看，数据湖引擎是使用标准SQL通过ODBC、JDBC或REST进行访问的，而数据湖引擎负责尽可能高效地访问和保护数据，不管你的数据是在哪里存放的。

BI分析工具，如Tableau、Power BI、R、Python和机器学习模型，是为数据生活在一个单一的、高性能的关系数据库中的环境而设计的。然而，多数组织使用不同的数据格式和不同的技术在多种解决方案中管理他们的数据。多数组织现在使用一个或多个非关系型数据存储，如云存储(如S3、ADLS)、Hadoop和NoSQL数据库(如Elasticsearch、Cassandra)。

当数据存储在一个独立的高性能关系数据库中时，BI工具、数据科学系统和机器学习模型可以很好运用这部分数据。然而，就像我们上面所说的一样，数据这并不是存在一个地方。因此，我们通常应用自定义ETL开发来集成来自不同系统的数据，以便于我们后续分析。通常分析技术栈分为以下几类：

• ODS，数据从不同的数据库转移到单一的存储区域，如云存储服务(如Amazon S3、ADLS)。    

• 数据仓库，虽然可以在Hadoop和云存储上直接执行SQL查询，但是这些系统的设计目的并不是提供交互性能。因此，数据的子集通常被加载到关系数据仓库或MPP数据库中，也就是构建数据仓库。

•  数据集市，为了在大型数据集上提供交互性能，必须通过在OLAP系统中构建多维数据集或在数据仓库中构建物化聚合表对数据进行预聚合。

这种多层体系架构带来了许多挑战。例如：

• 灵活性，比如数据源的变化或新的数据需求，必须重新访问数据仓库每一层，以确保后续应用人员来使用，可能会花费较长的实施周期。

• 复杂性，数据分析人员必须了解所有存储数据的查询语法，增加了不必要的复杂性。

• 技术成本，该架构需要广泛的定制ETL开发、DBA专业知识和数据工程来满足业务中不断发展的数据需求。

• 基础设施成本，该架构需要大量的专有技术，并且通常会导致存储在不同系统中的数据产生许多副本。

• 数据治理，该架构如果血缘关系搞的不好，便使得跟踪、维护变得非常困难。

• 数据及时性，在ETL的过程中需要时间，所以一般数据是T-1的统计汇总。

数据湖引擎采用了一种不同的方法来支持数据分析。数据湖引擎不是将数据移动到单个存储库中，而是在数据原本存储的地方访问数据，并动态地执行任何必要的数据转换和汇总。此外，数据湖引擎还提供了一个自助服务模型，使数据使用者能够使用他们喜欢的工具(如Power BI、Tableau、Python和R)探索、分析数据，而不用关心数据在哪存、结构如何。

有些数据源可能不适合分析处理，也无法提供对数据的有效访问。数据湖引擎提供了优化数据物理访问的能力。有了这种能力，可以在不改变数据使用者访问数据的方式和他们使用的工具的情况下优化各个数据集。

与传统的解决方案相比，数据湖引擎使用多种技术使数据消费者能够访问数据，并集成这些技术功能到一个自助服务的解决方案中。

那么在大数据时代，数据湖对于“数据驱动”更“敏捷”。但是，要真正用好数据湖，并不容易，也许下一个方向应该是数据湖的治理，当数据湖的治理明确后，也就是它真正普及的时刻了！