Update(Stage5)：Kudu入門_項目介紹_ CDH搭建

Kudu

導讀

1. 什麼是 Kudu

2. 操做 Kudu

3. 如何設計 Kudu 的表

Table of Contents

• 1. 什麼是 Kudu
  • 1.1. Kudu 的應用場景
  • 1.2. Kudu 和其它存儲工具的對比
  • 1.3. Kudu 的設計和結構
• 2. Kudu 安裝和操做
  • 2.1. 準備初始環境
  • 2.2. 配置 Yum 源
  • 2.. 使用 Java 操做 Kudu
  • 2.. 使用 Spark 操做 Kudu
• 4. Kudu 表和模式

1. 什麼是 Kudu

導讀

1. Kudu 的應用場景是什麼?

2. Kudu 在大數據平臺中的位置在哪?

3. Kudu 用什麼樣的設計, 才能知足其設計目標?

4. Kudu 中有什麼集羣角色?

1.1. Kudu 的應用場景

現代大數據的應用場景

例如如今要作一個相似物聯網的項目, 多是對某個工廠的生產數據進行分析

項目特色

1. 數據量大

   有一個很是重大的挑戰, 就是這些設備可能不少, 其所產生的事件記錄可能也很大, 因此須要對設備進行數據收集和分析的話, 須要使用一些大數據的組件和功能

2. 流式處理

   由於數據是事件, 事件是一個一個來的, 而且若是快速查看結果的話, 必須使用流計算來處理這些數據

3. 數據須要存儲

   最終須要對數據進行統計和分析, 因此數據要先有一個地方存, 後再經過可視化平臺去分析和處理

對存儲層的要求

這樣的一個流計算系統, 須要對數據進行什麼樣的處理呢?

1. 要可以及時的看到最近的數據, 判斷系統是否有異常

2. 要可以掃描歷史數據, 從而改進設備和流程

因此對數據存儲層就有可能進行以下的操做

1. 逐行插入, 由於數據是一行一行來的, 要想及時看到, 就須要來一行插入一行

2. 低延遲隨機讀取, 若是想分析某臺設備的信息, 就須要在數據集中隨機讀取某一個設備的事件記錄

3. 快速分析和掃描, 數據分析師須要快速的獲得結論, 執行一行 SQL 等上十天是不行的

方案一: 使用  Spark Streaming 配合  HDFS 存儲

總結一下需求

• 實時處理, Spark Streaming

• 大數據存儲, HDFS

• 使用 Kafka 過渡數據

可是這樣的方案有一個很是重大的問題, 就是速度機器之慢, 由於 HDFS 不擅長存儲小文件, 而經過流處理直接寫入 HDFS 的話, 會產生很是大量的小文件, 掃描性能十分的差

方案二:  HDFS +  compaction

上面方案的問題是大量小文件的查詢是很是低效的, 因此能夠將這些小文件壓縮合並起來

可是這樣的處理方案也有不少問題

• 一個文件只有再也不活躍時才能合併

• 不能將覆蓋的結果放回原來的位置

因此通常在流式系統中進行小文件合併的話, 須要將數據放在一個新的目錄中, 讓 Hive/Impala 指向新的位置, 再清理老的位置

方案三:  HBase +  HDFS

前面的方案都不夠舒服, 主要緣由是由於一直在強迫 HDFS 作它並不擅長的事情, 對於實時的數據存儲, 誰更適合呢? HBase 好像更合適一些, 雖然 HBase 適合實時的低延遲的數據村醋, 可是對於歷史的大規模數據的分析和掃描性能是比較差的, 因此還要結合 HDFS 和 Parquet 來作這件事

由於 HBase 不擅長離線數據分析, 因此在必定的條件觸發下, 須要將 HBase 中的數據寫入 HDFS 中的 Parquet 文件中, 以便支持離線數據分析, 可是這種方案又會產生新的問題

• 維護特別複雜, 由於須要在不一樣的存儲間複製數據

