Wormhole 大數據流式處理平臺之設計思想

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

開源地址：https://github.com/edp963/wormhole

1、Wormhole背景介紹

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

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

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

（企業組織結構）

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

（需求開發流程）

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

• 人力成本高

今後圖能夠看出，至少須要3個角色的人員才能完成一個需求，並且流式開發人員要花不少時間瞭解需求、業務、表結構等等。

• 上線週期長、效率低

全部需求都是由產品人員提出，由業務人員分析，而後與流式開發人員一塊兒設計開發完成，且須要大量時間測試及驗證結果。

• 複用低

在需求中，有不少業務是相似的，但因業務和定製化問題，因此沒法很好的作到代碼複用，致使重複開發比較多。

• 業務維護成本高

當上線的需求有變化時，就要在原有代碼的基礎上改造，流式處理開發人員也須要再一次瞭解業務流程、表結構等等，仍是須要不少的人力資源，而且週期也很長，同時改動會增長出問題的機率。

• 大量消耗資源

爲了功能隔離和下降維護難度，每一個定製化功能都要啓動一個流式應用，沒法複用，須要佔用大量硬件資源。

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

2、Wormhole是什麼

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

（Wormhole數據處理樣例）

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

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

3、Wormhole設計目標

3.1 設計目標

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

• 平臺化/組件化

經過平臺化支持，組件化組裝實施，能夠快速對原型進行驗證，和需求方造成反饋閉環快速迭代

• 標準化

對數據格式進行標準化，達到通用效果，減小數據格式化和維護的成本

• 配置化/可視化

用戶可視化配置、部署、管理、監控，下降大數據產品開發門檻，確保高質量產出

• 低延遲/高性能/高可用

根據實時性的要求，流式處理要求更低的延遲，而且要求更高的吞吐量，以及容錯能力，保證系統7*24正常運行

• 自助化/自動化

讓企業從數據中心化轉型爲平臺服務化，讓每一個數據從業者都可以有更多的自助服務，並釋放數據處理能力，系統替代人工完成重複低級的工做，讓從業者回歸數據和業務本質

3.2 效果體現

Wormhole平臺的建設帶來的效果主要體如今如下幾方面：

• 組織結構更合理：

以下圖，大數據相關部門再也不作定製化開發和業務維護，而是更專一平臺化和大數據環境的穩定，大大減小了人力資源的浪費。

（基於Wormhole的組織結構）

• 下降了流式處理開發的技術門檻：

流式處理的開發模式變爲了業務人員經過可視化配置和編寫SQL便可完成80%以上的業務場景，再也不須要對流式處理技術有很深的理解

• 縮短了需求上線週期：

以下圖所示基於Wormhole的需求開發流程，一個需求從提出到上線只須要產品人員和業務人員，大幅下降了溝通和學習成本，進而大大縮短了需求開發上線週期。

4、Wormhole設計規範

（Wormhole流程設計圖）

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

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

Namespace：數據的「IP」，經過7層結構惟必定位數據對應的物理位置，即

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

1）統一通用流消息協議——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格式

2）統一數據計算邏輯管道——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的具體功能。

做者：趙平

來源：宜信技術學院