跳到主要内容

架构定位与目标设计

本文档给出数据中台的总体定位和当前实现目标。

1. 项目定位​

数据中台是平台内部的业务数据底座，不是展示层分析产品。它的核心职责是：

  • 统一接入：接收 Relay/HTTP 事件，或通过 Doris Pull 从清洗后数据源增量拉取。
  • 统一标准化：沉淀为 dc_events_{game_id}_{region} 标准事件事实层。
  • 统一供数：通过 Aggregate、Free Query、SQL Query、Export、Alert Check 等 HTTP API 服务下游。
  • 统一治理：管理元数据、API Key、scope、Consumer Profile、Schema Family、外部数据源凭证、物化状态和补数修复。

当前实例按“一家组织一套部署”设计，组织之间物理隔离；实例内部按 Project、Business、Region、Dataset 和 API Key scope 做访问控制。运行时不再使用 tenant_id 作为数据隔离维度。

2. 当前目标架构​

Source
  ├─ Relay / HTTP Push
  ├─ Doris / DW source
  └─ TLog / historical compatibility input

Runtime
  ├─ Receiver FastAPI
  ├─ Doris Pull standalone worker
  ├─ Export worker
  └─ Airflow DAGs

Storage
  ├─ PostgreSQL + TimescaleDB
  │   ├─ dc_events_* standard event facts
  │   ├─ ga_* aggregate tables
  │   ├─ dc_* metadata and tasks
  │   └─ materialization / checkpoint / reconciliation status
  ├─ Redis
  │   ├─ rate limit and usage counters
  │   ├─ L2 query result cache
  │   └─ external query result cache
  ├─ DW / Doris external sources
  └─ 对象存储 export storage

Serving
  ├─ Aggregate API
  ├─ Free Query API
  ├─ SQL Query API
  ├─ Export API
  └─ Alert Check API

Control Plane
  ├─ Project / Business / Dataset
  ├─ API Key / Consumer Profile
  ├─ Schema Family / TLog Schema
  ├─ External Source credentials
  └─ Cube / Push config management

3. 关键架构决策​

3.1 标准事件层是主事实层​

所有可落地到中心侧的事件，都应进入 dc_events_{game_id}_{region}。下游契约不应依赖 TLog 文件名、TLog 字段顺序、临时验证脚本或本地模拟逻辑。

3.2 Doris Pull 是当前主写入 worker 能力​

Doris Pull 从外部源增量拉取事件，写入 dc_events_*，并维护 checkpoint、dead-letter、事件合约校验和全局 UUID 去重。生产环境中它应作为独立 worker 运行，而不是依赖 Receiver API 进程内嵌启动。

3.3 Receiver 是唯一对外联调入口​

下游联调应调用完整 Receiver 服务：

  • /api/v1/external/aggregate
  • /api/v1/external/free-query
  • /api/v1/external/sql-query
  • /api/v1/external/export
  • /api/v1/external/aggregate/check

本地验证脚本只用于准备数据、修复数据或排障，不代表生产调用链路。

3.4 聚合查询按实现路由​

当前 Aggregate API 的实际路由是：

  • 当日或未最终物化日期：从 dc_events_* 事件表计算实时/近实时值。
  • 历史日期：从 GA TimescaleDB 物化表读取。
  • GA 物化缺口：根据指标能力选择事件回退、不可用原因或 409。
  • Redis：用于 L2 查询结果缓存，不再作为实时 L0 指标源。

3.5 Free Query 和 SQL Query 与生产链路一致​

/free-query 和 /sql-query 不是本地特殊逻辑。它们共享 API Key、scope、Consumer Profile、限流和缓存，并按请求内容走：

  • Unified Query Engine / AggregateEngine 指标分支；
  • GA table executor 分支；
  • DW SparkSQL 原始表分支。

4. 数据分层​

层级当前实现用途
接入层Relay/HTTP、Doris Pull、兼容 TLog 工具接收或拉取上游数据
事实层dc_events_*当日指标、事件回退、明细事实
聚合层ga_*历史指标、固定看板、下游批量取数
状态层ga_materialization_status, dc_ga_coverage, ga_reconciliation_daily, dc_doris_checkpoint, dc_doris_pull_dead_letter物化门禁、覆盖判定、对账和拉取健康
查询缓存层Redis L2 / external result cache降低重复查询成本
元数据层dc_game_config, dc_api_keys, dc_external_source, dc_consumer_profile, dc_schema_family治理、权限、凭证和接口配置

5. 成功标准​

当前阶段的架构成功标准是：

  1. 下游只通过正式 Receiver API 调用，且本地联调与生产数据链路一致。
  2. game_a 等业务的数据可通过 Doris Pull 或正式补数链路进入 dc_events_*。
  3. /aggregate、/free-query、/sql-query 根据同一套元数据、scope 和查询引擎返回一致口径。
  4. GA 物化状态、覆盖状态、dead-letter 和对账结果能解释数据可用性。
  5. 过程脚本和本地模拟只作为运维工具，不成为对外契约。

6. 非目标​

当前项目不负责：

  • 在数据中台内实现完整 BI/分析产品 UI。
  • 为本地联调写独立绕行逻辑。
  • 让下游直接调用脚本或直连临时库表。
  • 在运行时恢复多租户 tenant_id 逻辑隔离。
  • 把未启用的 Redis Event Bus、Redis L0/L1 实时缓存或某内部 CH stub 写成生产主链路。
加载评论中...