導讀：網際網路的迅猛發展使得資料不再昂貴，而如何從資料中更快速獲取價值變得日益重要，因此，資料實時化成為了一個大趨勢。越來越多的業務場景需要實時分析，以極低的延遲來分析實時資料並給出分析結果，從而提高業務效率，帶來更高價值。流式處理作為實時處理的一種重要手段，正在因資料實時化的發展而蓬勃發展。本文是敏捷大資料（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主要基於Spark技術，實現了基於SQL的流上資料處理和異構系統冪等寫入等相關功能。如上圖（Wormhole資料處理樣例）所示，Wormhole接入流上的資料，然後將資料中的出生日期通過使用者編寫的SQL處理為年齡，寫入到另外一個儲存系統中。

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

三、Wormhole設計目標
基於敏捷大資料的思想，Wormhole的設計目標如下：

• 平臺化/元件化

通過平臺化支援，元件化組裝實施，可以快速對原型進行驗證，和需求方形成反饋閉環快速迭代

• 標準化

對資料格式進行標準化，達到通用效果，減少資料格式化和維護的成本

• 配置化/視覺化

使用者視覺化配置、部署、管理、監控，降低大資料產品開發門檻，確保高質量產出

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

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

• 自助化/自動化

讓企業從資料中心化轉型為平臺服務化，讓每個資料從業者都能夠有更多的自助服務，並釋放資料處理能力，系統替代人工完成重複低階的工作，讓從業者回歸資料和業務本質

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

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

下圖為基於Wormhole的組織結構

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

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

• 縮短了需求上線週期：

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

下圖為基於Wormhole的需求開發流程： 

四、Wormhole設計規範

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

• 統一資料邏輯表名稱空間——Namespace

Namespace：資料的“IP”，通過7層結構唯一定位資料對應的物理位置，即 
[Data System].[Instance].[Database].[Table].[Table Version]. [Database Partition].[Table Partition] 

• 統一通用流訊息協議——UMS

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

說明： 
 
o protocol-type目前支援data_increment_data（增量資料）和data_initial_data（初始化全量資料） 
o schema-namespace指定資料對應的namespace 
o schema-fields描述每個欄位的名稱、型別、是否可空。ums_id_代表記錄id，要求保證遞增；ums_op_代表資料操作（i：插入；u：更新；d：刪除）；ums_ts_代表資料更新時間 
o payload-tuple指一條記錄的內容，與schema-fields一一對應 
注：在Wormhole_v0.4.0版本後，應社群需求，支援使用者自定義半結構化JSON格式

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

說明： 

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

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

如想了解更多，您還可以：

1 到Github瀏覽更多平臺資訊

DBus地址

https://github.com/BriData/DBus

Davinci地址

https://github.com/edp963/davinci

Wormhole地址

https://github.com/edp963/wormhole

Moonbox地址

https://github.com/edp963/moonbox

--------------------- 
作者：敏捷大資料 
來源：CSDN 
原文：https://blog.csdn.net/weixin_41608840/article/details/80989926 
版權宣告：本文為博主原創文章，轉載請附上博文連結！