java - 按天和按小时比较分段粒度之间的有效性能查询topN

Question

我在 https://groups.google.com/forum/#!topic/druid-user/SYWcqcr504k 上提出了我的问题但没有人帮助我解决这个问题。

我正在处理大型数据集。对于 2 个案例(按天的分段粒度 vs 按小时的分段粒度)的 topN 查询，“queryGranularity”按“小时”。

案例01:按天

"granularitySpec" : {
        "type" : "uniform",
        "segmentGranularity" : "day",
        "queryGranularity" : "hour",
        "intervals" : ["2016-08-22/2016-08-23"]
      }

案例02:按小时

"granularitySpec" : {
        "type" : "uniform",
        "segmentGranularity" : "hour",
        "queryGranularity" : "hour",
        "intervals" : ["2016-08-22/2016-08-23"]
      }

但是查询“segmentGranularity”:“day”的时间比“segmentGranularity”:“hour”慢。谁能给我解释一下这个案例吗？为什么按天分段比按小时慢？那么在按天和按小时存储数据分段之间，如何选择分段类型？它如何影响我的查询？非常感谢 !

Answer 1

您可以考虑以下因素来决定分段粒度:

• 在实时摄取的情况下，段粒度将决定实时索引任务运行的时间。段粒度越粗，这些实时索引任务运行的时间就越长。只有当实时任务完成时，才会将数据保留在深层存储上。因此，如果某个时间间隔内实时任务的所有副本都被杀死，您将丢失该时间间隔的数据。因此，段粒度会影响丢失数据的风险。更细的分段粒度意味着中层管理人员可以投入更多资源，因为多个短任务将并行执行。
• 分段粒度还会影响所创建分段的大小。在基本设置中，为每个时间间隔创建一个段文件，其中时间间隔可由segmentGranularity 配置。一般来说，建议将段大小保持在 300-700 MB 的量级，最多 5 百万行。因此，此建议也可用于决定段粒度。如果生成的段非常少且大，则将影响查询的并行性，因为并行性的单位是段。因此，大段有时会减慢查询速度，在日级别创建段时可能会出现这种情况。

我还建议您查看查询节点发出的各种德鲁伊指标(即历史和实时)，以找出查询速度较慢时的瓶颈。各种指标请引用http://druid.io/docs/latest/operations/metrics.html