数据湖中的桌子有什么意义？

Question

我认为使用数据湖( Data )与数据仓库()的全部目的是将ETL (提取、转换、加载)过程转换为让(加载、提取、转换)。难道提取这些数据，将其转换并加载到一个表中，就能让我们回到我们开始的地方吗？

Answer 1

数据湖的目的是存储所有类型的数据:非结构化的、半结构化的和结构化的。Azure版本是Azure (ADLS)，它的主要功能是可扩展的、大容量的存储。

另外，还有一个产品Azure (ADLA)。这个分析产品可以与ADLS交互，也可以与blob存储、VM上的SQL (IaaS)以及两种PaaS数据库产品( storage和和HDInsight )进行交互。它有一种强大的批处理语言U，它是SQL和.net的结合，用于询问和操作这些数据存储。它还具有一个数据库选项，在适当的情况下，它允许您存储以表格式处理的数据。

一个例子可能是在您的湖中有一些非结构化数据，您运行批处理输出并希望存储结构化中间输出。这是您可以将输出存储在ADLA数据库表中的地方。我倾向于在能够证明我可以从中获得性能改进的地方使用它们，并且/或希望利用不同的索引选项。

我不认为这些是仓库表，因为它们还没有与其他产品很好地交互(它们还没有端点/不可见)(如Azure Data还不能从那里移动表)。

最后，我倾向于认为ADLS类似于HDFS，U/ADLA类似于Spark。

HTH

Answer 2

根据定义，数据湖是一个巨大的存储库，在需要之前以它的原生格式存储原始数据。湖泊使用的是平面架构，而不是嵌套(http://searchaws.techtarget.com/definition/data-lake)。湖中的数据具有唯一的ID和元数据标记，用于查询。

因此，数据湖可以存储结构化、半结构化和非结构化数据。结构化数据将包括带有行和列的表中的SQL数据库类型数据。半结构化将是CSV文件等。非结构化数据就是任何东西--电子邮件，PDF，视频，二进制。正是ID和元数据标记帮助用户在湖中查找数据。

为了使数据湖易于管理，成功的实现者定期从湖中旋转、归档或清除数据。否则，它就变成了一些人所说的“数据沼泽”，基本上是数据的坟墓。

传统的ELT流程更适合于数据仓库，因为它们更有结构，而且仓库中的数据也是为了某种目的而存在的。数据湖泊结构较弱，更适合于其他方法，如ELT (提取、加载、转换)，因为它们存储的原始数据仅按每个查询进行分类。(关于ELT对ETL的讨论，请参阅文章 by Panopoly。)例如，您希望看到2010年的客户数据。当您查询数据池时，您将从会计数据、CRM记录甚至2010年的电子邮件中获得所有信息。在将数据转换为可使用的格式之前，您无法分析这些数据，在这种格式中，公共分母是customers + 2010。

Answer 3

对我来说，答案是“钱”和“资源”。

(可能与使用Excel使用数据相关:)

我已经完成了一些从RDBMS到Hadoop/Azure平台的迁移，这可以归结为成本/预算和用例：

1)将遗留报告系统移植到新的体系结构

2)使用数据驱动业务价值的终端用户的技能集。

3)最终用户正在处理的数据类型

4)支持最终用户的一组技术支持人员

5)移徙的目的是降低基础设施支助费用，还是增强新的能力。

关于上述几个方面的更多细节：

遗留报告系统通常基于一些分析软件或本土系统，随着时间的推移，这些系统对干净的、受治理的、结构化的、强类型的数据有着根深蒂固的期望。关闭后端系统通常需要发布完全相同的结构，以避免替换整个分析解决方案和代码库。

技能集也是一个主要的关注点，因为您经常谈到数百到数千习惯使用Excel的人，其中有些人了解SQL。在我的经验中，很少有最终用户，也很少有分析师知道如何编程。统计学家和数据工程师倾向于R/Python。具有Java/C#经验的开发人员倾向于Scala/Python。

数据类型是确定什么工具适合这项工作.但是这里有一个很大的冲突，因为有些人知道如何处理“数据矩形”(例如dataframes/tabular数据)，以及那些知道如何使用其他格式的人。然而，我仍然发现，人们总是把半结构化/二进制/非结构化数据转换成一个表，只要他们需要得到一个可操作的结果.因为很难找到对火花的支持。