In-Stream Big Data Processing流式大資料處理詳解

相當長一段時間以來，大資料社區已經普遍認識到了批量資料處理的不足。很多應用都對即時查詢和串流產生了迫切需求。最近幾年，在這個理念的推動下，催生出了一系列解決方案，Twitter Storm，Yahoo S4，Cloudera Impala，Apache Spark和Apache Tez紛紛加入大資料和NoSQL陣營。本文嘗試探討串流系統用到的技術，分析它們與大規模批量處理和OLTP/OLAP資料庫的關係，並探索一個統一的查詢引擎如何才能同時支援流式、批量和OLAP處理。

在Grid Dynamics，我們面臨的需求是構建一個流式資料處理系統，每天需要處理80億事件，並提供容錯能力和嚴格事務性，即不能丟失或重複處理事件。新系統是現有系統的補充和繼任者，現有系統基於Hadoop，資料處理延遲高，而且維護成本太高。此類需求和系統相當通用和典型，所以我們在下文將其描述為規範模型，作為一個抽象問題陳述。

下圖從高層次展示了我們的生產環境概況：

這是一套典型的大資料基礎設施：多個資料中心的各個應用程式都在生產資料，資料通過資料收集子系統輸送到位於中心設施的HDFS上，然後未經處理資料通過標準的Hadoop工具棧（MapReduce，Pig，Hive）進行匯總和分析，匯總結果儲存在HDFS和NoSQL上，再匯出到OLAP資料庫上被定製的使用者應用訪問。我們的目標是給所有的設施配備上新的串流引擎（見圖底部），來處理大部分密集資料流，輸送預匯總的資料到HDFS，減少Hadoop中未經處理資料量和批量job的負載。

串流引擎的設計由以下需求驅動：

SQL-like功能：引擎能執行SQL-like查詢，包括在時間視窗上的join和各種彙總函式，用來實現複雜的商務邏輯。引擎還能處理從摘要資料中載入的相對待用資料（admixtures）。更複雜的多道次資料採礦演算法不在短期目標範圍內。

模組化和靈活性：引擎絕不僅是簡單執行SQL-like查詢，然後相應的管道就被自動建立和部署，它應該能通過串連各模組，很方便地組合出更複雜的資料處理鏈。

容錯：嚴格容錯是引擎的基本需求。如草圖中，一種可能的設計是使用分布式資料處理管道來實現join、匯總或者這些操作組成的鏈,再通過容錯的持久化buffer來串連這些管道。利用這些buffer，可以實現發布/訂閱的通訊方式，可以非常方便地增加或者移除管道，這樣最大程度提升了系統的模組化。管道也可以是有狀態的，引擎的中介軟體提供持久化儲存來啟用狀態檢查點機制。所有這些主題將在本文後續章節進行討論。

和Hadoop互動：引擎應該能接入流式資料和來自Hadoop的資料，作為HDFS之上的定製化查詢引擎提供服務。

高效能和便攜性：即使在最小規模的叢集上，系統也能每秒傳遞成千上萬次訊息。引擎理應是緊湊高效的，能夠被部署在多個資料中心的小規模叢集上。

為了弄明白如何?這樣一個系統，我們討論以下主題：

首先，我們討論流式資料處理系統，批量處理系統和關係型查詢引擎之間的關係，串流系統能夠大量用到其他類型系統中已經應用的技術。

其次，我們介紹一些在構建串流架構和系統中用到的模式和技術。此外，我們調研了當下新興技術，提供一些實現上的小貼士。

The article isbased on a research project developed at Grid Dynamics Labs. Much of the creditgoes to Alexey Kharlamov and Rafael Bagmanov who led the project and othercontributors: Dmitry Suslov, Konstantine Golikov, Evelina Stepanova, AnatolyVinogradov, Roman Belous, and Varvara Strizhkova.

分散式查詢處理基礎

分布式流式資料處理顯然和Distributed Relational Database Service有聯絡。許多標準查詢處理技術都能應用到串流引擎上來，所以理解分散式查詢處理的經典演算法，理解它們和串流以及其他流行架構比如MapReduce的關係，是非常有用的。

分散式查詢處理已經發展了數十年，是一個很大的知識領域。我們從一些主要技術的簡明概述入手，為下文的討論提供基礎。