阿里巴巴大數據架構

① 目前各大互聯網公司如阿里，騰訊，滴滴，美團，今日頭條這些公司的大數據分析的框架是怎樣的求解答！

阿里，騰訊 實力強，估計是自己開發或二次開發的，其他公司估計會版用開源或商用權的，但本質都是相同的，舉例，不外乎一個分布式集群（hadoop），搭配一些部署組件（docker，zookeeper），分布MQ（kafka），處理&計算（spark，hive，MR），存儲（es，hbase，mongo），可視化的話選擇很多，比如vue，react，angular，畫圖可以選擇highchart，echarts。
上述基本都是必備的，每個公司還會根據自己的需求增加額外的組件。

② 大數據之路

人類從「IT時代」進入「DT時代」。本書介紹了阿里巴巴的大數據系統架構，為了滿足不斷變化的業務需求，同時實現系統的 高擴展性 、 靈活性 以及 數據展現的高性能 。
數據體系主要包括： 數據採集 、 數據計算 、 數據服務 和 數據應用 四大層次。

事實表包括引用的 維度 和描述具體業務的 度量 。

事實表中一條記錄描述的業務的細節程度稱為 粒度 。粒度可以使用兩種方式來表示：（1）維度屬性組合（2）所表示的具體業務含義。

事實包括可加性、半可加性和不可加性三種類型：
半可加性：只可以針對特定維度做聚合，例如庫存（不能按照日期，可按照倉庫聚合）。
可加性：可以按照任意維度聚合。
不可加性：完全不具備可加性。（例如：比率，事實表可以拆分存儲分子分母）

維度屬性也可以存到事實表中，稱為 退化維度 。

事實表有三種類型：事務事實表、周期快照事實表、累計快照事實表。
事務事實表描述的是業務過程上的原子事務，也稱為 原子事實表 。
周期快照事實表是按照周期性規律的時間間隔記錄事實。
累計快照事實表：累計快照事實表用來表示過程開始和結束過程之間的關鍵步驟事件，覆蓋整個生命周期，通常用多個日期欄位記錄關鍵時間點，記錄會隨著時間變化而修改。

事實表設計原則：
原則1： 盡可能包含所有與業務過程相關的事實。
即時存在冗餘，也盡可能存儲。

原則2：只選擇與業務過程相關的事實。

原則3：分解不可加事實為可加的組件。
例如：不存成單率，轉而存儲成單數和提單數。

原則4：選擇維度和事實前，必須先聲明粒度。
建議粒度設置的越細越好，這樣可以最大限度的提高靈活性。可以通過業務描述或者維度屬性組合的方式來定義粒度。

原則5：在同一個事實表中，不應該有不同粒度的事實。
例如：一個事實表中不應該包含某些精確到訂單粒度的度量，同時又包含只精確到城市的度量。

原則6：事實的單位一致。

原則7：盡量處理掉事實表中的null值。
SQL中大於，小於的條件不適用與null值，所以盡量用數值替代null，例如0.

原則8：使用退化維度增加事實表的易用性。
在Kimball的維度設計模型中，分拆出單獨的維度表，為了節省存儲。但是為了減少使用時的關聯次數，可以多使用退化維度提供事實表易用性。

事實表設計方法：
1.選擇業務過程及確定事實表類型。2. 聲明粒度。3.確定維度。4.確定事實。5.冗餘維度（設計退化維度）。

事務事實表，即針對業務過程構建的一類事實表，用來跟蹤定義業務過程的個體行為，提供豐富的分析能力，作為數據倉庫原子的明細數據。

單事務事實表，即針對每一個業務過程設計一個事實表，這樣可以方便地對每一個業務過程進行分析研究。

表示同一個事實表包含不同的業務過程。多事務事實表有兩種實現方法：（1）使用兩個不同的事實欄位來保存各自業務過程。（2）使用同一個欄位保存，但是增加一個業務過程標簽。
下面舉例說明，淘寶交易事務事實表同時包含下單、支付和成功完結三個過程，三個過程粒度一致，可以放在一個事實表。下面確定維度和事實，該表中的下單度量、支付度量和成功完結度量信息分別存在不同欄位，如果不是當前業務處理，則用0來處理。
當不同業務過程的度量比較相似、差異不大時使用第二種事實表（使用一個欄位保存），當不同業務過程的度量差異大時，使用第一種（多欄位保存）。

