[推荐 ]druid 架构理解

 在druid进行配置时，首先需要搞清楚druid的整体架构、节点等概念，这对于后续各节点配置有更好的作用，druid整体架构如下：

 （1）broker Nodes：对于Historical Nodes和Real-time Nodes来说作用是查询路由，所有的客户端请求都会发送到Broker Nodes中，该节点知道在zookeeper之上的segments信息，哪些segments是可查询的和这些segments存储在什么位置，最后该节点会merge来自Historical Nodes 和Real-time Nodes的查询结果，反馈给客户端，此外该节点还提供缓存的功能，它会缓存查询结构，如果后续查询hit 缓存，则只会去Historical 和Real-time Nodes去查询。

（2）Real-time Nodes:实时节点，实时ingest摄取数据，并可提供立即查询，该节点只关注较小时间范围内的数据，它会周期性的将接受到的stream 流数据落盘（hand off ），通过zookeeper与其他节点进行协调，它内部为将要摄取的Stream 流数据提供了一个基于内存的Buffer，为了避免内存溢出，会周期性或者达到最大数据量时将数据落盘。

（3）Historical Nodes:历史查询节点，只负责从Deep Storage中加载数据，删除数据，并对加载到内存中数据提供查询功能，通过zookeeper上报状态，并且接受来自zookeeper的指令，包括加载（load）和删除（drop）segments,并保存着Deep Storage中segments中的存储信息，知道如何解压缩和处理segments.

 （4）Coordinate Nodes:主要负责分布在Historical Nodes节点之上数据的管理，它通过zookeeper告知Historical Nodes 去Load 新的segments 和drop 过期的segments,并保持真个cluster 的运行的balance。

（5） MySQL: 主要存储druid 的元数据，主要包括segments元数据信息、rule table 信息，ingest task任务信息等。

                                 

（6）zookeeper: 负责与各个节点进行协调和状态同步，并接受来自coordinate的指令（drop 、load），并存储druid 从Deep Storage中加载到内存中的segments信息，只有加载到内存，数据才是可查询的。

    对于druid 在搭建的时候需要配置各个节点，主要包括，

      

      其中middelManager和overlord均属于Real-time Node节点范围，overlord负责接受来自客户端的supervisor的请求，创建supervisor，而middelManager负责根据supervisor创建实际的task任务，task任务负责从外部message bus中实时获取数据，每个节点都包括jvm.properites和runtime.properties配置。

  （1） common configuration

      minial 配置如下，主要包括zookeeper配置，deep storage配置，mysql配置以及比较重要的druid.indexer.logs.directory配置，该属性便于后续查看task的日志信息。

druid.extensions.loadList主要配置extensions的依赖，如果实时从kafka读取数据，需要“druid-kafka-indexing-service”，如果需要hdfs 存储，则需要“druid-hdfs-storage”，需要根据实际情况去配置。

# Extensions
#

# This is not the full list of Druid extensions, but common ones that people often use. You may need to change this list
# based on your particular setup.
druid.extensions.loadList=["mysql-metadata-storage", "druid-hdfs-storage","druid-kafka-indexing-service","kafka-emitter","druid-datasketches"]

# If you have a different version of Hadoop, place your Hadoop client jar files in your hadoop-dependencies directory
# and uncomment the line below to point to your directory.
#druid.extensions.hadoopDependenciesDir=/my/dir/hadoop-dependencies

#
# Logging
#

# Log all runtime properties on startup. Disable to avoid logging properties on startup:
druid.startup.logging.logProperties=true

#
# Zookeeper
#

druid.zk.service.host=10.1.1.84:2181,10.1.1.77:2181,10.1.1.182:2181
druid.zk.paths.base=/druid

#
# Metadata storage
#

# For MySQL:
druid.metadata.storage.type=mysql
druid.metadata.storage.connector.connectURI=jdbc:mysql://xxxxxxxxxxxxxxxxxx:3306/druid
druid.metadata.storage.connector.user=xxxx
druid.metadata.storage.connector.password=xxxxx
#
# Deep storage
#

# For local disk (only viable in a cluster if this is a network mount):
druid.storage.type=local
druid.storage.storageDirectory=/var/druid/segments

# For HDFS (make sure to include the HDFS extension and that your Hadoop config files in the cp):
#druid.storage.type=hdfs
#druid.storage.storageDirectory=/druid/segments

#
# Indexing service logs
#

# For local disk (only viable in a cluster if this is a network mount):
druid.indexer.logs.type=file
druid.indexer.logs.directory=/var/druid/indexing-logs

# For HDFS (make sure to include the HDFS extension and that your Hadoop config files in the cp):
#druid.indexer.logs.type=hdfs
#druid.indexer.logs.directory=/druid/indexing-logs
#
# Service discovery
#

druid.selectors.indexing.serviceName=druid/overlord
druid.selectors.coordinator.serviceName=druid/coordinator

#
# Monitoring
#

druid.monitoring.monitors=["com.metamx.metrics.JvmMonitor"]
druid.emitter=composing
druid.emitter.logging.logLevel=info
  （2）Broker节点

    jvm.properties:

    

  runtime.propertis

其中druid.processing.buffer.sizeBytes * (druid.processing.numThreads + 3)要小于此目录下jvm.config文件中MaxDirectMemorySize的值，否则启动不起来。

（2）coordinate

   jvm.properties :

runtime.properties:

（3）historical configuration

  jvm.properties;

runtime.properties:

druid.processing.buffer.sizeBytes * (druid.processing.numThreads + 3)要小于此目录下jvm.config文件中MaxDirectMemorySize的值，否则启动不起来。

并可配置segments Cache的，以提高查询效率。

（4）overload configuration

 jvm.properties:

runtime.properties

(5)middle manager

jvm.properties;  

该节点的堆大小可设置较少，其主要创建task ,由task进行创建peon进行数据的实时ingest.

runtime.propertis：

其中，druid.worker.capacity主要配置可运行的task数量，task launch parameters主要用配置每个taskd的运行参数，并且

druid.processing.buffer.sizeBytes * (druid.processing.numThreads + 3)要小每个任务线程所使用的内存 –Xmx

启动druid

1、进入到druid-0.10.0目录下，使用bin/overlord.sh start，bin/coordinator.sh start 等命令启动对应的overlord、coordinator等节点。整个集群中，为确保HA，需要启动两个overlord、两个middleManager、两个coordinator、两个broker、三个historical节点。每台服务器上执行相应的启动节点命令。
2、验证：进入druid-0.10.0目录

①执行解压命令：

gzip -c -d quickstart/wikiticker-2015-09-12-sampled.json.gz > "quickstart/wikiticker-2015-09-12-sampled.json"
②导入数据：
 curl -X 'POST' -H 'Content-Type:application/json' -d @quickstart/wikiticker-index.json overlordip:host/druid/indexer/v1/task
       //overlordip替换为overlord节点所在服务器ip
   出现{"task":"index_hadoop_wikiticker_2018-02-07T02:23:25.718Z"}说明导入成功
③查询
curl -L -H'Content-Type: application/json' -XPOST --data-binary @quickstart/wikiticker-top-pages.json http://brokerip:host/druid/v2/?pretty

//brokerip替换为broker节点所在服务器ip

返回查询结果说明集群无问题
 

https://blog.youkuaiyun.com/xiaobai51509660/article/details/80741647