#Wormhole# 流式處理平台設計思想

05-25

來自專欄敏捷大數據

作者：趙平
編輯於：2018-05-24

互聯網的迅猛發展使得數據不再昂貴，而如何從數據中更快速獲取價值變得日益重要，因此，數據實時化成為了一個大趨勢。越來越多的業務場景需要實時分析，以極低的延遲來分析實時數據並給出分析結果，從而提高業務效率，帶來更高價值。流式處理作為實時處理的一種重要手段，正在因數據實時化的發展而蓬勃發展。本文是敏捷大數據（Agile BigData）背景下的實時流式處理平台Wormhole的開篇介紹。Wormhole具體是一個怎樣的平台呢？一起來看一下吧！

一、Wormhole背景介紹

在流式計算領域，越來越多成熟的技術框架出現在開源世界，如Storm、Heron、Spark、Samza、Flink、Beam等。流式技術也逐步進化發展，支持流上豐富計算語法（類SQL）、支持at least once或exactly once語義、支持高可靠高可用、支持高吞吐低延遲、支持基於事件時間計算、支持統一整合接入抽象等，這些都從不可能變為可能。

然而，雖然流式處理的技術已經很豐富，流式處理在企業中的實施仍然存在較大難度，主要原因是成本高，需求上線周期長等，而產生這樣問題的原因又分兩個方面，一是企業組織結構，二是技術。

傳統數據倉庫和BI的組織結構都是集中相關技術人員成立獨立大數據部門，各個業務部門向其提需求，做定製化開發。

企業組織結構

如上圖，大數據部門不僅僅做大數據環境運維，還做定製化開發和線上業務維護。恰恰這兩點會消耗大量的人力，也增加了管理和溝通成本。舉一個需求開發的例子，如下圖：

需求開發流程

上圖是企業普遍使用的一個開發流程，這裡邊就反應出一些問題：

人力成本高

從此圖可以看出，至少需要3個角色的人員才能完成一個需求，而且流式開發人員要花很多時間了解需求、業務、表結構等等

上線周期長、效率低

所有需求都是由產品人員提出，由業務人員分析，然後與流式開發人員一起設計開發完成，且需要大量時間測試及驗證結果

復用低

在需求中，有很多業務是類似的，但因業務和定製化問題，所以無法很好的做到代碼復用，導致重複開發比較多

業務維護成本高

當上線的需求有變化時，就要在原有代碼的基礎上改造，流式處理開發人員也需要再一次了解業務流程、表結構等等，還是需要很多的人力資源，並且周期也很長，同時改動會增加出問題的概率

大量消耗資源

為了功能隔離和降低維護難度，每個定製化功能都要啟動一個流式應用，無法復用，需要佔用大量硬體資源

目前流式處理的種種問題很大的制約了企業實時大數據的發展，各個公司都在尋找一條更輕量的解決之道。我們根據多年在實時大數據項目中的實踐和經驗積累，自主研發了流式處理平台——Wormhole，很大程度上解決了上述各類問題。下面我們來介紹一下Wormhole的具體情況。

二、Wormhole是什麼

Wormhole是一個面向實時大數據項目實施者的流式處理平台，致力於統一併簡化大數據開發和管理，尤其針對典型流式實時/准實時數據處理應用場景，屏蔽了底層技術細節，提供了極低的開發門檻。項目實施者只需簡單配置及編寫SQL即可支持大部分業務場景，使得大數據業務系統開發和管理變得更加輕量、可控可靠。

Wormhole數據處理樣例

Wormhole主要基於Spark技術，實現了基於SQL的流上數據處理和異構系統冪等寫入等相關功能。如上圖所示，Wormhole接入流上的數據，然後將數據中的出生日期通過用戶編寫的SQL處理為年齡，寫入到另外一個存儲系統中。

Wormhole通過技術手段實現基於SQL的流式處理方案，大大降低了流式處理的技術門檻；同時通過平台化和可視化等實現了職能的變化，減少了整個需求生命周期的參與角色數量，精鍊了整個開發過程，進而縮短了開發周期，也減少了開發和維護成本。

三、Wormhole設計目標

