使用Azure Data Lake Analytics与传统ETL方法的原因

Question

我正在考虑使用我最近几周一直在研究的Data Lake技术，与我多年来一直合作的传统ETL SSIS方案相比。

我认为Data Lake与大数据非常相关，但使用Data Lake技术与SSIS之间的界限在哪里？

使用25,000~100MB~300MB文件的Data Lake技术有什么优势吗？并行？灵活性？未来可扩展吗？ 当要加载的文件没有U-SQL最佳场景那么大时，是否有任何性能提升......

你有什么想法？是不是像用锤子敲打坚果？ 请不要犹豫，问我任何问题，以澄清情况。 在此先感谢!!

21/03编辑 更多说明：

1. 必须在云上
2. 我考虑使用ADL的原因是因为云中没有替代SSIS。有ADF，但它不一样，它编排数据，但它不像SSIS那么灵活
3. 我以为我可以使用U-SQL进行某些（基本）转换，但我看到了一些问题
   • 我做不了很多基本的事情：循环，更新，在SQL中写日志......
   • 输出只能是U-SQL表或文件。这种架构看起来不太好（尽管U-SQL对于大文件非常好，如果我需要一个额外的步骤将文件导出到另一个DB或DWH） - 或者这可能是在大数据仓库中完成的方式......我不知道
   • 在我的测试中，1MB文件需要40s，500MB文件需要1：15s。我无法证明40s的1MB处理（加上使用ADF上传到数据库/数据仓库）
   • 代码对于用户来说看起来没有组织，因为具有许多基本验证的脚本将是U-SQL脚本太长。

不要误会我的意思，我真的很喜欢ADL技术，但我认为，就目前而言，它是针对非常具体的事情而且仍然没有在云中替代SSIS。你做什么的？我错了吗？

Answer 1

对我来说，如果数据是高度结构化和关系型的，那么它的正确位置就是关系型数据库。在Azure中，您有以下几种选择：

1. VM上的SQL Server（IaaS） 在VM上运行的普通SQL Server，您必须自己安装，配置和管理它，但您可以获得产品的完全灵活性。
2. Azure SQL数据库 PaaS数据库选项的目标是较小的卷，但现在最高为4TB。普通SQL Server的所有功能都可能降低TCO，并可选择使用tiers进行扩展或缩小。
3. Azure SQL数据仓库（ADW） MPP产品适用于大型仓库。对我来说，入门标准是至少1TB的仓库，可能更像是10TB。小卷的MPP真的不值得。

对于所有数据库选项，您可以使用聚簇列存储索引（ADW中的默认值），它可以提供5x到10x之间的大规模压缩。

一年400MB每年总计~143GB，在现代数据仓库中通常没有那么多，通常以TB为单位测量。

Azure Data Lake Analytics（ADLA）的用武之地，是在普通SQL中做不到的事情，例如：

• 将C＃的强大功能与SQL相结合，实现强大的查询功能 - 例如here
• 处理非结构化文件，如images，xml或JSON - 示例here
• 使用RegEx
• 缩小R处理 - 示例here

ADLA还提供联合查询，能够查询数据所在的位置，即汇总数据库中的结构化数据和来自湖泊的非结构化数据。

您的决定似乎与您是否应该使用云有关。如果您需要云的弹性和可扩展功能，那么Azure数据工厂就是将数据从一个地方移动到另一个地方的工具。

HTH

Answer 2

小心点。这个问题很可能因为过于宽泛而被关闭。

有许多论据支持和反对。我们不能在这里讨论它们。

ADL不是SSIS的替代品。顾问一如既往地回答...... 取决于你在做什么/想做什么。

一个简单的答案可能是。 ADL无限且高度可扩展。 SSIS不是。但是，是的，由于可扩展性，ADL对小文件的入口点很高。

一般来说，我不认为这两种技术具有可比性。

如果您想在Azure中使用SSIS。等待MS将其作为PaaS发布。或者使用虚拟机。

Answer 3

我认为对于更简单的转换，它可能是一个很好的解决方案，但是如果你有复杂性，通知等，它可能是不兼容的。一个典型的场景就是将JSON文档转换为CSV，然后获取CSV并通过SSIS运行它以进行进一步的转换。肯定有一个未来的状态可以使U-SQL更强大，目前我认为U-SQL / ADLA / ADLS和SSIS有不同的独特用途。