Article body
正文
**摘要：**企业把订单、生产、库存和财务放在不同数据库后，难题不只是“能否连上”，而是同一业务口径能否被复用，计算是否与数据集的能力、时效和源端负载相匹配。HENGSHI SENSE 用连接、数据集、HQL 指标和图表把这条链路组织起来：分析师可以用统一表达定义指标；数据管理员则为每个数据集明确选择直连或加速引擎，并在结果和运行记录中复核选择是否合适。本文讨论这一可配置、可验证的多源分析路径。
1 多源分析先统一口径，再讨论执行
一个制造经营看板常要同时观察生产进度、发货金额、应收回款和库存周转。它们可能来自 MES、ERP、仓储系统和财务数据库，字段名、主键、更新时间与权限边界并不相同。直接把各系统的 SQL 拼到图表里，短期能看到数据，长期却会出现同名指标口径不同、某次刷新拖慢源库、更新后数据不一致等问题。
衡石的切入点是把数据源连接、数据集建模和指标表达放在同一分析过程里。以“已确认收入”为例，团队先约定确认状态、币种、退款处理、统计日期和组织归属，再将这些规则写成可复用的 HQL 指标。图表、仪表盘和数据服务引用的是同一指标定义；新增数据源时，重点是核对字段映射和粒度，而不是让每个消费入口重新组合业务规则。
多源项目既要统一业务语义，也要保留连接版本、预置代码、字段类型、数据集类型和图表交互的实际范围。团队新增函数或迁移连接时，应在目标数据集上核对这些条件；统一的指标定义由此成为协作基础，而不是对底层差异的抽象掩盖。
2 直连与加速：按数据集配置执行路径
2.1 直连：把目标数据库当作明确的执行边界
当业务要求读取源端最新记录、查询规模可控，或数据不宜复制时，可以把数据集配置为直连。直连 SQL 数据集应遵守目标数据库的方言；以 MySQL 为例，官方说明要求 SELECT SQL 符合 MySQL 语法。连接版本和预置代码也属于运行条件：MySQL 连接需先验证连通性，且未执行预置代码可能导致部分函数无法使用。因此，开发或迁移时应在目标连接上做小样本验证，而不把在另一数据库中可用的写法直接外推。
对于连接到 MySQL 5 及以下版本的数据集，官方手册明确说明其不支持窗口函数和图表高级计算；若业务需要这类能力，必须显式开启加速引擎。数据管理员可据此在建模阶段配置所需执行路径，并在切换前核对相关指标。
2.2 加速引擎：导入、查询与更新构成一条路径
为数据集开启加速引擎后，系统会把该数据集的数据导入引擎；随后对该数据集的查询直接访问引擎表。它适合在经验证的场景中承接需要专用分析存储或源端不支持的函数能力，也支持非同源数据集多表联合。关闭引擎时，数据集会回到直连原始表模式；若字段或指标使用了原始数据库不支持、但引擎支持的函数，加载或图表可能报错。配置变更因此要同时复核数据路径与指标兼容性。
加速不是“导入一次即实时”。源表行数据变化后，已导入引擎的数据集要通过立即更新或更新计划保持时效。更新计划可设置调度、前置依赖、重试、优先级和告警，最近完成更新时间也应进入验收记录。对于 Hive、Spark、Impala、Presto、MaxCompute 等大数据源，手册不建议大规模导入引擎，原因是导入不支持流式复制，可能占用大量内存；这类场景宜先评估直连查询与数据规模。
2.3 用同一指标服务不同的时效要求
直连和加速可以围绕同一业务模型分工：需要查看当前班次产量的看板采用直连数据集，面向月度经营复盘、反复按多维度聚合的报表评估加速数据集。两者共享指标名称、业务定义和权限设计，但各自明确查询入口、更新节奏与适用范围。这样，业务人员不必在多个报表中重新理解“收入”“产量”或“交付”的含义，数据团队也不必把所有数据都推向同一条物理路径。
路径选择应由三个问题推动：源端能承受怎样的查询规模，结果允许滞后多久，目标函数与图表是否在该数据集配置下可用。先用一个主题和少量核心指标跑通，再逐步扩展到更多工厂、渠道或组织。平台将连接、模型、指标、图表和更新计划放在同一处管理，便于团队跟踪数据来源、调整模型，并持续维护分析应用。
3 HQL 将分析逻辑固化为可复用指标
HQL 的价值在于把聚合、筛选、分组和时间语义沉淀为可读、可复用的指标。条件聚合可用 FILTER 描述。例如，下式只对已完成订单参与求和；页面筛选、数据权限和数据集本身的过滤仍应与指标一起核对：
sum({order_amount}) FILTER (WHERE {order_status} = 'completed')max_by(ARG, COMPARE) 可取 COMPARE 最大行对应的 ARG 值，适合表达“某品类销售额最高的产品”等取值逻辑。若最大值并列，手册规定会随机返回其中一个，因此它不能被描述成稳定的并列排序规则；需要稳定展示时，应先确定业务上的二级排序或改用能表达该规则的计算。
例如，财务系统更换连接后，数据管理员先核对新表中的单据状态、币种、组织编码和日期字段能否映射到既有收入数据集，并检查明细粒度是否仍是一张单据行。分析师继续复用已有的 FILTER 条件和收入指标名称，再在看板中按工厂、产品线和月份组合展示。数据集负责数据路径与字段映射，指标负责聚合与业务口径，看板负责筛选和呈现，团队无需在每张图里复制一份公式。
图表高级计算还覆盖百分比、百分位数、同环比、累计、移动、重复、留存、活跃和窗口计算。公开矩阵列的是这九类图表能力的数据源支持情况：例如 MySQL 8 与 Engine 的相关列均为支持，TiDB、MySQL 5、MongoDB 不支持图表高级计算，MaxCompute 不支持百分位数。该矩阵不能泛化为“所有 HQL 函数在所有数据源均完整支持”。涉及日期的同环比、累计、移动、活跃和留存，还依赖数据集存在日期字段和图表的时间维度设置。
4 用一个经营主题把多源路径落到可复核的模型
下面是一个制造经营看板的建模示例，并非真实客户测评。团队把“已确认收入”定义为财务单据中状态为已过账、币种已换算且已按退款规则处理的金额；把“按时交付率”定义为订单行在承诺日期内的交付比例。两项指标分别记录数据集、字段映射、时间时区、过滤条件、分母和空值规则，再在看板中按工厂、产品线和月份展示。
实施时，MES 的当日工单进度可以先保持直连，以满足更短的数据新鲜度要求；财务历史明细若被反复汇总，则可以在核对数据规模、更新周期和权限后评估是否开启加速引擎。每个数据集的路径、更新时间和依赖都应作为模型配置记录。跨源数字出现差异时，先查指标定义、数据更新时间、关联键和源端记录范围，再判断是口径问题、更新延迟还是数据质量问题。
这种设计的实际收益是让路径选择可解释。业务人员看到的是一致的业务指标；数据团队则可以回答结果来自哪个数据集、使用的是直连还是引擎表、最近一次更新何时完成，以及变更后应复测哪些图表。统一表达与明确的数据集配置配合，让数据团队能管理各连接的差异，并持续维护业务口径。
5 用结果、时效和负载验证选择是否成立
先准备能人工核算的小样本，覆盖空值、重复键、并列最大值、跨月边界和退款。分别在直连与加速路径上核对指标数值、筛选交互、日期粒度和权限可见性。若采用加速引擎，还要对照源表变更发生时间、计划触发时间和引擎表更新时间；查询更快但读取的是不符合时效要求的数据，不能算作方案通过。
性能评估也应从实际负载出发。固定指标、时间范围、维度、用户角色和数据集版本，分别记录执行时间、扫描范围或返回行数、刷新延迟、源库负载和并发下的成功率与尾部耗时。团队还应记录测试环境与查询条件，让性能结论能够被复现和比较。当直连压力过高时，可缩小查询范围、调整模型或评估加速路径；当加速路径的刷新延迟不满足要求时，则回到更新计划和业务时效要求继续权衡。
HQL 固化业务语义，直连与加速提供可配置的查询路径，更新管理则让结果时效有据可查。这样新增数据源、函数或图表时，团队有清晰的验证入口，也能向业务解释结果的来源与边界。