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

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

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

你的想法是什么？是不是用锤子敲打坚果？
请不要犹豫,问我任何问题,以澄清情况.
提前致谢！！

21/03编辑
更多说明：

>必须在云端
>我考虑使用ADL的原因是因为云中没有替代SSIS.有ADF,但它不一样,它编排数据,但它不像SSIS那么灵活
>我以为我可以使用U-SQL进行某些(基本)转换,但我看到了一些问题

>我不能做很多基本的事情：循环,更新,在SQL中写日志……
>输出只能是U-SQL表或文件.这种架构看起来不太好(尽管U-SQL非常适合大文件,如果我需要一个额外的步骤将文件导出到另一个DB或DWH) – 或许这就是在大数据仓库中完成的方式… 我不知道
>在我的测试中,1MB文件需要40秒,500MB文件需要1：15秒.我无法证明40MB的1MB进程(加上使用ADF上传到数据库/数据仓库)
>对于用户来说代码看起来没有组织,因为具有许多基本验证的脚本将是U-SQL脚本太长.

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

解决方法

> VM上的SQL Server(IaaS)
在VM上运行的普通SQL Server,您必须自己安装,配置和管理它,但您可以获得产品的完全灵活性.
> Azure SQL数据库
PaaS数据库选项的目标是较小的卷,但现在高达4TB.普通SQL Server的所有功能都可能具有较低的TCO,并且可以选择使用tiers进行扩展或缩小.
> 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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!