§1 通用思绪
数据归档就是把一坨数据挪走，换一个地方存放，然后把原来的数据干掉
数据移走后，不能影响现有业务的使用，需要继承保留被更新的能力（不存在完全冷掉的数据）
干掉原数据时要避免影响正常业务，主要是避免引起波动
但需要留意：数据归档不应该作为解决问题的首选方案
§2 快速归档
每次归档前，应该优先思量可否快速归档
- ==快速归档条件下，只需要思量把那些表中哪些数据截转走，然后清理原数据即可 ==
- 不需要思量全部使用场景和极端特殊环境，不是从0开始不思量，而是早就处理完了
- 不需要思量归档后数据再遇到更新诉求时的主动更新，不是直接不思量，而是已经具备了
- 首次归档时，只管创建快速归档能力（归档这个事不可能是一次性的，但不可强求）
快速归档几乎 不可能是首次归档时的首选方案，具有如下前提
- 截转数据不影响现有功能
- 不会出现<必须使用归档数据>的业务，即使有也已经支持了
- 全量数据已生存多份（好比es）且充分在各个查询业务中承担职责（数据切走后，逻辑不会崩）
- 归档数据极少修改诉求，极少是指可以轻松通过工单或运维功能完成归档数据更改的量，其他场景现有业务已经支持
- 归档环境健全
- 最好归档数据历史上归档过，直接复用归档过程中的数据处理方式（原样存、合并、计算等）
- 可以复用上次的归档工具、验证方法
当前归档不满意快速归档的前提条件时，需要按下面完整流程评估准备工作
通常，准备工作涉及业务实现方式的调整，需要较长时间，这个步调定义为 业务场景覆盖
直接的说就是决定业务数据会归档到那边去，以及如何与原数据的兼容
§3 归档团体流程（完整归档 & 快速归档）
数据归档实行流程如下，<快速归档>主要节流了<准备阶段>需要花费的精力：
完整归档流程
快速归档
§4 准备阶段
§4.1 确认归档表
完整确认归档表实践参考 【方案实践】数据归档-order
需要思量归档的依据：
- 以解决慢处理为目标
- 优先处理慢查询本身，然后思量低成本变动业务实现方式，假如可以实现就不优先思量以归档为首选方式
- 已经优化，但结果不抱负，或达不到压测、性能指标的
- 可以优化，但从数据增长趋势思量，短期内依然有性能伤害的
- 无所谓优化，数据量达到非常伤害的程度的
- 以清理磁盘为目标
- 优先思量扩容
- 优先思量归档非业务主数据，然后思量归档占数据量多的
磁盘占用与数据量方面，可以参考下面 sql，查询结果实比方下
留意：磁盘占用 = size + idxsize
- select
- table_name,
- table_comment,
- table_rows,
- CEILING(data_length / 1024 / 1024) size,
- CEILING(index_length / 1024 / 1024) idxsize
- from
- information_schema.TABLES
- where
- TABLE_SCHEMA = 'order'
- order by
- size | table_rows desc
§4.2 思绪：确认归档数据范围 & 归档方案待选（重点）
开端确定归档表后，需要按下面逻辑顺序评估归档数据范围
快速归档主要省略这里需要花费的精力
明白本次归档主要目标
- 清理磁盘空间：优先归档几乎没用但占地方的数据，日志、操作记载
- 解决慢 sql、慢业务：优先解决目标涉及的数据，须要时可以归档临近终态的数据
- 闲着没事优化、重构、项目优化等
完整的梳理业务场景
- 哪些项目、公共组件使用了归档表
- 使用场景分别是什么
- 简朴查询
- 关联查询
- 统计查询
- 分页
- 更新：数据还不能视为终态，但终态数据本身几乎就是伪命题
- 数仓抽数
- 定时任务爬表
明白各个场景出现频次
- 频繁逻辑：有些场景下，归档前需要做业务逻辑的调整，逻辑出现频繁可能导致这里成本变高
- 频繁调用：明显加剧慢业务影响，好比一个 10 秒慢 sql，每小时一次调用可以接受，一分钟一次就不行了
明白各数据性质
- 业务主数据：即流程性数据
- 轨迹数据：即周期性数据 + 临时性数据，都可以表现业务主数据的变迁轨迹
- 周期性数据存在时：虽然不保举，但对应的临时性数据可以忽略，即不归档直接清理
- 仅临时性数据存在时：若数据可以表现业务主数据变迁轨迹，则升格视同周期性数据，否则虽然大多数场景下不保举，但是可以删
整理可用归档目标地
- 同库同构表
- 异库表
- es
- monogo
- prometheus/prms
- 数仓
- oss
梳理可用的归档行为
- 全量归档：独立归档，全部字段基本原样归档，常见于业务主数据
- 关键信息归档：独立归档，舍弃时效性极强的字段，将关键信息归档，常见于轨迹数据
- 关联覆盖归档：独立归档，多个表间关联，但都需要归档，且归档存储介质、归档目标地可以雷同，则将多表按统一的业务逻辑关联关系归档。统一业务逻辑关联关系通常是一个统一的时间。虽然通常可以实现最小业务修改，但始终不保举
- 宽表归档（数据横向合并）：不独立归档，多少维度数据团结归档，多见于带有管理端花样查询、统计查询场景的数据
- 归并归档（数据纵向合并）：不独立归档，但做多条合并，常见于轨迹数据归档，要求查询场景很有限且要求不高
- 深度加工归档：不独立归档，涉及字段值的映射、计算、合并、统计，场景特殊，只管避免
上述归档行为均有各自得当的场景，但存储条件允许的前提下，能不删减信息就不删减信息，能不改变数据布局就不改变数据布局
归档数据划分与思绪引导
使用方式
- 以 慢处理 为主要目标时
- 应优先思量解决慢处理本身，慢处理是因数据量过多导致而不能优化时，才思量归档
- 普遍慢的话另行别论，解决慢处理得到成果可能比归档代价还大
- 例：A数据的简朴查询慢，可以优化吗，假如不能我应该从哪些角度思量归档
- 单纯以 清理磁盘 为目标时
- 优先清理已过失效性的轨迹数据
- 准备归档的数据分别遇到下面场景时，分别需要留意什么，综合起来要怎么归档
归档数据范围的划分，按时间范围截断，通常原库中保留 2/3/6 个月数据，其余归档走。
详细时间需要综合思量数据量和归档目标
- 解决慢处理时
- 统计各个级别保留和迁移走的数据量，count 不可用时可以使用 id 估算
- 预估一下最多保留多少数据时，可以达到解决慢处理的目标，保留数据可以参考下表
- 实验迁移较少数据，验证迁移结果，假如结果不抱负，可以思量二段迁移
- 归档对于业务影响不大时，可以一次稍微多迁移一些，但务必包管业务正常
简朴场景复杂场景业务主数据千万级数据不影响使用，以实测为准需要参考历史数据估算结果轨迹数据亿级数据不影响使用，以实测为准可以在归档后验证，如有须要进行二次归档 例：库中保留 6/3/2 个月数据时，依次剩余 5000w、3000w、2000w 数据，预计 4000w 数据量时慢处理可以改善。可以先迁移6个月前的数据并验证，假如不敷抱负再次迁移3个月数据观察结果。
- 清理磁盘时
- 统计各个级别保留和迁移走的数据量，可以使用 count 或用 (id 范围/步长) 估算
- 预估迁移数据大小 = 预计迁移数据量 * information_schema.TABLES.AVG_ROW_LENGTH
- 由磁盘占用比较突出的几个表凑够希望腾退的磁盘空间即可
§4.3 归档方式选择 & 业务场景覆盖
业务场景覆盖时应该思量
- 完全覆盖业务场景
- 只管少业务兼容性调整
- 只管少数据布局变化
- 在精力允许的环境下，只管思量扩展性（只要项目开始归档，就肯定不是一锤子交易）
业务场景覆盖时常用方案
- 全量切换数据源
- 完全切换新的数据源读数据，用于数据全量备份的场景，好比全量存了 es
- 双读
- aop 方式：先本地读，查无数据后归档读
- 接口路由：提供两个读实现，一个读原始库，一个读归档库，可以按肯定路由策略主动路由（需要业务场景支持）
- 降级：归档读作为本地读的降级方案（反过来可以作为业务场景覆盖阶段的测试手段）
- 双写
- aop方式：本地写，同时归档写
- 异步：同步本地写，扔异步归档写的消息等
- 监听binlog：同时保留归档单表与宽表
- 数据存在校验：可以直接区分出不存在的数据，存在的作为本地写，不存在可以详细问题详细分析
- 直接在业务场景上区分
- 在操作端直接区分现数据查询和归档数据查询，好比查询历史数据复选框
- 业务实现方式变动
- 多表关联 -> 单表多次查询
- 分页 -> 取消不须要的分页（好比轨迹数据，前端分页即可）
- 业务上实现方式的调整，同步->异步、扫全表->爬表、大驱动表->小驱动表、主动查询->被动消耗、全数据查抄->有效数据提取
业务场景覆盖阶段的衍生需求以及验证
- 可读性验证：新的读方式可以正常获取数据
- 归档数据使用场景验证：需要验证全部使用数据的业务场景，至少在基础数据服务阶段可以返回一样的数据。假如对业务实现修改幅度较大，可以不用纠结接口的统一
- 双写验证：验证对两个数据源可以随意写入，验证对老长期层增删改后新长期层可以同步
§4.4 确认归档数据范围 & 确认归档方案（快速归档可以直接从这里开始）
确认现存环境（主要用于评估业务场景覆盖的成本）
已有环境：db、mongo、es
已接入：db、mongo
可以搭建、接入：oss
估算归档数据范围的方法
估算步调
- 统计当前最大id，有的时候同时也是全表数据量
- 统计保留 2/3/4/6/12 个月数据时（不同的档位），右界限的id 和 剩余数据量
- 单月期望数据增量 = 保留3个月剩余数据量 - 保留2个月剩余数据量，再用 4-3 个月核算
- 半年期望数据增量 = 单月期望数据增量 * 6
- 半年后期望数据量 = 剩余数据量 + 半年期望数据增量
- 最后结合业务场景、迁移方式，决定选择哪个档位（此时业务场景实在很简朴了，基本都是简朴索引查询）
可以按下表进行整理，定位 id 时参考下面 sql，留意界限的开闭（这个过程容易眼瞎，留意缓解）
- select * from table_name where id<154408259 order by 1 desc limit 10
最后，结合各档位数据决定迁移的数据范围，按下表进行总结
表保留月数保留量截止id半年量 §4.5 迁移工具与方案
数据迁移的本质就是数据的复制，只有主动拉数和被动接受两个大方案，二者之间只是封装范围不同
可选现成的 dts 工具（保举），如阿里云的 dts，相关文档点这里
可以 组内自研（保举），按正常需求开发
可以二方库自研（有条件时保举，可以算部门kpi），按以下脉络开发
- 美满权限申请系统，用于二方库获取各业务侧数据源权限
- 对接各主流数据源，实现读写
- 完成对接简朴字段映射、edi功能，或直接对接业务侧指定服务的驱动
- 完成监控、陈诉、速率调节、断续等功能（重要）
§4.6 天生归档迁移实行计划
按下表梳理
表保留月数截止id迁移目标迁移技术洗濯/筛选迁移控制
- 数据筛选：主要针对过滤掉某些不需要归档的字段。可以但是完全不发起直接横向过滤掉某条数据，尤其对应的主数据还在的环境下
- 数据洗濯：主要是创建宽表过程中需要将散布在多处的信息整合为一行宽表数据
- 迁移控制
- 时机控制：在不影响业务的前提下，灵活控制，但要留意避开业务高峰期，夜间批量定时任务，和对数业务
- 速率控制：严禁无睡眠死循环处理，可以思量舱闭+漏桶，low一些可以用窗口+睡眠控制，在有需求的场景下可以增加速率控制策略（数据擦除时比较须要）
§5 迁移实行阶段
只需要留意对现有业务的影响，控制速率即可
即使迁移出了问题，由于源数据没有删除，因此可以原地重试
迁移过程，假如是自研的，可以思量美满陈诉机制，包罗如下内容
§6 验证阶段
数据量验证：不要纠结于 count，可以从多个途径对照
- 迁移工具迁移任务的统计
- 归档 schema 信息（table_rows）的对比
- id 范围对照
可读性验证：业务场景覆盖阶段已履历证
归档后效率验证：直接通过访问工具大概在环境上验证均可
归档数据使用场景验证：业务场景覆盖阶段已履历证，在迁移后，还需要有一次验证。
正确性验证：不是须要步调。
- 完整验证：对数任务，完整爬表对数，同时进行数据量验证，工作量极大
- 随机验证：主要用来验证迁移逻辑是否正确，在迁移的刚开始大概进行中，抽取多少数据，对比两个数据源中信息是否齐全正确。只能证实迁移逻辑是对的，但不能证实全部被迁移的数据都是对的
双写验证：业务场景覆盖阶段已履历证
§7 擦除阶段
前提：务必做完业务场景覆盖后的验证和归档迁移后的验证
擦除阶段只有单表 drop 的场景（非db也类似），只需要做好进度控制
- 不能影响原数据源 tps
- 速率不宜过快，不宜集中操作
- 先擦除轨迹数据，后擦除业务主数据
擦除速率定制
- 保举删除速率 1000 - 24000 /min
- 保举操作速率 < 12 /min
- 保举删除数据量 < 1000 /批次
删除速率 = 每批次删除量 * 删除操作频率
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
