Druid实战--摄入数据规范Ingestion Spec

最新推荐文章于 2024-10-24 13:36:11 发布
最新推荐文章于 2024-10-24 13:36:11 发布
阅读量1.1k 收藏
点赞数 3
分类专栏： Druid 文章标签： Druid 数据摄入规范 Ingestion Spec
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/aA518189/article/details/97569015
版权

简介

           Schema的定义，Druid摄入数据规范的核心是dataSchema,dataSchema定义了如何解析输入的数据，并将数据存储到Druid中。 ingestion spec 由三个部分组成：

{
  "dataSchema" : {...},
  "ioConfig" : {...},
  "tuningConfig" : {...}
}
字段类型描述是否必须
dataSchemaJSON Object指定传入数据的Schema。所有Ingestion Spec都可以共享相同的dataSchema。是
ioConfigJSON Object指定数据的来源和去向。此对象将随摄取方法而变化。是
tuningConfigJSON Object指定如何调整各种摄取参数。此对象将随摄取方法而变化。否

1.dataSchema

            首先我们创建一个json的文件：kafka-index-day-roll-up.json，在该文件中添加空dataSchema;

"dataSchema" : {}

2.DataSource name

            DataSource name指定，数据源名称由dataSchema中的datasource参数指定，在这里我们叫做kafka_to_druid,可以看作是数据库的表名；

"dataSchema" : {
  "dataSource" : "kafka_to_druid",
}

3.parser-解释器

              dataSchema中有一个parser这个字段，它是解释输入数据的解析器，上面的案例中我们使用的是JSON格式的字符串，因此我们使用JSON格式的字符串解释器解析数据。

如果type未包含，则解析器默认为string

如果format未包含，则parseSpec默认为tsv。

"dataSchema" : {
    "dataSource" : "kafka_to_druid",
    "parser" : {
      "type" : "string",
      "parseSpec" : {
         "format" : "json"
      }
    }
  }

4.Time column - 时间列

                解释器parser需要知道数据中每条数据的产生时间（main timestamp）,这个时间戳需要定义在 timestampSpec中。数据中有一列ts就是我们所需要的timestamp,因此我们将带有该信息的timestampSpec 添加到parseSpec中。

字段类型描述是否必须
columnString时间戳的列。是
formatStringiso，posix，millis，micro，nano，auto或任何Joda time格式。否（默认== ‘auto’）
"dataSchema" : {
    "dataSource" : "kafka_to_druid",
    "parser" : {
      "type" : "string",
      "parseSpec" : {
        "format" : "json",
        "timestampSpec" : {
          "format" : "auto",
          "column" : "ts"
        }
      }
    }
  }

5.Column types

         上面我们已经定义了time的列，接下来我们定义其它列的类型。Druid支持的column types: String, Long, Float, Double.我们将在接下来的小节中讨论以及如何使用它们。在我们去定义非时间序列之前，我们首先来讨论一下rollup。

6.Rollup

     druid在通过roll-up处理后，会将原始数据在注入的时候就开始进行汇总处理。roll-up是在数据存储到segment之前进行的第一层聚合操作。

  1. 如果rollup设置成true,这个时候就需要我们把输入的columns进行分为两类，维度(dimensions)和度量(metrics).dimensions是我们进行group的时候需要的列，metrics是我们进行聚合时需要的列。
  2. 如果rollup设置成false,这个时候我们会将输入的所有columns当做dimensions处理，并且没有预聚合的发生。
"dataSchema" : {
    "dataSource" : "kafka_to_druid",
    "parser" : {
      "type" : "string",
      "parseSpec" : {
        "format" : "json",
        "timestampSpec" : {
          "format" : "auto",
          "column" : "ts"
        }
      }
    },
    "granularitySpec" : {
      "rollup" : true
    }
  }

7.选择dimension和metrics

①在上面给到的数据集中，很明显的就可以区分开 dimensions 和 metrics。

Dimensions: startIP |  startPort | endIP  | endPort | protocol
Metrics: packets | bytes | costTime

