解决时区导致druid任务构建失败的问题:No buckets?? seems there is no data to index.

本文介绍了一个关于Druid数据处理框架中NoBuckets错误的问题及解决过程。该错误通常出现在数据索引任务失败时,通过调整系统的时区设置解决了问题。

===== update 2017-07-12 begin =====

No Buckets 的主要原因是: load batch data 的时候,intervals 的范围小于被上传数据的时间范围

===== update 2017-07-12  end   =====

Error stack as fllow:

2017-07-10T08:41:36,134 ERROR [task-runner-0-priority-0] io.druid.indexing.overlord.ThreadPoolTaskRunner - Exception while running task[HadoopIndexTask{id=index_hadoop_pageviews_2017-07-10T08:40:32.650Z, type=index_hadoop, dataSource=pageviews}]
java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
	at com.google.common.base.Throwables.propagate(Throwables.java:160) ~[guava-16.0.1.jar:?]
	at io.druid.indexing.common.task.HadoopTask.invokeForeignLoader(HadoopTask.java:204) ~[druid-indexing-service-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at io.druid.indexing.common.task.HadoopIndexTask.run(HadoopIndexTask.java:208) ~[druid-indexing-service-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at io.druid.indexing.overlord.ThreadPoolTaskRunner$ThreadPoolTaskRunnerCallable.call(ThreadPoolTaskRunner.java:436) [druid-indexing-service-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at io.druid.indexing.overlord.ThreadPoolTaskRunner$ThreadPoolTaskRunnerCallable.call(ThreadPoolTaskRunner.java:408) [druid-indexing-service-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_131]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_131]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_131]
	at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
Caused by: java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_131]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_131]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_131]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_131]
	at io.druid.indexing.common.task.HadoopTask.invokeForeignLoader(HadoopTask.java:201) ~[druid-indexing-service-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	... 7 more
Caused by: java.lang.RuntimeException: java.lang.RuntimeException: No buckets?? seems there is no data to index.
	at io.druid.indexer.IndexGeneratorJob.run(IndexGeneratorJob.java:215) ~[druid-indexing-hadoop-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at io.druid.indexer.JobHelper.runJobs(JobHelper.java:349) ~[druid-indexing-hadoop-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at io.druid.indexer.HadoopDruidIndexerJob.run(HadoopDruidIndexerJob.java:94) ~[druid-indexing-hadoop-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at io.druid.indexing.common.task.HadoopIndexTask$HadoopIndexGeneratorInnerProcessing.runTask(HadoopIndexTask.java:261) ~[druid-indexing-service-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_131]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_131]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_131]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_131]
	at io.druid.indexing.common.task.HadoopTask.invokeForeignLoader(HadoopTask.java:201) ~[druid-indexing-service-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	... 7 more
Caused by: java.lang.RuntimeException: No buckets?? seems there is no data to index.
	at io.druid.indexer.IndexGeneratorJob.run(IndexGeneratorJob.java:176) ~[druid-indexing-hadoop-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at io.druid.indexer.JobHelper.runJobs(JobHelper.java:349) ~[druid-indexing-hadoop-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at io.druid.indexer.HadoopDruidIndexerJob.run(HadoopDruidIndexerJob.java:94) ~[druid-indexing-hadoop-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at io.druid.indexing.common.task.HadoopIndexTask$HadoopIndexGeneratorInnerProcessing.runTask(HadoopIndexTask.java:261) ~[druid-indexing-service-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_131]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_131]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_131]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_131]
	at io.druid.indexing.common.task.HadoopTask.invokeForeignLoader(HadoopTask.java:201) ~[druid-indexing-service-0.9.2.2.6.0.3-8.jar:0.9.2.2.6.0.3-8]
	... 7 more

从中,我们可以看到异常关键词:

No buckets?? seems there is no data to index.

一般情况下,我解决问题的思路是,先百度,后 github,再解决不了只能看源码。

因为druid这东西在国内并不火,所以百度没啥效果,然后到druid的github中,搜上述关键词,得到一条类似的issue:

https://github.com/druid-io/druid/issues/3259

这个issue虽然没能解决问题,但给我提供了解决问题的思路:修改timezone!

于是乎先看了系统的timezone,已经是CST,时间正常。

然后观察druid日志,发现druid日志与系统时间相差了8小时。

于是在ambari中,查找和timezone相关的druid配置,结果发现,有如下属性和timezone有关:

- druid.broker.jvm.opts

- druid.coordinator.jvm.opts

- druid.historical.jvm.opts

druid.middlemanager.jvm.opts

- druid.overlord.jvm.opts

-druid.router.jvm.opts

-druid.indexer.runner.javaOpts

druid默认使用UTC,我这里发现日志和系统时间相差8小时,于是改为 UTC+8, 成功构建!

<think>好的,我现在需要帮助用户解决他们遇到的Druid连接池初始化错误的问题。用户提供的错误信息是“illegal initialSize 100, maxActive 8”,这个错误发生在初始化DruidDataSource的时候。首先,我需要理解这个错误的具体原因。 根据错误信息,IllegalArgumentException被抛出,说明在初始化参数时有不合法的值。错误提示指出initialSize是100,而maxActive是8。Druid连接池的参数配置有某些约束条件,这里的问题可能是initialSize(初始连接数)超过了maxActive(最大活跃连接数)。通常来说,初始连接数不能超过最大连接数,否则会导致资源分配不合理,甚至引发错误。 接下来,我需要回忆Druid连接池的相关配置参数。Druid的initialSize默认值通常是0,maxActive默认是8。如果用户将initialSize设置为100,而maxActive保持默认的8,这显然会导致initialSize > maxActive,从而触发异常。 那么,用户可能的配置文件中设置了initialSize为100,但没有调整maxActive的值。需要检查他们的配置文件,比如application.yml或application.properties,查看这两个参数的设置情况。 解决方案应该是调整这两个参数,使得initialSize不超过maxActive。例如,将maxActive增加到至少100或更高,或者将initialSize降低到8或以下。另外,还需要考虑其他相关参数,比如minIdle(最小空闲连接数),是否也需要调整以保证一致性。 此外,用户可能没有意识到这些参数之间的依赖关系,或者是在配置时出现了笔误。需要建议他们检查配置文件中的相关部分,特别是druid的连接池配置部分,确认参数是否合理。 同时,还需要提醒用户,连接池参数的设置需要根据实际应用的需求和数据库的处理能力来调整。过高的initialSize可能会在启动时给数据库带来压力,而maxActive设置过高可能导致资源耗尽。因此,建议他们根据实际情况进行测试和优化。 最后,可能需要提供一个完整的配置示例,帮助用户正确设置这些参数,并解释每个参数的作用,以避免未来的配置错误。</think>--- ### **错误原因分析** 根据报错信息 `illegal initialSize 100, maxActive 8`,说明 **Druid 连接池**的配置存在以下矛盾: 1. `initialSize`(初始连接数)设置为 `100`,但 `maxActive`(最大活跃连接数)设置为 `8`。 2. **Druid 要求**:初始连接数 `initialSize` 必须小于等于 `maxActive`,否则会抛出此异常。 --- ### **解决方案** #### **1. 调整连接池参数** 修改 `application.yml`(或 `application.properties`)中 Druid 的配置,确保 `initialSize ≤ maxActive`。 示例如下: ```yaml type: druid driverClass: dm.jdbc.driver.DmDriver url: jdbc:dm://172.16.1.30:5236/orcl?clobAsString=1&quoteReplace=1 username: heal-dm password: heal-dm@130301 # 新增连接池参数配置 initialSize: 5 # 初始连接数(建议 ≤ maxActive) maxActive: 20 # 最大活跃连接数(必须 ≥ initialSize) minIdle: 3 # 最小空闲连接数(建议 ≤ maxActive) ``` --- #### **2. 参数说明** | 参数名 | 含义 | 默认值 | 建议值范围 | |--------------|---------------------|--------|------------------| | `initialSize`| 启动时创建的连接数 | 0 | 根据负载设定,建议 `≤ maxActive` | | `maxActive` | 最大活跃连接数 | 8 | 根据数据库承载能力调整(如 `20~100`) | | `minIdle` | 最小空闲连接数 | 0 | 建议 `≤ maxActive` | --- ### **注意事项** 1. **参数合理性**: - `initialSize` 过高可能导致应用启动时数据库压力骤增。 - `maxActive` 需根据数据库连接上限调整(例如达梦默认连接数限制为 `1000`)。 2. **其他关联参数**: - `maxWait`:获取连接的超时时间(默认 `-1`,建议 `3000ms`)。 - `testOnBorrow`:是否在获取连接时检测有效性(默认 `false`,生产环境建议开启)。 --- ### **完整配置示例** ```yaml type: druid driverClass: dm.jdbc.driver.DmDriver url: jdbc:dm://172.16.1.30:5236/orcl?clobAsString=1&quoteReplace=1 username: heal-dm password: heal-dm@130301 # 连接池参数 initialSize: 5 maxActive: 20 minIdle: 3 maxWait: 3000 testOnBorrow: true validationQuery: SELECT 1 FROM DUAL ``` --- ### **验证方法** 1. 启动应用,观察是否仍然报错。 2. 通过 Druid 监控页面(如已启用)检查连接池状态,确认参数生效。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值