大范围的数据采集可能会遇到的问题

• 数据类别多
• 设计平台组件多
• 采集周期长，接入新的数据类型周期长，需要经过需求评审、开发、测试、联调、数据核对、上线。
• 接入效率低，采集稳定性：接入每种数据类型需要和业务方对接，效率不高，采集过程出现异常中断，不能及时感知到

明确采集哪些数据

• 定义采集对象：
  • 包括逻辑名及主要采集字段

数据提取方案

整体方案

• 从现有源头系统(或组件)的表直接获取
• 从现有源头系统(或组件)的API服务中直接获取
• 让采集源头系统(或组件)进行推送，一般适合于自研系统
• 解析源头系统(或组件)的配置文件获取关系数据

具体采集源头的数据获取思路

• 例如：通过JDBC的方式访问核心业务表A数据
• 例如：通过API的方式访问核心业务表B数据

已知采集方案优缺点对比

• 不同方案的优点和缺点
• 对比维度包括：侵入性、接入速度、耦合性、数据实效性
• 给出推荐方案

自研数据上报方案

• 展示数据流图
• 客户端设计说明
  • 如何支持数据质量检测通用规则
  • 如何支持已定义的通用数据模型打包
• 服务端设计说明
  • 鉴权机制
  • 数据入库服务
  • 大量数据下数据限流机制
• 数据模型介绍
  • 采集入库的模型及关系
• 数据安全性介绍
  • 如何确保数据不是伪造的？
  • 签名机制
• 采集模式介绍
  • 增量采集模式
  • 全量采集模式
  • 定期采集模式
  • 实施采集模式
• 数据存储机制
  • 根据实际数据量，进行数据库选型
  • 从使用者角度，设计数据宽表
  • 核心数据表说明
• 数据更新模式说明
  • 支持同步更新，确保实时性
  • 支持全量跟新，确保数据完整性
• 数据生命周期
  • 采集源头下线机制

系统监控

数据等级

• 不同采集源系统对应不同的数据等级
• 不同等级的数据，发生问题时走不同的告警方式

告警

• 告警信息模板定义
• 紧急通知渠道定义，例如电话或者短信

日常通报

• 没有问题也发发送日报给干系人

系统自监控

• 容易产生性能问题的核心组件，利用第三方系统进行自监控及预警机制
  • 例如数据阻塞

数据质量对比

• 一般都是事后对比
• 定期执行数据质量规则定义，并预警异常
• 数据采集趋势对比：当日vs 7日内平均值