本文只是將阿里大數據之路做了個人讀書筆記整理，如果與原版有偏差，以原版為準，僅供學習參考。

關于總述

數據采集-數據計算-數據服務-數據應用
1.數據采集層
日志采集體系包含兩大體系：
Aplus.JS: Web端日志采集技術方案
UserTack：App端日志采集技術方案
傳輸方面：
TimeTunnel(TT):數據庫的增量傳輸，日志數據的傳輸，支持實時流式計算，也支持各種時間窗口的批量計算
數據同步：DataX 直連異構數據庫來抽取各種時間窗口的數據

2.數據計算層
數據存儲及計算云平臺（離線計算平臺Maxcomputer 和實時計算平臺 SteamComputer）
數據整合及管理體系(OneData)
OneData:數據整合及管理的方法體系和工具

數據倉庫的加工鏈路遵守業界分層的原理：
ODS：operational Data Store 操作數據層
DWD：明細數據層
DWS：匯總數據層
ADS：應用數據層

元數據模型整合及應用：
數據源元數據
數據倉庫元數據
數據鏈路元數據
工具類元數據
數據質量類元數據
主要面向數據發現，數據管理如：存儲，計算和成本等。

3.數據服務層
數據服務層數據源架構在多種數據庫上，如Mysql ,Hbase,后續逐漸遷移至阿里云云數據庫ApsaraDB for RDS(RDS)和表格存儲（Table Store）
oneService 以數據倉庫整合計算好的數據作為數據源，對外通過接口的方式提供數據服務，主要提供簡單的/復雜的數據查詢服務，（集團用戶識別，用戶畫像）實時數據推送三大特色。

4.數據應用層
對數據應用表現方面：搜索，推薦，廣告，金融，信用，保險，文娛，物流等
本書選擇對外數據產品–生意參謀
實時數據監控
自助式的數據網站或產品構建的數據小站
宏觀決策分析支撐平臺
對象分析工具
行業數據分析數據門戶
流量分析平臺

日志采集

日志采集體系包含兩大體系：
Aplus.JS: Web端日志采集技術方案
UserTack：App端日志采集技術方案

瀏覽器的頁面日志采集

1.頁面瀏覽日志采集：
PV：頁面瀏覽量
UV：訪客數
2.頁面交互日志采集：
通過量化獲知用戶的興趣點或者優化點

采集流程

1.網頁瀏覽的過程：
用戶輸入–>發送請求–>服務器返回響應–>解析渲染

HTTP請求

HTTP響應

用戶輸入–>發送請求–>服務器返回響應–>解析渲染
由于前三步驟無法采集用戶瀏覽的日志，需要在第四步，瀏覽器開始解析文檔時才能進行
采集思路：在HTML文檔內的適當位置增加日志采集節點，當瀏覽器解析到這個節點的時候將會自動觸發一個特定的HTTP請求到日志采集服務器，服務器收到這請求就確定瀏覽器成功接收打開頁面，各類網頁日志采集的解決方案只是在實施的細節，自動采集的內容的廣度以及部署有點差異
幾個簡單的過程：
客戶端的日志采集
客戶端日志發送
服務器端日志收集
服務器端日志解析存檔

頁面瀏覽日志采集框架涉及：
1.采集技術方案
2.PV日志采集標準規范，關于PV應采集和可采集的數據項，并對數據格式做了規定。

頁面交互日志采集

黃金令箭采集方案（并未觸發瀏覽器加載新頁面-----無法采用PV日志采集）：
了解用戶在訪問某個頁面時具體的互動行為特征
了解對某些頁面交互的反應

-------技術服務形式呈現
如下步驟實現業務采集：
1）依次注冊需要采集的交互日志業務，具體的業務場景以及場景下的具體交互采集點，在注冊完成后，系統將生成與之對應的交互日志采集代碼模版
2）采集代碼植入，與需要檢測的業務行為做綁定
3）產生指定行為，采集代碼被執行
4）通過HTTP發送到服務器

關于采集到的日志處理

1.識別流量攻擊，網絡爬蟲，虛假流量
2.數據缺項補正
3.無效數據的剔除
4.日志隔離分發

無線客戶端的日志采集

