总述基于requestId、taskId、attemptId、applicationId建立全链路成本归因链路把租户、用户、业务线、数据集和 SQL 指纹与实际 CPU、内存、存储、网络等资源消耗关联起来。不同情况不同计算不同引擎的资源指标通过 EngineConn 适配层统一再按照企业资源单价计算任务成本。对于重试任务我会区分 Task 总成本、每次 Attempt 成本和失败重试成本对于共享集群则按实际资源使用量进行分摊。最终将成本、SLA、执行耗时和成功率反哺路由层让平台在满足 SLA 的前提下优先选择成本更低、复用率更高的执行环境。论述成本归因要解决的问题是查询执行消耗了多少计算资源这些资源应该归属到哪个租户、用户、业务线、数据集和 SQL 上能够进一步判断哪些查询成本过高、哪些引擎或集群更划算。我会把成本归因建立在全链路任务标识之上而不是只根据最终结果或集群总账单估算。整体归因分析链路是查询请求 - Task - ExecutionAttempt - RouteDecision - EngineConn - 外部 Application - 资源指标 - 成本计算 - 业务归因第一建立归因维度提交请求时统一入口需要补齐归因上下文tenantId userId businessLine application dataset sqlFingerprint taskId attemptId routeDecisionId engine cluster queue其中tenantId成本归属哪个租户 businessLine / application成本归属哪个业务线或应用 dataset成本由哪些数据集产生 sqlFingerprint哪类 SQL 消耗成本最高 taskId / attemptId哪一次任务、哪一次执行尝试产生了成本这些信息要一路透传到 Linkis、EngineConn 和外部计算引擎最后通过applicationId和资源监控系统关联起来。第二采集真实资源消耗对于一次查询不能只记录执行时长还要采集实际资源queueTime executeTime cpuTime memoryUsage executorCores executorMemory executorCount scanBytes shuffleBytes diskBytes例如 Spark 任务需要采集applicationId vcoreSeconds memorySeconds executor 数量 Executor 运行时长 Shuffle 数据量Trino 或 JDBC 可能没有完全相同的指标因此需要在引擎适配层统一成平台模型cpuCost memoryCost storageCost networkCost engineCost这样上层不需要感知 Spark、Trino 和 JDBC 指标的差异。第三建立成本计算模型成本不一定直接等于执行时间应该根据企业实际资源单价计算。例如计算成本 CPU 使用量 × CPU 单价 内存使用量 × 内存单价 存储成本 网络成本 引擎或集群附加成本Spark 可以按vcoreSeconds memorySeconds计算。Trino 可以按CPU 时间 内存使用时间 查询执行时间计算。如果企业暂时没有精确的云账单也可以先建立内部成本模型CPU0.01 元 / core-minute 内存0.005 元 / GB-minute 存储0.02 元 / GB例如一次查询实际消耗CPU40 core-minutes 内存80 GB-minutes那么CPU 成本 40 × 0.01 0.4 元 内存成本 80 × 0.005 0.4 元 总成本 0.8 元重点是先保证归因口径统一后续再替换成云厂商或集群真实计费价格。第四处理重试和共享资源这里要特别区分Task 成本 ExecutionAttempt 成本如果第一次路由到 Trino 失败第二次切换到 SparkTask查询订单金额 Attempt 1Trino消耗 0.2 元失败 Attempt 2Spark消耗 1.5 元成功这次查询的总成本应该是Task 总成本 Attempt 1 成本 Attempt 2 成本 1.7 元但在分析时还要区分业务查询成本1.7 元 失败重试成本0.2 元 有效结果成本1.5 元否则无法判断成本高是因为查询本身复杂还是因为路由错误导致重复执行。对于共享集群也不能把整个集群成本直接归给某个租户而应该按资源使用量进行分摊租户成本 租户实际 CPU / 集群总 CPU × 集群成本 租户实际内存 / 集群总内存 × 集群成本如果无法精确获得资源使用量可以根据队列 Executor 执行时长 CPU 和内存配置进行近似分摊但要明确这是估算成本。第五建立成本归因链路成本归因简单说就是一次查询消耗了多少 CPU、内存和存储资源这笔成本最后算到哪个租户、哪个业务线、哪条 SQL 上。最终要把成本信息和查询链路关联起来requestId - taskId - attemptId - routeDecisionId - engineConnId - applicationId - sqlFingerprint - costRecord成本记录可以包含tenantId businessLine dataset sqlFingerprint taskId attemptId engine cluster cpuCost memoryCost storageCost networkCost totalCost isRetry status这样可以回答哪个租户成本最高 哪个业务线增长最快 哪类 SQL 最耗资源 哪个引擎执行成本最低 哪些查询经常因为错误路由产生重试第六成本如何反哺路由成本归因不是为了做报表而是要反过来影响路由决策。例如同一个 SQL 指纹Trino 执行 10 秒 成本 0.8 元 SLA 命中率 95% Spark 执行 60 秒 成本 2.5 元 SLA 命中率 98%如果用户要求 10 秒返回系统可以优先选择 Trino。如果查询范围扩大后Trino 成本 8 元 经常内存不足 Spark 成本 3 元 执行稳定这时虽然 Trino 是交互式引擎但它已经不是更优选择路由层应该切换到 Spark。因此路由评分可以加入成本因素routeScore 性能得分 SLA 得分 稳定性得分 - 资源成本 - 排队成本同时需要设置成本预算单次查询成本上限 租户每日成本上限 业务线月度预算 超预算后的降级策略如何证明成本归因有效我会通过以下指标验证成本归因完整率 成本归因准确率 租户成本可见率 单位查询成本 重复查询节省成本 失败重试成本 查询结果复用率 SLA 成本例如结果复用率提高 重复扫描次数下降 单位查询成本下降 错误路由导致的重试成本下降这些指标可以证明成本归因不仅能解释“钱花在哪里”还推动了查询性能和引擎复用率的优化。其他成本归因的思路成本归因的关键是通过任务 ID 把业务上下文和外部引擎的资源消耗关联起来。任务创建时记录租户、业务线、数据集和 SQL 指纹每次执行生成独立的 AttemptLinkis 提交 Spark 或 Trino 后再把外部 applicationId 和 attemptId 关联起来。外部引擎只提供某个 applicationId 消耗了多少 CPU、内存和存储平台再通过 applicationId - attemptId - taskId 向上找到租户和业务线最终生成 costRecord。如果一个任务因为路由错误执行了两次就把两个 Attempt 的成本相加作为 Task 总成本同时单独统计失败重试成本。这样就能回答哪个租户、业务线、数据集和 SQL 指纹成本最高也能识别错误路由造成了多少资源浪费。 
长河君 · 2026/11/3 2:17:45 · 阅读 1.2k 【自助查询】建设查询成本归因
总述基于requestId、taskId、attemptId、applicationId建立全链路成本归因链路把租户、用户、业务线、数据集和 SQL 指纹与实际 CPU、内存、存储、网络等资源消耗关联起来。不同情况不同计算不同引擎的资源指标通过 EngineConn 适配层统一再按照企业资源单价计算任务成本。对于重试任务我会区分 Task 总成本、每次 Attempt 成本和失败重试成本对于共享集群则按实际资源使用量进行分摊。最终将成本、SLA、执行耗时和成功率反哺路由层让平台在满足 SLA 的前提下优先选择成本更低、复用率更高的执行环境。论述成本归因要解决的问题是查询执行消耗了多少计算资源这些资源应该归属到哪个租户、用户、业务线、数据集和 SQL 上能够进一步判断哪些查询成本过高、哪些引擎或集群更划算。我会把成本归因建立在全链路任务标识之上而不是只根据最终结果或集群总账单估算。整体归因分析链路是查询请求 - Task - ExecutionAttempt - RouteDecision - EngineConn - 外部 Application - 资源指标 - 成本计算 - 业务归因第一建立归因维度提交请求时统一入口需要补齐归因上下文tenantId userId businessLine application dataset sqlFingerprint taskId attemptId routeDecisionId engine cluster queue其中tenantId成本归属哪个租户 businessLine / application成本归属哪个业务线或应用 dataset成本由哪些数据集产生 sqlFingerprint哪类 SQL 消耗成本最高 taskId / attemptId哪一次任务、哪一次执行尝试产生了成本这些信息要一路透传到 Linkis、EngineConn 和外部计算引擎最后通过applicationId和资源监控系统关联起来。第二采集真实资源消耗对于一次查询不能只记录执行时长还要采集实际资源queueTime executeTime cpuTime memoryUsage executorCores executorMemory executorCount scanBytes shuffleBytes diskBytes例如 Spark 任务需要采集applicationId vcoreSeconds memorySeconds executor 数量 Executor 运行时长 Shuffle 数据量Trino 或 JDBC 可能没有完全相同的指标因此需要在引擎适配层统一成平台模型cpuCost memoryCost storageCost networkCost engineCost这样上层不需要感知 Spark、Trino 和 JDBC 指标的差异。第三建立成本计算模型成本不一定直接等于执行时间应该根据企业实际资源单价计算。例如计算成本 CPU 使用量 × CPU 单价 内存使用量 × 内存单价 存储成本 网络成本 引擎或集群附加成本Spark 可以按vcoreSeconds memorySeconds计算。Trino 可以按CPU 时间 内存使用时间 查询执行时间计算。如果企业暂时没有精确的云账单也可以先建立内部成本模型CPU0.01 元 / core-minute 内存0.005 元 / GB-minute 存储0.02 元 / GB例如一次查询实际消耗CPU40 core-minutes 内存80 GB-minutes那么CPU 成本 40 × 0.01 0.4 元 内存成本 80 × 0.005 0.4 元 总成本 0.8 元重点是先保证归因口径统一后续再替换成云厂商或集群真实计费价格。第四处理重试和共享资源这里要特别区分Task 成本 ExecutionAttempt 成本如果第一次路由到 Trino 失败第二次切换到 SparkTask查询订单金额 Attempt 1Trino消耗 0.2 元失败 Attempt 2Spark消耗 1.5 元成功这次查询的总成本应该是Task 总成本 Attempt 1 成本 Attempt 2 成本 1.7 元但在分析时还要区分业务查询成本1.7 元 失败重试成本0.2 元 有效结果成本1.5 元否则无法判断成本高是因为查询本身复杂还是因为路由错误导致重复执行。对于共享集群也不能把整个集群成本直接归给某个租户而应该按资源使用量进行分摊租户成本 租户实际 CPU / 集群总 CPU × 集群成本 租户实际内存 / 集群总内存 × 集群成本如果无法精确获得资源使用量可以根据队列 Executor 执行时长 CPU 和内存配置进行近似分摊但要明确这是估算成本。第五建立成本归因链路成本归因简单说就是一次查询消耗了多少 CPU、内存和存储资源这笔成本最后算到哪个租户、哪个业务线、哪条 SQL 上。最终要把成本信息和查询链路关联起来requestId - taskId - attemptId - routeDecisionId - engineConnId - applicationId - sqlFingerprint - costRecord成本记录可以包含tenantId businessLine dataset sqlFingerprint taskId attemptId engine cluster cpuCost memoryCost storageCost networkCost totalCost isRetry status这样可以回答哪个租户成本最高 哪个业务线增长最快 哪类 SQL 最耗资源 哪个引擎执行成本最低 哪些查询经常因为错误路由产生重试第六成本如何反哺路由成本归因不是为了做报表而是要反过来影响路由决策。例如同一个 SQL 指纹Trino 执行 10 秒 成本 0.8 元 SLA 命中率 95% Spark 执行 60 秒 成本 2.5 元 SLA 命中率 98%如果用户要求 10 秒返回系统可以优先选择 Trino。如果查询范围扩大后Trino 成本 8 元 经常内存不足 Spark 成本 3 元 执行稳定这时虽然 Trino 是交互式引擎但它已经不是更优选择路由层应该切换到 Spark。因此路由评分可以加入成本因素routeScore 性能得分 SLA 得分 稳定性得分 - 资源成本 - 排队成本同时需要设置成本预算单次查询成本上限 租户每日成本上限 业务线月度预算 超预算后的降级策略如何证明成本归因有效我会通过以下指标验证成本归因完整率 成本归因准确率 租户成本可见率 单位查询成本 重复查询节省成本 失败重试成本 查询结果复用率 SLA 成本例如结果复用率提高 重复扫描次数下降 单位查询成本下降 错误路由导致的重试成本下降这些指标可以证明成本归因不仅能解释“钱花在哪里”还推动了查询性能和引擎复用率的优化。其他成本归因的思路成本归因的关键是通过任务 ID 把业务上下文和外部引擎的资源消耗关联起来。任务创建时记录租户、业务线、数据集和 SQL 指纹每次执行生成独立的 AttemptLinkis 提交 Spark 或 Trino 后再把外部 applicationId 和 attemptId 关联起来。外部引擎只提供某个 applicationId 消耗了多少 CPU、内存和存储平台再通过 applicationId - attemptId - taskId 向上找到租户和业务线最终生成 costRecord。如果一个任务因为路由错误执行了两次就把两个 Attempt 的成本相加作为 Task 总成本同时单独统计失败重试成本。这样就能回答哪个租户、业务线、数据集和 SQL 指纹成本最高也能识别错误路由造成了多少资源浪费。