連續應用:發展流在Apache 2.0火花

自發布以來,引發流已經成為使用最廣泛的國家之一分布式流媒體引擎,由於其高層API,僅一次語義。然而,隨著這些類型的引擎變得普遍,我們發現開發人員常常需要的不僅僅是一個流編程模型構建實時應用程序。在磚,我們曾與成千上萬的用戶了解如何簡化實時應用程序。在這篇文章中,我們提出的想法,連續應用程序通過的,我們已經開始實施結構化流API在Apache 2.0火花。

大多數流引擎關注執行計算流:例如,你可以將流映射到每個記錄上運行一個函數,它聚合事件減少,等等。然而,我們與用戶合作,我們發現幾乎沒有的用例流引擎隻涉及對一個流進行計算。相反,流處理發生作為一個更大的應用程序的一部分,我們馬上打電話叫一個連續應用程序。下麵是一些例子:

1. 將在實時更新數據。例如,開發人員可能希望更新一個彙總表,用戶通過一個web應用程序將查詢。在這種情況下,大部分的複雜性是流引擎之間的交互和服務係統:例如,你可以在表上運行查詢時流引擎更新嗎?“完整的”應用程序是一個實時的服務係統,而不是一個地圖或減少在流。
2. 提取、轉換和加載(ETL)。一個常見的用例是不斷移動,將數據從一個存儲係統到另一個(例如一個JSON日誌Apache蜂巢表)。這需要仔細的與存儲係統,以確保沒有重複或丟失數據——大部分的邏輯協調工作。
3. 創建一個現有的批處理作業的實時版本。這是很困難的,因為許多流係統不保證他們的比賽結果將批處理作業。例如,我們已經看到公司建造現場儀表盤使用流引擎和每日報告使用批處理作業,隻有有顧客抱怨他們的日常報告(或更糟的是,比爾!)不匹配的生活指標。beplay体育app下载地址
4. 在線機器學習。這些連續應用程序通常結合大型靜態數據集,使用批處理作業,處理與實時數據和實時預測服務。

這些例子表明,流計算是應用程序的一部分,包括服務、存儲、或批處理作業。不幸的是,在目前的係統中,流計算上運行自己的,隻關注流在一個引擎。這讓開發人員負責與外部係統交互的複雜的任務(例如,管理事務),使其結果符合應用程序的其餘部分(例如,批處理作業)。這就是我們想解決與連續應用程序。

連續應用程序

我們定義了一個連續的應用端到端應用程序,對數據進行實時的反應。特別是,我們希望開發人員使用單獨的編程接口支持方麵的持續應用程序正在處理在單獨的係統中,如查詢服務或與批處理作業的交互。例如,在這裏我們將如何處理上述用例:

1. 實時更新數據,將服務。開發人員將編寫星星之火應用程序處理更新和服務(例如通過火花的JDBC服務器),或者使用一個API,可以自動執行事務服務係統上更新像MySQL,複述或Apache Cassandra。
2. 提取、轉換和加載(ETL)。開發人員隻會列出所需的轉換作為批處理作業,和流媒體係統將處理協調與存儲係統來確保隻有一次處理。
3. 創建一個現有的批處理作業的實時版本。流媒體係統將保證結果總是符合相同的數據的批處理作業。
4. 在線機器學習。的機器學習庫將設計結合實時培訓,定期分批培訓,和預測服務相同的API。

下圖顯示了哪些問題通常是處理流引擎,並需要在連續應用程序:

結構化流

結構化流是我們一個新的高層API為Apache火花2.0支持連續應用。第一,這是一個高級的API比引發流,引進其他結構化的思想火花(DataFrames和數據集)的API——值得注意的是,執行數據庫查詢優化的一種方法。然而,更重要的是,結構化流也包含了連續應用程序提供一係列的想法沒有其他流引擎提供的功能。

