IAAS: IT公司去IOE-Alibaba系統構架解讀

從Hadoop到自主研發,技術解讀阿里去IOE後的系統架構

原地址:......................
摘要:從IOE時代,到Hadoop與飛天並行,再到飛天單集羣5000節點的實現,阿里一直摸索在技術衍變的前沿。這裏,咱們將從架構、性能、運維等多個方面深刻了解阿里基礎設施。
【導讀】互聯網的普及,智能終端的增長,大數據時代悄然而至。在這個數據爲王的時代,數十倍、數百倍的數據給各個機構帶來了無盡的機遇;然而,無能否認的是,數據體積的暴增一樣史無前例的挑戰着企業的基礎設施。

        在這個大背景下,各個機構不得不在控制好成本支出的同時,不停摸索着時刻激增用戶數據的解決之道,其中阿里的成績無疑使人豔羨——單集羣規模5000+的飛天,以及多集羣跨機房計算的支持。本次咱們將以飛天爲例,爲你們分享大規模分佈式系統打造過程當中的艱難坎坷及應對之道。數據庫

        本次分享共分爲視點、技術專題、應用實踐三大板塊「視點」從人物着手細分阿里當時所面臨的形勢及各個據測制定的依據;「技術專題」主要從實踐出發剖析飛天5000節點擴展時所遭遇的艱難險阻及應對之道,涉及架構調整、性能優化、系統運維等多個領域;「應用實踐」則更注重於雲實踐經驗及用例分享。編程

目錄

視點安全

  1. 阿里雲觀察2014
  2. 阿里技術保障部:阿里雲的幕後英雄
  3. 不期而遇的飛天之路

技術專題性能優化

探索5K巔峯,雲梯架設的飛天之夢在3個月deadline的狀況下,阿里卻選擇投入更多人力物力及時間的雲梯1(以Hadoop爲底層的集羣)和雲梯2(以飛天爲底層的集羣)並行擴容,阿里人選擇背水一戰的緣由到底是什麼?在這個過程當中,他們又會遭遇哪些挑戰?目標實現後的驚喜又是什麼?架構

優化無極限:盤古Master優化實踐盤古,飛天的分佈式文件系統,在內部架構上盤古採用Master/ChunkServer結構,Master管理元數據,ChunkServer負責實際數據讀寫,經過Client對外提供類POSIX的專有API。在集羣擴展到5K規模後,相關問題紛至沓來,主要可分爲兩個部分:首先,盤古MasterIOPS問題;其次,盤古Master冷啓動速度。那麼到底是什麼形成了這些問題?阿里工程師又該如何應對?併發

走近伏羲,談5000節點集羣調度與性能優化伏羲,飛天平臺的分佈式調度系統。在5K攻堅中,從設計到實現每一步均可能存在性能「陷阱」,緣由主要在三個方面:規模放大效應;木桶效應;長路徑模塊依賴。5000節點後這些方面究竟存在什麼樣的問題?阿里人又經過了什麼方法保證了服務的性能與穩定性?框架

走近華佗,解析自動化故障處理系統背後的祕密5K後的運維模式究竟會產生什麼樣的變化?阿里人究竟爲何會開發華佗?上通飛天系統,下達運維各類系統,華佗健壯、簡單和開放的架構究竟表如今什麼方面?系統又是如何實現了自動化的運維?運維

ODPS技術架構及應用實踐ODPS採用抽象的做業處理框架將不一樣場景的各類計算任務統一在同一個平臺之上,共享安全、存儲、數據管理和資源調度,爲來自不一樣用戶需求的各類數據處理任務提供統一的編程接口和界面。那麼,在DT時代,不斷擴大的數據規模又會給ODPS帶來什麼樣的挑戰?網站日誌分析又該如何進行?分佈式

