0

我在https://groups.google.com/forum/#!topic/druid-user/SY​​Wcqcr504k上问了我的问题， 但没有人帮我解决这个问题。

我正在处理大型数据集。在 2 种情况下的 topN 查询（​​按天计算的段粒度与按小时计算的段粒度）在 sam 上的“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" 慢。谁能解释一下这个案子？为什么按天分段比按小时慢？在按天和按小时存储数据段之间，如何选择段类型？它如何影响我的查询？非常感谢 ！

4

1 回答 1

1

您可以考虑这些因素来决定分段粒度：

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

我还建议您查看查询节点（即历史和实时）发出的各种 druid 指标，以找出查询速度较慢的瓶颈。有关各种指标，请参阅http://druid.io/docs/latest/operations/metrics.html

于 2016-08-26T13:36:18.670 回答