我看分布式系統發展和阿里實踐(1)（32頁）.pdf

1、我看分布式系統架構設計和阿里實踐林偉阿里云大數據計算平臺資深架構師自我介紹 2002-2005：CPU設計和操作系統 2005-2009：分布式協議開發，存儲系統的開發 2009-2015：Bing&Cosmos&Scope 2015-至今：阿里巴巴計算平臺分布式系統發展并行單元互聯晶體管導線運算單元集成電路多Core高速總線多CPU訂制網絡多機商用網絡分布式系統設計中的變與不變 資源特性 二八原則 系統繁簡變換 一致性協議 MaxCompute大數據計算服務(MaxCompute)是一種快速、完全托管的PB/EB級數據倉庫解決方案。具備萬臺服務器擴展能力和跨地域容災能力，是阿里巴巴內部核心大

2、數據平臺，支撐每日百萬級作業規模。MaxCompute向用戶提供了完善的數據導入方案以及多種經典的分布式計算模型，能夠更快速的解決用戶海量數據計算問題，有效降低企業成本，并保障數據安全。MaxCompute性能1M+日任務40000+機器單機群上萬EB存儲8000+開發者2XHadoop性能1/3$Amazon EMR1M+表1500+項目377s100TB sortMaxCompute架構盤古（分布式存儲系統）伏羲（分布式調度系統）MaxCompute Engine流計算圖計算Batch內存計算機器學習MaxCompute LanguageSpark APIBeam APIHive API應

