怎么使用测量数据建立加载一反馈机制?

采集时序数据的另一个利益,就是可以或许经由过程编程使你的运用生成测量数据,从而可以树立平安、周详的反馈轮回,这方面有许多有效的例子。

在云盘算中,启用新的实例只须要给供给者发一条简略的API挪用即可,但要想知道什么时刻应当启动更多的实例或撤销正在运行的实例,就会很麻烦。假如基于采集的资本应用情形来断定启用撤销的话,就会轻易得多,这是测量数据用做反馈机制的一种惯例。

我在Flickr,有一个年夜型项目,应用了这种反馈机制,事实证实,异常有效。

2007年,Yahoo!决议关失落Yahoo!!Photos筹划很简略:通知Yahoo!Photos的用户,这个办事将被封闭,用户可以本身选择,将本身的照片连同元数据一路转移到其他的办事,包含非Yahoo!!的办事,像Shutterfly和KodakGallery,Flickr也是选项之一。

为这个项目做出容量评估将是一件苦差事。尽管有一些测量数器据,用上载频度、片年夜小及其他身分指述了Yahoo!Photos的典范用户,但有若干用户会选择Flickr,即使选择了Flickr,用户的应用模式又会若何变更,我们心里仍然没底。我们谈论的是一项已经跨越10年的照片存储办事,将会有巨量的数括,并且这么年夜的空同会在很短的时光内消费失落。不消讲得太准确,我告知你,2009年后期,Fick天天用失落年夜约12TB的存储客量。从Yahoo!Photos到Flickr的迁徙,在2007年连续了一段不长的时光,天天消费的存空间是这个数的两倍还多。

在在备迁徙的进程中,基于对迁徙的评估以及现有的Yahoo!Photos数器,我们对存需求做了最好的估量,并给出了一个宽松的平安体系,确保迁徙停止之前,不会涌现存空间不敷的情形。我们能想到的每件工作,都有测量数据:

● 迁徙的账户

● 迁徙的照片

● 处置的照片

● 迁徙队列年夜小

● 磁盘空间消费量

对选择迁徙到Flickr的用户,开端迁徙进程,并进行不雅察

我直接联到有意思的部门来说吧:即使微了如斯谨严的估量,我们照样错了,错年夜了。固然做了研讨,对存猪容量做了精心的评估,想迁近移到Fick来的人照样超越了我们的预期。要把想迁徙到Flickr来的人的Yhoo!Photos数据都近移过来的话,我们部看的存猪空间都邑用完。要么增长存猪,要么Flickr停滞上载片。

調寰宇,因为测量数据可以或许追踪磁を请耗,我们很如意识到了这点,但却受限于采购时光表。主要的是尽快购置、安装、设置装备摆设、安排更多存造,以免用完现有存。部著更多空间与迁徙过程之间睁开了一场比赛,

为懂得释我们是若何经由过程测量数据反转危为安的,要先介绍一下迁徙进程是若何进行的:

1.告诉用户,将封闭Yahoo!Photos办事,用户可以从列表中选择迁徙到哪里。假如选择Flickr的话,该用户账号就进人迁徙队列。

2.一旦用户的迁徙义务进入队列,则则锁定该用户的Yahoo!Photos账号,防止用户进行修正。如今Yahoo!Photos和Flickr之间进行API对API的通讯,以获取要迁徙的照片数据。

3.Flickr获取并处置Yahoo!Photos账号的照片及其元数据。

4.将Yahoo!Photos账号写人Flickr存储和数据库。

迁徙完成后,开放Flickr这边的账号,通知用户可以应用迁徙过来的Flickr新账号了。单个用户的迁徙并不须要很长时光,但用户量很年夜,所以照样花了不少时光。迁徙进程根本上就是一个年夜范围的异步进程,每个异步进程包含创立Flickr新账号和批量上载照片。

因为知道迁徙要消费若干存储、“有机”(非迁徙)增加要消费若干存储,即使估量不足的话,也可以猜测出还可以或许支撑的天数。我们下了一个宏大的订单,来购置存储,并开端计时。确认了发货和安装日期,如许我们就知道这些存储什么时刻可以或许在数据中间上架以及须要多久能力投入应用。

因为应用Ganglia采集数据,3行剧本代码就可以盘算出存储的消费率,然后将这个数字传给负责迁徙的API过程。照片是存储在散布于美国各地的若干个数据中间的,要确保API过程可以或许长途获得这个值,并检讨正在迁徙数据的所稀有据中间。我们修正了API的处置进程,以便不雅察存储消费的速度。假如在曩昔的一小时存储的消费率年夜于保持到新存储上线那天的消费率,则下降对列队期待迁徙的账号的处置速度,反之,则加速处置速度。前面列出的步调中,我们在步调2和步调3之间插入了一个检讨当前存储消费率的步调。

因为我们会依据存储的消费率调剂迁徙的速度,进入队列的账号可能会期待更长的时光。减慢处置进程也是一个不得已的折中,既要包管迁徙的顺遂进行,又要不影响Flickr的当前营业。

最终,迁徙顺遂完成,没有产生存储空间用光的情形。过后看来,我们的估量是有误差的,但并没有当初想的那么年夜。迁徙开端时的岑岭使我们担忧存储会用光,所以立时安排了更多的存储。但跟着逐渐接近本来的存储极限,进入迁徙队列的用户也慢慢削减了

这个故事解释,将散布在全国多个所在的网站扶植测量数据采集体系纳入反馈轮回,可以或许将PB级照片数据从Yahoo!Photos平安地迁徙到Flickr,同日时根本不影响两者的正常应用。

相關文章: