使用Azure数据湖分析方法与传统ETL方法比较的原因

Question

我正在考虑使用数据湖技术，最近几周我一直在研究这些技术，与我多年来一直在使用的传统ETL方案相比。

我认为data是与大数据非常相关的东西，但是使用Data技术与SSIS之间的界线在哪里呢？

使用25 Is ~100 Is~300 Is文件的数据湖技术有什么优势吗？平行？灵活性？将来还可以扩展吗？当要加载的文件没有U最好的场景那么大时，性能是否有提高.

你的想法是什么？就像用锤子敲螺母一样吗？请不要犹豫地问我任何问题来澄清情况。提前谢谢！！

21/03编辑更多说明：

1. 一定是在云端
2. 我之所以考虑使用ADL，是因为云中没有SSIS的替代。有ADF，但不一样，它编排数据，但不像SSIS那么灵活
3. 我想我可以使用use进行一些(基本的)转换，但是我看到了一些问题-- 。
   • 有许多基本的事情我不能做:循环，更新，用SQL写日志.
   • 输出只能是U表或文件。这样的架构看起来不太好(尽管U-SQL对于大文件非常好，如果我需要额外的步骤将文件导出到另一个DB或DWH) --或者这就是在大数据仓库中实现的方式.我不知道
   • 在我的测试中，1MB文件需要40,500 my文件需要1:15。我不能为1MB的40多个进程辩护(加上用ADF上传到数据库/数据仓库)
   • 对于用户来说，代码看起来是没有组织的，因为具有许多基本验证的脚本将是user脚本太长。

​

不要误解我的意思，我真的很喜欢ADL技术，但我认为，就目前而言，它是针对一些非常具体的东西，而且在云中仍然没有SSIS的替代品。你是怎么回事？我说错了吗？

Answer 1

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

1. 在VM (IaaS)普通Server上运行于VM上的Server，您必须自己安装、配置和管理它，但您可以获得产品的全部灵活性。
2. Azure数据库选项以较小的卷为目标，但现在达到4TB。具有潜在较低TCO的普通Server的所有特性，以及使用层层进行向上或向下扩展的选项。
3. 适用于大型仓库的Azure SQL数据仓库(ADW) MPP产品。对我来说，进入标准是仓库的大小至少是1TB，可能更像10 1TB。小容量的MPP实在不值得。

对于所有数据库选项，您可以使用聚集列存储索引(ADW中的缺省值)，这可以提供5x到10x之间的大量压缩。

每年每天400 TB的总容量为143 TB，这在现代数据仓库中并不算多，通常以TB来衡量。

Azure (ADLA)出现的地方，是做一些在普通SQL中无法做的事情，比如：

• 结合C#和SQL的强大查询功能-示例这里
• 处理非结构化文件，如图像、xml或JSON -示例这里
• 使用RegEx
• 扩展R处理-示例这里

ADLA还提供联邦查询功能，即将数据库中的结构化数据和湖中的非结构化数据结合在一起。

您的决定似乎更多地取决于您是否应该使用云。如果您需要云的弹性和可伸缩特性，则Azure Data是将数据从云中移到另一个位置的工具。

HTH

Answer 2

注意。这个问题可能会因为过于宽泛而被关闭。

有许多赞成和反对的论点。我们不能在这里讨论他们。

ADL不是SSIS的替代品。顾问的回答将一如既往。它取决于你在做什么/试图做什么。

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

一般来说，我不认为这两种技术是可比的。

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

Answer 3

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