在這篇文章中，我想比較ClickHouse，Druid和Pinot這三個開放源數據存儲，它們通過交互延遲對大量數據運行分析查詢。
警告：這篇文章很大，您可能只想閱讀最後的"摘要"部分。
信息來源
我從核心開發人員之一Alexey Zatelepin那裡瞭解了ClickHouse的實現細節。 本文檔頁面的最後四個部分是英語提供的最好的材料，但是非常稀缺。
我是Druid的提交者，但是我對這個系統沒有既得利益（實際上，我可能很快就會停止參與它的開發），因此讀者可以期望我對Druid相當客觀 。
我在這篇關於Pinot的文章中寫的所有內容都是基於Pinot Wiki中的Architecture頁面以及" Design Docs"部分中的其他Wiki頁面，這些頁面的最新更新於2017年6月，已經有半年多了。
這篇文章還評論了Alexey Zatelepin和Vitaliy Lyudvichenko（ClickHouse的開發人員），Gian Merlino（PMC成員和Druid的最活躍開發人員），Kishore Gopalakrishna（黑皮諾的建築師）和Jean-FrançoisIm（黑皮諾的開發人員）。 感謝審稿人。
在選擇大數據OLAP系統時，請不要比較它們在當前用例中的最佳狀態。 目前，它們都非常次優。 比較您的組織可以使這些系統朝著使您的用例更優化的方向移動的速度。
由於其基本的架構相似性，ClickHouse，Druid和Pinot在效率和性能優化上具有大約相同的"極限"。 沒有"魔術藥"可以使這些系統中的任何一個都比其他系統快得多。 在當前狀態下，系統在某些基準測試中的性能差異很大，因此請不要為之困惑。 例如 目前，Druid不像ClickHouse（請參見上文）那樣很好地支持"主鍵排序"，而ClickHouse不像Druid那樣不支持倒排索引，這使得這些系統在特定工作負載方面處於優勢。 如果您有意願和能力，則可以在選定的系統中實施缺少的優化，而無需花費很多精力。
· 您的組織中的任何一個都應該具有能夠閱讀，理解和修改所選系統的源代碼並具有執行此功能的工程師。 請注意，ClickHouse用C ++，Druid和Pinot用Java編寫。
· 或者，您的組織應與提供所選系統支持的公司簽訂合同。 ClickHouse有Altinity，德魯伊有Imply和Hortonworks。 目前沒有針對Pinot的此類公司。
其他開發注意事項：
· Yandex的ClickHouse開發人員表示，他們將50％的時間用於構建公司內部所需的功能，而50％的時間用於"社區投票"次數最多的功能。 但是，要從中受益，您在ClickHouse中所需的功能應與社區中大多數其他人所需的功能匹配。
· Imply的Druid開發人員具有建立廣泛適用的功能的動機，以最大程度地發展其未來業務。
· Druid的開發過程與Apache模型非常相似，多年來，它是由幾家公司開發的，這些公司的優先級相差很大，而且沒有一家公司佔有主導地位。 ClickHouse和Pinot目前距離該州還很遙遠，它們分別是分別由Yandex和LinkedIn開發的。 對德魯伊的貢獻以後被拒絕或撤銷的可能性最小，因為它們與主要開發者的目標不一致。 德魯伊沒有"主要"開發商公司。
· Druid承諾支持"開發人員API"，該API允許提供自定義列類型，聚合算法，"深度存儲"選項等，並使它們與核心Druid的代碼庫保持獨立。 Druid開發人員記錄了此API，並跟蹤其與先前版本的兼容性。 但是，該API尚未成熟，並且在每個Druid版本中都幾乎被破壞了。 據我所知，ClickHouse和Pinot沒有維護類似的API。
· 根據Github的說法，黑皮諾從事這項工作的人最多，去年似乎至少有10個人年在黑皮諾上進行了投資。 對於ClickHouse來說，這個數字可能是6；對於德魯伊，這個數字大約是7。 這意味著從理論上講，黑皮諾在主題系統中的進步最快。
系統之間的相似性
耦合數據和計算
從根本上講，所有ClickHouse，Druid和Pinot都是相似的，因為它們在同一節點上存儲數據並進行查詢處理，這與去耦BigQuery體系結構不同。 最近，我描述了在德魯伊（1，2）情況下耦合體系結構的一些固有問題。 目前沒有與BigQuery等效的開源軟件（也許是Drill？），我在此博客中探討了構建此類開源系統的方法。
與大數據SQL系統的區別：索引和靜態數據分發
主題系統的查詢運行速度比SQL-on-Hadoop系列中的大數據處理系統Hive，Impala，Presto和Spark更快，即使後者訪問以列格式存儲的數據（如Parquet或Kudu）也是如此。 這是因為ClickHouse，Druid和Pinot
· 具有自己的格式來存儲帶索引的數據，並與查詢處理引擎緊密集成。 Hadoop上的SQL系統通常與數據格式無關，因此在大數據後端的"侵入性"較小。
· 在節點之間相對"靜態"地分配數據，並且分佈式查詢執行利用了這一知識。 另一方面，ClickHouse，Druid和Pinot不支持要求在節點之間移動大量數據的查詢，例如 G。 在兩個大表之間聯接。
沒有點更新和刪除
從數據庫的另一端來看，與諸如Kudu，InfluxDB和Vertica（？）之類的列存儲系統相反，ClickHouse，Druid和Pinot不支持點更新和刪除。 這使ClickHouse，Druid和Pinot能夠進行更有效的列壓縮和更積極的索引，這意味著更高的資源效率和更快的查詢。
Yandex的ClickHouse開發人員的目標是將來支持更新和刪除，但是我不確定這是否是真正的點查詢或數據範圍的更新和刪除。
大數據樣式提取
所有ClickHouse，Druid和Pinot都支持從Kafka接收流數據。 Druid和Pinot支持Lambda樣式的流傳輸和同一數據的批量提取。 ClickHouse直接支持批量插入，因此不需要像Druid和Pinot那樣的單獨的批量攝取系統。 這篇文章下面將對此進行更詳細的討論。
大規模驗證
這三個系統都得到了大規模驗證：在Yandex.Metrica上有一個ClickHouse集群，大約有上萬個CPU內核。 Metamarkets運行著類似規模的Druid集群。 LinkedIn上的單個黑皮諾集群擁有"數千臺機器"。
不成熟
按照企業數據庫標準，所有主題系統都非常不成熟。 （但是，可能不比一般的開源大數據系統還不成熟，但這是另一回事。）ClickHouse，Druid和Pinot到處都缺乏明顯的優化和功能，並且到處都是bug（這裡我不能百分百確定） 關於ClickHouse和Pinot，但沒有理由認為它們比Druid更好。
這將我們帶入下一個重要部分-
性能比較與制度選擇
我經常在網上看到人們如何比較和選擇大數據系統-他們獲取數據樣本，以某種方式將其吸收到評估的系統中，然後立即嘗試衡量效率-它佔用了多少內存或磁盤空間， 在不瞭解所評估系統內部的情況下，查詢完成的速度如何。 然後，僅使用此類性能信息，有時還使用它們所需的功能列表以及當前比較的系統，他們會做出選擇，或者更糟糕的是，決定從頭開始編寫自己的"更好"的系統。
我認為這種方法是錯誤的，至少在開源大數據OLAP系統中是如此。 設計通用的大數據OLAP系統，使其能夠在大多數用例和功能（及其組合的強大功能！）中有效地工作，這個問題確實非常巨大-我估計這至少需要100個人年。 建立這樣的系統。
ClickHouse，Druid和Pinot當前僅針對開發人員關心的特定用例進行了優化，並且幾乎僅具有開發人員所需的功能。 如果您要部署其中一個系統的大型集群並關心效率，那麼我保證您的用例將遇到其獨特的瓶頸，主題OLAP系統的開發人員以前從未遇到過或沒有遇到過 不在乎。 更不用說上述方法"將數據投入您所不瞭解的系統並衡量效率"很有可能會遇到一些主要瓶頸，而這些瓶頸可以通過更改某些配置或數據模式或以其他方式進行查詢來解決 。
CloudFlare：ClickHouse與Druid
MarekVavruša的一個帖子說明了上述問題，其中一個例子是Cloudflare在ClickHouse和Druid之間的選擇。 他們需要4個ClickHouse服務器（超過了9個），並估計類似的Druid部署將需要"數百個節點"。 儘管Marek承認這是不公平的比較，但是由於Druid缺乏"主鍵排序"，他可能沒有意識到僅通過在"攝取規範"中設置正確的尺寸順序就可以在Druid中獲得幾乎相同的效果。 簡便的數據準備：將Druid的__time列值截斷為一些粗粒度，例如e。 G。 一個小時，如果某些查詢需要更細的時間範圍，則可以選擇添加另一個長型列" precise_time"。 這是一種技巧，但是允許Druid在__time之前按某種維度對數據進行實際排序也很容易實現。
我不會質疑他們選擇ClickHouse的最終決定，因為在大約10個節點的規模上，對於他們的用例，我還認為ClickHouse比Druid是更好的選擇（我將在本文下面進行解釋）。 但是他們得出的結論是，ClickHouse的效率（在基礎設施成本方面）至少比Druid高出一個數量級，這完全是謬論。 實際上，在這裡討論的三個系統中，Druid提供了最多的功能來實現真正便宜的安裝，請參閱下面的"在Druid中分層查詢處理節點"。
ClickHouse和Druid / Pinot之間的區別
數據管理：Druid和Pinot
在Druid和Pinot中，每個"表"中的所有數據（無論這些系統用什麼術語稱呼）都被劃分為指定數量的部分。 按照時間維度，通常還會將數據除以指定的時間間隔。 然後，將這些數據的各個部分分別"密封"到稱為"段"的自包含實體中。 每個段包括表元數據，壓縮的列數據和索引。
段被保留在"深度存儲"（例如，HDFS）中，並且可以被加載到查詢處理節點上，但是後者不負責段的持久性，因此可以相對自由地替換查詢處理節點。 段並非嚴格地附加到某些節點，它們可以或多或少地加載到任何節點上。 特殊的專用服務器（在Druid中稱為"協調器"，在Pinot中稱為"控制器"，但在下面我將其統稱為"主服務器"）負責將分段分配給節點，並在節點之間移動分段 ， 如果需要的話。 （這與我在本文中上面指出的觀點並不矛盾，因為包括Druid和Pinot在內的所有三個主題系統在節點之間均具有"靜態"數據分佈，因為Druid（我想是Pinot）中的段載荷和運動是昂貴的 操作，而不是針對每個特定查詢執行操作，通常僅每隔幾分鐘，幾小時或幾天執行一次。）
有關段的元數據直接在Druid中以及通過Pinot中的Helix框架保存在ZooKeeper中。 在Druid中，元數據也保留在SQL數據庫中，本文下面的" Druid與Pinot之間的區別"部分對此進行了詳細說明。
數據管理：ClickHouse
ClickHouse沒有"細分"，其中包含嚴格屬於特定時間範圍的數據。 沒有數據的"深度存儲"，ClickHouse群集中的節點還負責查詢處理以及存儲在其上的數據的持久性/持久性。 因此，不需要像Amazon S3這樣的HDFS設置或雲數據存儲。
ClickHouse具有分區表，由特定的節點集組成。 沒有"中央權限"或元數據服務器。 在其中對某個表進行分區的所有節點都具有表元數據的完全相同的副本，包括存儲該表分區的所有其他節點的地址。
分區表的元數據包括節點的"權重"，用於分配新寫入的數據，例如， G。 40％的數據應流向節點A，30％的數據流向節點B，30％的數據流向節點C。通常，數據在節點之間的分配應相等。 如上例所示，只有在將新節點添加到分區表中時才需要"傾斜"，以便用某些數據更快地填充新節點。 這些"權重"的更新應由ClickHouse群集管理員手動完成，或者應在ClickHouse之上構建一個自動化系統。
數據管理：比較
在ClickHouse中，數據管理方法比在Druid和Pinot中更簡單：不需要"深度存儲"，只需一種類型的節點，就不需要用於數據管理的專用服務器。 但是，當任何數據表變得如此之大以至於需要在數十個或更多節點之間進行分區時，ClickHouse的方法就變得有些問題了：查詢放大因子變得與分區因子一樣大，即使對於查詢而言，其覆蓋範圍很小。 數據：
> Data distribution tradeoff in ClickHouse
在上圖中給出的示例中，表數據分佈在Druid或Pinot中的三個節點之間，但是查詢少量數據間隔通常只會命中兩個節點（除非該間隔跨越了段間隔邊界）。 在ClickHouse中，如果表在三個節點之間進行分區，則任何查詢都需要命中三個節點。 在此示例中，這似乎並沒有太大的區別，但是可以想象節點數為100，而分區因子仍可以是e。 G。 10德魯伊或黑皮諾。
為了緩解此問題，實際上，Yandex上最大的ClickHouse群集（數百個節點）被分成許多"子群集"，每個群集包含幾十個節點。 該ClickHouse集群用於支持網站分析，並且每個數據點都有"網站ID"維度。 每個網站ID都嚴格分配給特定的子集群，該網站ID的所有數據都存放在該子集群中。 該ClickHouse群集之上有一些業務邏輯層，可在數據提取和查詢方面管理此類數據分離。 值得慶幸的是，在用例中，很少有查詢可以跨多個網站ID來訪問數據，而且這些查詢並非來自服務客戶，因此它們沒有嚴格的實時SLA。
ClickHouse方法的另一個缺點是，當群集快速增長時，如果沒有人工手動更改分區表中的"節點權重"，數據就不會自動重新平衡。
Druid中的查詢處理節點分層
具有段的數據管理"很容易推理"。 段可以相對容易地在節點之間移動。 這兩個因素幫助Druid實現了查詢處理節點的"分層"：將舊數據自動移動到磁盤相對較大但內存和CPU較少的服務器上，從而可以顯著降低運行大型Druid集群的成本， 減慢對舊數據的查詢。
與"扁平"集群相比，該功能可使Metamarkets每月節省數十萬美元的Druid基礎設施支出。
> Tiering of query processing nodes in Druid
據我所知，ClickHouse和Pinot還沒有類似的功能，它們群集中的所有節點都應該是相同的。
由於Pinot的體系結構與Druid的體系非常相似，因此我認為在Pinot中引入類似的功能並不難。 在ClickHouse中執行此操作可能會比較困難，因為段的概念對於實現此類功能確實很有幫助，但是仍然可以實現。
數據複製：Druid和Pinot
德魯伊和黑皮諾的複製單位是單個段。 段在"深層存儲"層（例如，HDFS中的三個副本，或者在雲blob存儲（例如Amazon S3）中透明完成）和查詢處理層中複製：通常在Druid和Pinot中，每個段 在兩個不同的節點上加載。 如果複製因子低於指定級別，則"主"服務器將監視每個段的複製級別並在某個服務器上加載一個段。 G。 如果某個節點無響應。
數據複製：ClickHouse
ClickHouse中的複製單元是服務器上的表分區，即 e。 來自某個表的所有數據，存儲在服務器上。 與分區類似，ClickHouse中的複製是"靜態且特定的"，而不是"雲樣式"，即 e。 多臺服務器知道它們是彼此的副本（對於某些特定表；對於其他表，複製配置可能不同）。 複製可提供持久性和查詢可用性。 當某個節點上的磁盤損壞時，數據也不會丟失，因為它也存儲在其他節點上。 當某個節點暫時關閉時，查詢可以路由到副本。
在Yandex上最大的ClickHouse集群中，不同數據中心中有兩組相等的節點，並且它們是成對的。 在每一對中，節點是彼此的副本（即使用兩個的複製因子）並且位於不同的數據中心中。
ClickHouse依賴ZooKeeper進行復制管理，但是不需要ZooKeeper。 這意味著單節點ClickHouse部署不需要ZooKeeper。
數據提取：Druid和Pinot
在Druid和Pinot中，查詢處理節點專門用於加載段並向段中的數據提供查詢，但不累積新數據併產生新段。
當可以延遲一個小時或更長時間來更新表時，將使用批處理引擎（例如Hadoop或Spark）創建分段。 Druid和Pinot都對Hadoop提供了"一流"的現成支持。 Spark中有一個用於Druid索引的第三方插件，但目前尚不支持。 據我所知，Pinot甚至沒有對Spark的這種支持。 e。 您應該自己做出貢獻：瞭解Pinot接口和代碼，編寫一些Java或Scala代碼。 但這並不難。 （更新：Slack的Ananth PackkilDurai現在正在為黑皮諾的Spark提供支持。）
當應該實時更新表時，Druid和Pinot都引入了"實時節點"的概念，該概念可做三件事：接受來自Kafka的新數據（Druid也支持其他來源），查詢最近的數據，以及 在後臺創建細分，然後將其推送到"深度存儲"。
數據提取：ClickHouse
ClickHouse無需準備嚴格包含所有數據（屬於特定時間間隔）的"段"，因此可以簡化數據提取架構。 ClickHouse不需要像Hadoop這樣的批處理引擎，也不需要"實時"節點。 常規ClickHouse節點（用於存儲數據併為其提供查詢）與之相同，它們直接接受批處理數據寫入。
如果表已分區，則接受批量寫入的節點（例如1萬行）將根據分區表本身中所有節點的"權重"來分配數據（請參見上方的"數據管理：ClickHouse"部分）。
單批寫入的行形成一個小的"集合"。 集立即轉換為列格式。 每個ClickHouse節點上都有一個後臺進程，該進程將行集合併為較大的行集。 ClickHouse的文檔在很大程度上將此原則稱為" MergeTree"，並強調了它與日誌結構的合併樹的相似之處，儘管IMO有點令人困惑，因為數據不是以樹的形式組織的，而是採用扁平列格式。
數據提取：比較
Druid和Pinot的數據攝取"繁重"：它包含幾種不同的服務，而管理是一項負擔。
儘管有一個警告，但ClickHouse中的數據提取要簡單得多（以更復雜的歷史數據管理為代價-參見上文）：您應該能夠在ClickHouse本身前面"批量"處理數據。 開箱即用的功能是自動獲取和批處理來自Kafka的數據，但是如果您有不同的實時數據源，包括從Kafka替代的排隊基礎架構，流處理引擎到簡單的HTTP端點，則需要 創建中間批處理服務，或直接向ClickHouse提供代碼。
查詢執行
Druid和Pinot具有稱為"代理"的專用節點層，它們接受對系統的所有查詢。 它們基於從段到加載段的節點的映射，確定應向哪些"歷史"查詢處理節點發出子查詢。 代理將此映射信息保留在內存中。 代理節點將下游子查詢發送到查詢處理節點，當這些子查詢的結果返回時，代理將它們合併，並將最終的合併結果返回給用戶。
我只能推測為什麼在設計Druid和Pinot時決定提取另一種類型的節點。 但是現在看來，這是必不可少的，因為隨著群集中的段總數超過一千萬，段到節點的映射信息需要GB的內存。 在所有查詢處理節點上分配這麼多的內存太浪費了。 因此，這是Druid和Pinot的"分段"數據管理架構所帶來的另一個缺點。
在ClickHouse中，通常不需要為"查詢代理"指定單獨的節點集。 ClickHouse中有一種特殊的臨時"分佈式"表類型，可以在任何節點上進行設置，並且對該表的查詢可以完成在Druid和Pinot中負責"代理"節點的工作。 通常，此類臨時表是在參與分區表的每個節點上建立的，因此，實際上，每個節點都可以作為對ClickHouse集群進行查詢的"入口點"。 該節點將向其他分區發出必要的子查詢，處理該查詢本身的一部分，並將其與其他分區的部分結果合併。
當一個節點（ClickHouse中的一個處理節點，或Druid和Pinot中的"代理"節點）向其他節點發出子查詢，並且單個或幾個子查詢由於某種原因而失敗時，ClickHouse和Pinot會正確處理此情況： 合併所有成功子查詢的結果，並且仍將部分結果返回給用戶。 現在，德魯伊非常缺乏此功能：如果任何子查詢失敗，那麼整個查詢也會失敗。
ClickHouse與Druid或Pinot：結論
Druid和Pinot中數據管理的"分段"方法與ClickHouse中較簡單的數據管理方法定義了系統的許多其他方面。 但是，重要的是，這種差異對潛在的壓縮效率（儘管目前這三個系統中的壓縮情況目前都是令人沮喪的）或查詢處理速度幾乎沒有影響。
ClickHouse與傳統的RDMBS類似。 G。 PostgreSQL。 特別是，ClickHouse可以僅部署在單個服務器上。 如果預計的部署規模很小，則e。 G。 不超過100個用於查詢處理的CPU內核和1 TB數據的數量，我想說ClickHouse相對於Druid和Pinot具有顯著優勢，因為它簡單易用，不需要其他類型的節點，例如" master"， "實時提取節點"，"經紀人"。 在此領域，ClickHouse與InfluxDB競爭而不是與Druid或Pinot競爭。
Druid和Pinot類似於大數據系統，例如HBase。 不取決於它們的性能特徵，而是取決於對ZooKeeper的依賴性，對持久性複製存儲（例如HDFS）的依賴性，對單個節點故障的恢復能力的關注以及不需要常規人員關注的自主工作和數據管理。
對於廣泛的應用程序，ClickHouse或Druid或Pinot都不是明顯的贏家。 首先，我建議考慮能夠理解的系統源代碼，修復錯誤，添加功能等。"性能比較和系統選擇"部分將對此進行更多討論。
其次，您可以查看下錶。 該表中的每個單元格都描述了某個應用程序的屬性，這使ClickHouse或Druid / Pinot可能是更好的選擇。 行沒有按其重要性排序。 每行的相對重要性對於不同的應用程序是不同的，但是如果您的應用程序由表中一列的許多屬性來描述，而由另一列的無或幾個屬性來描述，則很可能應該從列標題中選擇相應的系統 。
注意：以上兩個屬性都不意味著您必須使用相應的系統，或者必須避免使用其他系統。 例如，如果您預測的集群很大，那並不意味著您應該只考慮Druid或Pinot，而不要考慮ClickHouse。 相反，這意味著Druid或Pinot可能會成為更好的解決方案，但是在某些應用中，即使對於大型集群，ClickHouse最終也可能是更理想的選擇，即使對於大型集群也是如此。
Druid與Pinot的區別
正如我在上面多次提到的，Druid和Pinot具有非常相似的體系結構。 在一個系統中存在著幾個相當大的功能，而在另一個系統中則沒有，還有一些區域，其中一個系統比另一個系統前進得遠得多。 但是，我要提到的所有這些內容都可以通過合理的努力在另一個系統中複製。
Druid和Pinot之間只有一個區別，那就是太大了，無法在可預見的將來消除-這是"主"節點中的細分管理的實現。 而且，這兩種系統的開發人員可能都不想這樣做，因為兩者的方法各有利弊，並不是說一個人總比別人好。
Druid中的細分管理
Druid（和Pinot中都不是）中的"主"節點不負責集群中數據段的元數據的持久性以及段與加載這些段的查詢處理節點之間的當前映射。 此信息保留在ZooKeeper中。 但是，Druid還將這些信息保存在SQL數據庫中，應該提供該信息以設置Druid集群。 我不能說為什麼最初做出這個決定，但是目前它提供了以下好處：
· 較少的數據存儲在ZooKeeper中。 ZooKeeper中僅保留有關從段ID到加載該段的查詢處理節點列表的映射的最少信息。 剩下的擴展元數據（例如細分的大小，數據中的維度和指標列表等）僅存儲在SQL數據庫中。
· 如果由於數據段太舊而將其從集群中逐出（這是時間序列數據庫的常見功能，所有ClickHouse，Druid和Pinot都具有），則將它們從查詢處理節點上卸載，並從ZooKeeper中刪除有關它們的元數據 ，但不是來自"深度存儲"和SQL數據庫。 只要不從這些地方手動刪除它們，就可以快速"恢復"真正的舊數據，以防某些報告或調查需要該數據。
· 最初這不太可能是一個意圖，但是現在Druid中有計劃使對ZooKeeper的依賴成為可選。 目前，ZooKeeper用於三種不同的事物：段管理，服務發現和屬性存儲，例如。 G。 用於實時數據攝取管理。 服務發現和屬性存儲功能可以由Consul提供。 細分管理可以通過HTTP公告和命令來實現，而ZooKeeper的持久性功能已由SQL數據庫"備份"，則部分啟用了細分管理。
將SQL數據庫作為依賴項的弊端是更大的操作負擔，尤其是在組織中尚未建立某些SQL數據庫的情況下。 Druid支持MySQL和PostgreSQL，Microsoft SQL Server有一個社區擴展。 同樣，當Druid部署在雲中時，可以使用方便的託管RDBMS服務，例如Amazon RDS。
Pinot的細分市場管理
與Druid本身實現所有段管理邏輯並僅依賴Curator與ZooKeeper進行通信不同，Pinot將大部分段和集群管理邏輯委託給Helix框架。 一方面，我可以想象它為Pinot開發人員提供了一種專注於其系統其他部分的槓桿。 與在Druid中實現的邏輯相比，Helix的bug可能更少，這是因為在不同的條件下對它進行了測試，並且可能將更多的時間投入到Helix開發中。
另一方面，Helix的"框架界限"可能會限制Pinot。 螺旋線，進而是Pinot，可能永遠永遠依賴ZooKeeper。
現在，我將列舉Druid與黑皮諾之間更淺的區別。 這裡的"淺"是指如果有人願意的話，有一條清晰的途徑可以在缺少這些功能的系統中複製這些功能。
黑皮諾的"謂詞下推"
如果在攝取期間通過某些維鍵在Kafka中對數據進行了分區，則Pinot會生成包含有關該分區的信息的段，然後在執行帶有該維謂詞的查詢時，代理節點會預先過濾段，這樣有時段會少得多 因此，查詢處理節點需要命中。
此功能對於某些應用程序的性能很重要。
當前，如果在Hadoop中創建了段，但在實時攝取期間創建段時尚不支持，Druid支持基於密鑰的分區。 德魯伊目前尚未對經紀人實施"謂詞下推"。
"可插拔"Druid和自以為是的Pinot
由於Druid由許多組織使用和開發，因此隨著時間的流逝，它幾乎為每個專用部件或"服務"獲得了幾個可交換選項的支持：
· HDFS或Cassandra或Amazon S3或Google Cloud Storage或Azure Blob存儲等作為"深度存儲"；
· Kafka或RabbitMQ，Samza或Flink或Spark，Storm等（通過寧靜）作為實時數據提取源；
· Druid本身，或Graphite，Ambari或StatsD或Kafka，作為Druid群集（度量標準）遙測的接收器。
由於Pinot幾乎都是在LinkedIn上專門開發的，並且要滿足LinkedIn的需求，因此，它通常不能為用戶提供太多選擇：HDFS或Amazon S3必須用作深度存儲，而只有Kafka才能進行實時數據提取。 但是，如果有人需要，我可以想象不難為Pinot中的任何服務引入對多個可插拔選項的支持。 自Uber和Slack開始使用黑皮諾以來，這種情況可能很快就會改變。
在Pinot中更好地優化了數據格式和查詢執行引擎
也就是說，Druid目前尚不具備Pinot分段格式的以下功能：
· 在Druid中以位粒度和字節粒度壓縮索引列。
· 每一列的倒排索引都是可選的，在Druid中這是必填項，有時不需要，並且佔用大量空間。 Uber觀察到的Druid和Pinot之間在空間消耗上的差異可能是由於這一點。
· 每段記錄數值列中的最小值和最大值。
· 開箱即用的數據排序支持。 如上文" CloudFlare：ClickHouse與Druid"部分中所述，在Druid中只能通過手動方式和破解方式實現。 數據排序意味著更好的壓縮，因此Pinot的這一功能是Uber觀察到的Druid和Pinot之間的空間消耗（和查詢性能！）差異的另一個可能原因。
· 與Druid相比，用於多值列的某種更優化的格式。
所有這些事情都可以在Druid中實現。 而且，儘管Pinot的格式在目前比Druid的格式上有了更好的優化，但距離真正的優化還差很遠。 例如，Pinot（以及Druid）僅使用通用壓縮（例如Zstd），而尚未實現Gorilla論文中的任何壓縮思想。
關於查詢執行，不幸的是，Uber主要使用計數（*）查詢來比較Druid和Pinot（1、2）的性能，因為目前這只是Druid中的啞線性掃描，儘管用a代替它真的很容易。 正確的O（1）實現。 這是"黑匣子"比較毫無意義的說明，本文上面的"關於性能比較和系統選擇"部分對此進行了介紹。
我認為，Uber觀察到的GROUP BY查詢性能的差異應歸因於Druid的細分市場中缺乏數據排序，如本節上文所述。
Druid擁有更智能的細分分配（平衡）算法
Pinot的算法是將段分配給當前加載的總段數最少的查詢處理節點。 Druid的算法更加複雜，它考慮了每個細分的表格和時間，並應用了一個複雜的公式來計算最終得分，通過該公式對查詢處理節點進行排名，以選擇最佳的節點來分配新的細分。 該算法使Metamarkets的生產查詢速度提高了30–40％。 然而，在Metamarkets，我們仍然對這種算法不滿意，請參閱本文中的"歷史節點性能的巨大差異"部分。
我不知道LinkedIn在Pinot中使用如此簡單的分段平衡算法的效果如何，但如果他們需要時間來改進其算法，可能會有巨大的收穫等待著他們。
Pinot在查詢執行路徑上更具容錯能力
正如我在上面的"查詢執行"部分中提到的那樣，當"代理"節點向其他節點進行子查詢，而某些子查詢失敗時，Pinot會合並所有成功的子查詢的結果，並且仍將部分結果返回給用戶。
德魯伊目前尚未實現此功能。
Druid中的查詢處理節點分層
請參閱本文上方的同名部分。 Druid允許為較舊和較新的數據提取查詢處理節點的"層"，並且較舊數據的節點具有較低的" CPU，RAM資源/已加載段數"比率，從而可以在訪問時以較小的基礎架構開銷換取較低的查詢性能 舊數據。
據我所知，Druid目前沒有類似的功能。
摘要
ClickHouse，Druid和Pinot具有根本上相似的架構，它們在通用大數據處理框架（例如Impala，Presto，Spark和列式數據庫）之間具有獨特的優勢，並適當支持唯一主鍵，點更新和刪除（例如InfluxDB）。
由於它們的架構相似，ClickHouse，Druid和Pinot具有近似相同的"優化限制"。 但是到目前為止，這三個系統都還不成熟，距離該限制還很遙遠。 僅需花費幾個月的工程師工作，就可以對其中任何一個系統（當應用於特定用例時）大幅度提高效率。 我不建議您完全比較主題系統的性能，不要選擇您可以理解和修改的源代碼，或者要投資的源代碼。
在這三個系統中，ClickHouse與Druid和Pinot略有不同，而後兩個幾乎相同，但它們幾乎是完全獨立於同一系統的兩個獨立開發的實現。
ClickHouse更類似於PostgreSQL之類的"傳統"數據庫。 ClickHouse的單節點安裝是可能的。 在小規模（少於1 TB的內存，少於100個CPU內核）上，如果您仍然想與它們進行比較，則ClickHouse比Druid或Pinot更有趣，因為ClickHouse更簡單並且移動部件和服務更少。 我要說的是，它在這種規模上與InfluxDB或Prometheus競爭，而不是與Druid或Pinot競爭。
Druid和Pinot更類似於Hadoop生態系統中的其他大數據系統。 它們即使在非常大的規模（超過500個節點）中仍保留"自動駕駛"屬性，而ClickHouse需要專業SRE的大量關注。 此外，與ClickHouse相比，Druid和Pinot更適合優化大型集群的基礎架構成本，並且更適合雲環境。
Druid和Pinot之間唯一的可持續區別是Pinot依賴Helix框架，並將繼續依賴ZooKeeper，而Druid可以擺脫對ZooKeeper的依賴。 另一方面，Druid的安裝將繼續取決於某些SQL數據庫的存在。
目前，黑皮諾比德魯伊的優化效果更好。 （但是請在上面再次閱讀-"我不建議您完全比較主題系統的性能"，以及帖子中的相應部分。）
Druid和Pinot的體系結構幾乎完全相同，而ClickHouse則與它們略有不同。 我將首先將ClickHouse的架構與"通用" Druid / Pinot架構進行比較，然後討論Druid與Pinot之間的較小差異。
(本文翻譯自Roman Leventov的文章《Comparison of the Open Source OLAP Systems for Big Data: ClickHouse, Druid, and Pinot》，參考：https://medium.com/@leventov/comparison-of-the-open-source-olap-systems-for-big-data-clickhouse-druid-and-pinot-8e042a5ed1c7)
閱讀更多 聞數起舞 的文章