對於單事務事實表和多事務事實表的選擇上，可以從以下一些方面來區分：
業務過程、粒度和維度（不同業務過程粒度相同，並且維度相似時，可以選用單事務事實表）、事實、下游業務使用、計算存儲成本。電商環境下，有父子訂單的概念，店鋪多商品各生成一個訂單，在一個店鋪合成一個父訂單。

1.事實完整性：事實表包含與其描述的過程有關的所有事實。
2.事實一致性：明確存儲每一個事實以確保度量一致性。例如，有下單商品數和商品價格2個事實，同時保存下單金額（價格*商品數）。這樣下游使用時，直接取下單金額，而不是再次計算，以保證指標的一致性。
3.事實可加性：為確保下游使用時，指標的可聚合性，盡量保存原始數，而不是計算後的比率指標。

對於事務度量，事務性事實表可以很好地表徵。但是對於一些 狀態度量 ，例如買賣家累計交易金額、商品庫存、買賣家星級、溫度（事務事實表無法聚合得到）等，事務事實表的效率較低或者無法處理。為了解決狀態度量問題，引入周期性快照事實表（也稱為 快照事實表 ）。

1.用快照采樣狀態：快照事實表以預定的間隔采樣狀態度量。
2.快照粒度：快照事實表通常總是被多維聲明，即快照需要采樣的周期以及什麼將被采樣。
3.密度和稠密性：稠密性是快照事實表的重要特徵。事務事實表一般都是稀疏的，只要發生業務才會有相應記錄。
4.半可加性：快照事實表的狀態度量都是半可加的，例如商品庫存，只針對商品維度可加，對日期維度不可加。

設計快照事實表，首先確定快照粒度，然後確定采樣的狀態度量。下面介紹幾個快照事實表實例。
單維度每天快照事實表、混合維度每天快照事實表，這兩種快照表都可以從事務事實表匯總得到。另外的一種產出模式是直接使用操作型系統作為數據源來加工，例如淘寶賣家的星級評分是在操作型系統中計算得出的，倉庫直接拿來這部分數據加入事實表。全量快照事實表，是特殊類型的周期快照表，例如設計無事實的事實表來記錄評論的狀態度量。

對於研究事件之間的時間間隔需求時，累計快照事實表能較好符合需求。
特點：
1.數據不斷更新：例如，在下單、支付和確認收貨三個業務過程中，事務事實表會生成3條記錄，而累計快照表會不斷更新一條記錄（不生成新記錄）。
2.多業務過程日期：
累計快照表適用於具有較明確起止時間的短生命周期的實體，對於每個實體都經歷從誕生到消亡等步驟。
3.存儲歷史全量數據。

1.事件類的，例如瀏覽日誌。
2.條件范圍資格類的，例如客戶和銷售人員的分配情況。

主要是提前聚合，為了增加數據訪問的效率（不用再聚合了），減少數據不一致的情況。這類聚集匯總數據，被稱為「公共匯總層」。
聚集的基本步驟：1.確定聚集維度。2.確定一致性上鑽。3.確定聚集事實。

元數據主要記錄數據倉庫中模型的定義、各層級間映射關系、監控數據倉庫的數據狀態及ETL任務的運行狀態。元數據分為 技術元數據 和 業務元數據 。
阿里巴巴技術元數據包括：
數據表、列等信息；ETL作業的信息；數據同步、任務調度、計算任務等信息。數據質量和運維相關元數據。
阿里巴巴業務元數據包括：
維度屬性、業務過程、指標等。數據應用元數據，例如數據報表、數據產品等。

元數據價值：
元數據在數據管理方面為集團數據在計算、存儲、成本、質量、安全、模型等治理領域上提供數據支持。

阿里MaxCompute提供了archive壓縮方法，採用了具有更高壓縮比壓縮演算法，將數據以RAID file的形式存儲。這樣可以節省空間，但是恢復起來也更復雜，所以適用於冷備份的數據。

MaxCompute基於列存儲，通過修改表的數據重分布，避免列熱點，將會節省一定存儲空間。

