阿里巴巴大資料系統體系主要分為，資料採集、資料計算、資料服務和資料應用四大層次。
瀏覽器的頁面日誌採集
h5裝置標識
日誌傳輸資料同步基礎
不過濾刪除流水，下游邏輯刪除
過濾最後一條刪除流水，比如存在手工批量刪除或者備份刪除，則資料還是有效的不應當置為無效
過濾刪除流水和之前的流水
阿里資料倉儲的同步方式
批量 檔案匯出，實時查詢
實時 binlog解析通過my kafka傳輸
資料倉儲的清洗採用非侵入式的清洗策略，在資料同步過程中不進行資料清洗，避免影響資料同步的效率。資料進入ods層後，開始清洗，符合清洗資料清洗掉，並儲存到dirty表
任務排程系統
資料倉儲系統使用crontab定時任務功能進行任務排程處理，缺點：
分為排程引擎（phoenix engine）和執行引擎（alisa）兩個子系統。
資料時效性一般分為三種：
實時資料則需要在流式處理系統中完成。簡單來說，流失處理技術是指業務系統每產生一條資料，就立即被採集並實時傳送到流式任務中進行處理，不需要定時排程任務來處理資料。由於資料來源是流式的，在資料具有上下文關係的情況下，資料到達時間的不確定性會導致實時處理的結果與離線處理會有一定的差異。
流式技術架構
一般情況下，出於吞吐量及系統壓力上的考慮。並不是新增一條記錄就採集一次。而是基於資料大小限制，或者時間閾值限制，按批次對資料進行採集。對於採集到的資料，需要乙個資料交換平台分發給下游, 比如kafka.
訊息系統一般會用做業務資料庫變更的訊息中轉，比如訂單下單，支付等訊息，對於其他較大的業務資料，一般會通過資料中介軟體系統買中轉.雖然它的延遲在秒級，但是其支援的吞吐量高。
資料儲存
流式資料模型
多流關聯
在流式計算中常常需要把兩個實時流進行主鍵關聯，以得到對應的實時明細表。實時資料的到達是乙個增量的過程，並且資料到達的時間是不確定和無序的，因此在資料處理過程中會涉及中間狀態的儲存和恢復機制等細節問題。
實時採集兩張表的資料，每到來一條新資料是都在記憶體中的對方表截止當前的全量資料中查詢，如果能查詢到，則說明關聯成功，直接輸出，如果沒查詢到，則這把資料放在記憶體中的自己表資料集合中等待。另外，不管是否關聯成功，記憶體中的資料都需要備份到外部儲存系統中，在任務重啟時，可以從外部儲存系統中恢復記憶體資料。
在實際處理時考慮到查詢資料的效能，實時關聯這個步驟一般會把資料按照關聯主鍵進行分桶處理，並且在故障恢復時也根據分桶來進行，以降低查詢資料量和提高吞吐量。
dws 使用邏輯寬表做為防腐層
資料部門欄位的變更相對於比較頻繁，這種底層變更對應用層來說應該算是最糟糕的變更之一了，而邏輯表層的設計，很好的規避了這個痛點，只變更邏輯表中物理欄位的對映關係，並且即刻生效，對呼叫方來說完全無感知。
邏輯表可以理解為資料庫中的檢視是一張虛擬表，也可以看作是由若干主鍵相同的物理表構成的大寬表。
日期為今天是展現的是實時資料，日期為昨天事展現的就是離線資料，其背後的複雜性在於。
linux的創始人torvalds有一段關於「什麼才是優秀程式設計師」的話：「爛程式設計師關心的是**，好程式設計師關心的是資料結構和它們之間的關係。
ddd維度設計基礎
選擇維度或者新建維度，以**商品維度為例，有且只允許有乙個維度定義。
維度的層次結構
維度中的一些精連屬性以層次方式成一對多的方式相互差聯。比如陶寶商品維度，有賣家、類目、品牌制商品屬於類目，類目屬於行業，其中類目的最低級別是葉子類目，葉子類目屬於二級類目，二級類目屬子一級類目。
一致性維度和交叉探查
資料倉儲匯流排架構的重要基石之一就是一致性維度。在針對不同資料域進行迭代構建或並行構建時，存在很多需求是對於不同資料域的業務過程或者同一資料域的不同業務過程合併在一起觀察。比如對於日誌資料域，統計了商品維度的最近一天的pv和uv；對於交易資料域，統計了商品維度的最近一天的下單gmv。現在將不同資料域的商品的事實合併在一起進行資料探查，如計算轉化率等，稱為交又探查。
維度設計高階主題
維度變化
特殊維度
行為維度
在阿里巴巴的資料倉儲中，存在很多維表，如賣家主營類目維度賣家主營品牌維度、使用者常用位址維度等。其中賣家主營類目和主營牌通過賣家的商品分布和交易分布情況，採用演算法計算得到：去家常月位址通過最近一段時間內物流中賣家的發貨位址和買家的收貨位址
行統計得到。類似的維度，都和事實相關，如交易、物流等，稱之為
按照加工方式，行為維度可以劃分為以下幾種：
多值維度
對於多值維度，一種情況是事實表的一條記錄在某維表中有多條記錄與之對應。比如對於**交易訂單，買家一次購買了多種商品，如一件毛衣和兩雙襪子，稱為交易父訂單；對於每種商品的交易，稱為交易子訂單：此交易父訂單有兩個子訂單與之對應。假設設計交易父訂單事實表，則對於此事實表的每一條記錄，在商品表中都有一到多條記錄與之對應。
多值屬性
維表中的某個屬性字段同時有多個值，稱之為「多值屬性」。它是多值維度的另一種表現形式。在阿里巴巴的資料倉儲中，存在很多維表，如商品sku維表、商品屬性維表、商品標籤維表等。每個商品均有一到多個sku、一到多個屬性和一到多個標籤，所以商品和sku、屬性、標制
籤都是多對多的關係。
對於多值屬性，常見的處理方式有三種，可以根據具體情況進行選擇。
第一種處理方式是保持維度主鍵不變，將多值屬性放在維度的乙個屬性欄位中。json 格式
第二種處理方式也是保持維度主鍵不變，但將多值屬性放在維度的多個屬性字型中，擴充套件性較差
第三種處理方式是維度主鍵發生變化，乙個維度值存放多條記錄。資料膨脹嚴重
事實表中一條記錄所表達的業務細節程度被稱為粒度。通常粒度可以通過兩種方式來表述：一種是維度屬性組合所表示的細節程度：一種是所表示的具體業務含義。
事實表有三種型別：事務事實表、週期快照事實表和累積快照事實表，具體內容後面章節會詳細介紹。事務事實表用來描述業務過程，跟蹤空間或時間上某點的度量事件，儲存的是最原子的資料.週期快照事實表以具有規律性的、可預見的時間間隔記錄事實，時間間隔如每天、每月、每年等。累積快照事實表用來表述過程開始和結束之間的關鍵步驟事件，覆蓋過程的整個生命週期，通常具有多個日期欄位來記錄關鍵時間點，比如交易開始、交易結束。
事務事實表
在**交易過程中有四個重要業務過程，需要為每個業務過程確定乙個粒度。其中下單、支付和成功完結三個業務過程選擇交易子訂單程度，即每個子訂單為事務事實表的一行，每個子訂
單所表達的細節資訊為：交易時間、賣家、買家、商品。
週期快照事實表
解決使用事實表在大時間跨度下，效率變低的問題。
快照事實表中收集到的狀態量都是半可加的。比如**交易賣家快照事實表，每天的歷史至今的下單金額進行彙總，也沒有彙總意義。
累積快照事實表
用於考察實體的唯一例項，所以子訂單在此表中只有一行記錄，事件發生時，對此例項進行更新。
無事實的事實表
日誌聚集型事實表系統優化
hbohbo分配資源的步驟如下：
cbovolcano模型，不明白
任務優化
join 傾斜
maxcompute sql在join執行階段會將join key相同的資料分發到同乙個執行instance上處理。如果某個key上的資料量比較大，則會導致該instance執行時間較長。其表現為在執行日誌中該join task的大部分instance都已執行完成，但少數幾個instance一直處於執行中(這種現象稱之為長尾)。
因為資料傾斜導致長尾的現象比較普遍，嚴重影響任務的執行時間，尤其是在「雙11」等大型活動期間，長尾程度比平時更嚴重。比如某些大型店鋪的pv遠遠超過一般店鋪的pv，當用瀏覽日誌資料利用賣家維表關聯時，會按照賣家id進行分發，導致某些大賣家所在instance處理的資料量遠遠超過其他instance，而整個任務會因為這個長尾的instance遲遲無法結束。
reduce 傾斜
reduce端產生長尾的主要原因就是key的資料分布不均勻。比如有些reauce 在務instance理的資料記錄多，有些處理的資料記錄少，造成reduce端長尾。如下幾種情況會造成reduce端長尾:
目前已有的儲存治理優化項有未管理表、空表最近62天未訪問表，近據無更新無任務表、資料無更新有任務表、開發庫資料大於100gb且無訪問表、長週期表等。
maxcompute中的任何乙個計算任務都會涉及計算和儲存資源的消耗，其中計算資源的消耗主要考慮cpu消耗。為了下面更好地描述資料計量計費的演算法和規則，特做如下定義：cpu消耗的單位定義為cu，代表cpu的乙個核心（core)執行一天的消耗量。儲存資源的消耗主要考慮磁碟儲存的消耗，這裡採用國際通用的儲存單位pb來衡量.例如：計算資源的單價為1元/cu，儲存資源的單價為1元/p8天。
對資料成本的計量，可以採用最簡單的方式，將乙個資料表的成本分為儲存成本和計算成本。儲存成本是為了計量資料表消耗的儲存資源，計算成本是為了計量資料計算過程中的cpu消耗。但是，對這樣的資料成本計量方式會存在較大的質疑和挑戰。例如，如圖14.4所示，表d是業務方的乙個資料表，表d依賴表c，但是為了產生表c，往往上面存在乙個較長的資料劇新鏈路。表c的成本可能是10元，但是表a、b可能會是l00元。像這樣的情況，如果表c的成本僅僅用資料表c自身的儲存和計算成本衡量顯然是不合理、不準確的。
發布平台整合了通知功能，針對重要的場景發布會進行卡點，確認通知後才能完成發布。其次是資料庫表的變化感知，無論是隨著業務發展而做的資料庫擴存還其表的ddl變化，都需要主動通知到離線開發人員。是可以的，靈活性比較大。
另外，摩薩德提供了甘特圖的服務，針對業務的運**況，摩薩德會提供一條關鍵路徑，即完成業務的最慢任務鏈路圖。因為每個業務上游可能有成千上萬個任務，所以這條關鍵路徑對於業務鏈路優化來說非常重要。
資料質量故障體系
大資料之路 阿里巴巴大資料實踐 資料同步要點
使用者建立資料同步任務，並提交該同步任務。根據系統提前獲知及設定的資料，估算該同步任務需要同步的資料量 平均同步速度 首輪執行期望的執行緒數 需要同步的匯流排程數。根據需要同步的匯流排程數將待同步的資料拆分成相 等數量的資料塊，乙個執行緒處理乙個資料塊，並將該任務對應的所有執行緒提交至同步控制器。同...
《大資料之路 阿里巴巴大資料實踐》讀書筆記
ps 這本書主講阿里的大資料體系架構方案，從底層到高層闡述，目前對我來說此書的難度較大，不是很懂，大部分為對原書的引用歸納，我會給出相應的大牛的關於此書的讀書筆記的傳送門供參考。以下為大牛關於本書的讀書筆記供參考 讀書筆記傳送門 整本書分為四篇幅，共分16個章節分別闡述阿里巴巴在大資料的挑戰下的各個...
阿里巴巴大資料之路
資料治理 對這些資料進行有序 有結構地分類組織和儲存，目前企業資料現狀 集團資料儲存達到eb 1eb 1024pb 2 60位元組 級別，部分單張表每天的資料記錄數高達幾千億條 資料工程師工作 資料工程師每天要面對百萬級規模的離線資料處理工作。資料模型 資料研發 資料質量和運維保障工作。大資料系統體...