• 難以進行統一的查詢, 由於實時數據和離線數據不在同一個地方

這種方案, 也稱之爲 Lambda, 分爲實時層和批處理層, 經過這些這麼複雜的方案, 其實想作的就是一件事, 流式數據的存儲和快速查詢

方案四:  Kudu

Kudu 聲稱在掃描性能上, 媲美 HDFS 上的 Parquet. 在隨機讀寫性能上, 媲美 HBase. 因此將存儲存替換爲 Kudu, 理論上就能解決咱們的問題了.

總結

對於實時流式數據處理, Spark, Flink, Storm 等工具提供了計算上的支持, 可是它們都須要依賴外部的存儲系統, 對存儲系統的要求會比較高一些, 要知足以下的特色

• 支持逐行插入

• 支持更新

• 低延遲隨機讀取

• 快速分析和掃描

1.2. Kudu 和其它存儲工具的對比

導讀

1. OLAP 和 OLTP

2. 行式存儲和列式存儲

3. Kudu 和 MySQL 的區別

4. Kudu 和 HBase 的區別

OLAP 和  OLTP

廣義來說, 數據庫分爲 OLTP 和 OLAP。

數據處理大體能夠分紅兩大類：聯機事務處理OLTP（on-line transaction processing）、聯機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關係型數據庫的主要應用，主要是基本的、平常的事務處理，例如銀行交易。OLAP是數據倉庫系統的主要應用，支持複雜的分析操做，側重決策支持，而且提供直觀易懂的查詢結果。 

OLTP 系統強調數據庫內存效率，強調內存各類指標的命令率，強調綁定變量，強調併發操做；
OLAP 系統則強調數據分析，強調SQL執行市場，強調磁盤I/O，強調分區等。

• OLTP

  先舉個栗子, 在電商網站中, 常常見到一個功能 - "個人訂單", 這個功能再查詢數據的時候, 是查詢的某一個用戶的數據, 並非批量的數據

  OLTP 須要作的事情是

  1. 快速插入和更新

  2. 精確查詢

  因此 OLTP 並不須要對數據進行大規模的掃描和分析, 因此它的掃描性能並很差, 它主要是用於對響應速度和數據完整性很高的在線服務應用中

• OLAP

  OLAP 和 OLTP 的場景不一樣, OLAP 主要服務於分析型應用, 其通常是批量加載數據, 若是出錯了, 從新查詢便可

• 總結

  • OLTP 隨機訪問能力比較強, 批量掃描比較差

  • OLAP 擅長大規模批量數據加載, 對於隨機訪問的能力則比較差

  • 大數據系統中, 每每從 OLTP 數據庫中 ETL 放入 OLAP 數據庫中, 而後作分析和處理

行式存儲和列式存儲

行式和列式是不一樣的存儲方式, 其大體以下

• 行式存儲

  行式通常用作於 OLTP, 例如個人訂單, 那不只要看到訂單, 還要看到收貨地址, 付款信息, 派送信息等, 因此 OLTP 通常是傾向於獲取整行全部列的信息

• 列式存儲

  而分析平臺就不太同樣了, 例如分析銷售額, 那可能只對銷售額這一列感興趣, 因此按照列存儲, 只獲取須要的列, 這樣能減小數據的讀取量

存儲模型

結構

• Kudu 的存儲模型是有結構的表

• OLTP 中表明性的 MySQL, Oracle 模型是有結構的表

• HBase 是看起來像是表同樣的 Key-Value 型數據, Key 是 RowKey 和列簇的組合, Value 是具體的值

主鍵

• Kudu 採用了 Raft 協議, 因此 Kudu 的表中有惟一主鍵

• 關係型數據庫也有惟一主鍵

• HBase 的 RowKey 並非惟一主鍵

事務支持

1. Kudu 缺乏跨行的 ACID 事務

2. 關係型數據庫大多在單機上是能夠支持 ACID 事務的

性能

• Kudu 的隨機讀寫速度目標是和 HBase 類似, 可是這個目標創建在使用 SSD 基礎之上

