在實現企業背景調查平台的過程中，除了Spark，我們使用了很多開源組件：Flume、canal、HBase、Neo4j等。這些優秀的開源組件使得工程師擁有了更多可能。在大數據領域，開源軟體更是最主要的力量。本節將介紹一些比較有前景和新的開源大數據技術。

16.3.1　Apache Flink

不同於大多數起源於矽谷的大數據開源項目，Flink起源於2010年幾個德國柏林的大學和研究機構的研究項目，最初項目名是StratoSphere，2014年5月加入Apache軟體基金會，改名Flink，並於當年年底從孵化器畢業成為Apache頂級項目。自從加入了Apache，Flink發展速度非常迅猛，截至目前已經有500餘名貢獻者。如今，每年4月，Flink的技術盛會Flink Summit也會在舊金山如期舉行。

與Spark不同，Flink誕生較晚，但具有很強的後發優勢，尤其是在流處理方面。另外，Flink也用Table API統一了流和批的處理方式，這點與Spark的DataFrame API類似，但是比Structured Streaming要早。圖16-6是Flink的架構圖，FlinkML是Flink的機器學習庫，Gelly是圖處理框架。

圖16-6　Flink架構

如圖16-6所示，可以看到在Flink中流處理和批處理底層處理引擎是通用的。總的來說，Flink和Structured Streaming都是Dataflow模型的開源實現，差別會越來越小。

最後我們可以從Beam的角度來對比下Spark、Dataflow和Flink，Beam官網從「3W1H」這4個維度來橫向比較Flink、Spark、Dataflow以及多種主流計算框架，如圖16-7所示。

圖16-7　計算框架功能對比

毋庸置疑，Google Dataflow無論從推出時間和設計思想來說都占據優勢，功能最完備，而Flink目前功能性要明顯優於Structured Streaming。

2019年1月，來自中國的網際網路巨頭阿里巴巴宣布以9000萬歐元的價格收購總部位於柏林的Flink母公司Data Artisans，並立刻啟動Blink與Flink合併事宜，有了巨頭的資本和賦能，對Flink來說無疑是巨大利好。

16.3.2　Apache Apex

Apache Apex由DataTorrent公司在2015年6月推出，是一個企業級的基於Hadoop和YARN的數據處理平台，也是成為Apache頂級項目用時最短的項目之一（其標識如圖16-8所示）。Apex和Spark與Flink一樣，也統一了流處理和批處理。Apache Apex同樣借鑑了Dataflow的思想，將數據抽象為無邊界表，支持基於事件時間處理和窗口操作以及端到端的恰好一次的消息送達保證。Apex也可以作為Beam後端的執行引擎，具有分布式、可擴展、低延遲的特性，程式語言為Java。

圖16-8　Apache Apex

16.3.3　Ray

隨著機器學習算法和技術的發展，越來越多的機器學習應用需要在多台機器上並行執行，但是集群中的機器學習基礎架構仍然是專門設計的。當然，確實存在一些優秀的特定解決方案（如參數伺服器和超參搜索）以及一些高質量的分布式系統，如Hadoop和Spark。但是，對於那些前沿探索者來說通常要從0開始構建自己的系統，這意味著要耗費大量的時間和精力。例如，一個簡單概念的算法，如論文「Evolution Strategies as a Scalable Alternative to Reinforcement Learning」。算法包含數十行的偽代碼，它的Python實現也很簡單。但是，如果想在一個較為大型的集群上運行，需要上千行代碼的實現，其中包含通信協議、數據序列化和反序列化的策略以及各種數據處理策略。

Ray是RISE實驗室針對機器學習領域開發的一種新的分布式計算框架，官方對它的定義是「靈活的高性能的分布式執行框架」。Ray要解決的問題，主要是在類似增強學習這樣的場景中所遇到的工程問題。增強學習需要模擬目標系統的環境來實時獲取反饋信息，從而判斷收益並調整參數。模擬環境的過程可能涉及大量低延遲的計算任務，而這些計算任務通常來說執行時間差別很大，有些數百毫秒就完成任務，有些可能需要十幾分鐘。像Spark這樣的MapReduce類型計算框架很難支持上述需求，Spark的計算資源本質上是對基於CPU的作業系統線程抽象，因此Spark很難將數以億計的仿真實體合理地同時調度到集群中的CPU中，CPU數和計算任務數之間通常差了很多個數量級，而且MapReduce這種類型的計算框架是一種同步計算框架，等待所有計算任務完成同步不僅開銷很大而且很難實現。此外，Spark的計算任務圖是靜止的，不會改變，而在增強學習中，整個任務流程的計算任務圖也可能是動態變化的，系統往往可能需要根據前一個環節的結果，調整下一個環節的行為參數或者流程。這些大量的對計算任務圖的修改很難在Spark中得到有效的支持。

