原文地址：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產品；

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

轉載于:https://www.cnblogs.com/davidwang456/articles/11396198.html

總結

以上是生活随笔為你收集整理的淘宝大数据之路【转】的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。