数据归档那些事儿

在热点账户问题和常用解决方案【中】这篇文章中提到，解决热点读性能的一个非常通用方式是数据归档。本篇小拽总结下在操作数据归档过程中遇到的一些问题和经验！

一、数据归档

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

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

下面也着重从这三部分来聊聊

二、存储选型

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

2.1 归档的数据特点

既然是要选型数据归档的存储，首先来需要梳理下归档数据的特点

读性能：归档数据对读性能没啥要求，能够读出来就可以
写性能：尽可能好的批量写入性能，能够批量1w+达标
压缩比：尽可能的节省空间，采用高压缩比的存储引擎
分布式：最好能够分布式，考虑到目前单片都40T了，非分也可
数据量级：上限尽可能高，考虑到实际情况，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，三个不同来源的数据条目和总金额，保证一致性。

六、总结和不足

本篇主要总结了小拽在数据归档过程中，如何选型，如何归档以及在归档数据后引起的问题如何处理。

通过数据归档，更清楚的划定了不同存储介质的功能边界，是进行数据中台搭建，赋能业务的前置准备！

【转载请注明：数据归档那些事儿 | 靠谱崔小拽】