Azure Databricks大數(shù)據(jù)構(gòu)建營 小試牛刀,大數(shù)據(jù)基礎(chǔ)組件-ESG跨境

Azure Databricks大數(shù)據(jù)構(gòu)建營 小試牛刀,大數(shù)據(jù)基礎(chǔ)組件

Azure Databricks大數(shù)據(jù)構(gòu)建營 小試牛刀

看過美劇《絕命毒師》（Breaking Bad）的童鞋，恐怕都會(huì)對「老白」的化學(xué)知識和運(yùn)用這些知識的能力留下深刻印象。畢竟，生活中一些常見的物品，通過對它們的成分進(jìn)行一定組合往往能制造出很「不一般」的東西。

所以接下來你面對了一個(gè)新需求，老板要你實(shí)現(xiàn)這樣的功能：一家連鎖藥店，希望通過抽樣的方式檢查止咳糖漿的銷量，如果發(fā)現(xiàn)有人一次性購買10瓶以上就進(jìn)行實(shí)時(shí)告警。你準(zhǔn)備怎么做？

基于Azure Databricks的流計(jì)算就可以輕松實(shí)現(xiàn)。一起來看看吧。

本次《Azure Databricks大數(shù)據(jù)構(gòu)建營》系列文章，將主要圍繞Azure Databricks以及其他配套服務(wù)，通過一系列實(shí)戰(zhàn)教程告訴大家如何基于Azure云打造完全運(yùn)行在云端的閉環(huán)大數(shù)據(jù)平臺(tái)。

內(nèi)容涵蓋：Azure Databricks的基礎(chǔ)知識，以及如何借助Azure Databricks實(shí)現(xiàn)流計(jì)算（Structure Streaming）、批處理（Spark SQL）、安全訪問控制以及機(jī)器學(xué)習(xí)能力等。

本系列的第一篇文章概括介紹了有關(guān)Azure Databricks的基礎(chǔ)知識，錯(cuò)過的童鞋可以點(diǎn)擊這里回看。而本篇，將帶領(lǐng)大家小試牛刀，基于Azure Databricks開發(fā)上文提到的那種實(shí)時(shí)告警系統(tǒng)。準(zhǔn)備好，我們這就開始。

流計(jì)算架構(gòu)說明

本篇涉及到的服務(wù)全都部署在中國區(qū)Azure上。根據(jù)模擬場景的描述，首先我們可以設(shè)計(jì)出如下所示的架構(gòu)：

該解決方案將用到如下的產(chǎn)品和服務(wù)：

Azure虛擬機(jī)：作為數(shù)據(jù)源，扮演Producer生產(chǎn)者，通過Python代碼模擬客戶購買行為，生成示例數(shù)據(jù)并通過SDK發(fā)快遞數(shù)據(jù)到Azure EventHub。

Azure EventHub：消息隊(duì)列，做上下游生產(chǎn)者消費(fèi)者服務(wù)的解耦，Entity ingestion負(fù)責(zé)接收Producer發(fā)快遞的數(shù)據(jù)，Entity alerting接收經(jīng)過Databricks實(shí)時(shí)計(jì)算后的數(shù)據(jù)。

Azure Databricks：訂閱EventHub Entity ingestion作為數(shù)據(jù)源，通過Structure Streaming對數(shù)據(jù)進(jìn)行實(shí)時(shí)處理后發(fā)快遞給Entity alerting。

Azure LogicApp：訂閱EventHub Entity alerting并做郵件實(shí)時(shí)告警。

完整過程中的數(shù)據(jù)流是這樣的：

1.Producer生產(chǎn)者發(fā)快遞數(shù)據(jù)

2.EventHub Entity ingestion（Ingestion實(shí)體）

3.Databricks Structured Streaming（流計(jì)算框架）

4.EventHub Entity alerting（Alerting實(shí)體）

5.Logic App

Azure Databrick Structure Streaming的實(shí)現(xiàn)

1.Terraform自動(dòng)化部署

通過Terraform部署的服務(wù)組件包括Azure虛擬機(jī)、Azure Databricks、EventHub、Logic App，具體的tf文件和變量可參見這里。每項(xiàng)服務(wù)Terraform Azure Provider都由Resource支持，具體可參考官方文檔。部署完成后的資源清單如下圖所示，所有資源都部署在中國北二區(qū)域。

2.Producer代碼發(fā)布

模擬的生產(chǎn)者代碼通過虛擬機(jī)發(fā)布，通過調(diào)用Azure EventHub的SDK將消息寫入，具體代碼可見這里，幾個(gè)重要配置簡單說明下：

azure.eventhub：Azure EventHub SDK包，需要通過pip3 install azure.eventhub來指定安裝。

create_batch()：通過該方法批量發(fā)快遞數(shù)據(jù)，本次示例以1條消息為1個(gè)批次發(fā)國際快遞EventHub Entity ingestion。