• Kudu 的批量查詢性能目標是比 HDFS 上的 Parquet 慢兩倍之內

硬件需求

• Hadoop 的設計理念是儘量的減小硬件依賴, 使用更廉價的機器, 配置機械硬盤

• Kudu 的時代 SSD 已經比較常見了, 可以作更多的磁盤操做和內存操做

• Hadoop 不太能發揮比較好的硬件的能力, 而 Kudu 爲了大內存和 SSD 而設計, 因此 Kudu 對硬件的需求會更大一些

1.3. Kudu 的設計和結構

導讀

1. Kudu 是什麼

2. Kudu 的總體設計

3. Kudu 的角色

4. Kudu 的概念

Kudu 是什麼

HDFS 上的數據分析

HDFS 是一種可以很是高效的進行數據分析的存儲引擎

• HDFS 有不少支持壓縮的列式存儲的文件格式, 性能很好, 例如 Parquet 和 ORC

• HDFS 自己支持並行

HBase 能夠進行高效的數據插入和讀取

HBase 主要用於完成一些對實時性要求比較高的場景

• HBase 可以以極高的吞吐量來進行數據存儲, 不管是批量加載, 仍是大量 put

• HBase 可以對主鍵進行很是高效的掃描, 由於其根據主鍵進行排序和維護

• 可是對於主鍵之外的列進行掃描則性能會比較差

Kudu 的設計目標

Kudu 最初的目標是成爲一個新的存儲引擎, 能夠進行快速的數據分析, 又能夠進行高效的數據隨機插入, 這樣就能簡化數據從源端到 Hadoop 中能夠用於被分析的過程, 因此有以下的一些設計目標

• 儘量快速的掃描, 達到 HDFS 中 Parquet 的二分之一速度

• 儘量的支持隨機讀寫, 達到 1ms 的響應時間

• 列式存儲

• 支持 NoSQL 樣式的 API, 例如 put, get, delete, scan

整體設計

• Kudu 不支持 SQL

  Kudu 和 Impala 都是 Cloudera 的項目, 因此 Kudu 不打算本身實現 SQL 的解析和執行計劃, 而是選擇放在 Impala 中實現, 這兩個東西配合來完成任務

  Kudu 的底層是一個基於表的引擎, 可是提供了 NoSQL 的 API

• Kudu 中存儲兩類的數據

  • Kudu 存儲本身的元信息, 例如表名, 列名, 列類型

  • Kudu 固然也有存放表中的數據

  這兩種數據都存儲在 tablet 中

• Master server

  存儲元數據的 tablet 由 Master server 管理

• Tablet server

  存儲表中數據的 tablet 由不一樣的 Tablet server 管理

• tablet

  Master server 和 Tablet server 都是以 tablet 做爲存儲形式來存儲數據的, 一個 tablet 一般由一個 Leader 和兩個 Follower 組成, 這些角色分佈的不一樣的服務器中

Master server

• Master server 中存儲的其實也就是一個 tablet, 這個 tablet 中存儲系統的元數據, 因此 Kudu 無需依賴 Hive

• 客戶端訪問某一張表的某一部分數據時, 會先詢問 Master server, 獲取這個數據的位置, 去對應位置獲取或者存儲數據

• 雖然 Master 比較重要, 可是其承擔的職責並很少, 數據量也不大, 因此爲了增進效率, 這個 tablet 會存儲在內存中

• 生產環境中一般會使用多個 Master server 來保證可用性

Tablet server

• Tablet server 中也是 tablet, 可是其中存儲的是表數據

• Tablet server 的任務很是繁重, 其負責和數據相關的全部操做, 包括存儲, 訪問, 壓縮, 其還負責將數據複製到其它機器

