如何評價kudu儲存引擎？

1樓：

Kudu分布式儲存引擎

提取碼: f19f

2樓：網易數帆

Kudu 在乙個系統中融合了 OLTP 型隨機讀寫能力與 OLAP 型分析能力，填補了 Hadoop 儲存層的缺憾，是 Hadoop 生態的一大生力軍。Kudu 目前在網易、小公尺等公司的大資料技術體系中是不可或缺的。

Kudu的設計目標

Kudu設計之初，是為了解決以下問題：

對資料掃瞄(scan)和隨機訪問(random access)同時具有高效能，簡化使用者複雜的混合架構

高 CPU 效率，使使用者購買的先進處理器的的花費得到最大回報

高 IO 效能，充分利用先進儲存介質

支援資料的原地更新，避免額外的資料處理、資料移動

支援跨資料中心 replica on

Kudu 的很多特性跟 HBase 很像，它支援索引鍵的查詢和修改。Cloudera 曾經想過基於 HBase 進行修改，然而結論是對 HBase 的改動非常大，Kudu 的資料模型和磁碟儲存都與 HBase 不同。HBase 本身成功的適用於大量的其它場景，因此修改 HBase 很可能吃力不討好。

後 Cloudera 決定開發乙個全新的儲存系統。

Kudu 的定位是提供」fast analy cs on fast data」，也就是在快速更新的資料上進行快速的查詢。它定位 OLAP 和少量的 OLTP 工作流，如果有大量的 randomaccesses，官方建議還是使用 HBase 更為合適。

Kudu 和 HBase 二者的區別，可以參考：分布式儲存系統Kudu與HBase的簡要分析與對比

Kudu 在網易的應用

Kudu 在網易主要有兩個應用場景：

資料庫資料上的快速分析

使用者行為日誌的快速分析

正如問題描述，我們通過 Kudu 和 Impala 的配合，實現透明分層儲存管理，以實現快速資料的快速分析能力，讓實時資料倉儲的建設獲得了革命性的變化，資料展現的時差從此成為了歷史……

詳情參考：實時性和完整性兼得，使用 Kudu 和 Impala 實現透明的分層儲存管理

3樓：

和HBase很像，感覺很像是hbase+tikv+histore的結合體，分割槽參考了hbase，一致性參考了raft，物理儲存為列式儲存~ 分析性場景（count，sum(column)）有優勢。

分割槽雖然支援range和hash兩種和兩種的組合，但是不夠自動化，range的擴充套件需要人工干預。

一致性模型不夠清晰。

周邊工具不夠完善。

如果有資料量比較大的純實時insert的olap場景，還是比較合適的。

c++實現，是優點也是缺點吧。

目前只對impala支援的比較好，如果引入它還要買一贈一。

4樓：大資料技術峰會解讀

Kudu產品的幾個要點：

資料模型和關聯式資料庫類似，為結構化的表；列的數量有限（和HBase/Cassandra相比較而言）

內部資料組織方式為列式儲存

很好的橫向擴充套件能力，目前測試的是275個節點（3PB），計畫支援到上千個節點(幾十PB)

不錯的效能，集群能達到百萬級別的TPS，單節點吞吐為幾個GB/s

本身不提供SQL介面，只支援類似NoSQL的介面，如 Insert(), Update(), Delete() and Scan() 等

通過與 Spark 和 Impala 等（Drill，Hive的支援還在進行中）的整合，對外提供基於 SQL 的查詢分析服務

關於小公尺如何使用Kudu，這裡有更詳細的介紹：Apache Kudu 加速對頻繁更新資料的分析 - 知乎專欄

5樓：吳友強

首先是乙個分布式的列式儲存，大家都說到了主要是用於分析計算的儲存系統。但是也是可以用於存的儲存系統。kudu是乙個現代的列式儲存系統，需要最新的硬體支援，充分發揮現在高效能硬體和cpu指令集。

在儲存方面做了很多效能優化，資料一致性和容災主要還是靠raft。

6樓：chen davy

1：支援增、刪、改

2：一套儲存，即支援較快速查詢(對標HBase)，也支援較快速分析(對標impala)。而不必像之前，想查詢，用HBase得一套儲存，相分析，用impala得一套儲存

如何評價kudu儲存引擎？

為什麼沒有以hbase作為儲存引擎的關係型資料庫實現？

如何評價Square Enix的夜光引擎（Luminous Studio）？

如何評價FIFA online3新引擎？

其他用戶還看了：