原文地址：https://yq.aliyun.com/articles/62528
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所有的代碼都由阿里自己完成，在統一、安全、可管理、能開放方面相比於Hadoop做了大量的完善，ODPS系統命名為雲梯二，從2010年開始，在很長一段時間內，一直處於雲梯一和雲梯二並存的狀態；
這期間，集團為更好的打造數據生態，成立了CDO，統一數據平台事業群，專門投入研發大數據平台的相關工具，包含計算存儲平台、周邊的調度系統、元數據血緣系統、數據質量管理系統、還有DQC等；
這個狀態持續到2013年4月， 這時出現了一個新的挑戰，Hadoop集群的上限是5000個節點，按照當時數據增長數據的推算，集群存儲即將撞牆，但是基於當時的狀況，ODPS無法完全替代Hadoop，於是當時啟動了一個規模非常龐大的項目，叫做“5K項目”，同時進行雲梯一和雲梯二的跨機房集群項目，當時世界上沒有任何一家公司具備跨機房的能力，存在非常大的技術挑戰，最后項目歷經近5個月的周期，攻克大量技術難點，項目取得了成功；
在“5K項目”成功的同時，ODPS架構逐步成熟，於是全集團又啟動了一個規模更龐大的項目，叫做“登月項目”，將全集團的數據加工應用全部搬移到ODPS，項目一直持續到2015年，Hadoop正式下線，淘寶大數據徹底進入ODPS時代，整個數據的生態圈也越來越豐富，同時，阿里雲開始對外提供雲服務，其中大數據解決方案作為其中重要的組成部分，也開始對外提供；
時間回到2013年時，當時淘寶數據團隊的每個成員都在忙於應對各類需求，每天都有做不完的各類報表，當時為了解救自己，數據團隊開始摸索探索新的數據服務模式，思考如何解決數據冗余、口徑統一、數據交換、用戶自助等一系統問題，最終通過一段時間思考和摸索，開始研發孔明燈產品，針對不同的數據角色形成了一套完整的數據解決方案，如下：
圖6 孔明燈解決方案
孔明燈產品的出現，對傳統的開發模式做了個升級，對整個大數據建設也起到了非常好的管理作用，當時在淘寶內部，覆蓋了大部分的業務BU，對數據使用成本的降低，釋放了大量的人力，同時也吸引了外部用戶高德地圖、阿里健康基於這套體系進行大數據建設；
2014年，集團公共層項目啟動，集團內的各個數據團隊，開始進行數據內容重構和整合，同時，CCO正式成立，七公來到CCO帶領技術團隊，薛奎來到CCO帶領數據倉庫團隊，CCO也基於ODPS啟動公共層建設項目，集成了包括淘系、1688、ICBU、AE相關的服務數據，公共層建設的同時完成了登月項目，並且與DIC團隊、RDC團隊協同建設了服務數據門戶DIGO產品；
今天，數據在阿里巴巴已經深入到每個角落，阿里雲有強大的算法團隊、大批的數據接口人、分析師，每天的工作都與數據產生關聯，隨着人工智能的不斷深入使用，業務系統的不斷創新迭代，對數據的采集、加工、應用又提出了新的要求，如何更好的提供數據服務，面對未來我們需要思考更多，數據將進入一個新的時代-數據智能時代。