• 由於 Tablet server 特殊的結構, 其任務過於繁重, 因此有以下的限制

  • Kudu 最多支持 300 個服務器, 建議 Tablet server 最多不超過 100 個

  • 建議每一個 Tablet server 至多包含 2000 個 tablet (包含 Follower)

  • 建議每一個表在每一個 Tablet server 中至多包含 60 個 tablet (包含 Follower)

  • 每一個 Tablet server 至多管理 8TB 數據

  • 理想環境下, 一個 tablet leader 應該對應一個 CPU 核心, 以保證最優的掃描性能

tablet 的存儲結構

在 Kudu 中, 爲了同時支持批量分析和隨機訪問, 在總體上的設計一邊參考了 Parquet 這樣的文件格式的設計, 一邊參考了 HBase 的設計

• MemRowSet

  這個組件就很像 HBase 中的 MemoryStore, 是一個緩衝區, 數據來了先放緩衝區, 保證響應速度

• DiskRowSet

  列存儲的好處不只僅只是分析的時候只 I/O 對應的列, 還有一個好處, 就是同類型的數據放在一塊兒, 更容易壓縮和編碼

  DiskRowSet 中的數據以列式組織, 相似 Parquet 中的方式, 對其中的列進行編碼, 經過布隆過濾器增進查詢速度

tablet 的  Insert 流程

• 使用 MemRowSet 做爲緩衝, 特定條件下寫爲多個 DiskRowSet

• 在插入以前, 爲了保證主鍵惟一性, 會已有的 DiskRowSet 和 MemRowSet 進行驗證, 若是主鍵已經存在則報錯

tablet 的  Update 流程

1. 查找要更新的數據在哪一個 DiskRowSet 中

2. 數據放入 DiskRowSet 所持有的 DeltaMemStore 中, 這一步也是暫存

3. 特定時機下, DeltaMemStore 會將數據溢寫到磁盤, 生成 RedoDeltaFile, 記錄數據的變化

4. 定時合併 RedoDeltaFile

   • 合併策略有三種, 常見的有兩種, 一種是 major, 會將數據合併到基線數據中, 一種是 minor, 只合並 RedoDeltaFile

2. Kudu 安裝和操做

導讀

由於 Kudu 常常和 Impala 配合使用, 因此咱們也要安裝 Impala, 可是又由於 Impala 強依賴於 CDH, 因此咱們連 CDH 一塊兒安裝一下, 作一個完整的 CDH 集羣, 搭建一套新的虛擬機

1. 建立虛擬機準備初始環境

2. 安裝 Zookeeper

3. 安裝 Hadoop

4. 安裝 MySQL

5. 安裝 Hive

6. 安裝 Kudu

7. 安裝 Impala

2.1. 準備初始環境

導讀

以前的環境中已經安裝了太多環境, 因此換一個新的虛擬機, 從頭開始安裝

1. 建立虛擬機

2. 安裝系統

3. 複製三臺虛擬機

4. 配置時間同步服務

5. 配置主機名

6. 關閉 SELinux

7. 關閉防火牆

8. 重啓

9. 配置免密登陸

10. 安裝 JDK

Step 1: 建立虛擬機

1. 在 VmWare 中點擊建立虛擬機

2. 打開向導

3. 設置硬件兼容性

4. 指定系統安裝方式

5. 指定系統類型

6. 指定虛擬機位置

7. 處理器配置

8. 內存配置

9. 選擇網絡類型, 這一步很是重要, 必定要配置正確

10. 選擇 I/O 類型

11. 選擇虛擬磁盤類型

12. 選擇磁盤建立方式

13. 建立新磁盤

14. 指定磁盤文件位置

15. 終於, 虛擬機建立好了, 複製圖片差點沒給我累掛

Step 2: 安裝  CentOS 6

1. 爲虛擬機掛載安裝盤

2. 選擇安裝盤

3. 開啓虛擬機

4. 進入 CentOS 6 的安裝

5. 跳過磁盤選擇

6. 選擇語言

7. 選擇鍵盤類型

8. 選擇存儲設備類型

9. 清除數據

10. 主機名

11. 選擇時區, 這一步很重要, 必定要選

