数据归档那些事儿

所谓数据归档就是把部分 低频访问的历史数据 从线上库迁移到归档库的过程。在设计数据归档方案的时候通常需要思考三个问题

• 归档前：如何进行存储选型
• 归档中：如何保证迁移准确
• 归档后：如何处理数据完整性破坏所引起的问题

下面也着重从这三部分来沉淀一下

二、存储选型

存储选型是归档前要做的最重要的一件事情，目前市面上的存储方式多如牛毛，如何选择能够支撑当前业务环境的存储选型，就非常重要！

2.1 归档的数据特点

既然是用做数据归档，首先来需要梳理下归档数据的特点

• 读性能：没啥要求，归档数据了，能够读出来就可以
• 写性能：尽可能好的批量写入性能，能够1w+即可
• 压缩比：尽可能的节省空间，采用高压缩比的存储引擎
• 分布式：考虑到数据量超过单盘，最好能够分布式
• 数据量级：上限尽可能高，考虑到实际情况，10TB+基本
• 一致性保证：归档是兜底，尽可能高的保证数据不会出现异常丢失

2.2 通用选型因素

除了考虑归档数据的特点，还要考虑一些通用因素，例如

• 公司是否运维支持：大厂这个因素很重要，如果运维支持背书，是个非常重要的因素！
• 开源活跃程度：活跃度太低不能选
• 普遍使用场景：跳出存储给的通用场景的不能选

2.3 备选存储的特性

也初步总结总结和梳理了下可能用到的集中存储的特性

结合归档数据的特点和不同存储的优势，最终选用了

• rocksDB：压缩比不错，最主要是公司DBA愿意支持，存储归档数据
• es：作为在线查询，公司运维支持)
• HIVE：作为财务数仓核心数据和全量数据中心，哈哈，为下一篇财务数据中台做铺垫^_^
• fusion：幂等健破坏后的幂等健KV池

三、一致性保证

归档过程存在会删除线上数据，是个非常高危的操作 ，所以操作过程中和操作之后都需要特别注意数据一致性的保证。

对于操作过程的一致性保证相对简单，过程通常两步

step1 插入确认：查询线上库->插入归档库->查询归档库->确认插入

step2 删除确认：删除线上库->查询线上库->确认删除

注意：过程中尽可能的保证读取和写入的时间，删除会锁库，大批量读会抢网络和IO，防止对线上业务造成压力，尽可能调优批量数据，推荐条目在200-1000条一次，数据量在5M-100M一次

四、归档后问题

数据归档后，必然破坏了数据的完整性 ，会造成下面几个问题,，需要提前考虑

4.1 读数据穿透问题

低频历史数据归档后，造成线上数据缺失，查询数据穿透和范围关系查询损失都会存在。因此，数据归档后，对于读操作有两种处理方式

• 归档数据不读：最简单，但是对于某些场景可能确实不太合适。
• 读proxy兼容：通过读proxy，穿透性的选择各种存储截止。

针对读数据，还有一种比较特殊的情况，就是跨区间范围关系聚合，这样就 需要有一份完整数据 来满足极端需求，目前财务系统对于这类需求统一走离线财务数仓来解决！

4.2 写幂等破坏问题

对于写数据最大的问题就是幂等健被破坏， 归档了数据后，rds写入唯一健破坏，在极端情况下，可能会造成duplicate 。考虑到问题的出现概率和实现成本，初期可以忽略，采用人工干预的方式，归档最终要写入全量，写不进去就是duplicate了；后面可以采用前置幂等健组来挡，做到最终一致！

4.3 数据一致性问题

无论是数仓数据还是归档数据，作为财务数据，一旦提供资金服务，那么就必须保证强一致性，财务目前采用离线分天统计数据的金额和数量，来保证宏观上的一致性。这里面也有需要小坑，例如数据飘移，时间gap等，关于财务数仓中遇到的坑和解决方案，后续专项讨论

五、最终归档方案

分析了归档前选型，归档中数据转移，归档后数据完整性问题，初步的归档方案如下图

简单梳理下核心流程

• 写数据流：写数据写入online rds[备注：目前没有前置幂等拦截，后面择机完善]，写入后通过binlog准实时写入es，提供线上读服务；通过binlog小时级入hive，作为分析数据和全量数据存储；通过天级归档脚本，将历史数据导入rocksdb归档。同时，如果有日切，也会天级进行数据日切和新表创建。

• 读数据流：读数据过proxy，非归档期间数据直接读取es，归档数据和es没有的数据都会穿透到rocksdb。

• 监控流：天级监控hive，es，rocksdb，三个不同来源的数据条目和总金额，保证一致性。

六、总结和不足

本篇主要总结了数据归档过程中的选型经验，处理经验和初步的数据流建设。

通过数据归档，更清楚的划定了不同存储介质的功能边界，是进行数据中台赋能业务的前置准备！但是过程中也有些不足，例如没有通过数据归档抽象出一些数据通道的工具，没有抓住机会深入了解下存储介质的等！