相較傳統的重量級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實戰體驗（中）
“云間拾遺”專注于從用戶視角介紹云計算產品與技術，堅持以實操體驗為核心輸出內容，同時結合產品邏輯對應用場景進行深度解讀，歡迎掃描下方二維碼關注“云間拾遺”微信公眾號，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/57224.html
標籤：其他
上一篇：Flow-3d安裝問題請教