大數(shù)據(jù)存儲和計算資源管理單超

1、唯品會大數(shù)據(jù)平臺大數(shù)據(jù)存儲和計算資源管理郵箱: 微信: shanchaoeric唯品會大數(shù)據(jù)平臺規(guī)劃離線計算A臺流B計算A臺VDProcess實時計算VDBank實時接入VDEngine分布式存 (R E(實時推薦A臺 ABT(分流與實S)oring(初 選 Sorting(精 E Filtering(過 S 個性化推薦廣告聯(lián)盟精準營銷CRMMixer(接入分發(fā) DMP統(tǒng)一T戶 數(shù)D貨品 畫像驗 P型訓練A臺SparkDNN算法 庫數(shù)D分M數(shù)D服務(wù)數(shù)DF索數(shù)D管控標準化元數(shù)De i V 控校準gV R 維 控 c唯品會大數(shù)據(jù)平臺現(xiàn)狀大數(shù)據(jù)管理工作范疇 業(yè)務(wù)系統(tǒng) 調(diào)度系統(tǒng)ETL 數(shù)據(jù)模型 元數(shù)據(jù)

2、/主數(shù)據(jù)管理 數(shù)據(jù)質(zhì)量 開發(fā)流程 運維流程 數(shù)據(jù)審計和安全資源管理“數(shù)據(jù)平臺使用申請”用戶提交：資源類型hdfs存儲/hive數(shù)據(jù)庫/hive計算資源/mr計算資 源.資源數(shù)目100T存儲/1T內(nèi)存/1000顆CPU.訪問方式hive/presto/spark/webhdfs管理員處理：hdfs分配：path/name quota/space quotahive分配： 數(shù)據(jù)庫/授權(quán)yarn分配：隊列最小資源/最大資源/weight理想很豐滿,現(xiàn)實很骨感系統(tǒng)強大數(shù)據(jù)規(guī)范流程規(guī)范技術(shù)成熟業(yè)務(wù)成熟模型變更迅速，開發(fā)周期短用戶能力參差不齊大量的歷史包袱大量的技術(shù)包袱平臺不穩(wěn)定，掌控力差分層不明確理想現(xiàn)

3、實各種問題這個任務(wù)昨天還好好的，為什么今天跑不出來了？2-10倍的數(shù)據(jù)量，能撐得住嗎？怎么幾千個任務(wù)都慢了？最近磁盤使用急劇增加，誰在用？這個表好像不用了，我能刪除掉嗎？集群要擴容嗎？擴多少?核心 資源管控分田到戶目的：從亂序到有序申請和分配有據(jù)可查規(guī)則公開透明數(shù)據(jù)公開透明有多少資源，干多少事合理的KPI和懲罰機制ROI，資源傾斜給回報率高的項目資源有什么？為什么存儲和計算需要關(guān)注？Scale Up Scale OutNamenode - 存儲(2億blocks/2億files)standby namenode updateCountForQuota緩慢影響主從一致性，進而影響切換（HDFS-

4、6763)standby checkpoint緩慢導致增量blockreport匯報被skip, 影響主從一致性，進而影響切換（HDFS-7097)standby checkpoint GC導致transfer Fsimage超時失敗集群啟動期間, blockreport需要錯開，導致啟動緩慢，namenode壓力增加ResourceManager - 計算(1k+并行job/40w+ job每天)大量任務(wù)運行期間，resource manager分配能力不足/jira/browse/YARN-3547 部分解決問題https:/issues.a

5、/jira/browse/YARN-5188 our patch for fairscheduler隊列分配過粗，互相影響嚴重開源節(jié)流Federation 存儲優(yōu)化管理 計算優(yōu)化管理提升namenode rpc性能 提升yarn的containaer assign性能增加機器存儲資源管理存儲資源管理- hdfs存儲資源存儲資源管理- 如何獲取存儲數(shù)據(jù)hdfs -lsR slow but easyload【均為【均為hive table】文件元數(shù)據(jù)信息hive表元數(shù)據(jù)信息調(diào)度任務(wù)元數(shù)據(jù)信息路徑訪問信息calc1. 維度 分區(qū)/表/數(shù)據(jù)庫/任務(wù)/業(yè)務(wù)/人/目錄層級/時間2. 指標

6、 全量/增量/趨勢/平均文件大小/最大文件 大小/最小文件大小/文件數(shù)目/占比3. 熱度 哪些表被頻繁訪問？哪些表3個月都沒人訪問了？4. 安全 有沒有敏感信息被非法訪問fsimage parser fast but need devhive metastoreETL metadatahdfs audit log資源管控系統(tǒng)-demo資源管控系統(tǒng)-demo存儲資源管理- 如何使用存儲數(shù)據(jù)容量計費通過計費來控制資源存儲數(shù)據(jù)完整透明消費預(yù)警，提前知會用戶空間管理自動配置生命周期管理規(guī)則存儲格式，壓縮格式選擇（orc+gzip)文件管理自動配置生命周期管理規(guī)則小文件har歸檔存儲資源管理- 控制存儲

7、的價值解決NN“單點”瓶頸控制服務(wù)器數(shù)量，降低成本規(guī)范數(shù)據(jù)生命周期管理統(tǒng)計冷熱數(shù)據(jù)使用，反饋給ETL生命周期管理計算資源管理計算資源管理yarn - 統(tǒng)一調(diào)度管理yarn，好像搞定了資源管理，我們還需要管理什么？計算資源管理- beyond yarn隊列管理，共享還是獨享？隊列分到多細合適？如何確保關(guān)鍵隊列的資源？每個隊列的使用情況如何？這個部門的新同事總是寫錯sql, 占用大量資源，怎么辦？晚上3點多A隊列資源緊張，在干什么？B任務(wù)，最近消耗資源情況怎么樣？B任務(wù)，C sql, 為什么step1的application突然跑慢了？今天最消耗資源的application是哪個？能優(yōu)化嗎？有沒有

8、數(shù)據(jù)傾斜造成的任務(wù)延遲？我們要解決一下這么多機器，分配的任務(wù)數(shù)均衡嗎？有沒有一些機器任務(wù)失敗率特別高？計算資源管理- 實時計算資源信息yarn - mapreducewebui業(yè)務(wù)應(yīng)用mr codespark commandhive cmdexecutor(hive/ spark)hiveservermysql/hbase每分鐘 app快 照實時 app基 本信息實時明 細task 信息ETL任務(wù)信息+job基 礎(chǔ)信息分鐘快照實時快照明細task信息ETL相關(guān)信息隊列資源 使用實時 信息計算資源管理- 離線計算資源信息分鐘任務(wù)快照loadyarn每分鐘的任務(wù)快照yarn的明細的任務(wù)執(zhí)行信 息E

9、TL的任務(wù)信息ETL任務(wù)內(nèi)部的job信息隊列使用信息【均為hive tablecalc1.維度 任務(wù)/業(yè)務(wù)/人/隊列/時間/類 型(map|reduce)/服務(wù)器2.指標 全量/增量/趨勢/占比/讀寫資 源/cpu資源/shuffle資源實時任務(wù)快照task執(zhí)行明細ETL信息隊列使用信息計算資源管理- 如何使用計算資源容量計費通過計費來控制資源存儲數(shù)據(jù)完整透明消費預(yù)警，提前知會用戶實時告警和自動處理根據(jù)隊列設(shè)置不同的規(guī)則，如運行時長，使用資源，自動發(fā)現(xiàn)和觸發(fā)停止動作通過業(yè)務(wù)注碼，自動展示運行中的業(yè)務(wù)細節(jié)數(shù)據(jù)傾斜自動識別隊列數(shù)據(jù)化運營計算資源管理- 公平調(diào)度我們的管理原則：盡量細化，單個業(yè)務(wù)分配

10、單獨隊列隊列分配的min/max/weight由實際業(yè)務(wù)來評估，上線初期會不斷調(diào)整min是保證的最小資源，確保優(yōu)先獲得max是業(yè)務(wù)的最大資源限制，確保不會超過每個隊列由多個不同級別的子隊列組成，子隊列業(yè)務(wù)可靈活調(diào)整子隊列大小可以基于時間動態(tài)調(diào)整自天，天任務(wù)隊列縮小，小時任務(wù)隊列放大夜晚，天任務(wù)隊列放大，小時任務(wù)隊列縮小關(guān)鍵任務(wù)確保隊列內(nèi)的最小隊列保證計算資源管理- Yarn實時運行情況監(jiān)控優(yōu)點數(shù)據(jù)完全實時缺點展現(xiàn)不夠直觀無歷史時序數(shù)據(jù)計算資源管理（秒級）- 數(shù)據(jù)獲取historylog通過實時計算框架，獲取每個application的明細執(zhí)行結(jié)果缺點：任務(wù)完成后才能獲取到完整信息job api

11、通過api實時獲取到所有job的基礎(chǔ)信息比默認rm的api提供更多字段信息，如sql信息缺點：不是100%完整的數(shù)據(jù)，定期獲取必然會丟失數(shù)據(jù)計算資源管理（秒級）- 用戶查詢識別示例Thu Apr 21 18:48:01 CST 2016 jobname=-xxx.chen-qid:152011-.100(Stage-2) user=xxx.chen job_id=job_1459656116710_7806076 starttime=1461232053 exceed 3600 seconds,killing.計算資源管理（秒級）-實時監(jiān)控task kill ratio計算資源管理（分鐘級）-

12、 jmx數(shù)據(jù)來補充jmx: http:/%s:8088/jmx % (IP)返回格式：#name : Hadoop:service=ResourceManager,name=QueueMetrics,q0=root,q1=mapreduce,q2=xxx,q3=panda,#modelerType : QueueMetrics,q0=root,q1=mapreduce,q2=xxx,q3=panda,#tag.Queue : root.mapreduce.xxx.panda,#tag.Context : yarn,#tag.Hostname : xxxx,#running_0 : 0,#run

13、ning_60 : 0,#running_300 : 0,#running_1440 : 0,#FairShareMB : 0,#FairShareVCores : 0,#SteadyFairShareMB : 1228800,#SteadyFairShareVCores : 0,計算資源管理（分鐘級）- 單個隊列監(jiān)控實例隊列分配紅線跑平 隊列等待藍線升高-結(jié)論，單個業(yè)務(wù)資源吃緊-需要增加最大可分配資源計算資源管理（分鐘級）- resourcemanager metric監(jiān)控示例調(diào)整前： 高峰期app pending增加 凌晨任務(wù)1個小時任務(wù)延遲調(diào)整min后： 最大pending不超過100

14、pending很快下降計算資源管理（分鐘級）- resourcemanager metric監(jiān)控示例高峰期資源需求增加，但是分配能力下降yarn分配能力受到影響，將問題加劇計算資源管理（分鐘級）- 優(yōu)化展現(xiàn)集群總體資源分布情況最消耗資源的是什么任務(wù)實時/歷史的數(shù)據(jù)查看計算資源管理（分鐘級）- 隊列總覽展現(xiàn)計算資源管理（分鐘級）- 隊列總覽展現(xiàn)計算資源管理（天級）- 離線資源使用查詢集群的資源使用場景時間/應(yīng)用/隊列維度的資源使用情況核心ETL任務(wù)近期map/reduce使用情況單個attempt的metrics指標查看，如讀取超過1kw行數(shù)據(jù)的map任務(wù)等等計算資源管理（天級）- 數(shù)據(jù)傾斜識別示例計算資源管理-計算資源優(yōu)化實例用更少的資源計算orcfile, 壓縮率更高，列式存儲降低資源消耗權(quán)衡資源和性能，基于record而不是size調(diào)整reduce數(shù)量基于hll的uv估算函數(shù)，提供可增量的uv計算計算資源管理-計算資源優(yōu)化實例用更多的資源計算，更快的釋放sparksql，內(nèi)存需求高，復(fù)雜計算快presto/impala, 利用mpp框架提高計算性能計算資源管理-計算資源優(yōu)化實例不同隊列的資源使用上