②接下来我们如何在摄入数据规范中定义这些 dimensions列 和 metrics列呢？Dimensions：使用dimensionsSpec在parseSpec中指定。

"dataSchema" : {
      "dataSource" : "kafka_to_druid",
      "parser" : {
      "type" : "string",
      "parseSpec" : {
          "format" : "json",
          "timestampSpec" : {
               "format" : "auto",
               "column" : "ts"
          },
       "dimensionsSpec" : {
              "dimensions": [
                   "startIP",
                   { "name" : "startPort", "type" : "long" },
                   { "name" : "endIP", "type" : "string" },
                   { "name" : "endPort", "type" : "long" },
                   { "name" : "protocol", "type" : "string" }
              ]
            }   
           }
          },
       "metricsSpec" : [
              { "type" : "count", "name" : "count" },
              { "type" : "longSum", "name" : "packets", "fieldName" : "packets" },
              { "type" : "longSum", "name" : "bytes", "fieldName" : "bytes" },
              { "type" : "doubleSum", "name" : "costTime", "fieldName" : "costTime" }
      ],
       "granularitySpec" : {
              "rollup" : true
          }
      }

注：每个维度都有一个name 和 type，type的类型可能是："long", "float", "double", "string"。我们注意到startIP这个"string"类型的维度，它仅仅只需要指定名字就可以了。

③.在druid中，string 类型是默认的。除此之外，我们注意一下protocol是一个数值型的。但是我们定义的时候将其定义为 string。Druid会强制将该类型进行转换。Metrics:使用metricsSpec 在dataSchema中指定。

"dataSchema" : {
            "dataSource" : "kafka_to_druid",
            "parser" : {
              "type" : "string",
              "parseSpec" : {
                "format" : "json",
                "timestampSpec" : {
                  "format" : "auto",
                  "column" : "ts"
                },
                "dimensionsSpec" : {
                  "dimensions": [
                    "startIP",
                    { "name" : "startPort", "type" : "long" },
                    { "name" : "endIP", "type" : "string" },
                    { "name" : "endPort", "type" : "long" },
                    { "name" : "protocol", "type" : "string" }
                  ]
                }   
              }
            },
            "metricsSpec" : [
              { "type" : "count", "name" : "count" },
              { "type" : "longSum", "name" : "packets", "fieldName" : "packets" },
              { "type" : "longSum", "name" : "bytes", "fieldName" : "bytes" },
              { "type" : "doubleSum", "name" : "costTime", "fieldName" : "costTime" }
            ],
            "granularitySpec" : {
              "rollup" : true
            }
      }

注：当我们定义metric时，有必要指定在rollup期间对该列执行的聚合类型。我们将packets和bytes定义成long sum聚合操作，costTime定义成double sum聚合操作。 metricsSpec的嵌套级别与dimensionSpec或parseSpec不同，它和dataSchema属于同一嵌套级别。除此，我们还定义了一个count聚合操作器，它会在rollup过程中，记录输入的数据量总共有多少。支持的聚合器类型详情点击link

8.不使用rollup

如果不适用roolup所有输入的colums都被当做"dimensions"，不再区分"dimensions" 和"metrics"。

"dimensionsSpec" : {
  "dimensions": [
      "startIP",
      { "name" : "startPort", "type" : "long" },
      { "name" : "endIP", "type" : "string" },
      { "name" : "endPort", "type" : "long" },
      { "name" : "protocol", "type" : "string" },
      { "name" : "packets", "type" : "long" },
      { "name" : "bytes", "type" : "long" },
      { "name" : "startPort", "type" : "double" }
  ]
}

9.Define Granularities-粒度的定义。

接下来还有一些其他的属性需要在granularitySpec中设置，granularitySpec支持2中类型(type)：uniform和arbitrary。在这里，我们使用uniform这种类型，这会使所有的segment都有统一的间隔大小(比如：每个segment都保存一个小时内的值)。

①segment granularity这个属性是指一个segment应该包含多大时间间隔的数据，可以是： DAY, WEEK，HOUR , MINUTE...... 在这里，我们制定segment的粒度是HOUR。

