为什么需要动态数据源

在数据中台场景里，指标需求变化快、口径多样且时效要求高。以视频反应记录域为例，“观看数量”等指标既可能用于实时大屏，也可能用于临时专题或回溯分析。如果完全依赖“视频反应记录库”的微服务 API，对每个新指标都要联动源域开发、排期、发布，中台的交付效率和灵活性会被显著限制。

项目中的 dock-data-center-agility-data-source-framework 提供“动态数据源”能力：中台可按租户/环境在运行时直连指定数据库，通过配置化 SQL 拉取并聚合指标数据。例如，按天统计观看次数可直接通过如下 SQL 完成，而无需等待源服务新增 API：

SELECT
  video_type_id,
  video_id,
  DATE_FORMAT(enter_watch_time,'%Y%m%d') AS count_time,
  COUNT(id) AS watch_count
FROM d_video_react
WHERE video_id IN (:video_ids)
  AND video_type_id = :video_type_id
  AND enter_watch_time >= :start_time
  AND enter_watch_time <= :end_time
GROUP BY video_type_id, video_id, DATE_FORMAT(enter_watch_time,'%Y%m%d');

两种获取方式的核心差异

• API 调用（经源域微服务）
  • 优点：领域封装好、复用强、可做复杂业务校验与缓存。
  • 局限：上新慢（需开发/发布）、字段固定、易受服务故障和限流影响。
• 动态数据源（中台直连 DB）
  • 优点：配置即用、实时性强、可快速组合维度/口径、减少跨团队协作成本。
  • 局限：需配套完备的安全与治理；不宜承载复杂业务规则。

为什么数据中台需要动态数据源

• 交付敏捷：新口径/新维度“配置即上线”，避免跨团队排期，满足临时分析、运营突发与试验性指标。
• 实时与性能：把聚合下推到数据库，减少网络跳数与数据搬运；对大表扫描/聚合更友好，易达成分钟级乃至秒级更新。
• 解耦与稳定：源服务发布、限流或故障不阻断中台出数；必要时可“API ↔ 直连”双活切换做容灾。
• 成本可控：减少需求沟通与联调成本；避免为“长尾指标”频繁改造上游服务。
• 多租户/多环境灵活：运行时选择不同库/只读实例/地域节点，天然支持隔离与差异化治理。
• 一致性与口径沉淀：在中台统一管理指标 SQL 模板与参数，避免多处实现导致口径漂移。
• 数据核对与回溯：直连库便于对账、追根溯源、历史补数与再加工。

典型适用场景

• 临时/突发指标：活动专题、运营灵感验证、A/B 快速对比。
• 实时看板：对延迟敏感、追求近实时的监控与观测。
• 历史回溯与补数：大批量、长时间窗聚合。
• 跨环境/跨地域读取：按需切换到只读副本或就近实例减压。

与 API 的互补关系（何时用、何时不用）

• 优先用 API：对外复用广、稳定高 QPS、需要严格业务规则和统一权限的指标。
• 优先用动态数据源：临时/探索性指标、强实时聚合、快速试错、历史回溯、长尾需求。
• 混合策略：读走直连（快、灵活），写回或复杂规则经 API（稳、可控）。

必要的治理与安全建议

• 最小权限与只读账号：库级/表级/列级权限隔离，敏感列脱敏。
• 参数化与模板化：禁止拼接 SQL；使用白名单字段与可控变量。
• 资源与熔断：连接池隔离、超时/重试/限流、慢 SQL 审计与告警。
• 流量与副本: 优先读只读节点/从库，避免冲击主库与线上交易。
• 缓存与物化：对热点指标结合缓存或物化视图，稳态提速。
• 可观测性：埋点请求链路、记录入参与扫描行数，支持故障回溯与优化。

结语

• 动态数据源让数据中台“快而稳”：快速响应指标变化、提升实时性与可用性，显著降低跨团队协作成本。
• API 与直连并非二选一：两者互补，分别服务“业务封装与复用”与“数据聚合与敏捷探索”，共同构成高效、可靠的数据服务底座。