3、用生態不變：資源特點的相對關系高性能低性能低成本大容量高延時高成本小容量低延時變的：各資源絕對性能，種類MaxCompute：如何處理多種資源特性上到達最佳性能cacheSSDSATA(多副本）SATA Erasure Encoding（1.5X）熱冷MaxCompute：Reshuffle中容錯和性能的矛盾Reshuffle數據需要落盤，因為Resuffle把多個機器聯系起來，出錯概率大大增加但是落盤大大降低了系統的性能，但是如果只是簡單用network的方式來Shuffle數據，則不能容錯CCPPPMaxCompute：容錯和性能平衡 采用Network-Disk的可自適應性的channe

4、l來進行Data-ShufflePCWriteRead保存在內存中保存在盤古中不變：應用中的二八法則80%的訪問集中于20%數據20%的MaxCompute的項目貢獻80%的任務20%的任務占用80%系統資源80%的新數據訪問發生在最近20%的時間段中變：二八指代的對象,程度隨業務不同而不同 流計算用戶80%對latency更為看重 批處理用戶80%對throughput更為看重 我們BI系統希望服務好高頻的20%的數據，使得80%的訪問都達到毫秒級 MaxCompute API取舍（二八法則）80%數據工程師 關心數據本身特性，數據分析需要做什么 如何高效做由MaxCompute來選擇 SQ

5、L+UDF:Declare Language20%具有分布式開發經驗程序員 希望精確控制分布式程序的執行 能夠比系統生成出更加高性能分布式執行計劃 Lambda+SQL算子：函數式程序語言MaxCompute API層次SQL+UDF pluginMax用戶Non-SQL的擴展由UDF API定義能夠讓用戶對其UDF規范和描述，說明從外看起UDF的數據運算屬性使得系統優化能夠穿透Non-SQL的部分，從而到達更好的執行plan使得用戶能夠專注于其數據邏輯，系統進行全局優化來生成最優執行對系統優化器要求更高Non-SQL的driver+SQL算子用戶Non-SQL的部分由外部driver提供具有

6、普世性數據運算通過在API實現的關系代數數據算子來提供數據處理優化器局限于SQL關系代數算子之間，碎片化優化用戶需要更多考慮數據加工的分布式過程能夠更加靈活，給用戶更多選擇去精確控制分布式運算MaxComputeSpark系統設計繁簡以及之間變化簡明設計API簡約性能次用戶易用維護性強系統Scale對系統優化要求高復雜設計API復雜性能優用戶理解復雜維護性差系統難以scale對用戶的要求高新業務，新需求，新問題系統軟件成熟，更加優化兩種思路正在融合 Spark：Scala-DataFrame，擴大關系代數程序范圍，從而系統能夠有更大的空間進行優化 MaxCompute:提供DataFrame算

7、子，融入程序式編程方式一致性協議以及其特性Paxos/Primary-Backup/Chain-Replication強一致性，弱一致性，最終一致性一致性要求越高，吞吐量越小，性能越低，協議越復雜，但是用戶語義越簡單但不同系統對一致性要求程度不同，對于出現錯誤的代價不同系統設計中常用方法空間換時間數據冗余：Replication/Cache/時間換空間數據編碼，壓縮API層次設計主API服務80%的業務群體，使得80%的業務能夠最為方便享用主要服務同時提供底層API使得20%的群體能夠自行解決系統中層次法復雜問題-分內外層-轉變內層中二八法則指代或者改變其對資源需求-解決內層問題處理多種資源特

8、性上到達最佳性能 用其他資源來節省緊俏資源 CPU bound的任務shuffle數據的時候用非壓縮，盡量節省CPU編碼損耗，用存儲換CPU IO bound的任務shuffle數據的時候進行壓縮，節約數據傳輸量。時間空間系統設計中常用方法空間換時間數據冗余：Replication/Cache/時間換空間數據編碼，壓縮API層次設計主API服務80%的業務群體，使得80%的業務能夠最為方便享用主要服務同時提供底層API使得20%的群體能夠自行解決系統中層次法復雜問題-分內外層-轉變內層中二八法則指代或者改變其對資源需求-解決內層問題MaxCompute API層次用戶擴展由UDF接口提供，使得

9、查詢系統能夠規范用戶提供其UDF的數據特性，從而保留系統優化的能力在SQL的語言基礎上再提供類似Spark/Beam程序化編程方式Spark/Beam/Lambda20%SQL80%UDFUDF系統設計中常用方法空間換時間數據冗余：Replication/Cache/時間換空間數據編碼，壓縮API層次設計主API服務80%的業務群體，使得80%的業務能夠最為方便享用主要服務同時提供底層API使得20%的群體能夠自行解決系統中層次法復雜問題-分內外層-轉變內層中二八法則指代或者改變其對資源需求-解決內層問題層次化設計方法 復雜問題 難以在當前條件下解決分解 假設子問題已經解決下解決復雜問題轉換

10、子問題在規模和二八指代發生變化 從而變為新的問題產生子問題MaxCompute海量數據訪問 我們存儲了EB級別的數據，擁有百萬級別表格，許多表格具有數十萬的分區，每天有百萬的任務 如何能夠打造一個高可用，高可靠，高性能的數據倉庫服務層次化設計方法：MaxCompute 數倉的設計MaxComputeMaxComputeMeta ServerOTS（BigTable）Paxos一致性變強容量變小吞吐性能變小成本變高問題規模變小High throughputLarge scale(EB級別)Append-onlyReplicationLock Free強一致性數臺機器High QPSMassive

11、 Update百G規模分布式系統設計中的變與不變不變 資源特點相對關系 應用中的二八定律 一致性協議以及和容錯關系 API抽象，易用性和高性能，系統復雜性的矛盾 層次化設計方法變 各資源的絕對性能，種類 二八代表東西隨業務不同，需求不同而不同 一致性要求，錯誤代價應業務不同而不同 系統成熟使得復雜慢慢變得簡單 拆解問題角度架構師的經驗 熟悉各種資源的原始特性 知識面寬，科學在各個領域其實是相通 大量閱讀各種系統代碼，從前人的代碼汲取營養 實踐出真知 兩個數量級的性能變化系統的重新設計來追求新的平衡Question?兼容Hive擁抱生態，利用和回饋社區易用性，擴展性高性能，低成本持續可發展性多租戶需要滿足用戶不同規模，性能，延時，運算形式上要求大規模萬臺單集群，多集群穩定，隔離，數據安全MaxCompute更為具體例子GroupBy a b=UDF（a）Group By bMMMRRFFRRRMMMRRFFRRUDF 單調