"dataSchema" : {
        "dataSource" : "kafka_to_druid",
        "parser" : {
          "type" : "string",
          "parseSpec" : {
            "format" : "json",
            "timestampSpec" : {
              "format" : "auto",
              "column" : "ts"
            },
            "dimensionsSpec" : {
              "dimensions": [
                "startIP",
                { "name" : "startPort", "type" : "long" },
                { "name" : "endIP", "type" : "string" },
                { "name" : "endPort", "type" : "long" },
                { "name" : "protocol", "type" : "string" }
              ]
            }      
          }
        },
        "metricsSpec" : [
          { "type" : "count", "name" : "count" },
          { "type" : "longSum", "name" : "packets", "fieldName" : "packets" },
          { "type" : "longSum", "name" : "bytes", "fieldName" : "bytes" },
          { "type" : "doubleSum", "name" : "costTime", "fieldName" : "costTime" }
        ],
        "granularitySpec" : {
          "type" : "uniform",
          "segmentGranularity" : "HOUR",
          "rollup" : true
        }
      }

②.query granularity：查询的粒度通过queryGranularity配置在granularitySpec中，在这里我们使用minute粒度。

"dataSchema" : {
        "dataSource" : "realtime_kafka_to_druid",
        "parser" : {
           "type" : "string",
           "parseSpec" : {
               "format" : "json",
               "timestampSpec" : {
                "format" : "auto",
                "column" : "ts"
              },
            "dimensionsSpec" : {
              "dimensions": [
                "startIP",
                { "name" : "startPort", "type" : "long" },
                { "name" : "endIP", "type" : "string" },
                { "name" : "endPort", "type" : "long" },
                { "name" : "protocol", "type" : "string" }
              ]
            }      
          }
        },
        "metricsSpec" : [
          { "type" : "count", "name" : "count" },
          { "type" : "longSum", "name" : "packets", "fieldName" : "packets" },
          { "type" : "longSum", "name" : "bytes", "fieldName" : "bytes" },
          { "type" : "doubleSum", "name" : "costTime", "fieldName" : "costTime" }
        ],
        "granularitySpec" : {
          "type" : "uniform",
          "segmentGranularity" : "HOUR",
          "queryGranularity" : "MINUTE"
          "rollup" : true
        }
      }

③.Define an interval:定义时间间隔，在这个时间间隔之外的数据将不会被处理。注意，这个参数设置只在批处理中(batch)。interval需要在 granularitySpec中指定。

"granularitySpec" : {
   "intervals" : ["2019-01-17/2019-01-18"]
}

10.定义输入数据的数据源

IOConfig规范根据摄取任务类型而有所不同。

  1. 本机批量摄取：请参阅Native Batch IOConfig
  2. Hadoop Batch ingestion：请参阅Hadoop Batch IOConfig
  3. Kafka Indexing Service：请参阅Kafka Supervisor IOConfig
  4. Stream Push Ingestion：使用Tranquility进行Stream Push不需要IO配置
  5. Stream Pull Ingestion（已弃用）：请参阅Stream pull ingestion

11.tuningConfig-额外的配置

           每个摄入任务都有一个tuningConfig部分，让开发人员自行配置。在这里根据输入的数据源kafka来进行配置tuningConfig。type索引任务类型，此处是kafka 。reportParseExceptions默认是false，如果开启这个功能，当摄入数据过程中出现数据异常将会导致摄入数据停止。

"tuningConfig": {
  "type": "kafka",
  "reportParseExceptions": false
}

 

