每天几百 G 的数据, 有什么好的办法管理, 比如 k8s?

[DinoStray]

数据都是一条一条的, 比如 user:123, hash:123

彼此之间没有联系.

然后会写入文件, 目前每天 400 G 的数据, 通过定时脚本上传到阿里云 OSS.

写入文件既是为了持久化, 也是为了其他组件读取数据出分析统计结果.

最近一年内数据膨胀很厉害, 已经从单日 40G 快速涨到了现在 400G, 预计后续还会持续上涨.

所以目前想改进一下方案.

大家有什么推荐么. 最好是基于 k8s, 能跨阿里云 google 云实现的.

我的需求关键字应该是

1. 持久化数据

2. 数据可供消费

持久化的时间需求应该是半年

[gz911122]

写入数仓呗

这跟 k8s 没什么关系吧

阿里云有个 odps

[xlent]

阿里云的 sls，直接当日之存呢，也能消费

[snappyone]

跟 k8s 有啥关系，跨 google 阿里云这个也很迷啊

[snappyone]

另外这个需求挺适合 kafka 的

[lihongjie0209]

和 k8s 有什么关系?

[pmispig]

先部署一个 k8s 再部署一个 es ?

[ai277014717]

感觉没什么好改进的。可以尝试先消费数据？

[fireapp]

minio 走起，压缩 + 序列化

[jingxyy]

这么大的量 又有 olap 的消费需求 还是好好搞搞大数据那一套吧

[petelin]

@snappyone 这个应该不适合 一不需要多 replica 二不需要频繁读
压缩传到一个文件系统就完事了

[hihipp]

看楼主描述，每天文本数据并不是实时消费掉。

压缩文本数据，能节约好多空间，后续消费时只多了解压步骤。

压缩我推荐用 rar，设置恢复记录！！！

[goodryb]

压缩上传 oss，然后 odps 创建外部表，数据源就是 oss

如果不是经常查询老数据，可以设置定期转成归档存储，半年后自动删除

[ColinZeb]

@hihipp rar 压缩性能好点，但 7z 支持多线程比 rar 好

[tyoung]

MySQL+TokuDB 存储引擎，可以压缩 5 到 10 倍存储

[Giny]

emmm 跟 k8s 有关系 又是类似与键值对的形式 抱歉，我只能想到 etcd

[luozic]

键值对 ？还是啥值都有？ key：value 的 es 集群一天 400G 没多少，Postgres 也能塞。 其他的 请搜大数据咋存的我。