• 基于apache-druid-0.17.0

概述

• Router進程可以被用于查詢不同的Broker進程。通常情況下，broker查詢路由依賴與規(guī)則(Rule)的設(shè)定。舉例來說，假如最近一個月的數(shù)據(jù)被加載僅hot cluster，最近一個月內(nèi)的查詢可以路由到一組專用的Broker。查詢一個月之外的可以路由到另一組Brokers。這種設(shè)置提供了查詢隔離，以便對更重要數(shù)據(jù)的查詢不會受到對不太重要數(shù)據(jù)的查詢的影響。
• 如果你的Druid集群達到TB級別，作為使用這僅僅只需要回到查詢路由的進程即可。
• 配置文件信息及API信息詳見官網(wǎng)；

啟動命令

org.apache.druid.cli.Main server router

Router作為管理代理

• 可以將Router配置為將請求轉(zhuǎn)發(fā)給活著的Coordinator 或 Overlord 進程。將對集群的HA配置有效。

配置修改

• To enable this functionality, set the following in the Router's runtime.properties:

druid.router.managementProxy.enabled=true

管理代理路由配置

• 管理代理支持隱式和顯式路由。隱式路由是那些可以根據(jù)Druid API路徑約定從原始請求路徑確定目標的路由。對于Coordinator來說路徑是/druid/ Coordinator /*，對于Overlord來說路徑是/druid/indexer/*。這些是方便的，因為它們意味著使用管理代理不需要修改API請求，只需向路由器發(fā)出請求，而不是Coordinator或Overlord。大多數(shù)Druid API請求可以隱式路由。
• 顯式路由是指發(fā)送到路由器的請求包含一個路徑前綴，該前綴指示請求應該路由到哪個進程。對于Coordinator，這個前綴是/proxy/ Coordinator，對于Overlord，它是/proxy/ Overlord。這對于目標不明確的API調(diào)用是必需的。例如，所有的Druid進程都有/status API，所以需要使用顯式路由來指示代理目的地。
• 下表敘述如下：
  |Request Route|Destination|Rewritten Route|Example|
  |-------------|-----------|---------------|-------|
  |/druid/coordinator/*|Coordinator|/druid/coordinator/*|router:8888/druid/coordinator/v1/datasources -> coordinator:8081/druid/coordinator/v1/datasources|
  |/druid/indexer/*|Overlord|/druid/indexer/*|router:8888/druid/indexer/v1/task -> overlord:8090/druid/indexer/v1/task|
  |/proxy/coordinator/*|Coordinator|/*|router:8888/proxy/coordinator/status -> coordinator:8081/status|
  |/proxy/overlord/*|Overlord|/*|router:8888/proxy/overlord/druid/indexer/v1/isLeader -> overlord:8090/druid/indexer/v1/isLeader|

Router策略

• Router有一個可配置的策略列表，用于選擇將查詢路由到哪個Broker。策略的順序很重要，因為一旦匹配了策略條件，就會選擇Broker。

timeBoundary 時間邊界

{
  "type":"timeBoundary"
}

• 包含此策略意味著所有時間邊界查詢始終路由到最高優(yōu)先級的Broker。

priority 優(yōu)先級

{
  "type":"priority",
  "minPriority":0,
  "maxPriority":1
}

• 將優(yōu)先級設(shè)置為小于minPriority的查詢路由到最低優(yōu)先級的Broker。將優(yōu)先級設(shè)置為大于maxPriority的查詢路由到優(yōu)先級最高的Broker。默認情況下，minPriority是0,maxPriority是1。使用這些默認值，如果發(fā)送優(yōu)先級為0的查詢(默認查詢優(yōu)先級為0)，查詢將跳過優(yōu)先級選擇邏輯。

Avatica 負載均衡

• 所有具有給定連接ID的Avatica JDBC請求都必須路由到相同的Broker，因為Druid Broker之間不共享連接狀態(tài)。
• 為此，Druid提供了兩個內(nèi)置的平衡器，分別使用集合哈希和請求連接ID的一致哈希來分配請求給Broker。
• 請注意，當使用多個Router時，所有Router都應該具有相同的平衡器配置，以確保它們做出相同的路由決策。

Rendezvous hash平衡器

• 此平衡器使用Avatica請求的連接ID上的集合散列將請求分配給代理。
• 要使用此平衡器，請指定以下屬性:

druid.router.avatica.balancer.type=rendezvousHash

• If no druid.router.avatica.balancer property is set, the Router will also default to using the Rendezvous Hash Balancer.

Consistent hash平衡器

• 這個平衡器對Avatica請求的連接ID使用一致的散列來將請求分配給代理。
• 配置信息如下：

druid.router.avatica.balancer.type=consistentHash

• 這是一個非默認的實現(xiàn)，用于實驗目的。一致的hasher在初始化和代理集更改時的設(shè)置時間更長，但是在使用5個代理進行測試時，其代理分配時間比會合hasher更快。這兩種實現(xiàn)的基準都已經(jīng)在consistency asherbenchmark和voushasherbenchmark中提供了。一致的hasher也需要鎖定，而會合的hasher不需要。