ODPS跨集羣遷移與數據同步經驗分享阿里各業務部門如淘寶、天貓、一淘、B2B等天天都會產生大量的數據,日均增量數百TB。2013年初,阿里內部的生產集羣PA所在機房的存儲量最多可擴容到數十PB,而當時已使用75%的存儲量。存儲容量告急,迫切須要將生產集羣PA上的大量數據遷移到其餘集羣。那麼阿里人該如何安全地跨集羣遷移幾十PB的數據和其上相關業務?數據遷移以後,兩個集羣間存在大量的數據依賴,須要互相訪問最新的數據,如何安全快速地實現跨集羣數據同步?oop

飛天5K實戰經驗:大規模分佈式系統運維實踐但短期大規模快速膨脹的現狀,給運維帶來了巨大挑戰,其中雲梯2單集羣規模更是從1500臺升級到5000臺。爲此,運維須要作多個方向的調整,好比:提高全局掌控能力、實現系統的自我保護和自動化修復、大規模與精細化的平衡。那麼,阿里又是經過什麼途徑完成這些工做的?

應用實踐

  1. 數據生意背後的雲計算
  2. 登月1號:支付寶演繹空中升級絕技
  3. 御膳房:構建大數據的美食廚房

節選

《不期而遇的飛天之路》——去IOE,飛天勢在必行

        翻開歷史,淘寶曾啓用全亞洲最大的OracleRAC集羣,阿里更是購買過3年無限制的許可,阿里在IBM小型機以及EMC SAN存儲上的投入也曾成爲媒體爭相報道的事件。但隨着互聯網爆發式發展,淘寶、支付寶和阿里巴巴B2B的註冊用戶數激增,阿里只能不停地經過水平和垂直擴展架構來應對新增用戶生成的海量數據。而這種集中式數據庫的架構,使得數據庫成爲了整個系統的瓶頸,愈來愈不適應海量數據對計算能力的巨大需求,更不用說愈來愈難以承受的高昂投入。阿里的「去IOE」已經勢在必行:經過自主研發的分佈式系統取代集中式數據庫架構,使用MySQL+HBase取代Oracle,商用機取代小型機+SAN。

       選擇自主研發,這也是阿里雲在步入雲計算之路上作出的最重要的抉擇:堅持追求擁有自有的最有競爭力的核心技術。在唐洪看來,雲計算是一門高技術門檻的生意,具有核心技術競爭力等於具有了在戰場上能夠正面抗衡競爭對手的實力,儘管這個技術攻關的歷程很是之艱難。選擇自主研發而非採用開源Hadoop優化,也是基於必定的考慮,儘管Hadoop在離線大數據處理上具有優點,但沒法徹底提供阿里雲要求的大規模分佈式計算與處理的能力,而目前基於飛天上線的雲服務,已遠遠超出Hadoop的能力。開源能夠說是一條先易後難的路,儘管一開始能夠走一些捷徑,但過後在版本升級、研發上都會受頗多限制;從核心知識產權角度來看,今天不管是微軟、Amazon或者Google的雲計算平臺,都沒有采用Hadoop且不開放代碼開源,本質上都是在追求自有的核心競爭力。開源軟件沒法完全成爲一個雲計算底層平臺的基礎,採用開源軟件並不是解決作分佈式系統這個問題的一劑良方。發展自有技術,堅持底層自主研發,現在可以構建超級計算機的飛天已成爲阿里擁抱雲計算,以及對外提供雲計算服務的堅實基礎。

結語

       已經實現5000節點單集羣的飛天5K擁有驚人的規模:10萬核的計算能力;100PB存儲空間 ;可處理15萬併發任務數;可承載億級別文件數目;100TB排序30分鐘完成,遠超今年7月1日Yahoo!在Sort Benchmark排序測試Daytona Gray Sort所創造的世界紀錄——100TB排序完成時間約71分鐘。

       優秀的產品背後,一定有優秀的基礎設施支撐。在此,咱們指望愈來愈多的團隊打造出更加穩定、更具性能的底層平臺,不論是自主研發,亦或是基於開源。(審校/魏偉)

相關文章
相關標籤/搜索