12. 設置 root 帳號, 密碼最好是統一的, 就 hadoop 吧

13. 選擇安裝類型

14. 選擇安裝軟件的類型

15. 安裝完成, 終於不用複製圖片了, 開心

Step 3: 集羣規劃

HostName	IP
cdh01.itcast.cn	192.168.169.101
cdh02.itcast.cn	192.168.169.102
cdh03.itcast.cn	192.168.169.103

已經安裝好一臺虛擬機了, 接下來經過複製的方式建立三臺虛擬機

1. 複製虛擬機文件夾(Ps. 在建立虛擬機時候選擇的路徑)

2. 進入三個文件夾中, 點擊 vmx 文件, 讓 VmWare 加載

3. 爲全部的虛擬機生成新的 MAC 地址

4. 確認 vmnet8 的網關地址, 以及這塊虛擬網卡的地址

5. 修改網卡信息

   進入每臺機器中, 修改 70-persistent-net.rules

   vi /etc/udev/rules.d/70-persistent-net.rules

6. 更改 IP 地址,  修改/etc/sysconfig/network-scripts/ifcfg-eth0 文件。     注意: 1. 網關地址要和 vmnet8 的網關地址一致, 2. IP 改成 192.168.169.101; 3.修改好後，重啓系統！ 4.能夠經過ifconfig  或者 ip addr這2個命令來查驗IP地址是否正確。

Step 4: 配置時間同步服務

在幾乎全部的分佈式存儲系統上, 都須要進行時鐘同步, 避免出現舊的數據在同步過程當中變爲新的數據, 包括 HBase, HDFS, Kudu都須要進行時鐘同步, 因此在一切開始前, 先同步一下時鐘, 保證沒有問題

時鐘同步比較簡單, 只須要肯定時鐘沒有太大差別, 而後開啓 ntp 的自動同步服務便可

yum install -y ntp
service ntpd start
chkconfig ntpd on  設置開機啓動

同步大概須要 5 - 10 分鐘, 而後查看是否已是同步狀態便可

ntpstat

最後在其他兩臺節點也要如此配置一下

Step 5: 配置主機名

配置主機名是爲了在網絡內能夠通訊

1. 修改 /etc/sysconfig/network 文件, 聲明主機名

   # 在三個節點上使用不一樣的主機名
   HOSTNAME=cdh01.itcast.cn

2. 修改 /etc/hosts 文件, 肯定 DNS 的主機名

   127.0.0.1 cdh01.itcast.cn localhost cdh01
   
   192.168.169.101 cdh01.itcast.cn cdh01
   192.168.169.102 cdh02.itcast.cn cdh02
   192.168.169.103 cdh03.itcast.cn cdh03

3. 在其他的兩臺機器中也要如此配置

Step 6: 關閉  SELinux

修改 /etc/selinus/config 將 SELinux 關閉

最後別忘了再其它節點也要如此配置

Step 7: 關閉防火牆

執行以下命令作兩件事, 關閉防火牆, 關閉防火牆開機啓動

service iptables stop
chkconfig iptables off

最後別忘了再其它節點也要如此配置

Step x: 重啓

剛纔有一些配置是沒有及時生效的, 爲了不麻煩, 在這裏能夠重啓一下, 在三臺節點上依次執行命令

reboot -h now

Step 8: 配置三臺節點的免密登陸

SSH 有兩種登陸方式

1. 輸入密碼從而驗證登陸

2. 服務器生成隨機字符串, 客戶機使用私鑰加密, 服務器使用預先指定的公鑰解密, 從而驗證登陸

因此配置免密登陸就可使用第二種方式, 大概步驟就是先在客戶機生成密鑰對, 而後複製給服務器

# 生成密鑰對
ssh-keygen -t rsa

# 拷貝公鑰到服務機
ssh-copy-id cdh01
ssh-copy-id cdh02
ssh-copy-id cdh03

而後在三臺節點上依次執行這些命令

Step 9: 安裝  JDK

