阿里7 億元收購 Apache Flink 商業公司 DataArtisans

2020-12-13 IT168

  據歐洲外媒Deutsche Startups報導,阿里巴巴集團以1.033億美元(9000萬歐元)的價格收購了總部位於柏林的初創公司Data Artisans。

  Data Artisan成立於2014年,專門提供為公司企業部署大規模數據處理解決方案的服務。該公司的解決方案可以實時管理和部署這類數據,以便客戶更合理更快速地做出決策。Data Artisans由開源數據流處理技術Apache Fink的幾位開發者創辦。

  據Data Artisans官網介紹,其dA平臺由Apache Flink和dA Application Manager組成,「包括與容器編排、持續集成/持續交付(CI/CD)、日誌記錄、度量指標和狀態存儲整合的隨時可用的功能,為公司客戶提供了單一視圖,以便了解所有的數據流處理應用。」其客戶包括荷蘭國際集團(ING)、Netflix、優步、Lyft、阿里巴巴、eBay、康卡斯特、華為和King等。

  從阿里技術公眾號分享的一篇《阿里巴巴為什麼選擇Apache Flink?》的文章中可看出端倪,阿里巴巴計算平臺事業部資深技術專家莫問在雲棲大會的演講時表示隨著人工智慧時代的降臨,數據量的爆發,在典型的大數據的業務場景下數據業務最通用的做法是:選用批處理的技術處理全量數據,採用流式計算處理實時增量數據。在絕大多數的業務場景之下,用戶的業務邏輯在批處理和流處理之中往往是相同的。但是,用戶用於批處理和流處理的兩套計算引擎是不同的。

  因此,用戶通常需要寫兩套代碼。

  毫無疑問,這帶來了一些額外的負擔和成本。阿里巴巴的商品數據處理就經常需要面對增量和全量兩套不同的業務流程問題,所以阿里就在想,我們能不能有一套統一的大數據引擎技術,用戶只需要根據自己的業務邏輯開發一套代碼。這樣在各種不同的場景下,不管是全量數據還是增量數據,亦或者實時處理,一套方案即可全部支持,這就是阿里選擇Flink的背景和初衷。

  目前開源大數據計算引擎有很多選擇,流計算如Storm,Samza,Flink,Kafka Stream等,批處理如Spark,Hive,Pig,Flink等。而同時支持流處理和批處理的計算引擎,只有兩種選擇:一個是Apache Spark,一個是Apache Flink。

  從技術,生態等各方面的綜合考慮。首先,Spark的技術理念是基於批來模擬流的計算。而Flink則完全相反,它採用的是基於流計算來模擬批計算。

  從技術發展方向看,用批來模擬流有一定的技術局限性,並且這個局限性可能很難突破。而Flink基於流來模擬批,在技術上有更好的擴展性。從長遠來看,阿里決定用Flink做一個統一的、通用的大數據引擎作為未來的選型。

  Flink是一個低延遲、高吞吐、統一的大數據計算引擎。在阿里巴巴的生產環境中,Flink的計算平臺可以實現毫秒級的延遲情況下,每秒鐘處理上億次的消息或者事件。同時Flink提供了一個Exactly-once的一致性語義。保證了數據的正確性。這樣就使得Flink大數據引擎可以提供金融級的數據處理能力。

  Flink在阿里的現狀

  基於Apache Flink在阿里巴巴搭建的平臺於2016年正式上線,並從阿里巴巴的搜索和推薦這兩大場景開始實現。目前阿里巴巴所有的業務,包括阿里巴巴所有子公司都採用了基於Flink搭建的實時計算平臺。同時Flink計算平臺運行在開源的Hadoop集群之上。採用Hadoop的YARN做為資源管理調度,以 HDFS作為數據存儲。因此,Flink可以和開源大數據軟體Hadoop無縫對接。

  目前,這套基於Flink搭建的實時計算平臺不僅服務於阿里巴巴集團內部,而且通過阿里雲的雲產品API向整個開發者生態提供基於Flink的雲產品支持。

  Flink在阿里巴巴的大規模應用,表現如何?

  規模:一個系統是否成熟,規模是重要指標,Flink最初上線阿里巴巴只有數百臺伺服器,目前規模已達上萬臺,此等規模在全球範圍內也是屈指可數;

  狀態數據:基於Flink,內部積累起來的狀態數據已經是PB級別規模;

  Events:如今每天在Flink的計算平臺上,處理的數據已經超過萬億條;

  PS:在峰值期間可以承擔每秒超過4.72億次的訪問,最典型的應用場景是阿里巴巴雙11大屏;

  Flink的發展之路

  接下來從開源技術的角度,來談一談Apache Flink是如何誕生的,它是如何成長的?以及在成長的這個關鍵的時間點阿里是如何進入的?並對它做出了那些貢獻和支持?

  Flink誕生於歐洲的一個大數據研究項目StratoSphere。該項目是柏林工業大學的一個研究性項目。早期,Flink是做Batch計算的,但是在2014年,StratoSphere裡面的核心成員孵化出Flink,同年將Flink捐贈Apache,並在後來成為Apache的頂級大數據項目,同時Flink計算的主流方向被定位為S

  treaming,即用流式計算來做所有大數據的計算,這就是Flink技術誕生的背景。

  2014年Flink作為主攻流計算的大數據引擎開始在開源大數據行業內嶄露頭角。區別於Storm,Spark Streaming以及其他流式計算引擎的是:它不僅是一個高吞吐、低延遲的計算引擎,同時還提供很多高級的功能。比如它提供了有狀態的計算,支持狀態管理,支持強一致性的數據語義以及支持Event Time,WaterMark對消息亂序的處理。

  Flink核心概念以及基本理念

  Flink最區別於其他流計算引擎的,其實就是狀態管理。

  什麼是狀態?例如開發一套流計算的系統或者任務做數據處理,可能經常要對數據進行統計,如Sum,Count,Min,Max,這些值是需要存儲的。因為要不斷更新,這些值或者變量就可以理解為一種狀態。如果數據源是在讀取Kafka,RocketMQ,可能要記錄讀取到什麼位置,並記錄Offset,這些Offset變量都是要計算的狀態。

  Flink提供了內置的狀態管理,可以把這些狀態存儲在Flink內部,而不需要把它存儲在外部系統。這樣做的好處是第一降低了計算引擎對外部系統的依賴以及部署,使運維更加簡單;第二,對性能帶來了極大的提升:如果通過外部去訪問,如Redis,HBase它一定是通過網絡及RPC。如果通過Flink內部去訪問,它只通過自身的進程去訪問這些變量。同時Flink會定期將這些狀態做Checkpoint持久化,把Checkpoint存儲到一個分布式的持久化系統中,比如HDFS。這樣的話,當Flink的任務出現任何故障時,它都會從最近的一次Checkpoint將整個流的狀態進行恢復,然後繼續運行它的流處理。對用戶沒有任何數據上的影響。

  Flink是如何做到在Checkpoint恢復過程中沒有任何數據的丟失和數據的冗餘?來保證精準計算的?

  這其中原因是Flink利用了一套非常經典的Chandy-Lamport算法,它的核心思想是把這個流計算看成一個流式的拓撲,定期從這個拓撲的頭部Source點開始插入特殊的Barries,從上遊開始不斷的向下遊廣播這個Barries。每一個節點收到所有的Barries,會將State做一次Snapshot,當每個節點都做完Snapshot之後,整個拓撲就算完整的做完了一次Checkpoint。接下來不管出現任何故障,都會從最近的Checkpoint進行恢復。

  Flink利用這套經典的算法,保證了強一致性的語義。這也是Flink與其他無狀態流計算引擎的核心區別。

  下面介紹Flink是如何解決亂序問題的。比如星球大戰的播放順序,如果按照上映的時間觀看,可能會發現故事在跳躍。

  在流計算中,與這個例子是非常類似的。所有消息到來的時間,和它真正發生在源頭,在線系統Log當中的時間是不一致的。在流處理當中,希望是按消息真正發生在源頭的順序進行處理,不希望是真正到達程序裡的時間來處理。Flink提供了Event Time和WaterMark的一些先進技術來解決亂序的問題。使得用戶可以有序的處理這個消息。這是Flink一個很重要的特點。

  接下來要介紹的是Flink啟動時的核心理念和核心概念,這是Flink發展的第一個階段;第二個階段時間是2015年和2017年,這個階段也是Flink發展以及阿里巴巴介入的時間。故事源於2015年年中,我們在搜索事業部的一次調研。當時阿里有自己的批處理技術和流計算技術,有自研的,也有開源的。但是,為了思考下一代大數據引擎的方向以及未來趨勢,我們做了很多新技術的調研。

  結合大量調研結果,我們最後得出的結論是:解決通用大數據計算需求,批流融合的計算引擎,才是大數據技術的發展方向,並且最終我們選擇了Flink。

  但2015年的Flink還不夠成熟,不管是規模還是穩定性尚未經歷實踐。最後我們決定在阿里內部建立一個Flink分支,對Flink做大量的修改和完善,讓其適應阿里巴巴這種超大規模的業務場景。在這個過程當中,我們團隊不僅對Flink在性能和穩定性上做出了很多改進和優化,同時在核心架構和功能上也進行了大量創新和改進,並將其貢獻給社區,例如:Flink新的分布式架構,增量Checkpoint機制,基於Credit-based的網絡流控機制和Streaming SQL等。

  Flink的未來方向

  首先,阿里巴巴還是要立足於Flink的本質,去做一個全能的統一大數據計算引擎。將它在生態和場景上進行落地。目前Flink已經是一個主流的流計算引擎,很多網際網路公司已經達成了共識:Flink是大數據的未來,是最好的流計算引擎。下一步很重要的工作是讓Flink在批計算上有所突破。在更多的場景下落地,成為一種主流的批計算引擎。然後進一步在流和批之間進行無縫的切換,流和批的界限越來越模糊。用Flink,在一個計算中,既可以有流計算,又可以有批計算。

  第二個方向就是Flink的生態上有更多語言的支持,不僅僅是Java,Scala語言,甚至是機器學習下用的Python,Go語言。未來我們希望能用更多豐富的語言來開發Flink計算的任務,來描述計算邏輯,並和更多的生態進行對接。

  最後不得不說AI,因為現在很多大數據計算的需求和數據量都是在支持很火爆的AI場景,所以在Flink流批生態完善的基礎上,將繼續往上走,完善上層Flink的Machine Learning算法庫,同時Flink往上層也會向成熟的機器學習,深度學習去集成。比如可以做Tensorflow On Flink, 讓大數據的ETL數據處理和機器學習的Feature計算和特徵計算,訓練的計算等進行集成,讓開發者能夠同時享受到多種生態給大家帶來的好處。

