《大數據之路-阿里巴巴大數據實踐》拆書稿以及讀後感
總體分爲三個部分
第一部分：數據技術
數據採集，數據同步，離線和實時計算，數據服務以及數據應用
第二部分：數據模型
維度模型設計
第三部分：數據管理
元數據管理，計算管理以及生命週期管理
以上各部分在邏輯上所處的位置如下圖可見：
第一部分、數據技術
數據採集與數據同步屬於數據倉庫的輸入手段，數據採集大部分是數據主動觸發程序將數據流向數據倉庫，大部分的落地方式可以是以server/agent或者通過網絡協議直接發送數據。實時性較高； 而數據同步大部分落地方式是數據被動的被抽取程序獲取並流向數據倉庫。數據同步的方式應用場景多用於離線批量的數據同步。採用遠程訪問權限，直接將數據提取出來並存入數據倉庫。
《大數據之路》這本書中介紹的數據技術內容腦圖如下：
在個人的從業經驗中，數據倉庫的輸入部分應用最多的場景就是：Sqoop/DataX 完成數據同步，數據採集一般使用 Kafka+ Flume/Spark Streaming 。數據同步和採集部分是數據倉庫的數據源頭，程序的穩定性和準確性都應該保持相當高的水平，才能給後續的數據倉庫打好基礎。另一方面，數據倉庫的計算層，牽扯到數據倉庫的分層策略問題。完善的數據倉庫基本上應該會包含：數據操作層（近源層）、明細數據層（DWD）、數據彙總層/多維方陣、數據集市/應用。每一層對應的數據粒度不同，滿足的數據需求也不相同。
數據分層在一定程度上能夠解決以下問題：
- 1 降低數據統計方面的耦合度
- 2 便於數據追根溯源，查找問題
- 3 便於數據的血緣分析
- 4 不同分層對應不同粒度，滿足不同的數據需求
數據應用/服務：
針對數據應用方面個人認爲數據產品是以後的發展趨勢，每個行業在各自領域已經積累了大量的行業數據，目前的場景已經不是銷售市場去”打天下“的模式了。而要比的是服務，要將數據產品轉化成服務，和自身的業務深度契合。要從數據中發掘價值，體現價值，產生價值效益。現在的企業間合作已經不能停留在表面上的服務層面，而是要深耕業務場景，提供行業解決方案，與合作方深度合作。達到無法替代層次。否則，如果停留在表面的服務合作，無法解決企業痛點問題，終將被競爭激烈市場所淘汰
第二部分、數據模型
維度建模現在的應用越來越頻繁，並且基本上演變到最後都是星型模型和雪花模型的混合模型。
維度建模的具體方法論可以看我往期博客，這裏再度重申以下建模過程中最重要的幾點：
1. 數據規範和標準
- 數據分類標準
- 編碼規則標準
- 命名規範（詞根清單，表命名，字段命名，作業命名必須規範，見名知意）
2. 創建一致性維度
整個數據倉庫，在主題域中某一個維度的命名和含義有且只能有一個，不能出現二義性。並且必須保證其完整性（事件表中出現的維度編碼在維度表中一定要能找到含義）
3. 創建一致性事實
1）確定好事實表的粒度和維度，粒度是否可繼續下鑽（細分），維度是否可以再拆分和補全。
2）事實表的統計維度是否全面（可支撐此業務的所有數據需求），可適當的添加衍生維度
《大數據之路》這本書中介紹的數據模型內容腦圖如下：
第三部分、 數據管理
數據管理在 《大數據之路》這本書中介紹了比較多的內容， 這裏只側重於以下三點進行說明：
- 元數據管理
- 計算管理
- 生命週期管理
其實，數據管理的反饋機制存在着整個數據流轉過程，元數據管理能夠把控數據同步邏輯，數據清洗/統計規則，數據服務的邏輯規則等。計算管理能夠反饋作業的執行效率，數據提供服務的質量，集羣的性能等。生命週期管理能夠反饋數據的迭代更新，集羣的存儲空間，數據服務的廣度和深度等。
《大數據之路》中這三方面的思維導圖如下：
其中，在元數據管理方面，個人還沒有找到非常適合自己的工具，各位網友有這方面儲備的希望給我留言，給一個學習的機會，謝謝！
在元數據管理方面這本書中介紹了阿里的SmartDQ元數據管理模型，看完之後有非常大的觸動，在數據服務或接口方面可以參照此模型進行封裝服務。並且根據之前的工作經驗來看，這種模型的管理方式較爲靈活，可以應對不同的主題需求，也具有很強的擴展性。其模型的具體示意圖如下：
由上圖可以看到，可以在數據服務層構建一系列的虛擬主題，每個虛擬主題就類似與視圖，沒有實體表和數據，而是通過元數據管理，將主題下所有的物理表進行整合。在提供主題服務時並沒有產生數據表的冗餘計算和存儲空間的消耗。另外完全實現了靈活可配置。
整本書的思維導圖如下：