Ray與TensorFlow、PyTorch和MXNet等深度學習框架互相兼容，在很多應用中，我們都可以很自然地在Ray中使用一個或多個深度學習框架。而其他分布式系統，例如Spark或者Hadoop都不是以構建人工智慧應用為目標，基於此UC Berkeley的研究員認為目前的分布式系統缺乏以下特性：

• 支持毫秒級延遲的任務處理，每秒處理百萬級任務；
• 嵌套的並行化（任務內的並行化任務，例如超參數搜索中的並行模擬）；
• 在運行時動態確定任意任務的依賴性（例如，避免等待緩慢的工作節點）；
• 在共享可變狀態下運行任務；
• 支持異構計算（GPU、CPU等）。

這些都是Ray與MapReduce類型的計算框架不同之處。

Ray的架構分為兩層，第一層為應用層，第二層為系統層，如圖16-9所示，應用層實現了計算模型和邏輯，系統層負責調度、數據管理以滿足性能和容錯的需求。

圖16-9　Ray架構

在應用層中，Driver是執行用戶程序的進程；Worker會執行由Driver或者其他Worker調用（遠程調用）的任務。Actor是一個有狀態的進程，在調用時執行暴露的方法。與Worker不同，Actor由Worker和Driver顯式地實例化。Actor和Worker都是串行執行方法。Worker是無狀態的，所以它不用跨任務維護本地狀態，相同的參數遠程調用相同的遠程函數將返回相同的結果，與具體執行的Worker無關。Actor是一個有狀態的進程，方法調用的結果取決於該Actor之前執行的方法。

在系統層中，核心是全局控制存儲（GCS），它存儲所有最新的元數據並控制系統中的狀態信息，通過這種集中式存儲狀態，GCS使其他每個組件都無狀態了。這不僅簡化了容錯機制（故障時，組件重啟並從GCS中讀取最新的狀態），並且可以輕鬆擴展（擴展的副本都可以從GCS中獲取最新的狀態）。

Ray採用兩層（本地-全局）調度方案，與普通的兩層調度方案不同，在節點上創建的計算任務首先會交給本地的調度器，而不是提交給全局調度器。本地調度器在本地調度計算任務，除非節點不堪重負，或者不能滿足任務的要求（如缺少GPU、任務輸入在遠端）。如果本地調度程序未調度任務，則它將任務發送到全局調度器，由全局調度器再次進行調度，如果全局調度器遇到瓶頸，我們可以實例化多個全局調度器，本地調度器會隨機選擇一個並向其提交任務，如圖16-10所示，這種調度方式稱為自下而上的分布式調度器（bottom-up distributed scheduler）。

圖16-10　自下而上的分布式調度器

為了最小化計算任務的延遲，Ray實現了一個內存分布式存儲系統，本質上是一個對象存儲（object store）來存儲每個任務的輸入和輸出。它可以使Actor和Worker之間高效地共享數據。在每個節點上，Ray通過共享內存存儲對象。這種架構使任務之間無須進行數據複製。此外，Ray使用了Apache Arrow這種高效的內存布局。

由於Ray採用Python作為程式語言，底層採用了Actor框架來進行遠程調用，開發者只需要通過寥寥數行代碼就能將在筆記本電腦里運行的算法原型轉換成在分布式集群上運行的高性能應用。Ray本質上是面向人工智慧應用的分布式計算框架，它和Spark這類面向海量數據處理的計算框架不存在競爭關係而是互為補充：我們可以用Spark進行數據預處理，接著用Ray來進行人工智慧應用開發。

16.4　Spark未來發展方向

從2009年Spark誕生之日起，距今已經過十年，Spark也將在今年迎來自己的第三個大版本Spark 3.0。在這十年里，Spark經歷了脫胎換骨的變化，目標也逐漸清晰，社區對Spark未來的規劃也逐漸明朗，可以預見的是在未來一段時間，Spark將沿著這個路線飛速發展，Spark目前的三大目標如下。

• 統一數據處理 + 人工智慧。從2017年Spark Summit改名為Spark + AI Summit開始，Spark也將官網的口號從「閃電般的數據分析引擎」改為「大數據的統一分析引擎」，這些都昭示了Spark在數據科學和數據工程領域的宏大願景：統一與融合。在Hydrogen項目中，我們可以清晰地看到Spark為之而努力的路線圖。在Spark 2.x中：SPARK-21190實現了向量化的UDF，SPARK-24374實現了同步柵調度。在Spark 3.x中：Hydrogen項目將會實現加速器（GPU、FPGA）感知調度（SPARK-24615）和通用（支持更多語言）的向量化UDF（SPARK-24579）。
• 隨處運行。隨處運行一直是Spark的目標，Spark最初是被設計運行在Mesos中，隨著使用人數和部署需求的不斷增多，Spark增加了YARN、local和standalone模式。隨著Kubernetes擊敗Mesos成為最流行的容器編排系統，目前運行在Kubernetes中的Spark實例數量突飛猛進。社區很早就注意到了Kubernetes的潛力，Spark 2.4適時推出了Spark on Kubernetes模式，在3.x中，會繼續增加Pod模板、動態資源分配和外部Shuffle服務等新特性。
• 簡潔易用的API。Spark深受用戶喜愛的一個很重要的原因就是其簡潔易用的API，作者有個朋友，平時一直用Spark做數據處理，但是他處理的數據量並不大，問其原因，答曰API好用，加上對SQL支持很好。從Spark誕生之日開始，Spark使用的接口從最初的RDD API、DataFrame API進化到最後的Dataset API，從最初的只支持一種語言到支持多種語言，Spark在降低用戶學習成本和提升用戶體驗方面不遺餘力。

