開源大數據處理技術從 Hadoop 開始，經歷了 Storm，Spark，現在又到 Flink 的發展過程，計算模型也經歷了從批到流的轉換，目前的新趨勢也已經開始朝着批流融合方向演進。QCon北京2019 設有“實時計算”專題， 點此查看 ，瞭解各種新型實時計算技術的發展趨勢及一線生產場景的應用案例。
從媒體的最新資訊推送，到購物狂歡的實時數據大屏，實時計算已經應用到了多個生活、工作場景，隨着業務的快速增長，我們對實時計算的需求越來越高。
可用於實時計算的開源大數據計算引擎有多種選擇，比如 Storm、Samza、Flink 等，而支持流批一體的只有 Spark 和 Flink。目前，多家企業已經或正在將計算任務從舊系統 Storm 遷移到 Flink，騰訊便是其中之一。
騰訊實時計算團隊的任務是爲業務部門提供高效、穩定和易用的實時數據服務。其每秒接入的數據峯值達到了 2.1 億條，每天接入的數據量達到了 17 萬億條，每天的數據增長量達到了 3PB，每天需要進行的實時計算量達到了 20 萬億次。
其早期的實時計算平臺基於 Storm 構建，但隨着業務規模不斷擴大，業務需求不斷增多，原先的實時計算平臺遇到了很多問題， Storm 的一些缺陷也漸漸暴露出來。在此背景下，騰訊實時計算團隊選擇用 Flink 替換 Storm 作爲新一代的實時流計算引擎，對社區版的 Flink 進行了深度的優化，並在此之上構建了一個集開發、測試、部署和運維於一體的一站式可視化實時計算平臺——Oceanus。
Storm vs Flink
爲什麼騰訊會轉向 Flink？很簡單，我們不妨來做下對比。
Storm
Storm 是一個免費、開源的分佈式流處理計算框架，具有低延遲、容錯、高可用等特性。它可以輕鬆可靠地處理無限數據流，是實時分析、在線機器學習、持續計算、分佈式 RPC 、ETL 的優良選擇。
Storm 的拓撲（Topology）被設計爲有向無環圖（DAG）的形狀。圖表上的邊緣被命名爲 Stream，它是無限的元組序列，以分佈式方式並行處理和創建，將數據從一個節點指向另一個節點。而這個圖上有兩種節點，一是 Spout，拓撲中 Stream 的來源，二是 Bolt，拓撲中的所有處理都是用它完成的。Topology 類似於Hadoop 的 MapReduce，但有一個關鍵的區別，Storm 拓撲會永遠運行，除非你殺死它，而 MapReduce 作業必定結束。
主要特性：
極其廣泛的用例：可用於流處理、連續計算、分佈式RPC等等
可擴展：要擴展拓撲，您所要做的就是添加機器並增加拓撲的並行度設置
保證不丟失數據：實時系統必須對成功處理的數據有很強的保證，而 Storm 能保證每條消息都會被處理
容錯：如果在執行計算期間出現故障，Storm 將根據需要重新分配任務。Storm 確保計算可以永久運行（或直到你終止計算）
編程語言無關：Storm 拓撲和處理組件可以用任何語言定義，幾乎任何人都可以訪問Storm
缺點：
無狀態，需用戶自行進行狀態管理
沒有高級功能，如事件時間處理、聚合、窗口、會話、水印等
詳見：
https://github.com/apache/storm
http://storm.apache.org/index.html
Flink
Flink 是一個同時面向數據流處理和批量數據處理的開源框架和分佈式處理引擎，具有高吞吐、低延遲、高擴展、支持容錯等特性。
其以數據並行和流水線方式執行任意流數據程序，流水線運行時系統可以執行批處理和流處理程序。此外，Flink的運行時本身也支持迭代算法的執行。
主要特徵：
流批：流媒體優先運行時，支持批處理和數據流程序
優雅：Java 和 Scala 中優雅流暢的 API
高吞吐和低延遲：運行時同時支持非常高的吞吐量和低事件延遲
容忍數據的延時、遲到和亂序：解決基於事件時間處理時的數據亂序和數據遲到、延時的問題
靈活：非常靈活的窗口定義
容錯：提供了可以恢復數據流應用到一致狀態的容錯機制
背壓：流媒體中的自然背壓
缺點：
社區不如 Spark 那麼強大，但在快速成長
流處理遠遠流行於批處理
詳見：
https://flink.apache.org/flink-architecture.html
https://github.com/apache/flink
哪些公司被 Flink 吸引？
去年年底，一份市場調查報告顯示，Flink 是 2018 年開源大數據生態中發展“最快”的引擎，和 2017 年相比增長了 125% 。目前，全球有多家企業正在使用 Flink，比如 Amazon 的 Amazon Kinesis Data Analytics 是一種用於流處理的完全託管的雲服務，它部分地使用 Flink 來支持其 Java 應用程序功能。Ebay 的監控平臺由 Flink 提供支持，可評估數千條關於指標和日誌流的可自定義警報規則。除此之外，還有Uber、Yelp 和 CapitalOne 等公司也是 Flink 的用戶。
國內也有很多公司在使用 Flink ，我們在查詢相關資料時發現，部分公司正是從 Storm 遷移到 Flink 的，比如前面我們提到的騰訊，還比如：
阿里巴巴：阿里巴巴在2015年開始嘗試使用 Flink，但因當時 Flink 面世不久稍顯稚嫩，阿里巴巴在 Flink 的基礎上維護了一個內部版本的實時計算平臺 Blink，以滿足自身超大體量的業務需求。今年1月28日，Blink 被正式開源。在此之前，阿里巴巴使用的是 JStorm，與 Blink 相似，JStorm 是阿里巴巴用 Java 語言代替 Clojure 語言重寫的 Storm，在原有基礎上做了不少優化。JStorm 也是阿里巴巴開源的幾個明星產品之一。
字節跳動：字節跳動的多個業務曾跑在 JStorm 計算引擎上，但集羣過多等問題比較明顯，考慮到 Flink 可以解決相關問題，且能兼容 JStorm，字節跳動便將 JStorm 任務遷移到了 Flink 上。
有贊：實時計算在有讚的發展路程和大多數互聯網公司一樣，是從早期的 Storm，到 JStorm，Spark 再到 Flink。2014年，第一個 Storm 應用在有贊內部開始使用；2016年，有贊使用 Spark ；2018年，有贊在實時平臺中增加了對 Flink 引擎的支持。
餓了麼：餓了麼的實時計算平臺演進之路也是從 Storm 到 Spark，後來基於平臺的發展，選擇了擁抱 Flink 。
蘇寧：與餓了麼相同，從2014年到現在，蘇寧的實時計算平臺經歷了從 Storm 到 Spark 再到 Flink 的演進。
美團：美團在實時計算系統建設初期部署的是 Storm，隨着業務對實時數據的需求激增， Storm 無法跟上業務發展，經過調研，美團發現 Flink 的吞吐性能比 Storm 有顯著提升，遂更換選型。
唯品會：目前，唯品會的實時計算平臺並非統一框架，而是 Storm、Spark、Flink 三者共用。其中， Storm 作業最多，但是其業務重心正逐漸轉變到 Flink。
除了上面我們提到的，應用 Flink 技術的公司還包括百度、攜程、滴滴等。
實時計算技術演進
開源大數據處理技術從 Hadoop 開始，經歷了 Storm，Spark，現在又到 Flink 的發展過程，計算模型也經歷了從批到流的轉換，目前的新趨勢也已經開始朝着批流融合方向演進。此外，隨着 Presto，Impala，Kylin 和 Druid 等新興 OLAP 技術的出現，也爲實時數據分析增加了豐富的解決方案。
雖然網絡上有許多相關技術文章可參考，但是很多最新成果大家並不一定能接觸到，即將到來的 QCon北京2019 邀請了多位國內外知名企業的技術專家，與大家分享各種新型實時計算技術和大數據平臺架構的發展趨勢，並展示在一線生產場景的應用案例。
Flink 流批一體的技術架構以及在阿里的實踐 / 阿里巴巴高級技術專家楊克特（魯尼）
騰訊實時流計算平臺演進之路 / 騰訊 高級工程師楊華
ByteMQ: A distributed message queue towards scalability / 字節跳動消息隊列技術負責人龔雲飛
流式數據處理在百度數據工廠應用與實踐 / 百度高級研發工程師李俊卿
Pulsar 如何爲批和流處理提供高效統一的數據存儲 / StreamNative核心工程師翟佳
使用 TiDB 進行實時數據分析 / PingCAP 分析型產品負責人馬曉宇
攜程基於Flink構建實時智能異常檢測平臺Prophet實踐 / 攜程資深研發工程師潘國慶
蘇寧 OLAP 引擎發展之路 / 蘇寧科技集團 OLAP 平臺負責人趙雲
大數據 ClickHouse 在頭條的技術演進 / 字節跳動高級研發工程師陳星
Apache Hadoop 機器學習引擎 Submarine 及生態 / 網易杭州研究院機器學習開發組負責人劉勳
美團點評常態、異地、多機房、單集羣 Hadoop 架構實踐 / 美團點評大數據技術專家劉俊宏
快手萬億級別 Kafka 集羣應用實踐與技術演進之路 / 快手高級架構師大數據架構團隊負責人趙健博
阿里巴巴新一代交互式分析引擎 Hologres / 阿里巴巴高級技術專家金曉軍
滴滴大數據研發平臺最佳實踐 / 滴滴高級專家工程師曾文秋
點此查看 更多可參考案例。大會報名現已進入倒計時，團購可享折扣優惠！席位有限，馬上拿起電話聯繫票務小姐姐 Ring 吧：電話/微信：17310043226