項目落實方案選擇思考（KUDU）

目錄

• Kudu 的應用場景是什麼?
  • 項目特色
  • 方案一：使用 Spark Streaming 配合 HDFS 存儲
  • 方案二：HDFS+compaction
  • 方案三： HBase+HDFS
  • 方案四：Kudu
• KUDU 和其餘存儲工具對比
  • 理解 OLTP 和 OLAP
  • 列式存儲和行式存儲
  • 存儲模型

Kudu 的應用場景是什麼?

設計一個項目，分析其特色，設計方案，選取最佳處理方案
需求：作一個相似物聯網的項目, 多是對某個工廠的生產數據進行分析

項目特色

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

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

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

• 對存儲層的要求

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

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

      2.要可以掃描歷史數據, 從而改進設備和流程
因此對數據存儲層就有可能進行以下的操做

      1.逐行插入, 由於數據是一行一行來的, 要想及時看到, 就須要來一行插入一行     -->隨機插入，OLTP較擅長

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

      3.快速分析和掃描, 數據分析師須要快速的獲得結論, 執行一行 SQL 等上十天是不行的      -->批量讀取和分析，dfs

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

總結一下需求實時處理
- Spark Streaming
- 大數據存儲, HDFS
- 使用 Kafka 過渡數據(能夠過渡實時流數據）

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

方案二：HDFS+compaction

# 上面方案的問題是大量小文件的查詢是很是低效的，因此能夠將這些小文件壓縮合並起來
# 方案問題：
- 一個文件只有再也不活躍時才能合併（外部正在使用）
- 不能將覆蓋的結果放回原來的位置（外部須要使用原來的文件）
# 因此通常在流式系統中進行小文件合併的話, 須要將數據放在一個新的目錄中, 讓 Hive/Impala 指向新的位置, 再清理老的位置

方案三： HBase+HDFS

# Parquet文件格式存放 離線大規模數據分析的吞吐量最高

# 由於 HBase（隨機讀寫插入性能好） 不擅長離線大批量數據分析, 因此在必定的條件觸發下, 須要將 HBase 中的數據寫入 HDFS 中的 Parquet 文件中, 以便支持離線數據分析, 可是這種方案又會產生新的問題
      維護特別複雜, 由於須要在不一樣的存儲間複製數據
      難以進行統一的查詢, 由於實時數據和離線數據不在同一個地方
# 這種方案, 也稱之爲 Lambda, 分爲實時層和批處理層, 經過這些這麼複雜的方案, 其實想作的就是一件事, 流式數據的存儲和快速查詢

方案四：Kudu

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

• 項目難點總結

- 對於實時流式數據處理, Spark, Flink, Storm 等工具提供了計算上的支持, 可是它們都須要依賴外部的存儲系統, 對存儲系統的要求會比較高一些, 要知足以下的特色
- 支持逐行插入(機器生產的數據是逐條的）
- 支持更新（數據庫不斷更新）
- 低延遲隨機讀取（數據要能很快的讀取）
- 快速分析和掃描（離線大批量數據的掃描和分析）

KUDU 和其餘存儲工具對比

理解 OLTP 和 OLAP

• OLTP (On-Line Transaction Processing 聯機事務處理過程）

# 先舉個栗子, 在電商網站中, 常常見到一個功能 - "個人訂單", 這個功能再查詢數據的時候, 是查詢的某一個用戶的數據, 並非批量的數據
# OLTP 是傳統關係型數據庫的主要應用
用來執行一些基本的、平常的事務處理，好比數據庫記錄的增、刪、改、查等等
# OLTP 須要作的事情是
快速插入和更新
精確查詢
# 因此 OLTP 並不須要對數據進行大規模的掃描和分析, 因此它的掃描性能並很差, 它主要是用於對響應速度和數據完整性很高的在線服務應用中

• OLAP (On-Line Analytical Processing 聯機分析處理)

#OLAP 則是分佈式數據庫的主要應用
它對實時性要求不高，但處理的數據量大,一般應用於複雜的動態報表系統上
OLAP 和 OLTP 的場景不一樣, OLAP 主要服務於分析型應用, 其通常是批量加載數據, 若是出錯了, 從新查詢便可

# 總結

OLTP 隨機訪問能力比較強, 批量掃描比較差
OLAP 擅長大規模批量數據加載, 對於隨機訪問的能力則比較差
大數據系統中, 每每從 OLTP 數據庫中 ETL 放入 OLAP 數據庫中, 而後作分析和處理

列式存儲和行式存儲

# 行式通常用作於 OLTP, 例如個人訂單, 那不只要看到訂單, 還要看到收貨地址, 付款信息, 派送信息等, 因此 OLTP 通常是傾向於獲取整行全部列的信息
# 而分析平臺就不太同樣, 例如分析銷售額, 那可能只對銷售額這一列感興趣, 因此按照列存儲, 只獲取須要的列, 這樣能減小數據的讀取量

• 行式存儲

傳統的關係型數據庫，如 Oracle、DB二、MySQL、SQL SERVER 等採用行式存儲法(Row-based)，在基於行式存儲的數據庫中，
數據是按照行數據爲基礎邏輯存儲單元進行存儲的， 一行中的數據在存儲介質中以連續存儲形式存在。

• 列式存儲

列式存儲(Column-based)是相對於行式存儲來講的，新興的 Hbase、HP Vertica、EMC Greenplum 等分佈式數據庫均採用列式存儲。
在基於列式存儲的數據庫中， 數據是按照列爲基礎邏輯存儲單元進行存儲的，一列中的數據在存儲介質中以連續存儲形式存在。

存儲模型

• 結構

Kudu 的存儲模型是有結構的表
OLTP 中表明性的 MySQL, Oracle 模型是有結構的表
HBase 是看起來像是表同樣的 Key-Value 型數據, Key 是 RowKey 和列簇的組合, Value 是具體的值

• 主鍵

Kudu 採用了 Raft 協議, 因此 Kudu 的表中有惟一主鍵
關係型數據庫也有惟一主鍵
HBase 的 RowKey 並非惟一主鍵

• 事務支持

Kudu 缺乏跨行的 ACID 事務
關係型數據庫大多在單機上是能夠支持 ACID 事務的

• 性能

Kudu 的隨機讀寫速度目標是和 HBase 類似, 可是這個目標創建在使用 SSD 基礎之上
Kudu 的批量查詢性能目標是比 HDFS 上的 Parquet 慢兩倍之內

• 硬件需求

Hadoop 的設計理念是儘量的減小硬件依賴, 使用更廉價的機器, 配置機械硬盤
Kudu 的時代 SSD 已經比較常見了, 可以作更多的磁盤操做和內存操做
Hadoop 不太能發揮比較好的硬件的能力, 而 Kudu 爲了大內存和 SSD 而設計, 因此 Kudu 對硬件的需求會更大一些

[參考文檔] (file:///E:/Big_Data_Files/DMP_Systems/Day01/Kudu.html)