采用采集SDK完成
多使用名為UserTrack的SDK進行客戶端的日志采集
根據不同的用戶行為分為不同的事件，事件為無線客戶端行為的最小單位
UserTrack(UT)把事件分為：
頁面事件---------頁面瀏覽
控件點擊事件—頁面交互

頁面事件

每條頁面事件記錄三類信息：
1.設備及用戶的基本信息
2.被訪問頁面的信息
3.訪問基本路徑
UT接口：
頁面展現
頁面退出
添加頁面擴展信息的接口
透穿參數，SPM（超級位置模型）進行來源去向的追蹤來還原用戶的行為路徑

控件點擊及其他事件
操作頁面上某個控件，把相關基礎信息告訴SDK即可
特殊場景：
頁面的生命周期，識別頁面的復用，配合棧的深度來識別是否回退
H5&Native日志統一

無線日志傳輸

先存儲客戶端本地，再伺機上傳

日志采集挑戰

如何實現數據的結構化規范化組織，實現更為高效的下游統計計算

典型場景

日志分流與定制處理
采集與計算一體化設計
大促保障

數據同步

直連同步

數據文件同步

數據庫日志解析同步

阿里數據倉庫的同步方式

前提：多樣，海量

批量同步

要實現各類數據庫系統與數據倉庫系統之間的批量雙向數據同步，就需要先將數據轉換為中間狀態，統一數據格式，換為字符串類型
DataX

實時同步