相關焦點

  • 一篇文章讓深入理解Flink SQL 時間特性
    _import org.apache.flink.table.api.Tableimport org.apache.flink.table.api.scala._import org.apache.flink.table.api.EnvironmentSettingsimport org.apache.flink.table.api.scala.
  • Flink最難知識點再解析 | 時間/窗口/水印/遲到數據處理
    org.apache.flink.streaming.api.functions.AssignerWithPeriodicWatermarksimport org.apache.flink.streaming.api.scala.function.WindowFunctionimport org.apache.flink.streaming.api.scala.
  • Apache Flink 1.5.5 和 1.6.2 發布,通用數據處理平臺
    </groupId>  <artifactId>flink-java</artifactId>  <version>1.5.5</version></dependency><dependency>  <groupId>org.apache.flink</groupId>  <artifactId
  • flink-1.12.0 upsert-kafka connector demo
    :198) at org.apache.flink.client.ClientUtils.executeProgram(ClientUtils.java:114) at org.apache.flink.client.cli.CliFrontend.executeProgram(CliFrontend.java:743) at org.apache.flink.client.cli.CliFrontend.run
  • Flink寫入hive測試
    hadoop 2.7.6二、pom文件<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http
  • Apache Flink 誤用之痛
    郵件列表:user@flink.apache.com/user-zh@flink.apache.orgStack Overflow:www.stackoverflow.com2.另外,也要避免圖7中的這種滑動窗口,在圖7中每個記錄被50萬個窗口計算,無論是計算資源還是業務延遲都會非常糟糕。
  • 阿里為什麼要拿下Flink?
    如果這不是因為阿里新年消費的第一個大單,更多人知道Flink或許還會晚一點。據歐洲外媒Deutsche Startups報導,阿里巴巴集團以1.033億美元(9000萬歐元)的價格收購了總部位於柏林的初創公司Data Artisans。此消息之後得到了多家媒體從阿里處的證實。
  • Apache Beam實戰指南 | 手把手教你玩轉KafkaIO與Flink
    >  <version>2.4.0</version> </dependency> <dependency>  <groupId>org.apache.flink</groupId>  <artifactId>flink-java</artifactId>
  • 「阿里收購餓了麼,寫一份商業分析報告給我」
    ,其實就是阿里在收購前要解決的兩個問題:為什麼要收購?2018年的市場規模預計比2017年增加368億元。 所以說在線外賣市場規模大,而且有增長空間。 三、可行性分析 從收購經驗來看,阿里作為中國網際網路三大巨頭之一,近年不斷通過收購公司來開拓新市場,其收購經驗非常豐富。
  • 數據說話:大數據處理引擎Spark與Flink比拼
    Flink 任務圖(來源:https://ci.apache.org/projects/flink/flink-docs-release-1.5/concepts/runtime.html)  在 DAG
  • 阿里20 億元收購香港上市彩票公司亞博科技
    香港上市公司亞博科技發布公告,聲明該公司已經被Ali Fortune Investment Holding Limited(阿里財富投資控股有限公司)以23.88億港幣完成收購(折合人民幣20.5億元)。亞博科技控股周五收盤漲幅超過21%。
  • 阿里正式開源通用算法平臺Alink,「雙11」將天貓推薦點擊率提升4%
    在他看來,作為中國企業是GitHub上十大貢獻者之一,阿里致力於在軟體開發周期中儘早與開源社區建立聯繫。而在 GitHub 上開源 Alink 遵循了這一承諾。阿里目前已將 Alink 部署到其旗下電子商務平臺天貓上。
  • 萬字詳解Flink極其重要的Time與Window(建議收藏)
    根據數據進行截取(data-driven-window),比如每5個數據統計一次或每50個數據統計一次。 1import org.apache.flink.streaming.api.scala.StreamExecutionEnvironment 2import org.apache.flink.api.scala.
  • Flink保證端到端exactly-once語義(也適用於kafka)
    作者:Moon_Storm連結:https:英文連結:https:來源:簡書2017年12月,apache
  • 開篇|揭秘 Flink 1.9 新架構,Blink Planner 你會用了嗎?
    <dependency><groupId>org.apache.flink</groupId><artifactId>flink-table-api-scala-bridge_2.11</artifactId><version>1.9.0</version></dependency><
  • Flink 端到端 Exactly-once 機制剖析
    但是,flink有很多外接系統,比如將數據寫到kafka,一旦作業失敗重啟,offset重置,會消費舊數據,從而將重複的結果寫到kafka。如下圖:      這個時候,僅靠系統本身是無法保證exactly-once的。系統之間的數據一致性一般要靠2PC協議來保證,flink的TwoPhaseCommitSinkFunction也是基於此實現的。
  • 阿里全資收購中天微 力主研發AI「中國芯」
    對此,阿里巴巴集團技術部門負責人表示,此次收購基於阿里對晶片領域的長期關注和自身業務需求,並且希望藉此收購在物聯網、人工智慧等晶片競爭「新賽道」上,提升中國晶片競爭力。阿里巴巴集團首席技術官張建鋒表示,收購一家公司不是一天兩天能決定的。這次出手有基於技術發展、業務發展、生態發展等方面的長遠規劃。
  • 寫在阿里Blink正式開源之際
    代碼質量理論上應該是沒有原生flink好的。這個需要時間,不是靠人力就能搞定的。一點憂思阿里收購Flink母公司,然後馬上發通告,說blink要合併進flink了,之前還是商量口吻。顯然,這對於社區來說,是一個非常不友好的感覺。我猜測,社區部分優秀的人才(包括母公司)肯定會有人走的。
  • Structured Streaming與Flink比較
    Flink支持三種時間,同時flink支持基於事件驅動的處理模型,同時在聚合等算子存在的時候,支持狀態超時自動刪除操作,以避免7*24小時流程序計算狀態越來越大導致oom,使得程序掛掉。7. 觸發處理模型這個之所以講一下區別,實際緣由也很簡單,Structured Streaming以前是依據spark的批處理起家的實時處理,而flink是真正的實時處理。那麼既然Structured Streaming是批處理,那麼問題就簡單了,批次執行時間和執行頻率自然是有限制的,就產生了多種觸發模型,簡單稱其為triggers。
  • 實戰|Kafka + Flink + Redis 的電商大屏實時計算案
    前言數據格式與接入統計站點指標商品Top NThe End前言阿里的雙為了儘量穩妥,Flink官方也建議為每個算子都顯式地設定ID,參考:https://ci.apache.org/projects/flink/flink-docs-stable/ops/state/savepoints.html#should-i-assign-ids-to-all-operators-in-my-job插一下