2017-10-16 130 views
3

我認爲使用數據湖與數據倉庫的關鍵在於將ETL(提取,轉換,加載)過程轉換爲LET(加載,提取,轉換)。不提取這些數據,將其轉換並加載到表格中讓我們回到我們開始的地方?數據湖中的表格有什麼意義?

回答

4

恕我直言,數據湖的一點是存儲所有類型的數據:非結構化,半結構化和結構化。 Azure版本是Azure Data Lake Store(ADLS),其主要功能是可擴展的大容量存儲。

另外,還有一個產品Azure Data Lake Analytics(ADLA)。此分析產品可以與ADLS交互,但也可以在虛擬機(IaaS)和兩個PaaS數據庫產品,SQL數據庫和SQL數據倉庫以及HDInsight上使用blob存儲,SQL。它具有強大的批處理語言,稱爲U-SQL,SQL和.net的組合用於查詢和操作這些數據存儲。它還有一個數據庫選項,可以在適當的情況下存儲以表格格式處理的數據。

一個例子可能是你的湖中有一些非結構化數據,你運行你的批輸出並想存儲結構化的中間輸出。這是您可以將輸出存儲在ADLA數據庫表中的位置。我傾向於用它們來證明我可以從中獲得性能提升,並且/或者想要利用不同的索引選項。

我不傾向於將這些視爲倉庫表,因爲它們尚未與其他產品良好交互,即它們還沒有端點/不可見,例如Azure Data Factory無法移動從那裏桌子呢。

最後,我傾向於認爲ADLS與HDFS和U-SQL/ADLA類似,類似於Spark。

HTH

1

通過定義一個數據湖是一個巨大的庫中存儲的原始數據,在它的原生格式,直到需要。湖泊使用平坦的建築而不是嵌套(http://searchaws.techtarget.com/definition/data-lake)。湖中的數據具有唯一的ID和元數據標籤,用於查詢。

因此,數據湖泊可以存儲結構化,半結構化和非結構化數據。結構化數據將包含具有行和列的表中的SQL數據庫類型數據。半結構化將是CSV文件等。而非結構化數據就是一切 - 電子郵件,PDF,視頻,二進制文件。這就是ID和元數據標籤,可以幫助用戶在湖中找到數據。

爲了保持數據湖的可管理性,成功的實施者定期輪換,歸檔或清除湖中的數據。否則,它就成了一些人所說的「數據沼澤」,基本上就是數據的墳墓。

傳統的ELT過程更適合數據倉庫,因爲它們更加結構化,倉庫中的數據就是爲了某種目的。數據湖泊結構較少,更適合ELT(Extract,Load,Transform)等其他方法,因爲它們存儲的原始數據僅由每個查詢分類。 (關於ELT與ETL的討論,請參閱Panopoly的article)。例如,您希望查看2010年的客戶數據。當您查詢數據湖時,您將從2010年起獲得來自會計數據,CRM記錄甚至電子郵件的所有內容。在數據轉換成公用分母爲客戶+ 2010的可用格式之前,您無法分析這些數據。

0

對我來說,答案是「錢」,「資源」
(也許相關使用Excel消費數據:))

我已經經歷了幾個遷移從RDBMS到Hadoop的/ Azure的平臺,並把它歸結爲成本/預算和用例:

1)端口舊版報告系統,新的架構

終端用戶

2)技能誰將會消耗數據來驅動商業價值

3)數據的類型是由最終用戶處理

4)支持人員誰將支持最終用戶

5)是否遷移的目的是降低基礎設施支持成本,或啓用的技能組新功能。

幾以上的更多的細節:

舊版報告系統通常或者基於一些分析軟件或自行開發的系統,隨着時間的推移,有乾淨的根深蒂固的期望,支配,層次分明,強烈型數據。經常切換出後端系統需要發佈完全相同的結構,以避免更換整個分析解決方案和代碼庫。

技能是首要關注的問題爲好,因爲你經常談論的數百到數千人的誰是用來使用Excel,有一些知道SQL。很少有最終用戶,以我的經驗,很少有分析師我已經與曾知道如何編程。統計人員和數據工程師傾向於R/Python。擁有Java/C#經驗的開發人員傾向於使用Scala/Python。

數據類型是什麼工具是正確的工作一個夾子......但在這裏,你有一個大的衝突,因爲還有誰瞭解如何與「數據矩形」(例如dataframes /表格數據)工作的人,以及那些知道如何使用其他格式的人。不過,我仍然覺得人一貫只要他們需要得到一個結果操作性轉向半結構化/二/非結構化數據到一個表......因爲支持是很難找到的火花。