存儲治理項以元數據為基礎，列出例如「62天內未訪問的分區」、「數據無更新的任務列表」等等管理項推動ETL優化。形成現狀分析、問題診斷、管理優化、效果反饋的存儲治理項優化的閉環。

生命周期管理的目的是用最少的存儲成本來滿足最大業務需求，實現數據價值最大化。
1.周期性刪除策略：
2.徹底刪除策略：主要針對無用表，ETL中間過程表。
3.永久保存策略：
4.極限存儲策略：
5.冷數據管理策略：針對重要且訪問頻率低的數據。
6.增量表merge全量表策略：

將一個數據表的成本分為存儲成本和計算成本，除此之外，上游表對該表的掃描成本也應該計入。相應的計費分別核算為：計算付費、存儲付費和掃描付費。數據資產的成本管理分為數據成本計量和數據使用計費。

③ 從IT到DT 阿里大數據背後的商業秘密

從IT到DT：阿里大數據背後的商業秘密

空氣污染究竟在多大程度上影響了人們的網購行為？有多少比重的線上消費屬於新增消費？為什麼中國的「電商百佳縣」中浙江有41個而廣東只有4個？
這些電商的秘密就隱藏在阿里巴巴商業生態的「大數據」中。
「未來製造業的最大能源不是石油，而是數據。」阿里巴巴董事局主席馬雲如此形容「數據」的重要意義。
在他看來，阿里巴巴本質上是一家數據公司，做淘寶的目的是為了獲得零售的數據和製造業的數據；做螞蟻金服的目的是建立信用體系；做物流不是為了送包裹，而是這些數據合在一起，「電腦會比你更了解你」。與此同時，產業的發展也正在從IT時代走向以大數據技術為代表的DT時代。
而在阿里巴巴內部，由電子商務、互聯網金融、電商物流、雲計算與大數據等構成的阿里巴巴互聯網商業生態圈，也正是阿里研究院所紮根的「土壤」。
具體而言，阿里巴巴平台的所有海量數據來自於數百萬充滿活力的小微企業、個人創業者以及數億消費者，阿里研究院通過對他們的商務活動和消費行為等進行研究分析，從某種程度上可以反映出一個地方乃至宏觀經濟的結構和發展趨勢。
而隨著阿里巴巴生態體系的不斷拓展和延伸，阿里巴巴的數據資源一定程度上將能夠有效補充傳統經濟指標在衡量經濟冷暖方面存在的滯後性，幫助政府更全面、及時、准確地掌握微觀經濟的運行情況。
從IT到DT
不同於一些企業以技術研究為導向的研究院，阿里研究院副院長宋斐告訴《第一財經日報》記者，阿里研究院定位於面向研究者和智庫機構，主要的研究方向包括未來研究（如信息經濟）、微觀層面上的模式創新研究（如C2B模式、雲端制組織模式）、中觀層面上的產業互聯網化研究（如電商物流、互聯網金融、農村電商等）、宏觀層面上新經濟與傳統經濟的互動研究（如互聯網與就業、消費、進出口等）、互聯網治理研究（如網規、電商立法）等。
具體到數據領域，就是在阿里巴巴互聯網商業生態基礎上，從企業數據、就業數據、消費數據、商品數據和區域數據等入手，通過大數據挖掘和建模，開發若干數據產品與服務。
例如，將互聯網數據與宏觀經濟統計標准對接的互聯網經濟數據統計標准，包括了中國城市分級標准；網路消費結構分類標准；網上商品與服務分類標准等。
而按經濟主題劃分的經濟信息統計資料庫則包括商品信息統計資料庫；網購用戶消費信息統計資料庫；小企業與就業統計資料庫；區域經濟統計資料庫。
還有反映電商經濟發展的「晴雨表」——阿里巴巴互聯網經濟系列指數。其中包括反映網民消費意願的阿里巴巴消費者信心指數aCCI、反映網購商品價格走勢的阿里巴巴全網網購價格指數aSPI和固定籃子的網購核心價格指數aSPI-core、反映網店經營狀態的阿里巴巴小企業活躍度指數aBAI、反映區域電子商務發展水平的阿里巴巴電子商務發展指數aEDI等等。其中，現有aSPI按月呈報給國家統計局。
而面向地方政府決策與分析部門的數據產品「阿里經濟雲圖」，則將分階段地推出地方經濟總覽、全景分析、監測預警以及知識服務等功能。宋斐告訴記者，其數據可覆蓋全國各省、市、區縣各級行政單位，地方政府用戶經過授權後，可以通過阿里經濟雲圖看到當地在阿里巴巴平台上產生的電子商務交易規模、結構特徵及發展趨勢。
「藉助數據可視化和多維分析功能，用戶可以對當地優勢產業進行挖掘、對消費趨勢與結構變動進行監測、與周邊地區進行對比等等。」宋斐表示，該產品未來還可以提供API服務模式，以整合更多的宏觀經濟數據和社會公開數據，為當地經濟全貌進行畫像，給大數據時代的政府決策體系帶來新的視角和工具。
數據會「說話」
對於如何利用「大數據」，馬雲在公司內部演講中曾提到：「未來幾年內，要把一切業務數據化，一切數據業務化。」
其中，後半句話可以理解為，讓阿里巴巴各項業務所產生、積累的大數據來豐富阿里的生態，同時讓生態蘊含的數據產生新的價值，再反哺生態，這是一個相輔相成的循環邏輯。
宋斐對記者舉例稱，螞蟻金服旗下的芝麻信用已獲得人民銀行個人徵信牌照批准籌備，未來將通過分析大量的網路交易及行為數據，如用戶信用歷史、行為偏好、履約能力、身份特質、人脈等信息，對用戶進行信用評估，這些信用評估可以幫助互聯網金融企業對用戶的還款意願及還款能力做出結論，繼而為用戶提供快速授信及現金分期服務。本質上來說，「芝麻信用」是一套徵信系統，該系統收集來自政府、金融系統的數據，還會充分分析用戶在淘寶、支付寶等平台的行為記錄。
再如，對於如火如荼的農村電商領域，阿里研究院從2010年就已開始對「沙集模式」個案進行研究，後續一系列基於數據和案例調研所驅動的農村電商研究成果，對於地方政府科學決策，推動當地農村電子商務發展、創造就業和發展地方經濟起到了助力作用。到2014年底，全國已經涌現了212個淘寶村，而阿里巴巴也在這一年啟動千縣萬村計劃,將在三至五年內投資100億元,在農村建立起電子商務服務體系。
除了通過數據分析去助力業務外，宋斐告訴記者，有時候大數據報告可能會與傳統的印象結論差異很大。
以區域電子商務為例，在阿里研究院發布的2014年中國電商百強縣排行榜中，浙江有41個縣入圍，福建有16個，而廣東只有4個，這個結果與傳統的印象相差比較大。而事實上，這是因為浙江和廣東兩省電商發展在地理分布、產業結構等方面的明顯不同而帶來的。
再如，外界常常認為網路零售替代了線下零售，但事實上，麥肯錫《中國網路零售革命：線上購物助推經濟增長》的研究報告，通過借鑒阿里研究中心（阿里研究院前身）和淘寶網UED用戶研究團隊的大量報告與數據，最後發現：「約60%的線上消費確實取代了線下零售；但剩餘的40%則是如果沒有網路零售就不會產生的新增消費。」
「這一研究成果，有助於社會各界准確認識網路零售與線下零售的關系，共同探索和建設良好的商業發展環境。」

