我认为使用Data Lake与数据仓库的关键是将ETL（提取，转换，加载）过程反转为LET（加载，提取，转换）。不提取这些数据，将其转换并加载到表中会让我们回到我们开始的地方吗？
答案 0 :(得分：5)
恕我直言，数据湖的意义在于存储所有类型的数据：非结构化，半结构化和结构化。 Azure版本是Azure Data Lake Store（ADLS），其主要功能是可扩展的大容量存储。
另外，还有一个产品Azure Data Lake Analytics（ADLA）。此分析产品可以与ADLS进行交互，还可以与blob存储，VM上的SQL（IaaS）和两个PaaS数据库产品，SQL数据库和SQL数据仓库以及HDInsight进行交互。它有一个强大的批处理语言U-SQL，它是SQL和.net的组合，用于询问和操作这些数据存储。它还有一个数据库选项，在适当的情况下，您可以存储以表格格式处理的数据。
一个例子可能是您在湖中有一些非结构化数据，您运行批量输出并希望存储结构化中间输出。您可以在此处将输出存储在ADLA数据库表中。我倾向于使用它们，我可以证明我可以从中获得性能提升和/或想要利用不同的索引选项。
我不倾向于将这些视为仓库表，因为它们尚未与其他产品良好交互，即它们还没有端点/不可见，例如Azure Data Factory无法移动表从那里开始。
最后，我倾向于将ADLS视为类似于HDFS和U-SQL / ADLA，类似于Spark。
HTH
答案 1 :(得分：2)
根据定义，数据湖是一个巨大的存储库，在需要之前以原始格式存储原始数据。 Lakes使用扁平架构而不是嵌套（http://searchaws.techtarget.com/definition/data-lake）。湖中的数据具有唯一的ID和元数据标记，用于查询。
因此，数据湖泊可以存储结构化，半结构化和非结构化数据。结构化数据将包括具有行和列的表中的SQL数据库类型数据。半结构化将是CSV文件等。非结构化数据是任何东西 - 电子邮件，PDF，视频，二进制文件。它是ID和元数据标签，可帮助用户在湖中查找数据。
为了使数据湖易于管理，成功的实施者会定期轮换，存档或清除湖中的数据。否则它就变成了一些人所谓的数据沼泽＆＃34;，基本上是数据的坟墓。
传统的ELT流程更适合数据仓库，因为它们更加结构化，仓库中的数据就是出于某种目的。数据湖结构较少，更适合其他方法，如ELT（提取，加载，转换），因为它们存储的数据仅按每个查询进行分类。 （有关ELT与ETL的讨论，请参阅Panopoly的article。）例如，您希望查看2010年的客户数据。当您查询数据湖时，您将从会计数据，CRM记录和甚至是来自2010年的电子邮件。在将数据转换为可用格式之前，您无法分析这些数据，其中公共分母是客户+ 2010年。
答案 2 :(得分：0)
对我来说，答案是“钱”和“资源” （可能与使用Excel消耗数据有关:)）
我已经完成了从RDBMS到Hadoop / Azure平台的一些迁移，它归结为成本/预算和用例：
1）将遗留报告系统移植到新架构
2）将使用数据来推动业务价值的最终用户的技能组
3）最终用户正在处理的数据类型
4）支持最终用户的技术支持人员
5）迁移的目的是降低基础设施支持成本，还是启用新功能。
以上几点的更多细节：
传统报告系统通常基于某些分析软件或自行开发的系统，随着时间的推移，这些系统对清洁，受管理，结构化，强类型数据有着深刻的期望。切换后端系统通常需要发布完全相同的结构，以避免替换整个分析解决方案和代码库。
技能集也是一个主要问题，因为你经常谈论成百上千的习惯使用Excel的人，有些人知道SQL。根据我的经验，很少有最终用户和我曾经合作的分析师知道如何编程。统计学家和数据工程师倾向于R / Python。具有Java / C＃经验的开发人员倾向于使用Scala / Python。
数据类型是什么工具适合工作的关键......但是在这里你有一个很大的冲突，因为有些人了解如何使用“数据矩形”（例如数据框/表格数据），以及那些知道如何使用其他格式的人。但是，我仍然发现人们一旦需要将结果操作化，就会不断地将半结构化/二进制/非结构化数据转换为表格......因为Spark很难找到支持。