CONNECTION_STR：Azure EventHub Endpoint，該連接字符串可以在門戶上Shared access policies的Connection string–primary key中查看。

EVENTHUB_NAME：寫入的EventHub Entity Name。

3.Azure Databricks集群配置及Structure Streaming Notebook的集成

Azure Databricks的創(chuàng)建過程是：首先在Azure上創(chuàng)建一個(gè)Databricks實(shí)體，然后在此基礎(chǔ)上在實(shí)體內(nèi)部創(chuàng)建Workspace以及Cluster，再提交Job。每個(gè)Databricks資源都有唯一的ID和Endpoint與之對應(yīng)，以便能夠進(jìn)行Restful API調(diào)用，集群通過Databricks門戶創(chuàng)建即可。

本示例將創(chuàng)建1個(gè)Driver和2個(gè)Worker，共計(jì)3個(gè)節(jié)點(diǎn)的Standard Cluster，Databricks版本為6.4（包含Apache Spark 2.4.5、Scala 2.11）。如果需要做機(jī)器學(xué)習(xí)相關(guān)計(jì)算，可啟用集成GPU/ML框架的版本，詳細(xì)說明見官方文檔，這里不做贅述。

集群狀態(tài)變?yōu)镽unning就意味著就緒可以使用了。不過在導(dǎo)入Python Notebook之前，需要通過Maven Central安裝com.microsoft.azure:azureeventhubsspark庫文件，以便安裝Spark連接Azure EventHub Connector，需要注意庫文件的版本要匹配。

Notebook可以直接在門戶里新建寫入，也可以在VS Code等IDE中編寫完之后發(fā)布。本文采用第二種模式，原因是IDE豐富的插件可以提高效率。具體的Notebook本文不做展示，放在這里，有需要的童鞋可以自行查看。通過import導(dǎo)入后，附上導(dǎo)入后的截圖并做幾點(diǎn)說明：

整個(gè)Notebook分為三個(gè)階段：

第一階段：從EventHub Entity ingestion讀取Producer寫入的數(shù)據(jù)，通過Streaming DataFrames的spark.readStream()創(chuàng)建。

第二階段：通過DataFrame豐富的函數(shù)做字段篩選，篩選出來我們需要的字段。

第三階段：回寫EventHub Entity alerting，通過Streaming DataFrames的spark.writeStream()流式寫入，注意利用Checkpoint方便任務(wù)終止再運(yùn)行。

當(dāng)Producer運(yùn)行起來后，EventHub就會(huì)不斷有數(shù)據(jù)寫入，所以能看到Spark的Input Records圖像。對于每一個(gè)Job，都能看到對于該任務(wù)分配的資源和Spark參數(shù)配置項(xiàng)。

4.Logic APP配置郵件告警

經(jīng)過Azure Databricks的數(shù)據(jù)篩選后，篩選出來的Messages都寫入了EventHub Entity alerting中，此時(shí)通過LogicApp來定義一個(gè)自動(dòng)化的工作流來進(jìn)行郵件告警。具體創(chuàng)建過程選擇Blank，然后自己創(chuàng)建Step即可，當(dāng)然Azure門戶上的示例模板也可以用來參考，如下圖所示：

第一步訂閱EventHub Entity alerting，第二步集成Outlook郵件接口發(fā)快遞告警郵件。所以當(dāng)目標(biāo)消息被篩選出來之后，LogicApp就按照定義的郵件內(nèi)容（本文是消息內(nèi)容和時(shí)間戳）來發(fā)快遞郵件，發(fā)快遞郵件的截圖如下：

總結(jié)

總體上，一個(gè)通過消息隊(duì)列Azure EventHub以及Databricks做流計(jì)算處理的示例就完成了。

如果消息生產(chǎn)者Producer不斷產(chǎn)生消息，那么整個(gè)任務(wù)就會(huì)一直運(yùn)行下去，當(dāng)出現(xiàn)目標(biāo)消息的時(shí)候就會(huì)不斷的持續(xù)告警。在Spark推出Structure Streaming后，也解決了Spark Streaming micro batch的局限性。

本文開頭提及的需求已經(jīng)順利實(shí)現(xiàn)！

有關(guān)如何借助Azure Databricks實(shí)現(xiàn)流計(jì)算（Structure Streaming）的內(nèi)容就是這些了。隨后的內(nèi)容中，我們還將介紹如何實(shí)現(xiàn)批處理（Spark SQL）、安全訪問控制和機(jī)器學(xué)習(xí)能力。通過這些真實(shí)場景中的最佳實(shí)踐分享，也能幫助大家更清楚地認(rèn)識到Azure Databricks的價(jià)值。敬請期待！

特別聲明：以上文章內(nèi)容僅代表作者本人觀點(diǎn)，不代表ESG跨境電商觀點(diǎn)或立場。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。