基於敏捷大數據的思想，Wormhole的設計目標如下：

平台化/組件化
通過平台化支持，組件化組裝實施，可以快速對原型進行驗證，和需求方形成反饋閉環快速迭代
標準化
對數據格式進行標準化，達到通用效果，減少數據格式化和維護的成本
配置化/可視化
用戶可視化配置、部署、管理、監控，降低大數據產品開發門檻，確保高質量產出
低延遲/高性能/高可用
根據實時性的要求，流式處理要求更低的延遲，並且要求更高的吞吐量，以及容錯能力，保證系統7*24正常運行
自助化/自動化
讓企業從數據中心化轉型為平台服務化，讓每個數據從業者都能夠有更多的自助服務，並釋放數據處理能力，系統替代人工完成重複低級的工作，讓從業者回歸數據和業務本質

2. Wormhole平台的建設帶來的效果主要體現在以下幾方面：

組織結構更合理：
如下圖，大數據相關部門不再做定製化開發和業務維護，而是更專註平台化和大數據環境的穩定，大大減少了人力資源的浪費

基於Wormhole的組織結構

降低了流式處理開發的技術門檻：
流式處理的開發模式變為了業務人員通過可視化配置和編寫SQL即可完成80%以上的業務場景，不再需要對流式處理技術有很深的理解
縮短了需求上線周期：
如下圖所示，一個需求從提出到上線只需要產品人員和業務人員，大幅降低了溝通和學習成本，進而大大縮短了需求開發上線周期。

基於Wormhole的需求開發流程

四、Wormhole設計規範

Wormhole流程設計圖

上圖是Wormhole的一個設計介紹，體現了流式處理的從輸入到輸出的過程，在這個過程中，Wormhole定義新的概念，將整個流式處理進行了標準化，將定製化的流式計算變為標準化的流式處理，並從三個緯度進行了高度抽象。

統一數據邏輯表命名空間——Namespace

Namespace：數據的「IP」，通過7層結構唯一定位數據對應的物理位置，即

[Data System].[Instance].[Database].[Table].[Table Version]. [Database Partition].[Table Partition]

2. 統一通用流消息協議——UMS

UMS是Wormhole定義的流消息協議規範
UMS試圖抽象統一所有結構化消息
UMS自身攜帶結構化數據Schema信息，方便數據處理
UMS支持每一個消息中存在一份Schema信息及多條數據信息，這樣，在存在多條數據時可以降低數據大小，提高處理效率

說明：

protocol-type目前支持data_increment_data（增量數據）和data_initial_data（初始化全量數據）
schema-namespace指定數據對應的namespace
schema-fields描述每個欄位的名稱、類型、是否可空。ums_id_代表記錄id，要求保證遞增；ums_op_代表數據操作（i：插入；u：更新；d：刪除）；ums_ts_代表數據更新時間
payload-tuple指一條記錄的內容，與schema-fields一一對應

註：在Wormhole_v0.4.0版本後，應社區需求，支持用戶自定義半結構化JSON格式

3. 統一數據計算邏輯管道——Flow

Flow是Wormhole抽象的流式處理邏輯管道
Flow由Source Namespace、Sink Namespace和處理邏輯構成
Flow支持UMS和自定義JSON兩種消息協議
Flow支持Event和Revision兩種Sink寫入模式
Flow統一計算邏輯標準（SQL/UDF/介面擴展）

說明：

Flow

上圖中藍色框和箭頭組成了一個Flow，首先從TopicA中讀取Namespace1 (SourceNamespace)的數據，數據協議為UMS或者自定義JSON，然後處理用戶配置好的數據處理邏輯，輸出到Namespace2 (SinkNameSpace)對應的數據系統中，寫入支持insertOnly和冪等（對同key且不同狀態的數據保證最終一致性）。

作為一個實時大數據流式處理平台，Wormhole的設計目標和設計規範最終都是為流上處理數據而服務。本篇為Wormhole的具體功能做鋪墊，下篇系列文章我們將為大家介紹Wormhole的具體功能。

更多內容，請移步「敏捷大數據」官方微信公眾號：

搜索「ABD-STACK」或「敏捷大數據」，點擊關注。