淘寶大數據之路

免費開通大數據服務：https://www.aliyun.com/product/odps

轉載yanchun

2003年至今淘寶網從零開始飛速發展，走過了13個年頭，支撐淘寶業務野蠻式生長背後是一套不斷完善的技術平臺，淘寶大數據平臺，就是其中很是重要的一個組成部分，承擔了數據採集、加工處理、數據應用的職責，淘寶大數據平臺一路到今天，總共經歷了三個大的階段（如圖1），不一樣階段面臨了不同的挑戰，隨着個人理解回顧下這些年大數據所經歷過的故事：

圖1 數據倉庫平臺發展三個階段

第一個階段：RAC時代

      2008年前的單節點ORACLE，這個時候還稱不上數據倉庫，只能承擔簡單的數據處理工做，也基本上沒有數據倉庫架構，隨着業務的飛速發展，很快單節點的ORACLE因無擴展能力，計算存儲能力就應付不了了；

      2008年以後，爲了應對日益增加的數據量，RAC集羣應運而生，從一開始的4個節點逐步發展到20個節點，成爲當時號稱全球最大的RAC集羣，在ORACLE官網上也做爲了經典案例，RAC集羣當時無論在穩定性、安全性、存儲能力仍是計算能力都表現很是優秀，隨之而來第一代數據倉庫架構也逐步造成；

      這個階段數據的ETL過程主要經過ORACLE的存儲過程實現，大量的SQL腳本任務運行在集羣上，任務運行的調度過程是經過Crontab來進行控制管理，隨着任務數的不斷增加，這時面臨最大的問題是如何保證這成千上萬的腳本天天是正常運行，出錯後如何及時發現解決，這在當時每天困擾着開發，一直處於天天救火的狀態，也就是這個時候，爲了解決這個難題，數據團隊開始自主研發調度系統，並將之命名爲天網調度系統，造成了以下第一代調度系統的架構和原型：

圖2 天網調度系統架構

圖3 天網調度系統原型

第二個階段：HADOOP時代

      調度系統的上線很好的解決了天天救火的狀態，可是好景不常在；2008年，淘寶B2C新平臺淘寶商城（天貓前身）上線；2009年，淘寶網成爲中國最大的綜合賣場；2010年1月1日 淘寶網發佈全新首頁，此後聚划算上線，而後又推出一淘網；業務的飛速發展給數據帶來的挑戰，就是天天處理的數據量也在不斷的翻倍，首先碰上瓶頸的是RAC集羣針對網站的訪問日誌數據已經搞不定了，RAC集羣雖然有必定的擴展能力，可是沒法無限制的線性擴展，而且擴容就意味着高昂的機器成本和軟件成本，爲了應對日益增加的數據量，2009年數據團隊開始探索新的技術領域，同時探索應用了兩個方向的技術：Greenplum 和 Hadoop，主要的場景就是用來解決海量的日誌數據，Hadoop因其良好的線性擴展能力，而且是開源的系統，可以基於官方版本二次開發適合淘寶的特性功能，逐漸佔據了優點；

      2010年初，最終肯定放棄Greenplum和RAC，全面使用Hadoop，也就是這個時候我加入了淘寶數據團隊，以後不久數據團隊啓動了去O項目，整個數據團隊歷經一個多月時間，風風火火將全部RAC上的存儲過程，改寫成HIVE和MR腳本，並將全部的數據都搬到了Hadoop上，Hadoop集羣命名爲雲梯1，造成了Hadoop時代的數據倉庫架構，以下圖4：

圖4 雲梯1數據倉庫架構

      進入2010年末，數據應用場景愈來愈多，2010年末發佈了量子統計（淘寶官方版），2011年4月1日淘寶發佈了數據魔方，將數據對外進行開放，廣告和搜索團隊也大量將數據應用到業務系統中，對內的淘數據產品也愈來愈成熟，數據的大量應用，帶來的一個問題是如何保證數據的準確性和穩定性，須要從數據採集到數據加工及最終的數據應用全流程的保障；

      這時第一個環節就碰到了問題，數據同步，業務系統有各類各樣的數據源，ORACLE、MYSQL、日誌系統、爬蟲數據，當時有多種同步的方式，有經過SHELL腳本的、也有經過Jdbcdump的、還有別的方式，當時負責數據同步的同窗，最痛苦的事情莫過於，業務系統進行數據庫變動時，各類同步任務須要不斷的調整，每次調整幾百個任務極其容易出錯，當時爲了解決數據同步的問題，數據工具團隊開始研發專門的同步工具DATAX，也就是如今同步中心的前身，同時還研發了針對DB的實時同步工具Dbsync和針對日誌的TT，如今統一叫TT，如圖5：

