使用Azure Data Lake Analytics與傳統ETL方法的原因

Question

與傳統的ETL SSIS場景相比，我正在考慮使用我一直在研究最新周的Data Lake技術，這與我一直在努力的多年。

我認爲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對大文件非常好，如果我需要額外的步驟將文件導出到另一個數據庫或DWH） - 或者這可能是在大數據倉庫中完成的方式...我不知道
   • 在我的測試中，1MB文件需要40s，500MB文件需要1s15s。我不能證明1MB的40s進程（加上使用ADF上傳到數據庫/數據倉庫）
   • 代碼對於用戶來說看起來沒有組織，因爲具有許多基本驗證的腳本將是U-SQL腳本太長。

不要誤會我的意思，我真的很喜歡ADL techonologies，但我認爲，就目前而言，它是一件很具體，還有在雲中沒有替代SSIS。你有什麼事？我錯了嗎？

Answer 1

要小心。這個問題很可能因太寬泛而關閉。

有許多爭論和反對。我們無法在這裏討論他們。

ADL不是SSIS的替代品。顧問回答如往常一樣.. 它取決於你在做什麼/試圖做什麼。

一個簡單的答案可能是。 ADL是無限的，高度可擴展的。 SSIS不是。但是，是的，由於這種可擴展性，ADL對小文件具有很高的入口點。

通常我不認爲這兩種技術具有可比性。

如果你想在Azure中使用SSIS。等待MS將其作爲PaaS發佈。或者使用虛擬機。

Answer 2

我認爲對於更簡單的轉換，它可能是一個好的解決方案，但是如果你有複雜性，通知等，它可能是不兼容的。一個典型的場景就像是將JSON文檔轉換爲CSV，然後取得CSV並通過SSIS運行以進一步轉換。毫無疑問，未來的狀態將使U-SQL變得更強大，因爲現在我認爲U-SQL/ADLA/ADLS和SSIS有單獨和獨特的用途。

Answer 3

對我來說，如果數據是高度結構化和關係型的，那麼它的正確位置就是關係型數據庫。在Azure中，你有幾種選擇：在虛擬機（IaaS的）

1. SQL服務器 普通SQL Server上的虛擬機上運行，​​您必須安裝，配置和管理自己，但你的產品的充分的靈活性。
2. Azure SQL數據庫 PaaS數據庫選項針對的是較小的卷，但現在達到4TB。正常SQL Server的所有功能可能具有較低的TCO，並且可以使用tiers進行擴展或縮小。
3. Azure SQL數據倉庫（ADW） 適用於大型倉庫的MPP產品。對我而言，入口標準是倉庫至少1TB，可能更像10TB。小批量生產MPP是不值得的。

對於所有數據庫選項，您可以使用羣集列存儲索引（ADW中的默認值），它可以提供5倍和10倍之間的大規模壓縮。

一年400MB的總計〜143GB，這在現代數據倉庫條款中並不算太多，通常以兆兆字節（TB）爲單位。

凡Azure的數據湖分析（ADLA）到來時，正在做的事情，你不能在普通的SQL做的，如：

• 結合了C＃的功能與SQL的功能強大的查詢 - 例如here
• 交易非結構化的文件等的圖像，XML或JSON - 使用RegEx
• 尺度的R處理示例here
• - 例如here

ADLA還提供聯合查詢，可以「查詢數據在哪裏生活」，即將來自數據庫的結構化數據和來自您的湖泊的非結構化數據彙集在一起​​。

您的決定似乎與您是否應該使用雲有關。如果您需要雲的彈性和可擴展功能，那麼Azure Data Factory是將雲中的數據從一個地方移動到另一個地方的工具。

HTH