1. 強大的擔保和批處理作業的一致性。用戶指定一個流計算通過寫一個批處理計算(使用火花DataFrame /數據集API),並自動引擎incrementalizes這個計算(連續運行它)。在任何時候,結構化的輸出流的工作相同的運行批處理作業在一個前綴的輸入數據。最新的流媒體係統(例如Apache風暴,卡夫卡流,穀歌數據流和Apache Flink)不提供這種“前綴完整性”屬性。
2. 事務與存儲係統的集成。我們有照顧的內部設計以事務的方式來處理數據,然後更新輸出下沉,所以服務應用程序總是看到一致的快照數據。而火花2.0版本隻支持幾個數據源(HDFS和S3),我們計劃在未來的版本中添加更多。事務更新是一個頂尖的痛點火花和其他流媒體係統,用戶的要求手工工作,所以我們興奮地讓這些核心API的一部分。
3. 緊密集成與火花。結構化流媒體服務支持交互式查詢流狀態火花SQL和JDBC,集成了MLlib。這些集成隻是火花2.0開始,但會在將來的版本中。因為結構化流基於DataFrames,許多其他圖書館的火花自然會運行在它(例如,所有功能轉換MLlib書麵反對DataFrames)。

除了這些獨特的特點,結構簡化流流有其他新功能,如明確支持“活動時間”總訂單數據,和更豐富的支持窗口和會話。容錯的方式實現其一致性語義也不是easy-see我們姐姐的博客API和執行模型。

結構化流仍在α在火花2.0中,但我們希望你試試和發送反饋。我們的團隊和許多其他社區成員將擴大它在接下來的幾個版本。

一個例子

結構化流作為一個簡單的例子,下麵的代碼顯示了提取、轉換和加載(ETL)工作,將JSON數據轉化為Apache拚花。注意結構化流直接使用DataFrame API,所以幾乎是相同的一批版本的代碼。

(行網格=“是”)
[坳x = " 12 " md =“6”)

流的版本

//連續讀取JSON從S3logsDF=spark.readStream.json (s3: / /日誌)//變換與DataFrame API和保存logsDF.select (“用戶”,“url”,“日期”).writeStream.parquet (s3: / /)。開始()

[/坳]
[坳x = " 12 " md =“6”)

批版

/ /讀取JSON一旦從S3logsDF = spark.read.json (“s3: / /日誌”)/ /變換DataFrame API並保存logsDF.select (“用戶”,“url”,“日期”).write.parquet (“s3: / /”)

[/坳]
[/行]

雖然表麵看來的代碼簡單,火花在引擎蓋下麵做了很多工作,如分組數據為拚花的分區,確保每條記錄出現在輸出完全一次,恢複工作的狀態,如果你重新啟動它。最後,這個數據交互式地而不是寫拚花,我們可以改變writeStream使用(目前α)內存中沉和JDBC客戶機連接到火花來查詢。

長期願景

我們的長期願景流火花雄心勃勃:我們希望每個圖書館火花在結構化流以增量的方式工作。盡管這是一個大目標,Apache火花將實現它。它的庫已經建立在普遍,狹窄的api(抽樣和DataFrames),和結構化流明確給設計結果符合這些統一的接口。

火花開始以來最大的見解是,開發人員需要統一的接口。例如,批處理計算集群用於需要許多分離係統(MapReduce的ETL、蜂巢的SQL, Giraph圖,等等),複雜的開發和運營。火花統一這些工作負載在一個引擎,大大簡化這兩個任務。相同的見解應用於流媒體。因為流負載通常是一個更大的連續應用程序的一部分,它可能包括服務、存儲、和批處理作業,我們希望提供一個統一的API構建端到端連續應用程序和係統。

閱讀更多

我們的結構化流模型博客文章中更詳細地探討了流API和執行模型。我們建議你讀這篇文章開始使用結構化的流。

此外,以下資源覆蓋結構化流:

• 火花2.0和結構化流
• 構建火花:DataFrames,數據集和流
• 深入了解結構化流
• 結構化流編程指南