最近我们有5年历史的MySQL数据仓库(主要用于业务报告)已经很满了,我们需要找到一种方法来归档不经常访问的旧数据以清理空间。
我创建了一个流程,该流程将DW中的旧数据转储到Amazon S3中的.parquet文件中,然后将其映射到Athena表中。效果很好。
但是我们有时会在现有表中添加/重命名/删除列。我也希望更改也能反映在旧的存档数据中,但是我只是想出了一种无需重新处理整个数据集的好方法。
在实时数据仓库与其基于文件的归档数据之间是否存在保持结构兼容性的“经典”方法?我已经搜索了相关文献,却一无所获。
我是否应该接受这样一个事实,即如果我需要主动维护模式,那么数据就不是真正的存档?
答案 0 :(得分:1)
如果您在大数据空间中搜索术语“模式演化”,则互联网中有大量材料。
Athena文档中有一章关于案例更新here的案例更新。
如果您要重新处理整个存档数据集以处理架构更改,则可能做得太多了。
由于您具有镶木地板文件,并且默认情况下Athena镶木地板通过列名而不是索引来解析列,因此在几乎所有情况下都可以安全使用,即添加新列,删除列等,但列重命名除外。要处理重命名的列(并处理列的添加/删除),最快的方法是使用视图。在视图定义中,您可以为重命名的列添加别名。另外,如果列重命名主要是架构演变的情况,并且要进行很多工作,则还可以考虑使用AVRO来妥善处理。
答案 1 :(得分:0)
计划A:
现在这样做为时已晚,但是PARTITIONing
是从表中获取数据的绝佳工具。
我说“太晚了”,因为添加分区将需要足够的空间来复制已经很大的表。而且您没有那么多磁盘空间?
如果该表按年,季度或月划分,则可以
大约同时,您将建立一个新分区来接收新数据。
(我会将这两个过程分开,以便您可以花费5年以上的时间来扩展,或者将其压缩到5岁以下,而无需付出太多的努力。)
该方法的优点是在处理过程中对大表的影响几乎为零。
分区的另一个好处是:您实际上可以将空间返回给操作系统(假设您有innodb_file_per_table=ON
)。
计划B:
看看您对oooold数据的处理方式。只有几件事?可能涉及摘要?所以...