03d | 数据架构与飞轮设计

内部机密 | 返回 技术壁垒与产品化路线 | 返回 报告目录

目录

• 1. 数据分层架构
• 2. 时序数据建模
• 3. 向量数据库设计
• 4. 数据飞轮机制
• 5. 数据质量管理
• 6. 隐私与合规
• 7. 数据迁移与备份

1. 数据分层架构

1.1 四层数据架构总览

GEO平台采用经典的四层数据架构，确保数据从采集到服务的全链路可控：

1.2 各层存储技术选型

1.3 数据流转全景

2. 时序数据建模

2.1 核心时序数据模型

GEO监测数据天然是时序数据——品牌在每个时间点、每个平台、每个Prompt下的表现构成时间序列。

主表: brand_visibility_metrics

-- TimescaleDB hypertable
CREATE TABLE brand_visibility_metrics (
    time            TIMESTAMPTZ      NOT NULL,
    tenant_id       UUID             NOT NULL,
    brand_id        UUID             NOT NULL,
    platform        VARCHAR(32)      NOT NULL,  -- deepseek/chatgpt/...
    prompt_id       UUID             NOT NULL,
    language        VARCHAR(8)       NOT NULL,  -- zh/ja/ko/en
    -- 核心指标
    is_mentioned    BOOLEAN,
    mention_rank    SMALLINT,                   -- 推荐排位(1=最佳)
    sentiment_score FLOAT,                      -- -1.0 ~ 1.0
    accuracy_score  FLOAT,                      -- 0.0 ~ 1.0
    visibility_score FLOAT,                     -- 0 ~ 100 综合得分
    -- 详情
    response_text_hash VARCHAR(64),             -- 原文哈希(去重用)
    competitor_brands  JSONB,                   -- 同回答竞品
    source_citations   JSONB,                   -- AI引用的信源
    raw_response_ref   VARCHAR(256)             -- 原始回答S3路径
);
 
SELECT create_hypertable('brand_visibility_metrics', 'time');

2.2 分区策略

采用 时间+租户 双维度分区：时间维度按天自动创建chunk，空间维度按tenant_id哈希分区（8分区）。索引策略：主索引(time, tenant_id, brand_id)，辅助索引覆盖platform和language维度。

TimescaleDB配置要点：

2.3 数据保留策略 (Hot/Warm/Cold)

2.4 聚合表设计

为Dashboard和报告提供预计算的聚合数据，避免实时聚合热数据：

3. 向量数据库设计

3.1 向量数据应用场景

3.2 Pgvector方案设计

选择Pgvector而非独立向量数据库（如Milvus），原因：运维简化（与PostgreSQL共用实例）、事务支持（向量与业务数据同事务更新）、规模适合（初期百万级向量）、成本优势。

向量表核心设计：brand_description_vectors表包含brand_id、platform、language、embedding(vector(1024))、captured_at等字段，使用HNSW索引（m=16, ef_construction=64）实现高效余弦距离检索。

3.3 向量检索典型查询

4. 数据飞轮机制

4.1 飞轮核心逻辑

数据飞轮是GEO平台最重要的长期壁垒。随着客户增多和数据积累，平台的优化效果持续提升，形成正向循环：

4.2 飞轮各环节数据资产

4.3 飞轮启动策略

飞轮冷启动是最困难的阶段。启动策略：

4.4 跨客户数据价值

在保护数据隐私的前提下，跨客户的聚合数据产生额外价值：

5. 数据质量管理

5.1 数据校验规则

数据校验分为三个阶段：

• 摄入校验：JSON schema验证、必填字段完整性、UTF-8编码检查、业务规则校验（sentiment_score范围、platform枚举、brand_id存在性）、response_text_hash去重
• 加工校验：NER实体数量合理性、品牌名注册中心匹配、情感极端值检测、历史趋势偏差检测、NER与情感结果交叉验证
• 异常告警：数据缺失告警（连续N小时无数据）、指标突变告警（Z-score > 3）、校验失败率超阈值告警

5.2 异常检测策略

5.3 数据血缘追踪

每条分析数据可追溯到原始数据来源：原始AI回答(raw_response_id) → NER提取结果(含模型版本) → 情感分析结果 → 可见性评分(含计算公式版本) → 客户报告。所有中间结果记录处理时间戳和模型版本，支持问题排查和审计回溯。

6. 隐私与合规

6.1 多租户数据隔离

四层隔离方案：

6.2 加密方案

6.3 多法域合规要求

6.4 数据删除与导出机制

数据删除（Right to Erasure）：客户发起删除请求 → 系统扫描所有数据层 → 软删除(30天缓冲) → 硬删除(关系数据+时序分区+向量+S3归档) → 生成删除证明报告。

数据导出（Data Portability）：支持JSON完整导出(< 4h)、CSV摘要导出(< 30min)、PDF报告合集导出(< 1h)。

7. 数据迁移与备份

7.1 备份策略

7.2 灾备方案

7.3 双云数据同步

GEO平台需要同时服务中国和海外客户，采用双云架构：

7.4 同步数据分类与迁移方案

针对未来云厂商迁移，预留Debezium CDC + Kafka跨云迁移能力，同云迁移使用DTS服务（< 8h / 10TB），跨云迁移（< 24h / 10TB），均仅在最终切换时需短暂停机（< 10min）。

返回 技术壁垒与产品化路线 | 返回 报告目录