優化和提升從來都是無止境的，Databricks在Spark Summit 2019公布了一個開源項目：koalas，這個項目的初衷是，很多數據工程師和數據科學家最開始在學校學習的是pandas（Python DataFrame），工作後仍使用pandas處理小批量數據，處理海量數據時則會選用Spark，雖然Spark DataFrame API和pandas比較類似，但還是有所不同，為了進一步降低這類人群的使用成本並統一API，Databricks推出了koalas項目，為數據工程師和數據科學家提供了與pandas一模一樣的Spark API。

總體來說，Spark的這三個目標其實都是為了一個目標而服務：為了讓數據科學家更富成效地進行工作。目前，Spark完美地完成了任務，對於Spark的未來，我們拭目以待！

我們從GitHub上的代碼倉庫可以看到，Spark下一個大版本將會是Spark 3.0而不是2.5，如圖16-11所示。從JIRA官網上可以看到，目前和Spark 3.0有關的issue一共有242個。在這242個issue中，涉及Spark 3.0未來發展方向的史詩，只有一個SPARK-24579：標準化Spark和人工智慧、深度學習框架，如TensorFlow、MXNet之間的數據交換過程，並優化其傳輸性能，該史詩的出發點在於目前大數據與人工智慧的結合是很多業務與應用成功的關鍵，而這兩個領域的頂級開源社區也多次嘗試整合，但由於Spark SQL、DataFrame、Structured Streaming的日趨成熟，Spark仍然是大數據社區的首選，因此人工智慧框架如何與Spark進行集成是整合的關鍵，當然，目前已經存在一些解決方案如TensorFlowOnSpark、TensorFrames等，但是並沒有一種標準化傳輸方案，所以性能優化只能根據具體情況來實現，例如TensorFlowOnSpark使用Hadoop的InputFormat/OutputFormat格式來加載和保存TensorFlow的TFRecords，並用RDD將數據傳輸給TensorFlow。SPARK-24579所探討的正是如何降低整個過程的複雜性：標準化Spark和人工智慧、深度學習框架之間的數據交換接口。這樣，人工智慧、深度學習框架可以利用Spark從任何地方加載數據，而無須花費額外的精力來構建複雜的數據解決方案，例如從數據倉庫或流模型推斷中讀取某個特徵。Spark用戶可以使用人工智慧、深度學習框架，而無須學習特定的數據API，並且雙方的開發人員可以獨立地進行性能優化，因為接口本身不會帶來很大的開銷。SPARK-24579隻是Spark在人工智慧領域的一個開始，這也和2018年的Spark Summit首次改名為Spark + AI Summit相契合，預示著Spark將在人工智慧領域發力。Spark 3.0到底會加入哪些令人激動的特性，會朝著哪個方向發展，我們拭目以待。

圖16-11　原本的2.5的編號被修改為3.0

本文摘自《Spark海量數據處理 技術詳解與平台實戰》

• 基於Spark新版本編寫，包含大量的實例
• 用一個完整項目貫穿整個學習過程的實用Spark學習指南
• 層次分明、循序漸進，帶你輕鬆玩轉Spark大數據

本書基於Spark發行版2.4.4寫作而成，包含大量的實例與一個完整項目，層次分明，循序漸進。全書分為3部分，涵蓋了技術理論與實戰，讀者可以從實戰中鞏固學習到的知識。第一部分主要圍繞BDAS（伯克利數據分析棧），不僅介紹了如何開發Spark應用的基礎內容，還介紹了Structured Streaming、Spark機器學習、Spark圖挖掘、Spark深度學習等高級主題，此外還介紹了Alluxio系統。第二部分實現了一個企業背景調查系統，比較新穎的是，該系統借鑑了數據湖與Lambda架構的思想，涵蓋了批處理、流處理應用開發，並加入了一些開源組件來滿足需求，既是對本書第一部分很好的鞏固，又完整呈現了一個實時大數據應用的開發過程。第三部分是對全書的總結和展望。
本書適合準備學習Spark的開發人員和數據分析師，以及準備將Spark應用到實際項目中的開發人員和管理人員閱讀，也適合計算機相關專業的高年級本科生和研究生學習和參考，對於具有一定的Spark使用經驗並想進一步提升的數據科學從業者也是很好的參考資料。