文章目錄
一、Maxcompute在優酷的應用
1.1 優酷業務的特點
1.2 Maxcompute 簡單易用
1.3 Maxcompute 生態完善
1.4 Maxcompute 性能強悍
1.5 MaxCompute 資源彈性
1.6 大數據整體方案
1.7 數據分層
數據中臺，從ODS層 ——> CDM層 ——> ADS層
1.8 業務賦能
1.9 計算優化
1.10 存儲優化
二、鬥魚 MaxCompute + Hadoop 混搭大數據架構實踐
2.1 自建集羣的發展瓶頸
2.2 大數據上雲的挑戰
Hive 窗口函數 ，像 rank() ，MaxCompute 不支持，需要確定哪些業務可以遷到雲上，哪些不可以。
2.3 混合雲模式帶來的變化
三、MaxCompute SQL 優化
3.1 SQL 成本計算
- 計算成本 <- 讀取IO數據量 * SQL複雜度
- SQL 複雜度：Join / Group By / Order By / Distinct / window func / Insert into
因此，優化SQL的過程，實際上就是要儘可能減少IO讀取，儘可能減少計算資源使用，儘可能降低SQL複雜度，儘可能提升運行速度。
3.2 SQL IO 讀取優化
3.2.1 表分區優化
- 建立分區表
Create Table t1 (...) partitioned by (pt string,region string)
分區層數不要太多
- 分區裁剪
避免全表掃描，減少資源浪費
Case:where pt = xxx and region = xxx
分區儘量按層級順序剪裁
分區值儘量常量化，避免不可確定值，如UDF
分區值儘量避免引用列的表達式計算或者子查詢
- 寫分區
寫入靜態分區，優化數據存儲
避免動態分區，防止小文件過多和計算長尾
3.2.2 列裁剪、條件過濾
- 只引用有效列
避免 select * from xxx
常量代替引用列，如count© -> count(1) // c not null
- 儘可能 pushdown 過濾條件
where a > 10 and (b > 1 or c < 1)
- Limit N
3.2.3 源表用戶
- 合併不同SQL，一讀多計算
讀取相同源表可合併，節省IO和計算資源
對源表統計多種指標計算或者篩選不同數據處理
避免規模過大，運行時間過長
- Multi Insert ，動態分區，一讀多寫
同一SQL讀取相同源表，系統會優化只讀取一次
資源足夠，也可以考慮拆分SQL，讀取和計算更好並行，資源換時間
- 子查詢合併
對於SQL中相同的子查詢也會合併成一個源
儘可能保持子查詢語句一樣，觸發合併
3.3 SQL 計算優化
3.4 SQL 整體優化
3.4.1 關鍵路徑優化
3.4.2 長週期指標統計優化
3.5 總結
