原文連接:css
https://www.ericsson.com/en/blog/2019/6/applying-the-spark-streaming-framework-to-5g算法
編譯：數據庫
明柏，阿里巴巴計算平臺事業部EMR團隊技術專家，Apache Spark Contributor，目前從事 Spark 內核優化相關的工做，在分佈式系統和大數據調度也有較爲深刻的瞭解和實踐。apache
咱們已經很長時間沒有更新流處理框架的相關博客（apache-storm-vs-spark-streaming ，https://www.ericsson.com/en/blog/2015/7/apache-storm-vs-spark-streaming和 apache-storm-performance-tuners，https://www.ericsson.com/en/blog/2015/4/apache-storm-performance-tuners，此次想分享一下咱們關於當前流處理引擎及其在 5G 和 IoT 場景適用性的一些觀點。微信
在發展 5G 和 IoT 場景的準備階段，愛立信研究了各類可擴展和靈活的流處理框架，以解決數據流水線問題以及提高總體性能。咱們經過機器學習流數據進行自適應學習和智能決策從而實現各個領域的自動化。其中使用機器學習算法從流數據中逐步學習模型和獲取信息是一個巨大的挑戰。網絡
在這篇文章中，咱們將討論 AI 在流數據中的挑戰以及如何使用流處理框架（主要是 Spark Streaming 框架）來解決這些問題。架構
Spark Streaming框架
如下內容分爲輸入，處理（ETL 和 ML）和輸出階段。咱們還會介紹爲了高效的控制和優化，在流處理框架中使用的各類機器學習和數據分析技術。
app
輸入階段：
儘管有不一樣的輸入源（如文件、數據庫和各類端點），這個階段重要的是如何在Spark Streaming 框架下高效地使用 Apache Kafka。除了默認的基於接收端的方法以外，還有一種解決了性能和重複問題的 direct 技術。在咱們的電信領域中，網絡探測的數據速率能夠達到1TB/秒，direct 方式很好的解決了這個問題。除了性能以外，咱們還須要一種簡單的方式來維護複雜的電信系統中的分發技術而且知足 99.9999％ 的準確率，這對故障狀況也提出了極大的要求。而 direct 技術能夠下降了處理故障的複雜性，並減小了跨系統重複數據的維護數量。框架
處理階段：
提取，轉化和加載（ETL）：
在過去實踐流處理時，一般討論的是在 executors 上並行運行的 Bolts，咱們的主要任務是肯定部署拓撲，以得到均勻的分佈和可用資源的最大利用率。而後，咱們開始討論 micro-batches 及其與純流處理相比更出色的效率和容錯能力。此外，咱們還會常常討論將批處理和流處理結合在一個查詢的 Lambda 架構。目前，因爲 Spark Streaming 框架的日益流行，行業已經開始轉向甚至將寬表也被視爲流數據並增量處理的 Structured Stream Querying。Structured Stream Querying 容許咱們以更高優先級處理新到達的數據以響應查詢。機器學習
在電信領域，咱們有各類各樣的轉換，好比數字映射、清理、空值替換、變量轉換等等。由於不涉及 micro-batch 操做，咱們使用 Apache Flink 以純流方式處理全部這些操做。而對於諸如缺失值替換、最後N個值的平均值等操做（任何須要歷史數據的操做），咱們使用Spark Streaming 的 Structural Querying。
機器學習(ML):
在咱們的電信領域，咱們須要以流的方式建立訓練模型和測試數據。咱們嘗試了各類方法在新的數據流入時更新模型，發現分層模型更容易實現模型增量更新。這些分層數據模型能夠很容易地使用 Spark Streaming 框架進行部署，由於它內部支持對這些模型準備的 micro-batch 處理。咱們也瞭解到，利用 Apache Flink 的靈活性和純流特性，強化學習的實現很容易完成，並且與其餘框架相比，這些實現的性能指標具備很強的競爭力。
Sink 階段：
在數據處理層以後，咱們能夠將數據存儲到各類選項中，例如永久數據存儲、分佈式內存、返回到消息總線或者只是可視化數據點。在咱們的內部研究中，咱們將已處理的數據存儲在相對 partition tolerance 更重視 availablity 的 Cassandra（No-SQL數據存儲）中。鑑於在通訊應用使用 Apache Cassandra 的經驗，咱們發現它能夠經過微調來知足一致性和可用性的場景。當你不能提升 hbase 可用性時，能夠嘗試使用 Cassandra 並經過調整一致性來實現。
咱們還須要將數據存儲在「最佳」站點中。資源可能由存儲 A 中的站點 A 上的執行者建立，可是客戶端應用程序老是從站點 B 查詢它，這將要求咱們肯定在站點 B 上存儲資源的位置，以確保數據的本地性，這個咱們是經過 Sink Level 的內部優化實現的。
在本文中，我闡述了流處理框架中的一些問題和最佳的使用方式。流系統上的數據管道的介紹應該有助於對您的系統進行性能調優。至於流引擎如何支持 5G 網絡切片和物聯網數據，這些都將在咱們的下一篇博客中討論。請繼續關注!
與此同時，能夠回顧咱們的其餘博客: Apache Storm Performance Tuners，https://www.ericsson.com/en/blog/2015/4/apache-storm-performance-tuners；Apache Storm vs. Spark Streaming，https://www.ericsson.com/en/blog/2015/7/apache-storm-vs-spark-streaming
本文由用戶爲我的學習及研究之目的自行翻譯發表，如發現侵犯原做者的版權，請聯繫公衆號後臺處理。
本文分享自微信公衆號 - Apache Spark技術交流社區（E-MapReduce_Spark）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。