專訪朱詩雄：Apache Spark中的全新流式引擎Structured Streaming
接收程序員的 8 點技術早餐
編輯 | Tina
Apache Spark 在 2016 年的時候啟動了 Structured Streaming 項目，一個基於 Spark SQL 的全新流計算引擎 Structured Streaming，讓用戶像編寫批處理程序一樣簡單地編寫高性能的流處理程序。經過一年多的改進和完善，目前 Structured Streaming 已經在 Databricks 內部和客戶廣泛使用，InfoQ 採訪了 Structured Streaming 的核心開發朱詩雄來具體了解這個項目。
朱詩雄，Databricks 軟體開發工程師，Apache Spark PMC 和 Committer。曾任職於小米、微策略。作為 Structured Streaming 的核心開發人員，貢獻了大量的特性和改進，打造了基於 Spark SQL 的全新流計算引擎 Structured Streaming。同時也是 Databricks Delta 的核心開發人員，致力於構建一個基於 Cloud 的統一批處理和流處理的數據平台。他也為 Spark Core 和 Spark Streaming 貢獻了大量代碼，是目前 Spark RPC 框架的主要作者。此外，他還是著名的響應式編程庫 RxJava 的 Committer。
InfoQ：能否先簡單介紹一下 Spark Streaming 和 Structured Streaming？
朱詩雄：Spark Streaming 是 Spark 早期基於 RDD 開發的流式系統，用戶使用 DStream API 來編寫代碼，支持高吞吐和良好的容錯。其背後的主要模型是 Micro Batch，也就是將數據流切成等時間間隔的小批量任務來執行。
Structured Streaming 則是在 Spark 2.0 加入的經過重新設計的全新流式引擎。它的模型十分簡潔，易於理解。一個流的數據源從邏輯上來說就是一個不斷增長的動態表格，隨著時間的推移，新數據被持續不斷地添加到表格的末尾。用戶可以使用 Dataset/DataFrame 或者 SQL 來對這個動態數據源進行實時查詢。每次查詢在邏輯上就是對當前的表格內容執行一次 SQL 查詢。如何執行查詢則是由用戶通過觸發器（Trigger）來設定。用戶既可以設定定期執行，也可以讓查詢儘可能快地執行，從而達到實時的效果。一個流的輸出有多種模式，既可以是基於整個輸入執行查詢後的完整結果，也可以選擇只輸出與上次查詢相比的差異，或者就是簡單地追加最新的結果。這個模型對於熟悉 SQL 的用戶來說很容易掌握，對流的查詢跟查詢一個表格幾乎完全一樣。
InfoQ：是不是可以把 Structured Streaming 理解為對 Spark Streaming 的改進？Structured Streaming 的設計初衷是為了解決什麼具體問題的能介紹下嗎？
朱詩雄：Structured Streaming 並不是對 Spark Streaming 的簡單改進，而是我們吸取了過去幾年在開發 Spark SQL 和 Spark Streaming 過程中的經驗教訓，以及 Spark 社區和 Databricks 眾多客戶的反饋，重新開發的全新流式引擎，致力於為批處理和流處理提供統一的高性能 API。同時，在這個新的引擎中，我們也很容易實現之前在 Spark Streaming 中很難實現的一些功能，比如 Event Time 的支持，Stream-Stream Join（2.3.0 新增的功能），毫秒級延遲（2.3.0 即將加入的 Continuous Processing）。
類似於 Dataset/DataFrame 代替 Spark Core 的 RDD 成為為 Spark 用戶編寫批處理程序的首選，Dataset/DataFrame 也將替代 Spark Streaming 的 DStream，成為編寫流處理程序的首選。
InfoQ：有了 Structured Streaming，是否意味著 Spark 不僅具有卓越的批處理能力，也同時具備了優秀的流處理能力，可以用 Spark 來構建統一批處理和流處理的大數據平台？這樣子的平台是否更能適應未來人工智慧快速發展，對更大數據量、更多樣化的數據處理的需求？
朱詩雄：是的。Structured Streaming 決定使用 Dataset/DataFrame API 最主要的一個原因就是希望用戶不再需要分別為批處理和流處理編寫代碼，而是直接使用同一套代碼。目前我們也在 Databricks Delta 項目中探索如何基於 Cloud 構建一個統一的批處理和流處理的數據平台。
這樣的一個數據平台會對人工智慧有很大幫助。Google 之前有一篇 paper 提到了，在一個機器學習系統中的機器學習代碼只佔一小部分，有很大一部分是用來進行數據收集、清理、驗證、特徵提取、分析等各種操作 [1]。 而後面這些工作都是 Spark 所擅長的。
[1] "Hidden Technical Debt in Machine Learning Systems" Google NIPS 2015
InfoQ：可以聊聊有了 Structured Streaming 的 Spark 有什麼優劣勢嗎？
朱詩雄：Structured Streaming 的主要優勢體現在下面幾點：
簡潔的模型。Structured Streaming 的模型很簡潔，易於理解。用戶可以直接把一個流想像成是無限增長的表格。
一致的 API。由於和 Spark SQL 共用大部分 API，對 Spaprk SQL 熟悉的用戶很容易上手，代碼也十分簡潔。同時批處理和流處理程序還可以共用代碼，不需要開發兩套不同的代碼，顯著提高了開發效率。
卓越的性能。Structured Streaming 在與 Spark SQL 共用 API 的同時，也直接使用了 Spark SQL 的 Catalyst 優化器和 Tungsten，數據處理性能十分出色。此外，Structured Streaming 還可以直接從未來 Spark SQL 的各種性能優化中受益。
多語言支持。Structured Streaming 直接支持目前 Spark SQL 支持的語言，包括 Scala，Java，Python，R 和 SQL。用戶可以選擇自己喜歡的語言進行開發。
InfoQ：可以介紹一下在 Databricks 內部，哪些地方在使用 Structured Streaming 么？效果如何？
朱詩雄：我們內部使用 Structured Streaming 開發了自己的日誌處理系統，相比原來的批處理系統，延遲從幾十分鐘下降到了幾分鐘。我們還利用 Structured Streaming 來分析 Databricks 的客戶日誌，監控客戶使用 Structured Streaming 的情況。一旦發現用戶的程序有問題，會自動觸發報警。得益於 Structured Streaming 的高性能和低延時，我們甚至可以在客戶發現問題之前，提前幫助他們解決。
Databricks 的很多客戶也在使用 Structured Streaming，每天有 100 多個 Structured Streaming 的應用程序在生產環境中運行，最大的應用程序每個月可以處理幾十萬億條數據。
InfoQ：Structured Streaming 跟其他的流處理技術相比，算是比較年輕的技術吧？目前有什麼已知待解決的問題？未來有什麼新增功能和優化的計劃能否介紹下？
朱詩雄：是的，Structured Streaming 從開始開發到現在也就兩年時間，相當年輕，也存在一些待解決的問題。比如由於開發資源有限，一些不常用的功能還沒有完成，例如 Update 輸出模式。另外，Spark 的動態資源分配對 Structured Streaming 的支持不是很好，無法根據用戶的流處理程序很好地調整資源。大家可以到 Spark 的 JIRA 上查看 Structured Streaming 的相關 Issue。
在即將發布的 Spark 2.3.0 中，最令人期待的是支持毫秒級延遲的 Continuous Processing。同時，也新增了對 Stream-Stream Join 的支持。此外，在這個版本中，還將發布新的 Source 和 Sink API，讓用戶方便地開發各種 Streaming 數據源。
在未來的後續版本中，我們會繼續對 Continuous Processing 進行改進。同時，也會支持 Update 輸出模式，推出更多的 Streaming 數據源。
InfoQ：您對於未來 Structured Streaming 的發展和應用範圍有什麼預期嗎？
朱詩雄：我個人希望有更多的用戶來使用 Structure Streaming，包括新用戶和 Spark Streaming 已有的用戶。同時也希望能看到有更多的機器學習和圖處理演算法支持 Structured Streaming。
TAG:InfoQ |