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

Question

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

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

在25MB~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文件需要40秒，500MB文件需要1：15s。 我无法证明40MB的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，并且可以选择使用层扩展或缩小。
3. Azure SQL数据仓库（ADW）MPP产品适用于大型仓库。 对我来说，入门标准是至少1TB的仓库，可能更像是10TB。 小卷的MPP真的不值得。

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

一年400MB每年总计~143GB，在现代数据仓库术语中通常没有那么多，通常以兆兆字节（TB）为单位。

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

• 将C＃的强大功能与SQL相结合，实现强大的查询功能 - 例如此处
• 处理非结构化文件，如images，xml或JSON - 这里的例子
• 使用RegEx
• 扩展R处理 - 例如这里

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有各自不同的用途。