阿裡巴巴全域資料建設
分享人：張磊（阿裡巴巴進階技術專家）
資料中台
阿裡巴巴資料技術及産品部定位
2016年阿裡巴巴集團提出中台概念，阿裡巴巴資料技術及産品部承載了集團資料中台的工作，其核心就是建設全域大資料。
從内容上看，我們管理和運維着阿裡巴巴集團最核心的基礎資料；
從技術上看，我們覆寫了從資料采集、計算加工到資料服務、資料應用等資料鍊路上的每一個環節，為阿裡生态内外的業務、使用者、中小企業提供全鍊路、全管道的資料服務。
舉個例子，被大家熟知的雙11當天可見炫酷資料大屏就是由我們部門負責的。
資料中台全景圖
上圖是阿裡資料中台的全景圖，從這個圖中我們可以看見實際上阿裡資料中台在架構的組成上，呈現了一個“四橫三縱”的結構，底層的基礎設施來自于阿裡雲平台。
先來講四橫。整張架構圖從下往上看，最下面這塊内容主要從資料采集和接入為角度，按照業态接入資料（比如淘寶、天貓、盒馬等），我們把這些資料抽取到計算平台；接着通過OneData體系，以“業務闆塊+分析次元”為架構去建構“公共資料中心”；再基于公共資料中心在上層根據業務需求去建設：消費者資料體系、企業資料體系、内容資料體系等；經過深度加工後，資料就可以發揮其價值被産品、業務所用；最後通過統一的資料服務中間件“OneService”提供統一資料服務。
在阿裡内部，阿裡資料平台上的資料産品已有幾十種，每天有上萬内部員工在使用資料産品；我們的官方統一資料産品平台“生意參謀”累計服務了超2000萬商家……
接下來是三縱。基于阿裡巴巴如此大體量的資料體系建設背後，我們必須要通過大量工具去保證快速、高效、高品質資料接入，這部分我們通過智能資料研發平台來實作，将我們的理論及實踐過程，通過一整套的工具體系及研發流程去保障落地，確定每一個團隊，每一個BU，通過統一規則去建設資料體系；同時，當資料多了以後最直接問題就是成本，是以我們還建立了統一的資料品質管理平台。
全域資料到底是什麼？
阿裡巴巴目前生态建設包括了核心的電商業務，淘寶、天貓、聚劃算等，同時還有文娛闆塊的優酷、洋芋、UC浏覽器等，當然還有本地化服務比如口碑、餓了麼等。基于業态背後還有螞蟻、菜鳥、阿裡媽媽、阿裡雲等等。
這一系列的生态資料我們都會集中進行存儲和管理，并構成了我們的全域資料所覆寫的範圍。
一方面，上述每一種業态都是全域資料的來源；另外一方面基于這些優質的資料，進行解析和處理，再反哺給到業務。我們要實作的是：利用全域資料去驅動業務，讓資料發揮更大價值。
以手淘為例，手機螢幕是非常小的，我們如何在有限的空間内展示給到使用者看到他們真正希望看見的内容？“千人千面”這一應用的背後，實際上就是基于大資料的算法應用場景，來實作的。還有芝麻信用、菜鳥的智能物流、阿裡媽媽的精準營銷等等，它們都是通過大資料驅動之下，構成了業務與資料聯通的閉環。
阿裡全域資料建設的初衷
我們為什麼要做全域資料？
首先，降低成本。大家都知道大資料建設的資金投入其實是非常巨大的。比如基礎建設的投入、機房、機架、伺服器、網絡帶寬，包括軟體平台建設，開發運維團隊的組建等等，都會耗費企業大量的資金和人力。以優土（優酷洋芋的簡稱）為例，優土去年加入阿裡巴巴集團之後，我們開始啟動資料融合項目：在此之前，優土有自己的Hadoop叢集，阿裡巴巴的資料規模則大的多，将優土資料融合到阿裡大平台上，可以讓優土獲得更多彈性資源，也可以在基礎設施運維、人力運維、平台運維上複用集團的技術體系；基于OneData大資料建設體系、統一的資料采集規範等，減少人力及運維成本。當項目完結後，我們發現目前優土在資料建設上的成本不到原來50%。
其次，技術賦能。客觀來說，在阿裡生态内公司的資料能力參差不齊，是以為了賦能其他生态公司，我們通過短時間的資料體系遷移，讓他們擁有和阿裡集團同樣的大資料能力。上述的優土融合項目就是通過半年時間，實作了技術賦能。
第三，資料連接配接。我們知道資料孤島的現象不光存在于傳統行業，網際網路行業也是一樣。是以隻有把資料連接配接起來，它才能發揮更大的價值，消除資料孤島，讓資料連接配接起來，也是我們進行全域資料建設的目的之一。
最後，賦能業務。無論我們的叢集規模有多大，服務體量有多大，最終還是要回歸業務、通過業務的資料表現來展現我們的價值——把資料體系統一後，除了讓業務可以更加準确、快速的擷取決策分析資料外，還能提供業務快速試錯的機會，最終為業務創新降低了門檻。
如何建設全域資料
在整個全域資料接入過程中，盡管基礎設施建設已經非常強大，但在實際過程中，我們仍然面對了諸多困難和挑戰。仍以優土為例，它的大資料機房在青島，阿裡集團大部分資料叢集都在内蒙古和張北，而涉及到資料遷移也絕不是“拉一根網線”這麼簡單——其中涉及到應用體系、大資料架構都需要定制方案去做；
另外，統一資料采集在接入的過程中也會就原有業務進行統一梳理，包括後面的資料驗證，做過資料的人應該都知道其中的痛點；同時在遷移過程中，原有的資料對業務的服務還不能停，這事情我們叫——飛機上換輪子，一邊要進行核心零部件更新，一邊還要保持高速飛行；
最後就是項目周期，基于現實情況，大資料建設一般需要較長的周期，無法在幾周内完工，因為大資料建設不是一蹴而就，而是一根體系化過程。
從基礎設施來看，阿裡經過電商發展，包括多年雙11這種特殊場景下的考驗，在基礎設施上，從資料中心到網絡到伺服器，到資料庫中間件、計算平台、資料平台、算法平台都有了非常多的沉澱。
是以，在建設全域資料的時候，我們要做的第一步就是将生态公司的資料在基礎設施階段就進行融合。
我們的資料元件劃分如下：
最底層——資料采集，這是資料的來源；中間——計算存儲平台：實時計算采用自主研發的Blink，離線則采用MaxCompute。
上圖則更詳細介紹了我們的資料元件：
基于使用者的網上行為去做資料采集（我們有PC和無線的采集體系）然後放到實時、離線計算平台上來，這兩個計算平台除本身計算能力外，還有許多基于SQL、Graph等可程式設計的能力，最上面就是研發工具、産品服務、BI工具。
有如此強有力的基礎支撐外，長在上面的應用能力也非常給力：以研發工具為例，阿裡有約兩萬名研發工程師，而每天基于阿裡資料平台開展工作的同學就有近一萬人！
基于這些豐富的大資料元件，大部分的研發同學、專業的或非專業的同學都能在上面基于大資料做一些探索和嘗試。
下面介紹我們在全域資料建設中的幾個體系。
首先看流量體系，這是網際網路行業和傳統行業最大的差別。
打個比方，如果我們把淘寶可以看做流量分發中心，使用者進來後把流量給到商品、給到賣家。那麼在進行流量資料采集時，大家可能會給出不同的方案。
我們基于阿裡巴巴多年的電商經驗，也沉澱出來了一套統一的流量采集規範——超級位置模型：
以淘寶的頁面為例：
站點就是淘寶，下面會有頁面、區塊、位置，這些都是可以根據業務實際需求去埋點，并直覺擷取頁面任何位置的資料，比如頁面概況分析、路徑分析、跳轉分析、頁面點選、使用者分析等等。業務方隻需要按照規範埋點，我們就能夠迅速給到基礎的流量分析能力，而基于此，配套對應的資料産品就可以解決80%的流量方面的資料問題。
其次，計算元件化。
衆所周知，基于網際網路的基礎内容其實是能夠固化下來特定需求，中間過程可以通過工程化能力去解決，然後迅速把這些東西配置出來，而不需要每一個需求都去做代碼開發計算——這就是計算元件化。
這樣做的好處首先就是；配置簡單、複用性高，同時，在注意統一規範後，未來接入uc、接入高德等業務，我們可以做到一鍵接入。
全域資料建設最核心的體系是——OneData體系。
目前，從整個大資料建設過程來看，它分為資料接入、規範定義、計算加工、資料驗證、資料穩定性，這幾個部分合并構成了整體的資料研發流程。
OneData體系工具是全域建設的保障——我們知道現在存儲和計算可能已不是瓶頸。随着分布式技術的發展，以Hadoop為典型代表，廉價的pc伺服器即可搭建出超強的計算能力，是以存儲和計算未來會變的越來越便宜，但相對昂貴的是工程師的時間成本。
是以，工具化是解決研發效率的關鍵一環。我們把大量機械、人肉、不産生價值的工作，通過工具去完成，比如從資料的接入開始，我們有OneClick保證高效接入，根據阿裡巴巴完善的中繼資料，我們有能力把基于業務db的資料一鍵拉到計算平台，這個過程幾乎不需要人的參與。
同時，通過OneDefine工具來確定資料建設過程是規範的，比如：模型分層、表命名規範、字段命名規範等。
再看計算過程，阿裡資料應用的群體在能力上是參差不齊的，有專業的資料研發、有算法工程師、有分析師、可能還有業務營運，很多人可能簡單自學SQL後，就可以自己跑資料：通常情況下，SQL品質無法保證，如果查詢的資料量非常大，可能背景幾千台機器就轉起來了，為避免類似情況發生，我們會在送出任務過程中做代碼校驗，對于性能問題、規範問題、代碼品質問題都會給出必要的提示，比如sql代碼對于除數為0沒有做代碼相容，比如我們的ddl語句中沒有做資料生命周期的設定，比如sql的query中沒有做分區的條件限制，甚至你的sql代碼别人已經計算過，可以複用結果不需要重新計算這些問題，我們都會給出精确到提示；
在資料研發過程中，代碼編寫可能隻占工作量的20%，那麼大部分時間都去幹嗎了？是資料驗證，代碼修改前和代碼修改後，資料到底差多少，差在哪兒？過去如果沒有工具隻能寫一堆角本，再去驗證，效率極其低下，而且極易出錯，現在有了“在彼岸”工具我們可以通過簡單的勾勾選選就知道前後差異到底差在哪？然後迅速給測試報告，保證整個研發過程的資料品質是有保障的。
最後，任務上線後，大量時間都在運維，監控資料品質、監控産出時間等等，這些日常要去關注的工作我們也會有相關的工具去支援，是以OneData體系工具是全域資料建設的重要保障。
工具有了，規範有了，我們還需要與研發流程全程打通，我們就可以確定規範真正的落實到每位開發者身上，是以我們可以這樣來了解研發流程：某位研發同學在做資料需求，要先把規範定義完成才能繼續進行代碼開發。
代碼開發中會有兩道檢查：
第一道是SQLscan：這裡面會檢查代碼規範性、代碼品質、可能出現的性能問題，把這些問題避免掉；
另一道是“在彼岸”資料測試，重要的資料做了資料變更後，會要求做回歸測試流程，輕松簡單的勾選，就可以快速給出測試。如果任務需在生産環境運作，這兩個環節必須完成後才能夠送出，上述過程就是整個基于OneData體系的研發流程。
目前阿裡巴巴資料總量已超EB級别，總表數也已經超百萬，這麼大體量下，如何能夠做到高效靈活卻又不失規範的大資料建設，我們确實探索了很長時間。
随着阿裡業務的不斷拓展，對于大資料能力的要求會越來越高，技術上，如何突破傳統數倉etl架構？我們從基礎設施的計算存儲分離、離線線上混布等事情上已經開始探索，相信在不久的将來，我們會對傳統數倉etl進行重新的定義。
來源：阿裡資料
<a href="https://mp.weixin.qq.com/s/3d80_wyaS15d2ffj429kDA">原文連結</a>