1、簡介 背景： 大數據主要存儲的兩種方式： ①靜態數據（HDFS）： 優點： 吞吐量大 缺點： 隨機讀寫差 不支持更新操作 //單條數據無法實現更新 ②動態數據（HBase）: 優點： 隨機讀寫良好 支持更新操作 缺點： 數據分析的吞吐量小 //HBase讀取數據路徑比較長，從內存到磁盤，可能還需要讀多個HFile文件做版本合並。所以存儲在HBase的數據，當我們用 //HBase做數據分析的時候，效率低 注：隨機讀寫是指對任意一個位置的讀和寫，磁盤隨機讀寫慢是因為需要尋道，倒帶才可以訪問到指定存儲點。 eg：比如今天12點的數據13才到，那么我想寫到12點的那個位置上去，利用HBase中的RowKey的有序性可以解決 傳統解決方案: 混合架構（T+1）： 數據實時更新在HBase，第二天凌晨同步到HDFS做離線分析。 ①數據鏈長，維護不易 ②時效性低，一般的周期都是一天/小時，不能做實時的分析 ③如果數據已經同步到了HDFS，那么數據延遲問題得不到解決 kudu : 定義：是一個既支持隨機讀寫、又支持實時sql查詢、數據更新插入的大數據存儲引擎 kudu在HDFS和HBase中平衡了隨機讀寫和批量分析的性能，完美的和impala集成，既支持了SQL實時查詢，也支持了數據更新插入操作 2、架構Table： table 是數據存儲在 Kudu 的位置，具有 schema 和全局有序的 primary key。 Tablets： ① 一個Tablets是一張Table連續的segment ②Tablets是存在副本的，副本存在於不同的Tablet Server上，副本提供讀服務，只有leader提供寫服務 Tablet Server： 一個Tablet Server包含多個不同Tablets //最大並行化操作 Master Server: kudu的整體架構包含兩部分： Tablet Server集群、Master Server集群 Master Server為了保證高可用，一般設置為3台以上，一個為leader，其余為followers。一般只會有一個master起作用（也就是 leader） 作用： ①存儲跟蹤所有的 tablets，tablet servers，Catalog Table 等 metadata。 ②協調客戶端的 metadata operations（元數據操作） 例如： 當創建新表時，客戶端內部將請求發送給 master。 master 將新表的元數據寫入 catalog table，並協調在 tablet server 上創建 tablet 的過程。 注：tablet server 以設定的間隔向 master 發出心跳（默認值為每秒一次） Raft （類似於zk）： ①tablet、Master的副本選舉 ②tablet、Master的副本數據寫入 //接受以及復制到 follower 副本數據的寫入 ③tablet、Master的數據遷移 //在節點宕機之后的數據遷移 Catalog Table（目錄表）： 存儲有關 tables 和 tablets 的信息，只能通過客戶端 API 中公開的元數據操作訪問 Tables ： table schemas, locations, and states（表結構，位置和狀態） Tablets 現有tablet 的列表，每個 tablet 的副本所在哪些tablet server，tablet的當前狀態以及開始和結束的keys（鍵） Logical Replicationa（復制邏輯）： HDFS操作的是磁盤上的數據。 Kudu： insert（插入）和 update（更新）確實通過網絡傳輸數據 delete（刪除）操作被發送到每個 tablet server，它在本地執行刪除。 3、kudu底層存儲原理
參考網址：https://blog.csdn.net/lingbo229/article/details/80359987 ①1個Table包含多個Tablet，其中Tablet的數量是根據hash或者是range進行設置的 ②1個Tablet中包含MetaData信息和多個RowSet信息 //MetaData就是保存的Tablet Server上的位置信息等 ③1個RowSet包含一個MemRowSet和多個DiskRowSet 其中MemRowSet用於存儲insert數據和update后的數據，寫滿后會刷新到磁盤中也就是多個DiskRowSet中，默認是1G刷新一次或者是2分鍾 //1G數據刷新到眾多的DiskRowSet DiskRowSet會定期的刷新，進行合並操作，刪除更新數據之前的歷史數據 ④1個DiskRowSet包含1個BloomFilter，1個Ad_hoc Index，一個BaseData，多個Delta file文件（UndoFile、RedoFile)，一個Delta MemStore BloomFile：根據DiskRowSet中key生成一個bloom filter，用於快速模糊的定位某一個key是否在DiskRowSet中 Ad_hoc Index：是主鍵的索引，用於定位key在DiskRowSet中具體哪個偏移位置 BaseData：是MemRowSet flush下來的數據，按照列存儲，按照主鍵有序 //也就是CFile文件 Deltafile： UndoFile：是BaseData之前的數據歷史數據 //更新數據之前的數據 RedoFile：是BaseData之后的mutation記錄，可以獲得較新的數據 //最新的更新數據 DeltaMemStore： Delta Memstore達到一定程度后會在內存中合並數據，然后生成Redo data到磁盤 合並策略： ①多個DeltaFile進行合並生成一個大的DeltaFile。默認是1000個DeltaFile進行合並一次 ②DeltaFile文件的大小和Base data的文件的比例為0.1的時候，會進行合並操作，生成Undo data 4、kudu讀寫流程
讀流程： 1、客戶端連接TMaster獲取表的位置信息 2、客戶端找到TServer，Kudu接受讀請求，並記錄timestamp信息，如果沒有顯式指定，那么表示使用當前時間 3、從內存中讀取數據，也就是MemRowSet和DeltaMemStore中讀取數據，根據timestamp來找到對應的mutation鏈表 //DeltaMemStore是合並數據的緩沖區中，如果都找不到，說明數據在磁盤 4、從磁盤中讀取數據，由boom filter快速定位含有此key的DiskRowSet。 5、由index來判斷rowId在Data中的偏移 6、根據讀操作中包含的timestamp信息判斷是否需要將base data進行回滾操作從而獲取數據 寫流程： 1、客戶端連接TMaster獲取表的位置信息 2、客戶端找到TServer。 3、Kudu在Tablet中的所有rowset（memrowset,diskrowset）中進行查找，看是否存在與待插入數據相同主鍵的數據，如果存在就返回錯誤，否則繼續 4、寫入操作先被提交到tablet的預寫日志(WAL)，並根據Raft一致性算法取得追隨節點的同意，然后才會被添加到其中一個tablet的內存中， 插入會被添加到tablet的MemRowSet中 更新和刪除操作將被追加到MemRowSet中的原始行之后以生成redo記錄的列表 5、Kudu在MemRowset中寫入一行新數據，在MemRowset（1G或者是120s）數據達到一定大小時 MemRowset將數據落盤，並生成一個diskrowset用於持久化數據還生成一個memrowset繼續接收新數據的請求 數據更新流程： 1、客戶端連接TMaster獲取表的位置信息 2、客戶端找到TServer。 3、因為待更新數數據可能位於memrowset中，也可能已經flush到磁盤上，形成diskrowset。 a. 當待更新數據位於memrowset時： 找到待更新數據所在行，然后將更新操作記錄在所在行中一個mutation鏈表中，與插入數據不同的位置上， 在memrowset將數據落盤時，Kudu會將更新合並到base data，並生成UNDO records用於查看歷史版本的數據 b. 當待更新數據位於DiskRowset時： 找到待更新數據所在的DiskRowset，每個DiskRowset都會在內存中設置一個DeltaMemStore，將更新操作記錄在DeltaMemStore中， 在DeltaMemStore達到一定大小時，flush在磁盤，形成DeltaFile中 注：wal日志的作用是如果我們在做真正的操作之前，先將這件事記錄下來，持久化到可靠存儲中