在這篇文章中，我想比較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（黑皮諾的開發人員）。感謝審稿人。
系統之間的相似性
耦合數據和計算
從根本上講，ClickHouse，Druid和Pinot都是相似的，因為它們在同一節點上存儲數據並進行查詢處理，這與去耦BigQuery體系結構不同。最近，我以Druid為例描述了一些固有的問題與耦合結構1，2）。目前沒有與BigQuery等效的開源軟件（也許是Drill嗎？），我已經在本博文中探討了構建此類開源系統的方法。
與大數據SQL系統的區別：索引和靜態數據分發
特有系統的查詢運行速度比Hadoop-SQL系列Hive，Impala，Presto和Spark中的大數據處理系統要快，即使后者訪問以列格式存儲的數據（例如Parquet或Kudu）。這是因為ClickHouse，Druid和Pinot：
- 具有自己的格式來存儲帶索引的數據，並與查詢處理引擎緊密集成。Hadoop上的SQL系統通常與數據格式無關，因此在大數據后端的“侵入性”較小。
- 在節點之間相對“靜態”地分配數據，並且分布式查詢執行利用了這一知識。另一方面，ClickHouse，Druid和Pinot不支持要求在節點之間移動大量數據的查詢，例如，兩個大型表之間的聯接。
沒有點更新和刪除
從數據庫的另一端來看，與諸如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上的一個Pinot 集群擁有“ 數千台機器 ”。
不成熟
按照企業數據庫標准，所有特有系統都非常不成熟。（但是，可能不比一般的開源大數據系統還不成熟，但這是另一回事。）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如果某些查詢需要更精細的時間范圍，則將列值設置為一些粗粒度（例如一個小時），並可選地添加另一個長型列“ precise_time”。這是一個hack，但是允許Druid之前實際上按某種維度對數據進行排序__time也將很容易實現。
我不質疑他們選擇ClickHouse的最終決定，因為在大約10個節點的規模上，並且對於他們的用例，我還認為ClickHouse比Druid更好的選擇（我將在本文下面進行解釋）。但是他們得出的結論是，ClickHouse的效率（在基礎設施成本方面）至少比Druid高出一個數量級，這完全是謬論。實際上，在這里討論的三個系統中，Druid提供了最多的功能來實現真正方便的安裝，請參閱下面的“在Druid中分層查詢處理節點”。
在選擇大數據OLAP系統時，請勿比較它們當前對於您的用例的最佳程度。目前，它們都非常次優。比較您的組織可以使這些系統朝着使您的用例更優化的方向移動的速度。
由於其基本的架構相似性，ClickHouse，Druid和Pinot在效率和性能優化上具有大約相同的“極限”。沒有“魔術葯”可以使這些系統中的任何一個都比其他系統快得多。在當前狀態下，這些系統在某些基准測試中的性能有很大不同，這一事實並不會讓您感到困惑。例如 當前，Druid與ClickHouse不同（參見上文），它不很好地支持“主鍵排序”，而ClickHouse與Druid不同，它不支持反向索引，這使這些系統在特定工作負載方面處於優勢。如果您有意願和能力，則可以在選定的系統中實施缺少的優化，而無需花費很多精力。
- 您的組織中的任何一個工程師都應該具有能夠閱讀，理解和修改所選系統的源代碼。請注意，ClickHouse用C ++，Druid和Pinot用Java編寫。
- 或者，您的組織應與提供所選系統支持的公司簽訂合同。有Altinity為ClickHouse，Imply和Hortonworks為Druid，目前沒有針對Pinot的此類公司。
其他開發注意事項：
- Yandex的ClickHouse開發人員表示，他們將50％的時間用於構建公司內部所需的功能，而50％的時間用於“社區投票”次數最多的功能。但是，要從中受益，您在ClickHouse中所需的功能應與社區中大多數其他人所需的功能匹配。
- Imply的Druid開發人員具有建立廣泛適用的功能的動機，以最大程度地發展他們的未來業務。
- Druid的開發過程與Apache模型非常相似，多年來，它是由多家公司開發的，這些公司的優先級大相徑庭，並且在任何一家公司中都不占主導地位。ClickHouse和Pinot目前距離這種狀態還很遙遠，它們分別是分別由Yandex和LinkedIn開發的。對Druid的貢獻以后被拒絕或撤銷的可能性最小，因為它們與主要開發者的目標不一致。Druid沒有“主要”開發商公司。
- Druid承諾支持“開發人員API”，該API允許提供自定義列類型，聚合算法，“深度存儲”選項等，並使它們與核心Druid的代碼庫分開。Druid開發人員記錄了此API，並跟蹤其與先前版本的兼容性。但是，該API尚未成熟，並且在每個Druid版本中都幾乎被破壞了。據我所知，ClickHouse和Pinot沒有維護類似的API。
- 根據Github的說法，Pinot 從事這項工作的人最多，去年似乎至少有10個人年在Pinot 上進行類似工作。對於ClickHouse來說，這個數字可能是6；對於Druid，這個數字大約是7。這意味着從理論上講，Pinot在主題系統中的進步最快。
Druid和Pinot的體系結構幾乎完全相同，而ClickHouse則與它們略有不同。我將首先將ClickHouse的架構與“通用” Druid / Pinot架構進行比較，然后討論Druid與Pinot之間的較小差異。
ClickHouse和Druid / Pinot之間的區別
數據管理：Druid 和Pinot
在Druid和Pinot中，每個“表”中的所有數據（無論這些系統用什么術語稱呼）都被划分為指定數量的部分。按照時間維度，通常還會將數據除以指定的時間間隔。然后，將這些數據的各個部分分別“密封”到稱為“段”的自包含實體中。每個段包括表元數據，壓縮的列數據和索引。
段保留在“深度存儲”（例如HDFS）中，可以加載到查詢處理節點上，但是后者不負責段的持久性，因此可以相對自由地替換查詢處理節點。段並非嚴格地附加到某些節點，它們可以或多或少地加載到任何節點上。一個特殊的專用服務器（在Druid中稱為“協調器”，在Pinot中稱為“控制器”，但在下面我將其統稱為“主服務器”）負責將分段分配給節點，並在節點之間移動分段， 如果需要的話。（這與我在本文中上面指出的觀點並不矛盾，因為包括Druid和Pinot在內的所有三個特有系統在節點之間都具有“靜態”數據分布，這是因為Druid（Pinot一樣），因為Druid（Pinot一樣）中的段加載和移動是昂貴的操作，並且對於每個特定查詢都沒有完成，並且通常僅每隔幾分鍾，幾小時或幾天發生一次。
有關段的元數據在Druid中直接保存在zookeeper，在Pinot中的通過Helix框架保存在ZooKeeper 中。在Druid中，元數據也保留在SQL數據庫中，在本文下面的“ Druid與Pinot之間的區別”部分中對此進行了詳細說明。
數據管理：ClickHouse
ClickHouse沒有“段”的概念，其中包含嚴格屬於特定時間范圍的數據。沒有數據的“深度存儲”，ClickHouse群集中的節點還負責查詢處理以及存儲在其上的數據的持久性。因此，不需要HDFS設置，也不需要像Amazon S3這樣的或雲數據存儲。
ClickHouse具有分區表，由特定的節點集組成。沒有“中央權限”或元數據服務器。在其中對某個表進行分區的所有節點都具有表元數據的完全相同的副本，包括存儲該表分區的所有其他節點的地址。
分區表的元數據包括用於分發新寫入的數據的節點的“權重”，例如40％的數據應流向節點A，30％的數據流向節點B，30％的數據流向節點C。通常應在節點之間的相等分布。如上例所示，只有在將新節點添加到分區表中時才需要“傾斜”，以便用某些數據更快地填充新節點。這些“權重”的更新應由ClickHouse群集管理員手動完成，或者應在ClickHouse之上構建一個自動化系統。
數據管理：比較
在ClickHouse中，數據管理方法比在Druid和Pinot中更簡單：不需要“深度存儲”，只需一種類型的節點，就不需要用於數據管理的專用服務器。但是，當任何數據表變得如此之大以至於需要在數十個或更多節點之間進行分區時，ClickHouse的方法就變得有些問題了：查詢放大因子變得與分區因子一樣大，即使對於查詢而言，其覆蓋數據范圍很小：
Data distribution tradeoff in ClickHouse
在上圖中給出的示例中，表數據分布在Druid或Pinot中的三個節點之間，但是查詢少量數據間隔通常只會命中兩個節點（除非該間隔跨越了段間隔邊界）。在ClickHouse中，如果表在三個節點之間進行分區，則任何查詢都需要命中三個節點。在此示例中，這似乎並沒有太大的區別，但是可以想象節點數為100，而在Druid或Pinot中，分配因子仍可以是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
Druid和Pinot的復制單位是單個段。段在“深層存儲”層（例如，HDFS中的三個副本，或者在雲blob存儲（例如Amazon S3）中透明完成）和查詢處理層中復制：通常在Druid和Pinot中，每個段在兩個不同的節點上加載。如果復制因子低於指定的級別（例如，如果某個節點變得無響應），則“主”服務器將監視每個段的復制級別並在某個服務器上加載一個段。
數據復制: ClickHouse
ClickHouse中的復制單元是服務器上的表分區，即某個表中的所有數據都存儲在服務器上。與分區類似，ClickHouse中的復制是“靜態的和特定的”，而不是“雲樣式”，即，幾台服務器知道它們是彼此的副本（對於某些特定表；對於不同的表，復制配置可能不同）。復制可提供持久性和查詢可用性。當某個節點上的磁盤損壞時，數據也不會丟失，因為它也存儲在其他節點上。當某個節點暫時關閉時，查詢可以路由到副本。
在Yandex上最大的ClickHouse集群中，不同數據中心中有兩組相等的節點，並且它們是成對的。在每對節點中，節點是彼此的副本（即，使用兩個復制因子），並且位於不同的數據中心中。
ClickHouse依賴ZooKeeper進行復制管理，但是不需要ZooKeeper。這意味着單節點ClickHouse部署不需要ZooKeeper。
數據提取: Druid and Pinot
在Druid和Pinot中，查詢處理節點專門用於加載段並向段中的數據提供查詢，但不累積新數據並產生新段。
當可以延遲一小時或更長時間來更新表時，將使用批處理引擎（例如Hadoop或Spark）創建分段。Druid和Pinot都對Hadoop提供了“一流”的現成支持。Spark中有一個用於Druid索引的第三方插件，但目前尚不支持。據我所知，Pinot甚至沒有對Spark的這種支持，即您應該自己做出貢獻：了解Pinot接口和代碼，編寫一些Java或Scala代碼。但這並不難。（更新：Slack的Ananth PackkilDurai 現在正在為Pinot的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會正確處理此情況：合並所有成功子查詢的結果，並且仍將部分結果返回給用戶。目前，Druid非常缺乏此功能：如果任何子查詢失敗，則整個查詢也會失敗。
ClickHouse vs. Druid or Pinot: 結論
Druid和Pinot中數據管理的“分段”方法與ClickHouse中較簡單的數據管理方法定義了系統的許多其他方面。但是，重要的是，這種差異對潛在的壓縮效率（盡管目前這三個系統中的壓縮情況目前都是令人沮喪的）或查詢處理速度幾乎沒有影響。
ClickHouse與傳統的RDMBS類似，例如PostgreSQL。特別是，ClickHouse可以僅部署在單個服務器上。如果部署的預計規模很小，例如，不超過用於查詢處理的100個CPU內核和1 TB數據的數量級，那么我想說ClickHouse相對於Druid和Pinot具有顯着優勢，因為它非常簡單並且不需要其他類型的節點，例如“主節點”，“實時提取節點”，“經紀人”。在此領域，ClickHouse與InfluxDB競爭而不是與Druid或Pinot競爭。
Druid和Pinot類似於大數據系統，例如HBase。不取決於它們的性能特征，而是取決於對ZooKeeper的依賴性，對持久性復制存儲（例如HDFS）的依賴性，對單個節點故障的恢復能力的關注以及不需要常規人員關注的自主工作和數據管理。
對於廣泛的應用程序，ClickHouse或Druid或Pinot都不是明顯的贏家。首先，我建議考慮您能夠理解的系統源代碼，修復錯誤，添加功能等。“性能比較和系統選擇”部分將對此進行更多討論。
其次，您可以查看下表。該表中的每個單元格都描述了某個應用程序的屬性，這使ClickHouse或Druid / Pinot可能是更好的選擇。行沒有按其重要性排序。每行的相對重要性對於不同的應用程序是不同的，但是如果您的應用程序由表中一列的許多屬性描述，而由另一列的無或幾個屬性描述，則很可能應該從列標題中選擇相應的系統。
| ClickHouse | Druid or Pinot |
|---|---|
| The organization has expertise in C++ | The organization has expertise in Java |
| Small cluster | Large cluster |
| A few tables | Many tables |
| Single data set | Multiple unrelated data sets (multitenancy) |
| Tables and data sets reside the cluster permanently | Tables and data sets periodically emerge and retire from the cluster |
| Table sizes (and query intensity to them) are stable in time | Tables significantly grow and shrink in time |
| Homogeneity of queries (their type, size, distribution by time of the day, etc.) | Heterogeneity |
| There is a dimension in the data, by which it could be partitioned and almost no queries that touch data across the partitions are done (i. e. shared-nothing partitioning) |
There is no such dimension, queries often touch data across the whole cluster. Edit 2019: Pinot now supports partitioning by dimension. |
| Cloud is not used, cluster is deployed on specific physical servers | Cluster is deployed in the cloud |
| No existing clusters of Hadoop or Spark | Clusters of either Hadoop or Spark already exist and could be used |
Differences between Druid and Pinot
正如我在上面多次提到的，Druid和Pinot具有非常相似的體系結構。在一個系統中存在着幾個相當大的功能，而在另一個系統中則沒有，還有一些區域，其中一個系統比另一個系統的進步要遠得多。但是我要提到的所有這些內容都可以通過合理的努力在另一個系統中復制。
Druid與Pinot之間只有一個區別，那就是太大了，無法在可預見的將來消除-這是“主”節點中段管理的實現。而且，這兩種系統的開發人員可能都不想這樣做，因為兩者的方法各有利弊，並不是說一個人總比另一個人好。
Segment Management in Druid
Druid（以及Pinot中的兩個節點）中的“主”節點不負責集群中數據段的元數據的持久性以及段與加載這些段的查詢處理節點之間的當前映射，此信息保留在ZooKeeper中。但是，Druid 還將這些信息保存在SQL數據庫中，應該提供該信息以設置Druid集群。我不能說為什么最初做出這個決定，但是目前它提供了以下好處：
- 較少的數據存儲在ZooKeeper中。ZooKeeper中僅保留有關從段ID到加載該段的查詢處理節點列表的映射的最少信息。其余的擴展元數據（例如段的大小，其數據中的維度和指標列表等）僅存儲在SQL數據庫中。
- 如果由於數據段太舊而將其從集群中逐出（這是時間序列數據庫的常見功能，所有ClickHouse，Druid和Pinot都具有），則將它們從查詢處理節點上卸載，並從ZooKeeper中刪除有關它們的元數據，但不是來自“深度存儲”和SQL數據庫。只要不從這些地方手動刪除它們，就可以快速“恢復”真正的舊數據，以防某些報告或調查需要該數據。
- 最初這不太可能是一個意圖，但是現在Druid中有計划使對ZooKeeper的依賴成為可選。目前，ZooKeeper用於三種不同的事物：段管理，服務發現和屬性存儲，例如用於實時數據攝取管理。服務發現和屬性存儲功能可以由Consul提供。段管理可以通過HTTP公告和命令來實現，而ZooKeeper的持久性功能已由SQL數據庫“備份”，則部分啟用了該功能。
將SQL數據庫作為依賴項的弊端是更大的操作負擔，尤其是在組織中尚未建立某些SQL數據庫的情況下。Druid支持MySQL和PostgreSQL，Microsoft SQL Server有一個社區擴展。同樣，當Druid部署在雲中時，可以使用方便的托管RDBMS服務，例如Amazon RDS。
Segment Management in Pinot
與Druid本身實現所有分段管理邏輯並且僅依靠Curator與ZooKeeper進行通信不同，Pinot將大部分分段和集群管理邏輯委托給Helix框架。一方面，我可以想象它為Pinot開發人員提供了一種專注於其系統其他部分的杠桿。與在Druid中實現的邏輯相比，Helix的bug可能更少，這是因為在不同的條件下對它進行了測試，並且可能將更多的時間投入到Helix開發中。
另一方面，Helix的“框架界限”可能會限制Pinot。Helix，進而是Pinot，可能永遠永遠依賴ZooKeeper。
現在，我將列舉Druid與Pinot之間更淺的區別。這里的“淺”是指如果有人願意的話，有一條清晰的途徑可以在缺少這些功能的系統中復制這些功能。
“Predicate pushdown” in Pinot
如果在攝取期間通過某些維鍵在Kafka中對數據進行了分區，則Pinot會生成包含有關該分區的信息的段，然后在執行帶有該維謂詞的查詢時，代理節點會預先過濾段，這樣有時段會少得多因此，查詢處理節點需要命中。
此功能對於某些應用程序的性能很重要。
當前Druid支持基於密鑰的分區，如果在Hadoop中創建了段，但在實時攝取期間創建段時尚不支持。Druid 目前不對broker實施“謂詞下推”。
“Pluggable” Druid and Opinionated 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以來，這種情況可能很快就會改變。
Data Format and Query Execution Engine are Optimized Better in 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主要用於count (*)查詢與Druid（以比較Pinot的表現1，2），因為它只是一個愚蠢的線性掃描在Druid的那一刻，雖然它很容易用適當的替換為o（1 ）實施。這是“黑匣子”比較毫無意義的例證，本文上面的“關於性能比較和系統選擇”部分對此進行了介紹。
我認為，GROUP BYUber觀察到的查詢性能差異應歸因於Druid細分市場中缺乏數據排序，如本節上文所述。
Druid Has a Smarter Segment Assignment (Balancing) Algorithm
Pinot的算法是將段分配給當前加載的總段數最少的查詢處理節點。Druid的算法復雜得多，它考慮了每個段的表和時間，並應用了一個復雜的公式來計算最終分數，通過該公式對查詢處理節點進行排名，以選擇最佳的節點來分配新的段。該算法使Metamarkets的生產查詢速度提高了30–40％。然而，在Metamarkets我們仍然不滿意這個算法，請參閱“歷史節點的性能差異巨大” 這篇文章。
我不知道LinkedIn在Pinot中使用如此簡單的分段平衡算法的效果如何，但是如果他們需要時間來改進其算法，那么可能巨大的收獲正在等待着他們。
Pinot is More Fault Tolerant on the Query Execution Path
正如我在上面的“查詢執行”部分中提到的那樣，當“代理”節點向其他節點進行子查詢，並且某些子查詢失敗時，Pinot會合並所有成功的子查詢的結果，並且仍將部分結果返回給用戶。
Druid目前沒有實現此功能。
Tiering of Query Processing Nodes in Druid
請參閱本文上方的同名部分。Druid允許為較舊和較新的數據提取查詢處理節點的“層”，而較舊數據的節點具有較低的“ CPU，RAM資源/已加載段數”比率，從而可以在訪問時以較小的基礎架構開銷換取較低的查詢性能舊數據。
據我所知，Pinot目前沒有類似的功能。
Summary
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框架，並將繼續依賴ZooZeeper，而Druid可以擺脫對ZooKeeper的依賴。另一方面，Druid的安裝將繼續取決於某些SQL數據庫的存在。
目前，Pinot比Druid的優化效果更好。（但請在上面再次閱讀-“我不建議完全比較主題系統的性能”，以及帖子中的相應部分。）
原文帖子：https://medium.com/@leventov/comparison-of-the-open-source-olap-systems-for-big-data-clickhouse-druid-and-pinot-8e042a5ed1c7