大數據實戰【千億級數倉】項目總結

        前段時間作過一個大數據離線數倉的項目，先後花了有好幾周的時間。一共是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、HL七、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數據表的查詢效率。

---

結語

        關於大數據離線數倉項目的總結，暫時就先更到這裏…後期博主可能會對此進行更詳細的補充，敬請期待????

        若是以上過程當中出現了任何的紕漏錯誤，煩請大佬們指正????

        受益的朋友或對大數據技術感興趣的夥伴記得點贊關注支持一波????