高负载低延迟:动态算法+Hadoop+AWS+NoSQL解析

摘要:本文由Datasalt(一家专注于大数据的公司)的创始人Ivan de Prado和Pere Ferrera提供,文章通过BBVA信用卡支付的例子详解了云计算中的低延时方案。在该解决方案中,Datasalt通过使用AWS、Hadoop和Voldemort搭载的架构,每月仅需花费几千美元就可以实现了低延时的云服务要求。

这篇文章由Datasalt的创始人Ivan de PradoPere Ferrera提供,Datasalt是一家专注于大数据的公司,推出了PangoolSpoilt SQL Big Data等开源项目。在这篇文章中,通过BBVA信用卡支付的例子详解了云计算中的低延时方案。

 

以下为文章全文:

 

使用信用卡进行支付的款项是巨大的,但是很明显,通过分析所有的交易,我们也可以从数据中得到内在的价值。比如客户忠诚度、人口统计数据、活动的受欢迎程度、商店的建议和许多其他的统计数据,这对商家和银行来说都是非常有用的,可以改进他们与市场的联系。在Datasalt,我们已经与BBVA银行合作开发了一个系统,该系统能够对多年的数据进行分析,并为网络应用程序和移动应用程序提供不同的方案和统计资料。

 

我们除了需要对面处理大数据输入这个主要挑战外,还要面对大数据的输出,甚至输出量比输入量还要大。并且需要在高负载下提供更快捷的输出服务。

 

我们开发的解决方案中有一个每月只需几千美元的基础设施成本,这要感谢使用的云(AWS)HadoopVoldemort。在下面的内容中,我们将解释所提出的架构的主要特点。

 

数据、目标和首要决定

 

该系统利用BBVA的信用卡在世界各地的商店交易信息作为输入源的分析。很明显,为了防止隐私问题,数据是匿名的、客观的和分离的,信用卡号码被切割。任何因此而产生的见解总是聚集,所以从中得不出任何个人信息。

 

我们计算每个店和每个不同的时间段的许多统计资料和数据。以下是其中的一些:

 

  • 每家店铺的付款金额的直方图
  • 客户端的保真度
  • 客户端人口统计
  • 商店的建议(在这购买的客户还购买了……)、过滤的位置和商店类别等

 

该项目的主要目标是通过低延迟的网络和移动应用提供所有这些信息到不同的代理(商店、客户)。因此,一个苛刻的要求是要能够在高负载下能够提供亚秒级延迟的服务。因为这是一个研究项目,还需要在代码和要求需要处理方面有一个高度的灵活性。

 

由于更新的数据只能每一次并不是一个问题,我们选择了一个面向批处理的架构(Hadoop)。并且我们使用Voldemort作为只读存储服务于Hadoop产生的见解,这是一个既简单又超快的键/值存储。

 

平台

 

该系统以Amazon Web Services为基础建立。具体地说,我们用S3来存储原始输入数据,用Elastic MapReduce(亚马逊提供的Hadoop)分析,并用EC2服务于结果。使用云技术使我们能够快速迭代和快速交付功能原型,而这正是我们需要那种项目。

 

体系架构

 

高负载低延迟:动态算法+Hadoop+AWS+NoSQL解析

 

该架构具有三个主要部分:

 

  • 数据存储:用户保持原始数据(信用卡交易)和得到的Voldemort商店。
  • 数据处理:Hadoop的工作流程在EMR上运行,执行所有计算并通过Voldemort创建所需要的数据存储。
  • 数据服务:一个Voldemort集群从数据处理层提供预先计算好的数据。

 

每一天,银行上传在那一天发生的所有交易到S3上的一个文件夹中。这可以让我们保留所有的历史数据——每天所有的信用卡执行的交易。所有的这些数据都被输入处理层,所以我们每天都会重新计算一切,之后再处理这些数据,我们就能够非常灵活。如果需求变更或如果我们找到一个愚蠢的错误,我们只需要在下一批中更新项目代码和所有的固定数据就可以了。这让我们作出了一个开发的决定:

 

  • 一个简化代码的基础架构
  • 灵活性和适应性的变化
  • 易于操作的人为错误(刚刚修复的错误,并重新启动的过程)

 

每天,控制器都会在EMR上启动一个新的Hadoop集群以及启动处理流程。这个流程由约16组MapReduce工作组成,计算各种方案。最后的一部分流程(Voldemort索引)负责构建稍后会部署到Voldemort的数据存储文件。一旦流程结束,得出的数据存储文件就会上传到S3上。控制器关闭Hadoop集群,并发送一个部署请求给Voldemort。然后,Voldemort会从S3上下载新的数据存储,并执行一个热交换,完全取代旧的数据。

相关推荐