系统产生的数据, 是有生命周期的. 总结来说可以分成三个阶段:
- 炙手可热.
- 不时之需
- 以备后患
0x00 炙手可热
数据处于"炙手可热"时期, 一般指线上系统会访问, 或者近期计算需要使用的数据. 比如线上 DB 中的数据, 或者当天产生的日志. 这种情况下, 必须以性能为主要考虑因素, 放在访问最快的介质中
0x01 不时之需
过一段时间后, 部分数据会变成只有很少情况会访问到的情况. 比如一年前的订单, 或者是已经 ETL 过的原始的日志手. 这种场景下, 就可以将数据迁移到相对便宜的存储方案中. 例如一些电商网站把这个阶段的数据存储到 HBase 中. 这种存储的选型, 更多的是结合业务系统的改造, 尽量选择一个价格便宜, 但数据迁移成本相对低廉的方案.
0x02 以备后患
这种场景下, 数据变成了容灾备份, 无论如何线上系统或者分析系统都不会访问这部分数据. 但一旦需要这种数据时, 最重要的却是多长时间能够数据到位(一般备份数据都很大). 成本低廉 + 持久性好 + 容灾恢复快是此类型数据存储选型的三个要素. 当然, 更关键并且容易忽略的是, 备份完成后一定要验证备份可用啊, Gitlab.com 300G 数据遭误删，5种备份失效，在线等！, 如果标题中的主角换成你家公司, 你肯定准备卷包袱走人了吧...
0x03 存储选型闲扯
举两个例子, 闲扯一下线上数据库和分析数据存储在上述三种情况下的选型.
线上数据库
-
炙手可热阶段数据一般都存储在 MySQL 中 -
不时之需阶段数据可以选择 HBase 等便宜又能塞的多的品种; 数据迁移的策略也可以根据业务场景进行选择, 比如一刀切按照时间迁移, 或则给每个用户保存最后一段时间范围的数据. -
以备后患阶段, 就要看手头有什么了, 如果是 AWS 家的, 强烈推荐 S3
日志存储
-
炙手可热阶段, AWS 家的话数据可以存储在 S3 的 Standard 级别的存储中; 自建 Hadoop 的话就是 HDFS 了 -
不时之需阶段, 由于 S3 便宜, Standard 这个级别还可以继续保持 Standard 级别的存储; HDFS 的话, 就要参考 HDFS 新特性: Archival Storage, SSD & Memory -
以备后患阶段, AWS 家有 Glacier/Standard IA 两个选择, 更便宜, 直设置一下规则即可
0x04 总结
数据按照生命周期这个维度选择不同的存储介质, 以来节省成本, 二来还能降低对炙手可热级别系统的影响, 比如爬虫经常爬历史数据导致线上数据库负载高影响正常用户.
日志型数据存储分级别就更是刚需了, 当年 HDFS Archival Storage 没有的年代, 冷数据扔也不是, 不扔存储3份还嫌贵的纠结谁经历过谁知道其中的酸爽. 不过这里还是要表扬一下 AWS 家的 S3, 通过简单的设置就可以支持回收站和冷热数据转移的功能. 例如如下 Terraform 配置:
lifecycle_rule {
id = "log"
# 根据路径指定存储规则
prefix = "log/"
enabled = true
# ----- 冷热数据分级配置 ----
## 30 天后将数据放到稍微便宜一点儿的存储
transition {
days = 30
storage_class = "STANDARD_IA"
}
## 60天后, 将数据转移到 Glacier 级别的存储, 就是最便宜那种
transition {
days = 60
storage_class = "GLACIER"
}
## 这里的意思是 90 天后数据就自动删除
expiration {
days = 90
}
# -------------------
## 往下就是回收站功能
## 数据删除 30 天后, 转移到便宜的 IA 级别
noncurrent_version_transition {
days = 30
storage_class = "STANDARD_IA"
}
## 数据被删除90天后, 自动彻底删除
noncurrent_version_expiration {
days = 90
}
}
-- EOF --
