培训资料专业资料更新于 2026-07-296 分钟阅读
Apache Doris 数仓与慢查询必知必会：Query Profile四层证据
整理Doris模型、导入、指标服务和Query Profile四层证据，提供20项公开安全检查清单；不包含客户SQL、对象、节点、端点、账号或完整Profile。
摘要
Doris查询变慢时，先从Summary、ExecutionSummary、MergedProfile和DetailProfile逐层收敛，再结合版本、并发、数据分布和资源证据人工签收；不从改参数开始。
适用对象
数仓工程师OLAP 平台团队数据分析团队实时数仓负责人
核心结论
- Doris 必知必会包括表模型、分区分桶、导入方式、物化视图、查询优化和资源治理。
- OLAP 性能问题常来自模型选择和数据分布，不应只靠增加机器解决。
- Query Profile要按四层证据收敛，不能只截取一个算子耗时或直接修改FE、BE、资源组和拓扑。
- InchStack 可把指标口径、导入变更、质量校验和分析交付组织成闭环。
01慢查询证据
Query Profile按四层收敛，不从改参数开始
Summary先确认版本、执行FE、Profile引用和总耗时；ExecutionSummary区分规划、调度和执行前阶段；MergedProfile用于缩小到Fragment、Operator、处理行数和倾斜；DetailProfile只在受控位置比较BE与PipelineTask差异。
每层都需要写明证据来源、可见性和签收责任。公开文件不保存客户SQL、谓词、对象、节点、端点、账号或完整Profile，也不授权全局开启Profile。
Doris慢查询四层分流
| 层级 | 主要问题 | 形成的结论 | 明确边界 |
|---|---|---|---|
| Summary | 版本、执行FE、Profile入口和总耗时是否明确 | 证据入口可复查 | 找不到Profile不等于没有问题 |
| ExecutionSummary | 慢在规划、调度还是执行前阶段 | 阶段级候选 | 不能单独归因到SQL或节点 |
| MergedProfile | 哪个Fragment、Operator或倾斜范围最突出 | 缩小复核范围 | 不能用未验证阈值自动判定 |
| DetailProfile | 受控位置中的BE与PipelineTask差异 | 人工脱敏结论 | 不公开完整Profile，不自动改参 |
参考依据
以下来源用于确认市场趋势、政策背景和术语边界；具体落地方案仍以客户的数据范围、权限和交付目标为准。
常见问题
Doris 培训应先讲表模型还是 SQL 优化？
应先讲表模型和数据分布。很多 SQL 优化问题源于建模和导入策略，后期再调 SQL 成本更高。
InchStack 如何服务 Doris 场景？
它可以管理指标口径、导入变更、质量校验、查询验证和交付证据，让 OLAP 能力和业务责任连接起来。
拿到Query Profile后可以直接调参数吗？
不可以。Profile先用于确认阶段、算子、数据分布和资源候选；参数、资源组、FE/BE或拓扑变更必须结合版本、基线、回滚和业务责任另行审批。