④ 阿里巴巴的大數據包括

1. 大數據基礎服務包括 Maxcompute 分析型資料庫等

2. 大數據分析於展現包括內容 Date V Quick BI 畫像分析等
   

3. 大數據應用 包括 推薦引擎 企業圖譜

建議可以從阿里雲的大數據認證了解，參加阿里雲大數據認證培訓快速熟悉阿里雲產品

⑤ 阿里巴巴四大業務板塊

阿里巴巴集團經營多項業務，業務包括核心電商、雲計算、數字媒體和娛樂以及創新項目另外也從關聯公司的業務和服務中取得經營商業生態系統上的支援。業務和關聯公司的業務包括：淘寶網、天貓、聚劃算、全球速賣通、阿里巴巴國際交易市場、1688、阿里媽媽、阿里雲、螞蟻金服、菜鳥網路等。

2014年9月19日，阿里巴巴集團在紐約證券交易所正式掛牌上市，股票代碼「BABA」，創始人和董事局主席為馬雲。《財富》世界500強排行榜發布，阿里巴巴集團排名300位。2018年12月，阿里巴巴入圍2018世界品牌500強。

(5)阿里巴巴大數據架構擴展閱讀：

1、阿里巴巴業務板塊：

阿里系的電子商務服務、螞蟻金融服務、菜鳥物流服務、大數據雲計算服務、廣告服務、跨境貿易服務、前六個電子商務服務以外的互聯網服務。