圖5 雲梯1數據同步工具

      天網調度系統也不斷進行完善，開始支持小時調度、甚至分鐘調度，而且集成了自動告警等一系統功能，升級爲在雲端，相關的DQC系統、數據地圖、血緣分析等周邊系統在這個時期不斷推出，數據團隊也不在斷壯大。

      在這期間，雙十一網購狂歡節的影響力不斷放大，已成爲中國電子商務行業的年度盛事，而且逐漸影響到國際電子商務行業，不斷刷新的成交記錄刺激着全部人的神經。這時爲了直觀的提供第一線的數據給到決策層，產生了數據直播間的數據應用，須要活動當天及統計相關的數據，2013年前，採用的方式都是基於Hadoop一個小時計算一次的方式進行數據計算，數據存在必定的延遲性，從2013年開始，數據團隊開始投入研發實時計算平臺，也就是如今的galaxy，並在當年的雙11上線了第一個應用，雙11數據直播間實時版本。

 

第三個階段：MaxCompute（原ODPS）自主研發的大數據平臺時代

      就在Hadoop大量應用的同時，另一個項目正在悄悄進行，那就是阿里雲團隊自主研發的ODPS系統，ODPS全部的代碼都由阿里本身完成，在統1、安全、可管理、能開放方面相比於Hadoop作了大量的完善，ODPS系統命名爲雲梯二，從2010年開始，在很長一段時間內，一直處於雲梯一和雲梯二並存的狀態；

      這期間，集團爲更好的打造數據生態，成立了CDO，統一數據平臺事業羣，專門投入研發大數據平臺的相關工具，包含計算存儲平臺、周邊的調度系統、元數據血緣系統、數據質量管理系統、還有DQC等；

      這個狀態持續到2013年4月， 這時出現了一個新的挑戰，Hadoop集羣的上限是5000個節點，按照當時數據增加數據的推算，集羣存儲即將撞牆，可是基於當時的情況，ODPS沒法徹底替代Hadoop，因而當時啓動了一個規模很是龐大的項目，叫作「5K項目」，同時進行雲梯一和雲梯二的跨機房集羣項目，當時世界上沒有任何一家公司具有跨機房的能力，存在很是大的技術挑戰，最後項目歷經近5個月的週期，攻克大量技術難點，項目取得了成功；

      在「5K項目」成功的同時，ODPS架構逐步成熟，因而全集團又啓動了一個規模更龐大的項目，叫作「登月項目」，將全集團的數據加工應用所有搬移到ODPS，項目一直持續到2015年，Hadoop正式下線，淘寶大數據完全進入ODPS時代，整個數據的生態圈也愈來愈豐富，同時，阿里雲開始對外提供雲服務，其中大數據解決方案做爲其中重要的組成部分，也開始對外提供；

      時間回到2013年時，當時淘寶數據團隊的每一個成員都在忙於應對各種需求，天天都有作不完的各種報表，當時爲了解救本身，數據團隊開始摸索探索新的數據服務模式，思考如何解決數據冗餘、口徑統1、數據交換、用戶自助等一系統問題，最終經過一段時間思考和摸索，開始研發孔明燈產品，針對不一樣的數據角色造成了一套完整的數據解決方案，以下：

圖6 孔明燈解決方案

      孔明燈產品的出現，對傳統的開發模式作了個升級，對整個大數據建設也起到了很是好的管理做用，當時在淘寶內部，覆蓋了大部分的業務BU，對數據使用成本的下降，釋放了大量的人力，同時也吸引了外部用戶高德地圖、阿里健康基於這套體系進行大數據建設；

      2014年，集團公共層項目啓動，集團內的各個數據團隊，開始進行數據內容重構和整合，同時，CCO正式成立，七公來到CCO帶領技術團隊，薛奎來到CCO帶領數據倉庫團隊，CCO也基於ODPS啓動公共層建設項目，集成了包括淘系、168八、ICBU、AE相關的服務數據，公共層建設的同時完成了登月項目，而且與DIC團隊、RDC團隊協同建設了服務數據門戶DIGO產品；

      今天，數據在阿里巴巴已經深刻到每一個角落，阿里雲有強大的算法團隊、大批的數據接口人、分析師，天天的工做都與數據產生關聯，隨着人工智能的不斷深刻使用，業務系統的不斷創新迭代，對數據的採集、加工、應用又提出了新的要求，如何更好的提供數據服務，面對將來咱們須要思考更多，數據將進入一個新的時代-數據智能時代。