table 在数据湖中有什么意义？
What is the point of a table in a data lake?
我认为使用数据湖与数据仓库的全部意义在于将 ETL（提取、转换、加载）过程转换为 LET（加载、提取、转换）。提取这些数据，将其转换并加载到 table 中不会让我们回到起点吗？
恕我直言，数据湖的要点是存储所有类型的数据：非结构化、半结构化和结构化。它的 Azure 版本是 Azure Data Lake Store (ADLS)，其主要功能是可扩展的大容量存储。
另外还有一个产品 Azure Data Lake Analytics (ADLA)。此分析产品可以与 ADLS 交互，还可以与 blob 存储交互，SQL 在 VM (IaaS) 上和两个 PaaS 数据库产品，SQL 数据库和 SQL 数据仓库和 HDInsight。它有一种名为 U-SQL 的强大批处理语言，它是 SQL 和 .net 的组合，用于查询和操作这些数据存储。它还有一个数据库选项，在适当的情况下，允许您以 table 格式存储已处理的数据。
一个例子可能是您的湖中有一些非结构化数据，您 运行 您的批处理输出并希望存储结构化的中间输出。这是您可以将输出存储在 ADLA 数据库中的地方 table。我倾向于在我可以证明我可以从中获得性能改进的地方使用它们 and/or 想利用不同的索引选项。
我不倾向于将这些视为仓库 table，因为它们还不能与其他产品很好地交互，即它们还没有端点/不可见，例如 Azure数据工厂还不能从那里移动 tables。
最后我倾向于认为 ADLS 类似于 HDFS，U-SQL/ADLA 类似于 Spark。
HTH
根据定义，数据湖是一个巨大的存储库，在需要时以其本机格式存储原始数据。 Lakes 使用平面架构而不是嵌套 (http://searchaws.techtarget.com/definition/data-lake)。湖中的数据具有唯一的 ID 和元数据标签，用于查询。
所以数据湖可以存储结构化、半结构化和非结构化数据。结构化数据将包括 SQL 具有行和列的表中的数据库类型数据。半结构化将是 CSV 文件等。非结构化数据无所不包——电子邮件、PDF、视频、二进制文件。正是该 ID 和元数据标签帮助用户在湖中查找数据。
为了保持数据湖的可管理性，成功的实施者定期从湖中轮换、存档或清除数据。否则它会变成一些人所说的 "data swamp"，基本上是数据的坟墓。
传统的 ELT 流程更适合数据仓库，因为它们更加结构化，并且仓库中的数据是有目的的。结构化程度较低的数据湖更适合其他方法，例如 ELT（提取、加载、转换），因为它们存储仅按每个查询分类的原始数据。 （有关 ELT 与 ETL 的讨论，请参阅 Panopoly article。）例如，您想查看 2010 年的客户数据。当您查询数据湖时，您将获得会计数据、CRM 记录和甚至是 2010 年的电子邮件。在将数据转换为可用格式之前，您无法分析该数据，其中公分母是客户 + 2010。
对我来说，答案是 "money" 和 "resources"
（并且可能与使用 Excel 来消费数据相关：））
我完成了从 RDBMS 到 Hadoop/Azure 平台的几次迁移，归结为 cost/budget 和用例：
1) 将遗留报告系统移植到新架构
2) 将使用数据来推动业务价值的最终用户的技能组合
3) 最终用户正在处理的数据类型
4) 支持最终用户的支持人员的技能组合
5) 迁移的目的是降低基础设施支持成本，还是启用新功能。
以上一些的更多详细信息：
遗留报告系统通常基于某些分析软件或本土系统，随着时间的推移，这些系统对干净、受监管、结构化、强类型的数据有着根深蒂固的期望。切换后端系统通常需要发布完全相同的结构以避免替换整个分析解决方案和代码库。
技能组合也是一个主要问题，因为您经常谈论成百上千习惯使用 Excel 的人，其中一些人知道 SQL。根据我的经验，很少有最终用户知道如何编程，而且与我共事过的分析师也很少。统计学家和数据工程师倾向于 R/Python。具有 Java/C# 经验的开发人员倾向于 Scala/Python。
数据类型是确定适合工作的工具的决定因素...但是这里有一个很大的冲突，因为有些人了解如何使用 "Data Rectangles"（例如 dataframes/tabular 数据），以及那些知道如何使用其他格式的人。但是，我仍然发现人们在需要将结果付诸实施时，始终如一地将 semi-structured/binary/unstructured 数据转换为 table... 因为很难找到对 Spark 的支持。
我认为使用数据湖与数据仓库的全部意义在于将 ETL（提取、转换、加载）过程转换为 LET（加载、提取、转换）。提取这些数据，将其转换并加载到 table 中不会让我们回到起点吗？
恕我直言，数据湖的要点是存储所有类型的数据：非结构化、半结构化和结构化。它的 Azure 版本是 Azure Data Lake Store (ADLS)，其主要功能是可扩展的大容量存储。
另外还有一个产品 Azure Data Lake Analytics (ADLA)。此分析产品可以与 ADLS 交互，还可以与 blob 存储交互，SQL 在 VM (IaaS) 上和两个 PaaS 数据库产品，SQL 数据库和 SQL 数据仓库和 HDInsight。它有一种名为 U-SQL 的强大批处理语言，它是 SQL 和 .net 的组合，用于查询和操作这些数据存储。它还有一个数据库选项，在适当的情况下，允许您以 table 格式存储已处理的数据。
一个例子可能是您的湖中有一些非结构化数据，您 运行 您的批处理输出并希望存储结构化的中间输出。这是您可以将输出存储在 ADLA 数据库中的地方 table。我倾向于在我可以证明我可以从中获得性能改进的地方使用它们 and/or 想利用不同的索引选项。
我不倾向于将这些视为仓库 table，因为它们还不能与其他产品很好地交互，即它们还没有端点/不可见，例如 Azure数据工厂还不能从那里移动 tables。
最后我倾向于认为 ADLS 类似于 HDFS，U-SQL/ADLA 类似于 Spark。
HTH
根据定义，数据湖是一个巨大的存储库，在需要时以其本机格式存储原始数据。 Lakes 使用平面架构而不是嵌套 (http://searchaws.techtarget.com/definition/data-lake)。湖中的数据具有唯一的 ID 和元数据标签，用于查询。
所以数据湖可以存储结构化、半结构化和非结构化数据。结构化数据将包括 SQL 具有行和列的表中的数据库类型数据。半结构化将是 CSV 文件等。非结构化数据无所不包——电子邮件、PDF、视频、二进制文件。正是该 ID 和元数据标签帮助用户在湖中查找数据。
为了保持数据湖的可管理性，成功的实施者定期从湖中轮换、存档或清除数据。否则它会变成一些人所说的 "data swamp"，基本上是数据的坟墓。
传统的 ELT 流程更适合数据仓库，因为它们更加结构化，并且仓库中的数据是有目的的。结构化程度较低的数据湖更适合其他方法，例如 ELT（提取、加载、转换），因为它们存储仅按每个查询分类的原始数据。 （有关 ELT 与 ETL 的讨论，请参阅 Panopoly article。）例如，您想查看 2010 年的客户数据。当您查询数据湖时，您将获得会计数据、CRM 记录和甚至是 2010 年的电子邮件。在将数据转换为可用格式之前，您无法分析该数据，其中公分母是客户 + 2010。
对我来说，答案是 "money" 和 "resources"
（并且可能与使用 Excel 来消费数据相关：））
我完成了从 RDBMS 到 Hadoop/Azure 平台的几次迁移，归结为 cost/budget 和用例：
1) 将遗留报告系统移植到新架构
2) 将使用数据来推动业务价值的最终用户的技能组合
3) 最终用户正在处理的数据类型
4) 支持最终用户的支持人员的技能组合
5) 迁移的目的是降低基础设施支持成本，还是启用新功能。
以上一些的更多详细信息：
遗留报告系统通常基于某些分析软件或本土系统，随着时间的推移，这些系统对干净、受监管、结构化、强类型的数据有着根深蒂固的期望。切换后端系统通常需要发布完全相同的结构以避免替换整个分析解决方案和代码库。
技能组合也是一个主要问题，因为您经常谈论成百上千习惯使用 Excel 的人，其中一些人知道 SQL。根据我的经验，很少有最终用户知道如何编程，而且与我共事过的分析师也很少。统计学家和数据工程师倾向于 R/Python。具有 Java/C# 经验的开发人员倾向于 Scala/Python。
数据类型是确定适合工作的工具的决定因素...但是这里有一个很大的冲突，因为有些人了解如何使用 "Data Rectangles"（例如 dataframes/tabular 数据），以及那些知道如何使用其他格式的人。但是，我仍然发现人们在需要将结果付诸实施时，始终如一地将 semi-structured/binary/unstructured 数据转换为 table... 因为很难找到对 Spark 的支持。