2、阿里巴巴組織架構：

2012年7月23日，阿里巴巴集團對業務架構和組織進行調整，從子公司制調整為事業群制，成立淘寶、一淘、天貓、聚劃算、阿里國際業務、阿里小企業業務和阿里雲共七個事業群。

3、阿里巴巴業務模式：

阿里巴巴已經形成了一個通過自有電商平台沉積以及UC、高德地圖、企業微博等埠導流，圍繞電商核心業務及支撐電商體系的金融業務，以及配套的本地生活服務、健康醫療等，囊括游戲、視頻、音樂等泛娛樂業務和智能終端業務的完整商業生態圈。

參考資料來源：阿里巴巴官網-公司簡介

⑥ 阿里的總監將大數據、數字化的經驗，總結成資料干貨，可以收藏

阿里把企業的數字化轉型劃分為「數字化重構」和「數字化增長」兩大類別，這個概念是不是聽著很難懂？

重構，就是轉型嘛；增長，就是更進一步嘛，說白了還是原來的老樣子，換了個解釋而已。

說到數字化轉型，我覺得這是一個非常好的話題，甚至能衍生出很多干貨，無論是傳統企業，還是頂尖的互聯網大公司，如阿里騰訊，老闆都在朝這個方向努力。

所以和大數據有關的知識，還是很有必要學習的。

我給大家整理了很多干貨，我從一個10年從業者和管理者的角度，這份干貨，無論是底層幹活的，中層管控的，上層布局的，都能夠很清楚的學習到。

涉及到的方面還是很廣的：大數據、數倉、中台、AI、IT規劃、大數據平台、BI工具。

我是怎麼總結的？

從架構入手，到每個模塊的分解，再到每個地方的注意點，基本上就行了，太細的也不是通過文字去說清楚的。

只要能做到，看了干貨資料，能對實際工作產生指導，就可以了。

這只是一部分，還有更多，自己來看就好。

⑦ 阿里巴巴採用自己研發的分布式資料庫系統叫什麼,它有哪些特點

AanlyticDB，可以兼容Mysql5.x系列和抄SQL等，阿里巴巴襲自主研發、唯一經過超大規模以及核心業務驗證的PB級實時數據倉庫。自2012年第一次在集團發布上線以來，至今已累計迭代發布近百個版本，支撐起集團內的電商、廣告、菜鳥、文娛、飛豬等眾多在線分析業務。阿里巴巴最初通過單節點Oracle進行准實時分析,後來轉到OracleRAC，隨著業務的飛速發展,集中式的SharedStorage架構需要快速轉向分布式，遷移到了Greenplum，但不到一年時間便遇到擴展性和並發的嚴重瓶頸。為了迎接更大數據集、更高並發、更高可用、更實時的數據應用發展趨勢，從2011年開始，在線分析這個技術領域，阿里實時數倉堅定的走上了自研之路。特點和性能參考這個網路網頁鏈接

⑧ 阿里巴巴由哪些部門構成的，具體系統怎麼運作的

阿里巴巴由25個事業部組成。具體事業部的業務發展將由各事業部總裁（總經理）版負責。新體系由戰權略決策委員會和戰略管理執行委員會構成。阿里巴巴集團經營多項業務，另外也從關聯公司的業務和服務中取得經營商業生態系統上的支援。

25個事業部及其負責人：

(8)阿里巴巴大數據架構擴展閱讀

阿里巴巴網路技術有限公司（簡稱：阿里巴巴集團）是以曾擔任英語教師的馬雲為首的18人於1999年在浙江杭州創立。

阿里巴巴集團經營多項業務，另外也從關聯公司的業務和服務中取得經營商業生態系統上的支援。業務和關聯公司的業務包括：淘寶網、天貓、聚劃算、全球速賣通、阿里巴巴國際交易市場、1688、阿里媽媽、阿里雲、螞蟻金服、菜鳥網路等。