提交我们的task，然后查询数据。

  • 1.需要在Overlord节点执行：

    curl -X 'POST' -H 'Content-Type:application/json' -d @quickstart/kafka-druid/kafka-index-day-roll-up.json http://host1:8090/druid/indexer/v1/supervisor

    2.此刻开启程序，往kafka的topic=druid-topic-book中发送数据，此代码不做重点。

    3.上面的步骤执行完之后，我们可以查看druid最终存入的数据。需要在broker节点执行。

    ①.rollup-select-sql.json内容，注意查询的DataSource名称

    {
   "query":"select * from \"realtime_kafka_to_druid\""
}

    ② 执行

     curl -X 'POST' -H 'Content-Type:application/json' -d @rollup-select-sql.json http://host2:8082/druid/v2/sql

     

    扫一扫加入大数据公众号和技术交流群，了解更多大数据技术，还有免费资料等你哦

    扫一扫加入大数据公众号和技术交流群，了解更多大数据技术，还有免费资料等你哦

    扫一扫加入大数据公众号和技术交流群，了解更多大数据技术，还有免费资料等你哦

Druid实践系列《一》
sinat_32176267的博客
08-31 932
一、Druid介绍... 2 1.1官方介绍... 2 1.2架构：... 3 1.3 Data Storage and Segment 4 1.4数据... 5 1.4查询过程... 7 二、Druid使用... 7 2.1加载数据到Druid. 7 2.1.1加载静态数据... 8 2.1.2加载流式数据... 8 2.2数据查询... 9 三、单机安装... 10 3...
实现连接池druid操作数据库实战-包含所需要的jar包
12-29
实现连接池druid操作数据库实战-包含所需要的jar包实现连接池druid操作数据库实战-包含所需要的jar包-创建表
Druid集成实战
三侠剑的博客
09-19 315
Druid介绍：https://www.iteye.com/magazines/90#111 1. 引用依赖 <!-- mybatis --> <mybatis.spring.boot.starter.version>2.0.0</mybatis.spring.boot.starter.version> <mybatis.spring.version>2.0.0</mybatis.spring.version> &
Druid实战--安装与配置
阿华田的博客
07-28 2353
简介 服务的搭建与运行是认识Druid的第一.步，采取分布式设计的Druid由不同职责的节点组成，同时为了实现节点间的信息同步和服务高可用性，其还依赖--些外部组件如Zookeeper、MySQL 和HDFS。本文将从如下几部分重点介绍Druid的安装部署和配置。 Druid服务的安装部署(单机版用于测试学习，集群版用于生产环境)。 如何搭建一个Druid集群以及关键...
CC00012.druid——|Hadoop&OLAP_Druid.V12|——|Druid.v12|实战|Druid实战案例.V1|
yanqi_vip
04-14 102
一、需求分析 ### --- 场景分析 ~~~ 数据量大，需要在这些数据中根据业务需要灵活做查询 ~~~ 实时性要求高 ~~~ 数据实时的推过来，要在秒级对数据进行分析并查询出结果 二、数据分析 ### --- 数据描述 ~~~ # 数据json串 {"ts":1607499629841,"orderId":"100938...
SpringBoot实战（二十）集成Druid连接池
ACGkaka的博客
07-09 2766
SpringBoot实战（二十）集成Druid连接池
druid-spring-boot-starter-1.1.9-API文档-中文版.zip
07-14
赠送jar包：druid-spring-boot-starter-1.1.9.jar； 赠送原API文档：druid-spring-boot-starter-1.1.9-javadoc.jar； 赠送源代码：druid-spring-boot-starter-1.1.9-sources.jar； 赠送Maven依赖信息文件：druid-...
druid-spring-boot-starter-1.1.22.jar
03-01
druid-spring-boot-starter-1.1.22.jar
druid-spring-boot-starter-1.1.10-API文档-中文版.zip
06-06
赠送jar包：druid-spring-boot-starter-1.1.10.jar； 赠送原API文档：druid-spring-boot-starter-1.1.10-javadoc.jar； 赠送源代码：druid-spring-boot-starter-1.1.10-sources.jar； 赠送Maven依赖信息文件：druid-...
druid-spring-boot-starter-1.1.9-API文档-中英对照版.zip
07-14
赠送jar包：druid-spring-boot-starter-1.1.9.jar； 赠送原API文档：druid-spring-boot-starter-1.1.9-javadoc.jar； 赠送源代码：druid-spring-boot-starter-1.1.9-sources.jar； 赠送Maven依赖信息文件：druid-...
druid-spring-boot-starter-1.2.8.jar
04-04
druid-spring-boot-starter-1.2.8.jar
druid 手动指定数据源_MyBatis初级实战之三：集成druid
weixin_39558221的博客
11-22 570
欢迎访问我的GitHubhttps://github.com/zq2599/blog_demos内容：所有原创文章分类汇总及配套源码，涉及Java、Docker、Kubernetes、DevOPS等；本篇概览本文是《MyBatis初级实战》系列的第三篇，我们将实战springboot、mybatis、druid的集成，并验证，由以下内容组成：新建springboot工程，里面有详细的集成druid...
Druid配置——Ingestion Spec（摄取规范）
Niclas的博客
07-05 2623
Ingestion Spec（摄取规范） Apache Druid ingestion spec 由三个部分组成： { "dataSchema" : {...}, "ioConfig" : {...}, "tuningConfig" : {...} } 字段 类型 描述 是否必须 dataSchema JSON Object 指定传入数据的Schema。所有Inges...
springboot 连接池wait_timeout超时设置
weixin_34072637的博客
11-02 3310
使用springboot 线程池连接MySQL时，mysql数据库wait_timeout 为8个小时，所以程序第二天发现报错，在url配置了 autoReconnect=true 也不行，查询配置以下 #验证连接的有效性 spring.datasource.test-while-idle=true #获取连接时候验证，会影响性能spring.datasource.test-on-borrow=t...
配置dataSource三种方式
oook
07-20 8665
1、使用org.springframework.jdbc.datasource.DriverManagerDataSource  说明：DriverManagerDataSource建立连接是只要有连接就新建一个connection,根本没有连接池的作用。  &lt;bean id="dataSource" class="org.springframework.jdbc.datasource.Dr...
Druid实战指南：基础知识、实战应用及最佳实践全攻略
最新发布
学海无涯，行者无疆
10-24 1252
在Java系统实现过程中，我们不可避免地会借助大量开源功能组件。然而，这些组件往往功能丰富且体系庞大，官方文档常常详尽至数百页。而在实际项目中，我们可能仅需使用其中的一小部分功能，这就造成了一个挑战：如何在有限的时间和精力下，高效地掌握并使用这些组件的核心功能，以实现投入产出最大化？ 针对这一问题，我基于二八原则，整理编写本文。 首先，我会聚焦于组件的常见和核心功能，这些功能通常是我们在日常开发中频繁使用到的，也是构建稳定、高效系统的基石。通过深入了解这些核心功能的使用方法和最佳实践，我们可以确保在关键
spring.datasource.name 和spring.datasource.username
qq_40652679的博客
06-15 1万+
spring.datasource.name 和spring.datasource.username 所踩的坑 spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver spring.datasource.url=jdbc:mysql://localhost:3306/thread?useSSL=false&useUnicode=true&characterEncoding=UTF-8 spring.datasource.use
Spring中配置DataSource数据源的几种选择
热门推荐
当幸福来敲门的专栏
03-10 2万+
Spring中配置DataSource数据源的几种选择 在Spring框架中有如下3种获得DataSource对象的方法: 从JNDI获得DataSource.从第三方的连接池获得DataSource.使用DriverManagerDataSource获得DataSource. 一、从JNDI获得DataSource SpringJNDI数据源配
SpringBoot配置属性之DataSource
weixin_33936401的博客
01-16 1250
SpringBoot配置属性系列 SpringBoot配置属性之MVC SpringBoot配置属性之Server SpringBoot配置属性之DataSource SpringBoot配置属性之NOSQL SpringBoot配置属性之MQ SpringBoot配置属性之Security SpringBoot配置属性之Migrati...
掌握Druid-1.0.18版本的加密解密方法
此外，Druid-1.0.18版本还包含了对数据源、监控特性的进一步优化和改进。在使用过程中，开发者可以根据具体的业务需求调整配置文件中的参数，例如连接池的最大、最小连接数、连接超时时间等，以便更好地适应不同的...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

阿华田512

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值