数据湖中的表格有什么意义？

Question

我认为使用数据湖与数据仓库的关键在于将ETL（提取，转换，加载）过程转换为LET（加载，提取，转换）。不提取这些数据，将其转换并加载到表格中让我们回到我们开始的地方？

Answer 1

恕我直言，数据湖的一点是存储所有类型的数据：非结构化，半结构化和结构化。 Azure版本是Azure Data Lake Store（ADLS），其主要功能是可扩展的大容量存储。

另外，还有一个产品Azure Data Lake Analytics（ADLA）。此分析产品可以与ADLS交互，但也可以在虚拟机（IaaS）和两个PaaS数据库产品，SQL数据库和SQL数据仓库以及HDInsight上使用blob存储，SQL。它具有强大的批处理语言，称为U-SQL，SQL和.net的组合用于查询和操作这些数据存储。它还有一个数据库选项，可以在适当的情况下存储以表格格式处理的数据。

一个例子可能是你的湖中有一些非结构化数据，你运行你的批输出并想存储结构化的中间输出。这是您可以将输出存储在ADLA数据库表中的位置。我倾向于用它们来证明我可以从中获得性能提升，并且/或者想要利用不同的索引选项。

我不倾向于将这些视为仓库表，因为它们尚未与其他产品良好交互，即它们还没有端点/不可见，例如Azure Data Factory无法移动从那里桌子呢。

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

HTH

Answer 2

通过定义一个数据湖是一个巨大的库中存储的原始数据，在它的原生格式，直到需要。湖泊使用平坦的建筑而不是嵌套（http://searchaws.techtarget.com/definition/data-lake）。湖中的数据具有唯一的ID和元数据标签，用于查询。

因此，数据湖泊可以存储结构化，半结构化和非结构化数据。结构化数据将包含具有行和列的表中的SQL数据库类型数据。半结构化将是CSV文件等。而非结构化数据就是一切 - 电子邮件，PDF，视频，二进制文件。这就是ID和元数据标签，可以帮助用户在湖中找到数据。

为了保持数据湖的可管理性，成功的实施者定期轮换，归档或清除湖中的数据。否则，它就成了一些人所说的“数据沼泽”，基本上就是数据的坟墓。

传统的ELT过程更适合数据仓库，因为它们更加结构化，仓库中的数据就是为了某种目的。数据湖泊结构较少，更适合ELT（Extract，Load，Transform）等其他方法，因为它们存储的原始数据仅由每个查询分类。 （关于ELT与ETL的讨论，请参阅Panopoly的article）。例如，您希望查看2010年的客户数据。当您查询数据湖时，您将从2010年起获得来自会计数据，CRM记录甚至电子邮件的所有内容。在数据转换成公用分母为客户+ 2010的可用格式之前，您无法分析这些数据。

Answer 3

对我来说，答案是“钱”，“资源”
（也许相关使用Excel消费数据:)）

我已经经历了几个迁移从RDBMS到Hadoop的/ Azure的平台，并把它归结为成本/预算和用例：

1）端口旧版报告系统，新的架构

终端用户

2）技能谁将会消耗数据来驱动商业价值

3）数据的类型是由最终用户处理

4）支持人员谁将支持最终用户

5）是否迁移的目的是降低基础设施支持成本，或启用的技能组新功能。

几以上的更多的细节：

旧版报告系统通常或者基于一些分析软件或自行开发的系统，随着时间的推移，有干净的根深蒂固的期望，支配，层次分明，强烈型数据。经常切换出后端系统需要发布完全相同的结构，以避免更换整个分析解决方案和代码库。

技能是首要关注的问题为好，因为你经常谈论的数百到数千人的谁是用来使用Excel，有一些知道SQL。很少有最终用户，以我的经验，很少有分析师我已经与曾知道如何编程。统计人员和数据工程师倾向于R/Python。拥有Java/C＃经验的开发人员倾向于使用Scala/Python。

数据类型是什么工具是正确的工作一个夹子......但在这里，你有一个大的冲突，因为还有谁了解如何与“数据矩形”（例如dataframes /表格数据）工作的人，以及那些知道如何使用其他格式的人。不过，我仍然觉得人一贯只要他们需要得到一个结果操作性转向半结构化/二/非结构化数据到一个表......因为支持是很难找到的火花。