5月12日，信服雲大資料研發技術專家Cody在信服雲《Tech Talk · 雲技術有話聊》系列直播課上分享了 **《基於低程式碼的資料開發》** ，詳細介紹了低程式碼平臺如何提升使用者的資料開發效率，傳統的資料倉儲、實時計算開發、離線計算開發場景面臨的挑戰和解決方案，以及信服雲大資料在安全日誌分析、資料倉儲方面的資料開發經驗等內容。以下是他分享的內容摘要，想要了解更多可以關注“深信服科技”公眾號觀看直播回放。

**一、Studio架構和定位**

aBDI-Studio是基於aBDI-Base基礎平臺，以資料作為經營物件，提供全面的資料開發、資料管控、資料交換、資料應用能力，打造全生命週期的智慧開發平臺，**透過該平臺，可以將低價值資料，加工成高價值資料產品和服務**。

Studio 包括資料整合、任務排程、資料服務、資料治理、許可權運維、探索開發。其中，探索開發包括流資料的開發、融合數倉的開發、離線資料的開發、綜合檢索開發等四大部分。探索開發關係到平臺的開發效率，也是本次直播的重點內容。

![image.png](https://p1-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/aeacc1c956a64d2fba146c884ba62c09~tplv-k3u1fbpfcp-watermark.image?)

aBDI 產品包含兩大部分，一部分是底層 base 平臺，一部分是上層低程式碼開發平臺Studio。Studio 在 aBDI 產品架構中位於上面應用層，其功能主要集中在資料倉儲開發、實時開發、離線開發。資料倉儲開發包含了數倉的建模、數倉的質量、源資料的管理、資料資產目錄、資料地圖和資料服務，以及資料同步。

![image.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9405cdeff201473fae85d962ca847c7a~tplv-k3u1fbpfcp-watermark.image?)

**低程式碼資料開發平臺跟傳統的資料開發不同點在於，傳統資料開發用時較長，中間環節較多。** 以業務變化為例，它要先去做一個業務的需求變化確認，再進行程式碼開發，程式碼開發完之後聯調，接著是功能測試和系統部署，最後是停機發布。這一整個流程花費時間較多，效率也不高。

低程式碼的應用場景，**一部分要實現高穩定性，滿足穩態業務開發的維護需求；同時也要保障靈活性和通用性，可以適應敏態業務快速變化的需求。**

基於低程式碼的開發可以簡化這些步驟。針對業務變化和需求確認，使用者只需要做後面的系統配置，聯調和測試是在低程式碼開發平臺直接覆蓋。低程式碼開發平臺可以說既高效又靈活，不僅節省了流程需要的時間，也不需要人力再去做任何配置。

Studio 平臺的受眾包含四類人群：在資料開發或者應用過程中，**資料開發者**可以編輯和排程開發能力，拖拽任務元件、編排業務流程，降低開發門檻，快速上手；對於**資料資產的管理人員**，可以透過實現資產的統一管理，平臺裡提供了豐富的資源管理操作功能，包括檔案的上傳、下載等；對於**運維人員**來說，透過模型的運維可以進行資料語言的接入配置管理，以及模型執行監控和異常告警，這樣可以簡化運維；對於**資料分析師**來說，平臺的資料探索提供了管道式的檢索語言，最終處理完的資料可以透過 spl 去查詢資料，比較自由靈活，遮蔽了底層，不需要感知底層那麼複雜的介面，這解決了程式設計式探索操作複雜的痛點。

**二、Studio資料倉儲開發**

傳統的大資料數倉的建設，一般都是由建模工程師提出分析使用者需求，提供數倉的建模的指標資訊，提交給開發工程師。開發工程師拿到需求之後進行編碼實現，編碼完成後，會自己去提交測試，測試工程師會根據提交的應用去測試。測試結束，應用即可釋出。釋出之後，建模工程師就去看釋出後的應用，驗證模型是否符合使用者的訴求。

![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/32136ba2d9de4ef69ae450153e3098e5~tplv-k3u1fbpfcp-watermark.image?)

**在低程式碼的開發平臺，步驟簡化成：** 數倉建模工程師會去分析使用者的需求，藉助數倉的建模平臺直接開發數倉模型，低程式碼的大資料建模平臺直接可以給建模的工程師用，可以直接在上面除錯，也不需要寫程式碼。模型釋出之後，可以直接看到輸出的結果，也不需要開發工程師介入，就直接在一個平臺上看到想要的結果，也可以驗證一下模型的輸出是否符合使用者的訴求，以及模型跑完的結果是否正確。

對比來看，傳統的數倉建設參與角色包括建模/開發工程師、測試工程師等，但Studio 只需要一個建模工程師，這樣可以減少開發成本、測試成本、以及溝通成本。同時，Studio 支援可拖拽，透過“拖拽”就可以把一個模型建好，建模週期大大縮短，由原來“天級別”到了“小時級別”。模型建完之後，按照傳統的流程需要以週期來發布，週期可能會比較久。但是Studio 上的數倉的建設，剛建立好之後，就可以直接釋出，交付週期也大大縮短。

**三、Studio實時計算開發**

傳統方式一般需要寫一段程式碼，以Flink 為例，它可能要寫到 Flink 的程式碼。在 Flink 的程式碼裡面，第一部分還要定義一個資料來源和一個資料目的。最後資料來源和目的之間，它會有個資料運算元，比如它要制定一個 map 運算元或者是 aggregate 聚合運算元或者是轉換的運算元，模型開發完之後，進行除錯。除錯之後要透過命令列的方式往資料來源中打入樣例的資料，然後提交。最後去檢視單個實時計算模型開發除錯完成的耗時，這樣的開發流程單次可能需要 8 小時。

但是在 Studio 裡面開發週期就比較短。首先它要拖一個資料來源，然後再拖兩個資料目的，中間是運算元。而資料來源只需要在介面上去配置即可，再配置觸發條件和資料目的。**這些也都可以在視覺化畫布裡面開發完之後再去配置。配置完成後還可以透過除錯模型的方式除錯，檢視資料對不對。**

![image.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/81bb89db34354cfbba76441e485ab1f0~tplv-k3u1fbpfcp-watermark.image?)

**四、Studio離線計算開發**

離線計算開發步驟包括：業務開發、資源管理、模型開發、定時管理、模型管理。

![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/7dc21cb3492d435799206648ffbec443~tplv-k3u1fbpfcp-watermark.image?)

具體來說，第一步是**模型的開發**。開發人員是要先把運算元拖拽到畫布中。第二步，**把程式和資源配置到運算元中間**。比如說要把 Spark 的應用或者Flink的應用或者一個 Python 的指令碼上傳，給應用程式執行時使用。第三步，**配置一下運算元之間的依賴關係**。這裡面的運算元端就區分處理類的運算元、流程類的運算元。當上遊的運算元執行成功之後才執行下游的運算元，在模型開發中，透過簡單拖拽即可實現。

aBDI 裡面的 Studio 離線開發，底層的技術實現跟業界的方案有些不同，**主要是增強穩定性和提高易用性。**

不同點體現在以下方面：

（1）Studio支援 HA ，去中心化的多 Master 多 Worker ；

（2）對於過載處理，當任務過多時會快取在佇列中，所有任務都執行在叢集中，不會造成伺服器卡死；

（3）不會影響正在執行的任務程式；

（4）當程式宕掉的時候，會自動會拉起；

（5）監控介面上， DAG 監控介面支援檢視任務狀態、任務型別、重試次數、任務執行機器、視覺化變數、執行時間、錯誤日誌；

（6）所有流程定義操作都是視覺化的，透過拖拽任務來繪製DAG，配置資料來源及資源。同時對於第三方系統提供API方式操作；

（7）在快速部署上，實現視覺化一鍵部署。

![image.png](https://p6-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3b53086a8fb94d9cb17b4b0a06023c8b~tplv-k3u1fbpfcp-watermark.image?)

Studio 低程式碼平臺目前主要用在如下三個場景。第一個是**感測器的資料分析**，首先由使用者去採集多個系統的感測器資料，然後聯動多個系統進行資料分析，產生告警後及時輸出告警直觀展示。使用者可以透過 Studio 去完成發現問題、資料採集、資料處理轉化、視覺化的對映、使用者感知的流程等一整套的過程。

第二個**場景是日誌分析**。平臺透過資料來源把日誌採集過來，放到訊息佇列之後透過流處理或者是離線的方式處理，之後會持續寫到 ES 裡，再基於 ES 的結果，使用者進行資料的檢索跟行為的分析或者異常分析。Studio也擅長幫助使用者處理有大量併發寫入的實時資料、資料的儲存、希望能夠實時分析以及從海量日誌中提取有價值的資料。

最後一個**場景是數倉建設**，是從資料的接入到資料的處理、再到資料模型的構建和資料的查詢，這些過程，Studio基本上都能覆蓋到。

以上就是本次直播的主要內容。對大資料低程式碼開發感興趣的IT朋友可以關注“深信服科技”公眾號回顧本期直播，瞭解更多技術內容。

Tech Talk · 雲技術有話聊 | 基於低程式碼的資料開發如何提升效率？

相關文章