⑨ 阿里巴巴運用大數據包括哪些

1. 大數據計算服務（MaxCompute，原ODPS）

2. Data IDE（原BASE）

3. 數據集成（原CDP雲道）

4. 大數據基礎服務包括 Maxcompute 分析型資料庫等
   

5. 大數據分析於展現包括 Date V Quick BI 畫像分析等
   

6. 大數據應用 包括 推薦引擎 企業圖譜

⑩ 轉載：阿里巴巴為什麼選擇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計算的主流方向被定位為Streaming，即用流式計算來做所有大數據的計算，這就是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的Job調度和資源管理做了一個清晰的分層和解耦。這樣做的首要好處是Flink可以原生的跑在各種不同的開源資源管理器上。經過這套分布式架構的改進，Flink可以原生地跑在Hadoop Yarn和Kubernetes這兩個最常見的資源管理系統之上。同時將Flink的任務調度從集中式調度改為了分布式調度，這樣Flink就可以支持更大規模的集群，以及得到更好的資源隔離。

另一個是實現了增量的Checkpoint機制，因為Flink提供了有狀態的計算和定期的Checkpoint機制，如果內部的數據越來越多，不停地做Checkpoint,Checkpoint會越來越大，最後可能導致做不出來。提供了增量的Checkpoint後，Flink會自動地發現哪些數據是增量變化，哪些數據是被修改了。同時只將這些修改的數據進行持久化。這樣Checkpoint不會隨著時間的運行而越來越難做，整個系統的性能會非常地平穩，這也是我們貢獻給社區的一個很重大的特性。

經過2015年到2017年對Flink Streaming的能力完善，Flink社區也逐漸成熟起來。Flink也成為在Streaming領域最主流的計算引擎。因為Flink最早期想做一個流批統一的大數據引擎，2018年已經啟動這項工作，為了實現這個目標，阿里巴巴提出了新的統一API架構，統一SQL解決方案，同時流計算的各種功能得到完善後，我們認為批計算也需要各種各樣的完善。無論在任務調度層，還是在數據Shuffle層，在容錯性，易用性上，都需要完善很多工作。

篇幅原因，下面主要和大家分享兩點：

● 統一 API Stack

● 統一 SQL方案

先來看下目前Flink API Stack的一個現狀，調研過Flink或者使用過Flink的開發者應該知道。Flink有2套基礎的API，一套是DataStream，一套是DataSet。DataStream API是針對流式處理的用戶提供，DataSet API是針對批處理用戶提供，但是這兩套API的執行路徑是完全不一樣的，甚至需要生成不同的Task去執行。所以這跟得到統一的API是有沖突的，而且這個也是不完善的，不是最終的解法。在Runtime之上首先是要有一個批流統一融合的基礎API層，我們希望可以統一API層。

因此，我們在新架構中將採用一個DAG（有限無環圖）API，作為一個批流統一的API層。對於這個有限無環圖，批計算和流計算不需要涇渭分明的表達出來。只需要讓開發者在不同的節點，不同的邊上定義不同的屬性，來規劃數據是流屬性還是批屬性。整個拓撲是可以融合批流統一的語義表達，整個計算無需區分是流計算還是批計算，只需要表達自己的需求。有了這套API後，Flink的API Stack將得到統一。

除了統一的基礎API層和統一的API Stack外，同樣在上層統一SQL的解決方案。流和批的SQL，可以認為流計算有數據源，批計算也有數據源，我們可以將這兩種源都模擬成數據表。可以認為流數據的數據源是一張不斷更新的數據表，對於批處理的數據源可以認為是一張相對靜止的表，沒有更新的數據表。整個數據處理可以當做SQL的一個Query，最終產生的結果也可以模擬成一個結果表。

對於流計算而言，它的結果表是一張不斷更新的結果表。對於批處理而言，它的結果表是相當於一次更新完成的結果表。從整個SOL語義上表達，流和批是可以統一的。此外，不管是流式SQL，還是批處理SQL，都可以用同一個Query來表達復用。這樣以來流批都可以用同一個Query優化或者解析。甚至很多流和批的運算元都是可以復用的。

Flink的未來方向

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

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

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