基于TiDB使用拉链表存储设备用户数据

2020-04-26  本文已影响0人  一起码

场景

目标

概要方案

概要描述

存储设备、用户的基本信息以及每条记录的生命周期。可以快速查询当天的最新数据以及之前的历史数据

device_id uid uuid ... t_start_time t_end_time
FC:AB:90:C8:11:66 233E77A6-E62D-4BD6-B902-877D95CF38AE ... 2019-01-01 08:21:32 2019-01-01 08:31:32
FC:AB:90:C8:11:66 11111 E206C3CE-0FB7-43AB-AF8C-34A8D51CD011 ... 2019-01-01 08:31:32 9999-12-31 23:59:59
AB:FC:00:A9:22:88 22222 ABCDC3CE-0FB7-43AB-AF8C-34A8D51C1234 ... 2019-01-01 08:51:32 2019-05-31 23:59:59
AB:FC:00:A9:22:88 33333 BCDEC3CE-0FB7-43AB-AF8C-34A8D51C5678 ... 2019-05-31 23:59:59 9999-12-31 23:59:59
CD:EF:11:B1:33:99 22222 BDCBAC3CE-0FB7-43AB-AF8C-34A8D51C1100 ... 2019-05-31 23:59:59 9999-12-31 23:59:59

TiDB+拉链表

  1. TiDB和MySQL高度兼容
  2. 无需考虑分库分表
  3. 集群QPS(万级起)和延迟(毫秒级)
  4. 分布式事务和强一致性并对各种Join的支持
  5. 拉链表避免数据无限扩展

拉链表:针对数据仓库设计中表存储数据的方式而定义的,顾名思义,就是记录历史,记录一个实物从开始,一直到当前状态的所有变化信息
拉链表vs流水表:流水表存放的是所有变更记录,但是拉链表中只有一条记录,拉链表设计需要注意粒度问题,比如按天

落地方案

数据流程

数据获取 -> 数据处理 -> 数据应用,详细数据流转图如下


设备信息存储
  1. 原始数据可通过订阅binlog、订阅事件消息(Kafka、Flink等)或者接口查询等方式进行获取,避免由于原始数据异常或者获取程序异常的问题造成账数据,可将原数据分别落库存储
  2. 将原始事件数据清理及按业务规则处理汇总后落每日数据宽表,避免数据源有误影响,每日数据量频繁变化,小表性能更优
  3. 每日日终生成主表日切表,避免延后发现问题数据进入主表,不易恢复
  4. 每日日终校验当日数据表准确性及完整性,校验通过则汇总进入主表,校验不通过需要通过重试及人工介入等多种方式修复完成后结合日切数据再进入主表,避免主表数据被干扰
  5. 根据主表数据和每日数据表在Flink或Spark中进行运算对外提供查询服务,对于查询量大的场景可以考虑增加缓存

前期最少保留30天原始数据、每日数据和日切数据(可根据实际业务场景及存储容量调整)
所有任务可重新执行,任何异常场景都可较低成本的恢复

高可用

业务高可用

保留原始数据表、每日新增表和日切表

  1. 原始数据异常,通过补偿订阅数据修复,重新执行清洗梳理任务即可,后续流程不受影响
  2. 每日宽表数据异常,作废当日宽表,根据每日原始数据重新执行清洗梳理任务,重新生成当日宽表
  3. 主表数据异常,定位异常开始日期,以异常前一天数据为基准,重新执行数据收集、清洗梳理、校验、汇总等任务重新生成主表数据
  4. 实时监控数据写入和查询日常(显式异常:接口调用失败等和隐式异常:数据数量、比例异常等)
  5. 接口支持幂等、任务可以重新执行

TiDB高可用

  1. 借助TiDB生态
  2. TiDB支持水平扩展(计算能力和存储能力)
  3. TiDB高可用,TiDB、TiKV、PD都允许部分实例失效

最意外场景,TiDB不可用时,

  1. 数据收集可以记入其他存储,如文件、NoSQL等,待TiDB恢复后重新执行流程任务
  2. 数据查询集群不可用时,可将结果数据存入NoSQL等

参考

漫谈数据仓库之拉链表(原理、设计以及在Hive中的实现)
淘宝云梯极限存储
拉链表与极限存储
TiDB 帮助万达网络科技集团实现高性能高质量的实时风控平台
TiDB

上一篇下一篇

猜你喜欢

热点阅读