前段時間做過一個大資料離線數倉的項目，前後花了有好幾周的時間。一共是6個階段，想關注階段細節的朋友可以檢視大資料實戰項目這個專欄。
現在項目結束了，理應對此進行一個總結，好好回顧一下這個項目中遺漏的細節…
文章目錄
- 項目架構
- 技術選型
- 資料來源
- 資料存儲
- 資料同步
- 計算模型
- 結果存儲
- 加速查詢
- 結語
項目架構
① 原始資料在mysql中存儲
② 使用kettle将資料從mysql同步到資料倉庫(hive)
同步分為全量同步+增量同步
增量同步需要使用到拉連結清單(目标：既能夠儲存曆史資料，又不會有資料備援)
③ 資料儲存到hive
hive數倉内結構:
ODS : 存儲着資料源同步過來的資料
DW : 對ODS層資料機型預處理（資料過濾，資料填充），以及資料的拉寬，将業務中需要的字段，但是字段不在一個表裡。使用拉寬（join）将這些字段拉到一個表中。
ADS：存儲最終結果
④ 使用kylin對hive内的資料進行預計算，提高查詢效率
⑤ 部分資料同步至mysql,使用sqoop/kettle同步
技術選型
★ 資料來源： MySQL
★ 資料存儲： Hive
★ 資料同步： Kettle
★ 計算模型（數倉）： ODS，DW，ADS三層
★ 結果存儲： Hive的ads和Mysql
★ 加速查詢的元件： Kylin
…
以為就這樣技術選型就講完了？不不不，既然在開頭咱都談到了需要深挖細節，那麼接下來我們就要從結論反推，思考某個方面的技術為什麼需要用到這個技術/元件，而不是其他類似的技術/元件。
資料來源
我們的資料來源為什麼選擇的是關系型資料庫MySQL，而不是其他的非關系型資料庫？
最主要的原因是因為 MySQL
■ 體積小，速度快，總體擁有成本低，開源；
■ 支援多種作業系統；
■ 是開源資料庫，提供的接口支援多種語言連接配接操作；
而以MongoDB為例的非關系型資料庫
□ 使用鍵值對存儲資料；
□ 無需經過sql層的解析，讀寫性能很高；
□ 不提供SQL支援，學習使用成本較高；
□ 無事務處理，附加功能bi和報表等支援也不好；
綜上所述，在該項目中，關系資料庫MySQL更适合。
資料存儲
Hive是基于Hadoop的一個資料倉庫工具，可以将結構化的資料檔案映射為一張資料庫表，并提供類SQL查詢功能（HQL）。其本質是将SQL轉換為MapReduce的任務進行運算，底層由HDFS來提供資料的存儲，hive可以了解為一個将SQL轉換為MapReduce的任務的工具。
使用Hive的好處:
√ 操作接口采用類SQL文法，提供快速開發的能力。
√ 避免了去寫MapReduce，減少開發人員的學習成本。
√ 功能擴充很友善。
通過Hive與傳統RDBMS的對比
| Hive | RDBMS | |
| 查詢語言 | HQL | SQL |
| 資料存儲 | HDFS | Raw Device or Local FS |
| 執行 | MapReduce | Excutor |
| 執行延遲 | 高 | 低 |
| 處理資料規模 | 大 | 小 |
| 索引 | 0.8版本後加入位圖索引 | 有複雜的索引 |
總結：
hive具有sql資料庫的外表，但應用場景完全不同
hive隻适合用來做批量資料統計分析
資料同步
談到關于資料同步的問題，相信很多好學的朋友有疑問了????
為啥這個項目不用Sqoop來進行資料的同步？
相信看完下面Kettle與Sqoop差異對比的表格就清楚了。
| 功能 | Kettle | Sqoop |
| 領域 | 資料抽取、轉換、加載 | 關系型與非關系型資料庫資料遷移 |
| 輸入 | 關系型資料庫、HDFS、Hbase、Excel、HL7、JSON、RSS、文本檔案、等等 | 關系型資料庫、非關系型資料庫 |
| 輸出 | 關系型資料庫、Hbase、HDFS、Excel、CSV、等等 | 關系型資料庫、非關系型資料庫 |
| Hadoop內建度 | 外部工具，需要安裝對應版本的插件，僅支援流行的Hadoop發行版 | 屬于Hadoop生态圈，啟動即用 |
| 适用資料量 | 十萬、百萬、千萬級 | 億級 |
| 支援系統 | Linux、Windows、Unix | Linux |
| 互動 | 有圖形界面 | 沒有圖形界面 |
| 底層 | 多線程提高效率 | MapReduce |
在這個項目階段一開始的時候，就介紹了，咋們這個項目的每日訂單量為10W，按照上圖表格所述，确實不太适合 支援系統單一，互動無圖形化界面，底層計算效率低的 Sqoop。
當然也并不是說Sqoop沒用，當資料量真的達到億級别之後，Kettle就無法發揮它的優勢，這個時候我們就隻能借助于Sqoop了。
計算模型
每個企業根據自己的業務需求可以分成不同的層次，但是最基礎的分層思想，理論上資料分為三個層，資料營運層、資料倉庫層和資料服務層。基于這個基礎分層之上添加新的層次，來滿足不同的業務需求。
數倉分層通過資料分層管控資料品質，需要對資料清洗等操作，不必改一次業務就需要重新接入資料，每一層資料都是單獨的作用，同時規範資料分層，減少業務開發、直接抽取資料。
其中
資料營運層ODS存儲着資料源同步過來的資料
資料倉庫層DW需要對ODS層資料進行預處理（資料過濾，資料填充）
資料服務層存儲最終結果
結果存儲
通過上面的分析，在Hive中ADS層負責存儲着結果資料，可以根據使用者需求，利用簡易sql而查詢出最終結果。而資料源來自MySQL，我們自然也可以選擇将結果存儲至MySQL當中。資料同步元件根據實際情況選擇Kettle或者Sqoop。
加速查詢
Kylin 是一個 Hadoop 生态圈下的 MOLAP 系統，是 ebay 大資料部門從2014 年開始研發的支援 TB 到 PB 級别資料量的分布式 Olap 分析引擎。其特點包括:
✔ 可擴充的超快的 OLAP 引擎
✔ 提供 ANSI-SQL 接口
✔ 互動式查詢能力
✔ MOLAP Cube 的概念
✔ 與 BI 工具可無縫整合
Kylin 的核心思想是利用空間換時間，在資料 ETL 導入 OLAP 引擎時提前計算各次元的聚合結果并持久化儲存。
在離線數倉項目中，我們使用Kylin對Hive的ADS層的資料進行預處理，并将結果寫入到HBase，提高了實際應用場景對于Hive資料表的查詢效率。
結語
關于大資料離線數倉項目的總結，暫時就先更到這裡…後期部落客可能會對此進行更詳細的補充，敬請期待????
如果以上過程中出現了任何的纰漏錯誤，煩請大佬們指正????
受益的朋友或對大資料技術感興趣的夥伴記得點贊關注支援一波????