構建企業級資料湖？Azure Data Lake Storage Gen2實戰體驗（下）
相較傳統的重量級OLAP資料倉庫，“資料湖”以其資料體量大、綜合成本低、支援非結構化資料、查詢靈活多變等特點，受到越來越多企業的青睞，逐漸成為了現代資料平臺的核心和架構正規化。
作為微軟Azure上最新一代的資料湖服務，Data Lake Storage Gen2的釋出，將雲上資料湖的能力和體驗提升上了一個新的臺階。在前面的文章中，我們已分別介紹了其基本使用和大資料叢集掛載的場景。作為本系列的下篇，讓我們繼續深度體驗之旅。
ADLS Gen2體驗：資料湖共享
在企業中，一個龐大的資料湖往往需要被共享。比如資料湖通常會被劃分為多個區域，這些區域最好能夠被各自對應的計算叢集所訪問以進行不同的計算任務。這也充分體現了計算儲存分離的理念，是雲端計算的架構精髓。那麼ADLS Gen2能否支援這一重要場景呢？
答案是肯定的。對於各計算叢集而言，不妨淡化它自己的“本地”儲存，轉為考慮叢集是否能夠讀取訪問遠端的資料湖例項——在這樣的思路下，就可以設立一個統一而獨立的資料湖例項，被多個計算叢集共享，同時按目錄進行許可權設定和資料隔離。資料湖的生命週期可獨立於計算叢集的建立和銷燬，在需要時作為外部資料被引用和訪問就可以了。
接下來我們以前篇文章建立的HDInsight Spark叢集為例，繼續資料湖共享的實戰驗證。微軟的一段文件告訴了我們如何讓HDInsight叢集訪問“外部”的ADLS Gen2：
To add a secondary Data Lake Storage Gen2 account, at the storage account level, simply assign the managed identity created earlier to the new Data Lake Storage Gen2 storage account that you wish to add.
https://docs.microsoft.com/en-us/azure/hdinsight/hdinsight-hadoop-use-data-lake-storage-gen2
看起來頗為容易，只需要將代表叢集的identity賦予相應的ADLS Gen2許可權即可。注意這裡的許可權粒度事實上可以設定得非常細緻，精確到目錄乃至檔案層級，這正是我們需要的。
接下來我們來構建和實驗這樣一個常見的重要場景：原始資料位於資料湖的區域一中，由叢集1的spark程式來進行處理，並將處理後的資料落地到同一資料湖的區域二中；叢集2則利用hive來對區域二中的處理後資料進行查詢。注意這裡由於計算儲存進行了分離，資料處理和查詢叢集都可以是無狀態的，無工作負載時可以關閉，也能夠隨時建立或橫向擴充套件。
我們先來準備共享資料湖，在系列上篇中已經建立的儲存賬號cloudpickerdlg2中新建一個檔案系統datalakefs-shared用於共享資料。隨後在其中分別建立zone-rawdata和zone-processed兩個資料夾，並在zone-rawdata資料夾中存放入前面使用過的小說《雙城記》文字檔案ATaleOfTwoCities.txt：
接下來，為使Spark叢集順利訪問這個中央資料湖中的資料，我們只需對之前建立的spark-cluster-identity分別對兩個資料夾進行授權。這裡為zone-rawdata賦予讀許可權，對於zone-processed賦予讀寫許可權：
隨後，我們就可以複用系列中篇裡的Spark叢集來訪問這個遠端的資料湖了。再次祭出Jupyter Notebook進行資料處理，並將Spark的處理結果以parquet形式寫入zone-processed：
val domain = "abfss://[email protected]/" val book = spark.sparkContext.textFile(domain + "zone-rawdata/ATaleOfTwoCities.txt") val wordCounts = book.flatMap(l => l.split(" ")).map(w => (w, 1)).reduceByKey((a,b) => a+b).map( { case (w, c) => (w, c, w.length) } ) val wordCountsWithSchema = spark.createDataFrame(wordCounts).toDF("word", "count", "word_length") wordCountsWithSchema.write.parquet(domain + "zone-processed/ATaleOfTwoCities.parq")
執行之後可以看到，結果集parquet檔案已經位於zone-processed中了。
接下來我們進行考慮查詢資料湖的部分，可以建立一個獨立的Hive查詢叢集並指向資料湖上的處理結果。在Azure上有一個專門為高效能線上查詢優化的HDInsight大資料叢集型別，被稱為Interactive Query，其中使用了Hive LLAP，很適合我們的場景。我們不妨就部署它作為查詢叢集。
在此我們略去建立Hive LLAP叢集的詳細過程，其步驟與建立Spark叢集類似，按照Wizard的提示逐步選取即可。需要注意的是，我們也相應地需要為查詢者建立一個對應的身份hive-cluster-identity，並將這個hive-cluster-identity設定為查詢叢集的身份。
在共享資料湖datalakefs-shared方面無需和查詢叢集發生直接關聯，只要把待讀取的路徑(zone-processed資料夾)向hive-cluster-identity開放讀取許可權即可：
然後就可以在Hive叢集上用SQL來進行資料湖查詢了：
--建立外部表指向資料湖中parquet資料
create external table WordsOnDataLake(
word string,
count int,
word_length int
) STORED AS PARQUET
LOCATION 'abfss://[email protected]/zone-processed/ATaleOfTwoCities.parq';
-- 立刻就能直接查詢資料湖上資料，例如按單詞長度分組聚合統計
select word_length, sum(count) as total_count from WordsOnDataLake
group by word_length
order by total_count desc
limit 10;
最後順利地跑出了結果：
+--------------+--------------+--+ | word_length | total_count | +--------------+--------------+--+ | 3 | 31667 | | 4 | 24053 | | 2 | 22800 | | 5 | 15942 | | 6 | 12133 | | 7 | 9624 | | 8 | 6791 | | 9 | 4716 | | 1 | 4434 | | 0 | 4377 | +--------------+--------------+--+ 10 rows selected (4.295 seconds)
可以看到Hive LLAP順利地讀取了遠端資料湖的資料，而且速度頗為可觀，數秒內就返回了結果。如果關閉LLAP模式而採用傳統方式執行（將hive.llap.execution.mode設為none），筆者實驗下來同樣的查詢需要25秒左右才能完成。
在實際場景中，Hive LLAP叢集可以始終保持線上，以便應對隨時到來的查詢請求；而負責ETL的Spark叢集則可按需啟動，計算任務完成後關閉。這樣的設計既充分利用了共享資料湖的架構，也體現了雲端按需伸縮啟停的特點。
總結
資料湖是近年流行的架構思維，有助於提高資料服務能力的靈活性，也為企業跨領域統一大資料平臺的構建提供了指導正規化和落地支撐。
因此，公有云巨頭們紛紛為資料湖構建提供及增強了對應的產品線，本系列文章聚焦的Azure Data Lakge Storege Gen2即是其中傑出代表。通過三篇文章的層層深入，我們既分析了產品功能，又結合應用場景進行了POC驗證。實踐證明，ADLS Gen2能夠成為構建企業級資料湖的堅實基礎和可靠保障。
最後，我們使用一張架構圖來作為全文的收束，它很好地總結了ADLS Gen2的能力、定位及與周邊系統的關係：
（圖片來自https://www.blue-granite.com/blog/10-things-to-know-about-azure-data-lake-storage-gen2）
從現在開始，就請考慮利用ADLS Gen2和相關配套雲服務，來構建你自己的資料湖吧！
相關文章：
構建企業級資料湖？Azure Data Lake Storage Gen2實戰體驗（上）
構建企業級資料湖？Azure Data Lake Storage Gen2實戰體驗（中）
“雲間拾遺”專注於從使用者視角介紹雲端計算產品與技術，堅持以實操體驗為核心輸出內容，同時結合產品邏輯對應用場景進行深度解讀。歡迎掃描下方二維碼關注“雲間拾遺”微信公眾號。
&n