安裝 JDK 以前, 能夠先卸載已經默認安裝的 JDK, 這樣能夠避免一些詭異問題

1. 查看是否有存留的 JDK

   rpm -qa | grep java

2. 若是有, 則使用以下命令卸載

   rpm -e -nodeps xx

3. 上傳 JDK 包到服務器中

4. 解壓並拷貝到 /usr/java 中

   tar xzvf jdk-8u192-linux-x64.tar.gz
   mv jdk1.8.0_192 /usr/java/

5. 修改 /etc/hosts 配置環境變量

   export JAVA_HOME=/usr/java/jdk1.8.0_192
   export PATH=$PATH:$JAVA_HOME/bin

6. 在剩餘兩臺主機上重複上述步驟

 

2.2. 建立本地 Yum 倉庫

導讀

建立本地 Yum 倉庫的目的是由於從遠端的 Yum 倉庫下載東西的速度實在是太渣, 然而 CDH 的全部組件幾乎都要從 Yum 安裝, 因此搭建一個本地倉庫會加快下載速度

1. 下載 CDH 的全部安裝包

2. 生成 CDH 的 Yum 倉庫

3. 配置服務器, 在局域網共享倉庫

Step 1: 下載  CDH 的安裝包

建立本地 Yum 倉庫的原理是將 CDH 的安裝包下載下來, 提供 Http 服務給局域網其它主機(或本機), 讓其它主機的 Yum 可以經過 Http 服務下載 CDH 的安裝包, 因此須要先下載對應的 CDH 安裝包

須要注意的是, 這一步能夠一點都不作, 由於已經爲你們提供了對應的安裝包, 在 DMP 的目錄中, 就能找到 cloudera-cdh5 這個目錄, 上傳到服務器便可

1. 下載 CDH 的安裝包須要使用 CDH 的一個工具, 要安裝 CDH 的這個工具就要先導入 CDH 的 Yum 源

   wget https://archive.cloudera.com/cdh5/redhat/6/x86_64/cdh/cloudera-cdh5.repo
   mv cloudera-cdh5.repo /etc/yum.repos.d/

2. 安裝 CDH 安裝包同步工具

   yum install -y yum-utils createrepo

3. 同步 CDH 的安裝包

   reposync -r cloudera-cdh5

Step 2: 建立本地  Yum 倉庫服務器

建立本地 Yum 倉庫的原理是將 CDH 的安裝包下載下來, 提供 Http 服務給局域網其它主機(或本機), 讓其它主機的 Yum 可以經過 Http 服務下載 CDH 的安裝包, 因此須要提供 Http 服務, 讓本機或者其它節點能夠經過 Http 下載文件, Yum 本質也就是幫助咱們從 Yum 的軟件倉庫下載軟件

1. 安裝 Http 服務器軟件

   yum install -y httpd
   service httpd start

2. 建立 Yum 倉庫的 Http 目錄

   mkdir -p /var/www/html/cdh/5
   cp -r cloudera-cdh5/RPMS /var/www/html/cdh/5/
   cd /var/www/html/cdh/5
   createrepo .

3. 在三臺主機上配置 Yum 源

   最後一步即是向 Yum 增長一個新的源, 指向咱們在 cdh01 上建立的 Yum 倉庫, 可是在這個環節的第一步中, 已經下載了一個 Yum 的源, 只須要修改這個源的文件, 把 URL 替換爲 cdh01 的地址便可

   因此在 cdh01 上修改文件 /etc/yum.repos.d/cloudera-cdh5.repo 爲

   baseurl=http://cdh01/cdh/5/

   在 cdh02 和 cdh03 上下載這個文件

   wget https://archive.cloudera.com/cdh5/redhat/7/x86_64/cdh/cloudera-cdh5.repo
   mv cloudera-cdh5.repo /etc/yum.repos.d/

   而後在 cdh02 和 cdh03 上修改文件 /etc/yum.repos.d/cloudera-cdh5.repo

   baseurl=http://cdh01/cdh/5/