通過解析MySQL的binlog日志（相當于Oracle的歸檔日志）來實時獲得增量的數據更新，并通過消息訂閱模式來實現數據的實時同步的
TimeTunnel(TT）

數據同步遇到的問題與解決萬案

分庫分表的處理

一個中間表，具備將分布在不同數據庫中的不同表集成為一個表的能力TDDL( Taobao D istributed Data Layer）

高效同步和批量同步

OneClick產品：·對不同數據源的數據同步配置透明化，可以通過庫名和表名唯一定位，通過IDB接口獲取元數據信息自動生成配置信息?！ず喕藬祿降牟僮鞑襟E，實現了與數據同步相關的建表、配置任務、發布、測試操作一鍵化處理，并且封裝成Web接口進一步達到批量化的效果?！そ档土藬祿降募寄荛T檻，讓數據需求方更加方便地獲取和使用數據。

增量與全量同步的合并

在傳統的數據整合方案中，合并技術大多采用merge方式( update+insert）：當前流行的大數據平臺基本都不支持update操作，現在我們比較推薦的方式是全外連接（fullouter join) ＋數據全量覆蓋重新加載（insertoverwrite），即如日調度，則將當天的增量數據和前一天的全量數據做全外連接，重新加載最新的全量數據。
如果擔心數據更新錯誤問題，可以采用分區方式，每天保持一個最新的全量版本，保留較短的時間周期（如3～7天）。
當業務系統的表有物理刪除數據的操作，而數據倉庫需要保留所有歷史數據時，也可以選擇這種方式，在數據倉庫中永久保留最新的全量數據快照。

同步性能的處理

數據漂移的處理

1.多獲取后一天的數據
2.通過多個時間戳字段限制時間來獲取相對準確的數據

離線數據開發

數據開發平臺

阿里數據研發崗位：
了解需求→模型設計→ETL開發→測試→發布上線→日常運維→任務下線

通過統一的計算平臺（MaxCompute）
統一的開發平臺（D2等相關平臺和工具）
統一的數據模型規范和統一的數據研發規范

統一計算平臺–MaxCompute

MaxCompute由四部分組成，分別是客戶端（MaxComputeClient）、接人層（MaxCompute Front End）、邏輯層（MaxCompt陽Server）及存儲與計算層（Apsara Core）。Max

統一開發平臺

在云端（02)
SQLSCAN
DQC
在彼岸

任務調度系統

實時技術

流式技術架構

1.數據采集
2.數據處理
3.數據存儲

數據采集

數據處理

1.去重指標
2.數據傾斜
3.事務處理

數據存儲

1.表名設計
2. rowkey設計
3. 數據服務

流式數據模型

1.數據分層
2.多流關聯
3.維表使用

數據服務

1.服務架構的更迭
2.技術架構
3.性能
4.穩定性

數據挖掘

必備：
①面向機器學習算法的并行計算框架與算法平臺
②面向企業級數據挖掘的算法資產管理體系
MPI可以更好：頻繁進行網絡通信、內存消耗高、計算要求快速迭代的算法任務（所以沒有選擇基于MapReduce 與Hive的計算）

數據中臺

通常一次數據挖掘的過程包括商業理解、數據準備、特征工程、模型訓練、模型測試、模型部署、線上應用及效果反饋等環節。
構建中臺的意義：將一些通用的技術集成起來形成中臺技術體系，為各業務部門提供統一、高效的技術服務，避免各業務部門在各自業務發展的過程中進行重復的技術建設造成不必要的資源浪費與時間消耗。

挖掘數據中臺

包含兩類數據：特征數據與結果數據

挖掘算法中臺

數據挖掘案例

用戶畫像

詳細講解該用戶標簽是如何基于全域數據產出的？

互聯網反作弊

unit2數據模型篇

大數據領域建模綜述

數據模型就是數據組織和存儲方法，它強調從業務、數據存取和使用角度合理存儲數據。
經典數據庫理論書籍，如《數據庫系統概念》
？
OLTP系統通常面向的主要數據操作是隨機讀寫，主要采用滿足3NF的實體關系模型存儲數據，從而在事務處理中解決數據的冗余和一致性問題
OLAP系統面向的主要數據操作是批量讀寫，事務處理中的一致性不是OLAP所關注的，其主要關注數據的整合，以及在一次性的復雜大數據查詢和處理中的性能，因此它需要采用一些不同的數據建模方法。

典型的數據倉庫建模萬法論

ER模型

維度模型

Data Vault模型

ER模型的衍生

Anchor模型

對DataVault模型做了進一步規范化處理

阿里巴巴數據模型

第一階段 ODS+DSS
第二階段

在不太成熟、快速變化的業務面前，構建ER模型的風險非常大，不太適合去構建ER模型。
第三階段 Kimball

阿里巴巴數據整合及管理體系–OneData

概述

規范定義

名詞術語

指標體系

模型設計

指導理論–維度建模

模型層次

基本原則

1 .高內聚和低輯合
2.核心模型與擴展模型分離
3.公共處理邏輯下沉及單一
4.成本與性能平衡
5.數據可回滾
6.一致性
7.命名清晰、可理解

模型實施

常用的模型實施過程

1.Kimball
2.Inmon

3.其他模型實施過程

OneData實施過程

維度設計

在維度建模中，將度量稱為“事實”，將環境描述為“維度”。
維度是用于分析事實所需要的多樣環境。

維度設計

維度表的主鍵一般都使用代理鍵，沒見過用自然鍵的維表
選擇主鍵：自然鍵還是代理鍵？

基本方法

第一步：選擇維度或新建維度
第二步：確定主維表
第三步：確定相關維表
第四步：確定維度屬性：
1.從主維表中選擇維度屬性或生成新的維度屬性；
2.從相關維表中選擇維度屬性或生成新的維度屬性

維度的層次結構

規范化和反規范化

一致性維度和交叉探查

維度設計高級主題

維度整合

1.垂直整合
2.水平整合

維度拆分

1.垂直拆分
2.水平拆分

維度變化

緩慢變化維

快照維表

極限存儲

微型維度

特殊維度

1.遞歸層次

行為維度

多值維度

雜項維度

事實表設計

事實表基礎

事務事實表

單事物事實表

多事物事實表

周期快照事實表

累積快照事實表

三種事實表的比較

無事實的事實表

聚集型事實表

unit 3 數據管理篇

元數據

技術元數據
業務元數據

計算管理

系統優化

1.HBO
2.CBO

任務優化

1.MAP傾斜
2.join傾斜
3.Reduce傾斜

存儲和成本管理

數據壓縮

archive壓縮方法

數據重分布

主要通過修改distributeby和sortby字段的方法進行數據重分布

存儲泊理頂優化

生命周期管理

數據成本計量

數據使用計費

數據質量

1 .消費場景知曉
2.數據生產加工各個環節卡點校驗
3.風險點監控
4.質量衡量
5.質量配套工具

Uint4 數據應用篇

生意參謀

對內數據產品平臺

總結

以上是生活随笔為你收集整理的大数据之路-阅读笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。