我刚接触大数据技术,所以想看看使用spark对可变数据执行增量更新是否是个好主意。并对合并后的数据进行计算。
要求:
我的数据总容量现在是200gb,年环比增长100%。
这是一个日常工作,我计划使用aws电子病历,我不认为我能负担得起有一个持久的电子病历集群,这将是太昂贵的方式,下面的工作流程可以通过临时电子病历集群完成吗?
我想完成的基本工作流程如下:
有一个初始快照,主要数据源是ddb。
捕获对原始数据的更改,使用spark将delta与旧快照合并以进行更新
对新快照进行计算以联接重叠的时间间隔以生成报告。
(拉伸目标)修剪过时数据以控制数据大小的增长。
数据合并
我正在研究的数据应该是这样的。初始快照:
blobId | manifestId | archiveId | usageValue | createdAt | deletedAt
---------------------------------------------------------------------------
blob1 | manifest1 | arch1 | 60 | 2020-06-20 8:00 |
blob1 | manifest2 | arch1 | 60 | 2020-06-20 1:00 | 2020-06-25 1:00
blob3 | manifest5 | arch1 | 70 | 2020-06-19 6:00 |
需要合并的增量:
blobId | manifestId | archiveId | usageValue | createdAt | deletedAt
---------------------------------------------------------------------------
blob1 | manifest1 | arch1 | 60 | 2020-06-20 8:00 | 2020-06-28 9:00
blob5 | manifest8 | arch1 | 80 | 2020-06-16 6:00 |
最终快照应为:
blobId | manifestId | archiveId | usageValue | createdAt | deletedAt
---------------------------------------------------------------------------
blob1 | manifest1 | arch1 | 60 | 2020-06-20 8:00 | 2020-06-28 9:00
blob1 | manifest2 | arch1 | 60 | 2020-06-20 1:00 | 2020-06-25 1:00
blob3 | manifest5 | arch1 | 70 | 2020-06-19 6:00 |
blob5 | manifest8 | arch1 | 80 | 2020-06-16 6:00 |
计算
现在我要计算2020-06-20 00:00和2020-06-21 00:00(24小时)之间的时间间隔的arch1的总大小。适用以下规则:
对于共享的blob,只计算一次,例如blob1被manifest1和manifest2共享,它们的时间间隔将被聚合。
blob大小将每小时计算一次,例如,blob1(size=60)是在2020-06-20 8:00创建的,那么它的大小将每小时添加到总存档大小中,假设blob1是存档中的唯一对象,在2020-06-20 8:00和2020-06-20 10:00之间,存档总大小将为120。
连接重叠的时间间隔
对于规则1,可以共享blob,最终聚合的时间间隔如下所示:
blob1,时间间隔(2020-06-20 1:00--2020-06-21 00:00)
blob3,时间间隔(2020-06-20 00:00--2020-06-21 00:00)
blob5,时间间隔(2020-06-20 00:00--2020-06-21 00:00)
尺寸计算
根据规则2,拱门1的最终尺寸为:6023+7024+80*24
这是一个简单的情况,我们只有一个档案,真正的数据将有100万档案。
扩展目标:清除过时数据
将来,arch1会被删除,我们可以安全地清除arch1下的所有数据。如何使用spark?
暂无答案!
目前还没有任何答案,快来回答吧!