為什麼在Apache Druid中的實時資料使用Kafka索引 ? -Kartik Khare

banq發表於2019-12-25

將資料儲存在實時資料流中一直是一個挑戰。解決方案取決於您的用例具體情況。如果要儲存資料以進行每日或每月分析,則可以使用分散式檔案系統並在其上執行HivePresto;如果要執行一些簡單的實時分析,則可以將最新資料儲存在Elasticsearch中,併為圖表執行Kibana

Apache Druid可以同時解決上述兩個用例。它可以用作每日或每月分析的持久資料儲存。它也可以用作快速可查詢的資料儲存,使您可以實時推送和檢索資料。

但是,早期版本的Apache druid的問題是從資料庫中的流中提取資料。讓我們看一下開發人員之前面臨的挑戰。

Tranquility

Tranquility是Apache Druid提供的用於攝取實時資料的軟體包。Tranquility並不完全等同於JDBC或Cassandra驅動程式。它為您處理分割槽,複製,服務發現和架構過渡。使用者只需要關心他需要使用的資料和資料來源。

雖然它解決了使用者可能面臨的許多問題。但是,它捆綁了自己的一系列挑戰。

1. 不完全一次

Tranquility在某些情況下可以建立重複的記錄。它不提供任何準確的保證。在某些情況下,例如POST請求資料超時或未收到確認,Tranquility可能會產生重複的記錄。

這種情況使使用者有責任對資料進行重複資料刪除。如果使用一個,它甚至可能導致Apache superset 超集中的圖形不正確

2.資料丟失

最令人擔憂的問題是資料丟失。在各種情況下,“Tranquility”有意或由於錯誤而無法插入資料。官方文件中列出的某些情況是:

  • 時間戳超出您配置的windowPeriod的事件將被刪除。
  • 如果您遭受的Druid中級管理器故障比配置的副本數更多,則可能會丟失部分索引的資料。
  • 如果存在持續的問題,無法與Druid索引服務進行通訊,並且在此期間內重試策略已用盡,或者該期間的持續時間長於windowPeriod,則某些事件將被丟棄。
  • 如果存在阻止“Tranquility”從索引服務接收到確認的問題,它將重試該批處理,這可能導致重複的事件。

最糟糕的是,在大多數情況下,您甚至都不知道在查詢之前資料已被刪除。

3.錯誤處理

由於Tranquility守護程式在JVM中執行,因此應用程式負責處理超時等錯誤。對於諸如Apache Flink之類的應用程式,如果不能有效地管理這些錯誤之一,則可能導致不必要的重啟。

Tranquility是為druid 0.9.2.構建,使用0.16.0以上版本會導致無法定位問題。

卡夫卡索引器

為了解決上述所有問題,Apache druid在0.9.1版中新增了Kafka Indexer。索引器一直處於實驗狀態,直到版本0.14。

Kafka Indexing Service首先根據您指定的配置啟動管理員。主管然後定期啟動新的索引編制任務,這些任務負責使用來自Kafka的資料並將其釋出到Druid中。

Kafka索引任務可以長期執行。最小編號之後可以釋出多個細分。

1.一次精確語義

Kafka索引器為使用者提供一次準確的保證。由於預設的Kafka使用者(因為Kafka 0.11.x提供了對此語義的開箱即用的支援),因此可以保證這一點。

2.釋出延遲資料

Kafka索引器旨在釋出延遲的資料。該功能使使用者可以自由地將資料從Kafka中的特定偏移回填到Druid。

3.架構更新

儘管“Tranquility”還支援架構更新,但在Kafka Indexer中更容易做到。您只需要提交一個包含新模式的POST請求,supervisor 將使用更新後的模式生成新任務。您不需要在生產者端進行任何更改。如果您新增新列,則較舊的行將在這些列中顯示空值,但這些行仍可查詢。

Kafka Indexer服務解決了開發人員在使用Tranquility時遇到的許多問題。如果要開始使用Kafka Indexing服務,可以在官方Druid文件中參考Apache Kafka Ingestion

相關文章