Druid使用Kafka Indexing Service方式push数据以及实时节点pull数据步骤

2018年05月27日 13:44:07

阅读数：77

  Druid中从kafka摄入数据，存在两种方式，一种是pull，需要依赖实时节点，一种是push，需要依赖Kafka Indexing Service（kafka索引服务）

     注：在0.9.1.1版本前使用Tranquility-Kafka组件接入实时数据，由于存在时间窗口，即在时间窗口内的数据会被提交给Firehose，时间窗口外的数据则会被丢弃；如果Tranquility-Kafka临时下线，会导致Kafka中数据“过期”从而被丢弃，无法保证数据完整性，同时这种“copy service”的使用模式不仅占用大量CPU与内存，又不满足原子操作，所以在0.9.1.1版本后，建议使用Druid的新特性Kafka Indexing Service，Druid内部使用Kafka高级Consumer API保证exactly-once semantics，尽最大可能保证数据完整性。

     步骤一：下载Kafka Indexing Service扩展，将扩张加入到druid目录下的extensions目录下。

     步骤二：将扩展绑定在middlemanager以及overlord上，在开发中，实际配置方案为直接配置/opt/druid/conf/druid/_common/common.runtime.properties，在druid.extensions.loadList中加入Kafka Indexing Service，如图：

                   ，如果不进行配置，无法使用kafka索引服务

     步骤三：在druid目录下的var目录下新建tmp目录作为java.io.tmpdir（jvm.config配置文件）目录。如果目录不存在。Druid报错

     步骤四：编写Json配置文件：示例如下

1. {
2. "type": "kafka",
3. "dataSchema": {
4. "dataSource": "kafka3", //Druid中的表名
5. "parser": {
6. "type": "string",
7. "parseSpec": {
8. "format": "json",
9. "timestampSpec": { //时间戳列
10. "column": "timestamp",
11. "format": "auto"
12. },
13. "dimensionsSpec": { //维度列
14. "dimensions": [ "timestamp", "from"],
15. "dimensionExclusions": []
16. }
17. }
18. },
19. "metricsSpec": [ //指标列
20. {
21. "name": "count",
22. "type": "count"
23. },
24. {
25. "name": "PVSum",
26. "fieldName": "PVSum",
27. "type": "longSum"
28. },
29. {
30. "name": "UVSum",
31. "fieldName": "UVSum",
32. "type": "longSum"
33. }
34. ],
35. "granularitySpec": { //查询维度
36. "type": "uniform",
37. "segmentGranularity": "DAY",
38. "queryGranularity": "NONE"
39. }
40. },
41. "tuningConfig": { //优化型配置
42. "type": "kafka",
43. "maxRowsPerSegment": 75000,
44. "workerThreads": 2
45. },
46. "ioConfig": { //指明数据来源
47. "topic": "zhangzl",
48. "consumerProperties": {
49. "bootstrap.servers": "ip1:9092,ip2:9092,ip3:9092"
50. },
51. "useEarliestOffset": true,
52. "taskCount": 1,
53. "replicas": 1,
54. "taskDuration": "PT1M"
55. }
56. }

 步骤五： 确认workerThreads配置为（taskCount * replicas +1）；

 步骤六：调整配置项useEarliestOffset为true，否则druid只会读取最新数据，不会从beginning开始读取数据。

实时节点使用步骤：

注：使用tranquility为0.8.2版本，在使用过程中尝试使用0.8.0版本以及0.8.1版本均为成功，具体原因不明，下载地址：http://static.druid.io/tranquility/releases/tranquility-distribution-0.8.2.tgz

步骤一：将下载好的tranquility-distribution-0.8.2.tgz解压后的目录移动到Druid的home目录下。

步骤二：编辑配置文件，示例如下：

1. {
2. "dataSources": [{
3. "spec": {
4. "dataSchema": {
5. "parser": {
6. "type": "string",
7. "parseSpec": {
8. "timestampSpec": { //时间戳列，必须指定，实时节点根据该列对时间窗口进行判断
9. "column": "timestamp",
10. "format": "auto"
11. },
12. "dimensionsSpec": { //维度列
13. "dimensions": [ "timestamp", "from"],
14. "dimensionExclusions": []
15. },
16. "format": "json"
17. }
18. },
19. "dataSource": "twitter", //Druid中的表名
20. "granularitySpec": {
21. "type": "uniform",
22. "segmentGranularity": "DAY",
23. "queryGranularity": "NONE"
24. },
25. "metricsSpec": [{ //指标列
26. "name": "count",
27. "type": "count"
28. },
29. {
30. "name": "PVSum",
31. "fieldName": "PVSum",
32. "type": "longSum"
33. },
34. {
35. "name": "UVSum",
36. "fieldName": "UVSum",
37. "type": "longSum"
38. }
39. ]
40. },
41. "tuningConfig": {
42. "type": "realtime",
43. "maxRowsInMemory": "75000", //内存中存储的最大数据量，超过该数据量之后会刷新到Druid中
44. "intermediatePersistPeriod": "PT1M", //时间窗口
45. "windowPeriod": "PT10M" //延时窗口，超过时间窗口后的数据，如果还在延时窗口中，则还会被处理，超过延时窗口的数据会被丢弃
46. }
47. },
48. "properties": {
49. "task.partitions": "2",
50. "task.replicants": "2",
51. "topicPattern": "twitter" //kafka topic
52. }
53. }],
54. "properties": {
55. "zookeeper.connect": "ip1:2181,ip2:2181,ip3:2181", //druid zk
56. "zookeeper.timeout": "PT20S",
57. "druid.selectors.indexing.serviceName": "druid/overlord",
58. "druid.discovery.curator.path": "/druid/discovery",
59. "kafka.zookeeper.connect": "ip1:2182,ip2:2182,ip3:2182", //kafka zk
60. "kafka.group.id": "tranquility-kafka",
61. "consumer.numThreads": "2",
62. "commit.periodMillis": "15000",
63. "reportDropsAsExceptions": "false"
64. }
65. }

步骤三：进入到目录下使用如下命令：bin/tranquility kafka -configFile <配置文件路径>进行启动

步骤四：使用kafka生产消息，注：时间戳列采用yyyy-MM-ddTHH:mm:ssZ格式，否则数据无法解析，应该可以配置，但未找到配置点。

索引服务与实时节点比较：

在Druid重启时，索引服务不会丢数据，但是对于实时节点，如果重启太慢，数据超过了时间窗口以及延时窗口，这部分数据会被丢弃。

索引服务实际是在指定时间内处理数据，然后将数据积压，可以配置提交时间，到达提交时间时进行提交。

索引服务在Druid重启后，不会重读消费过的数据，也就是offset不会从begining开始，数据不会重叠。

索引服务出现在tranquility服务之后，实际是对实时节点的一个补充，但是索引服务只在0.9.1.1版本之后进行支持