這篇文章由Datasalt的創始人Ivan de Prado和Pere Ferrera提供，Datasalt是一家專注于大數據的公司，推出了Pangool和Spoilt SQL Big Data等開源項目。在這篇文章中，通過BBVA信用卡支付的例子詳解了云計算中的低延時方案。
以下為文章全文：
使用信用卡進行支付的款項是巨大的，但是很明顯，通過分析所有的交易，我們也可以從數據中得到內在的價值。比如客戶忠誠度、人口統計數據、活動的受歡迎程度、商店的建議和許多其他的統計數據，這對商家和銀行來說都是非常有用的，可以改進他們與市場的聯系。在Datasalt，我們已經與BBVA銀行合作開發了一個系統，該系統能夠對多年的數據進行分析，并為網絡應用程序和移動應用程序提供不同的方案和統計資料。
我們除了需要對面處理大數據輸入這個主要挑戰外，還要面對大數據的輸出，甚至輸出量比輸入量還要大。并且需要在高負載下提供更快捷的輸出服務。
我們開發的解決方案中有一個每月只需幾千美元的基礎設施成本，這要感謝使用的云(AWS)、Hadoop和Voldemort。在下面的內容中，我們將解釋所提出的架構的主要特點。
數據、目標和首要決定
該系統利用BBVA的信用卡在世界各地的商店交易信息作為輸入源的分析。很明顯，為了防止隱私問題，數據是匿名的、客觀的和分離的，信用卡號碼被切割。任何因此而產生的見解總是聚集，所以從中得不出任何個人信息。
我們計算每個店和每個不同的時間段的許多統計資料和數據。以下是其中的一些：
·每家店鋪的付款金額的直方圖
·客戶端的保真度
·客戶端人口統計
·商店的建議(在這購買的客戶還購買了……)、過濾的位置和商店類別等
該項目的主要目標是通過低延遲的網絡和移動應用提供所有這些信息到不同的代理(商店、客戶)。因此，一個苛刻的要求是要能夠在高負載下能夠提供亞秒級延遲的服務。因為這是一個研究項目，還需要在代碼和要求需要處理方面有一個高度的靈活性。
由于更新的數據只能每一次并不是一個問題，我們選擇了一個面向批處理的架構(Hadoop)。并且我們使用Voldemort作為只讀存儲服務于Hadoop產生的見解，這是一個既簡單又超快的鍵/值存儲。
平臺
該系統以Amazon Web Services為基礎建立。具體地說，我們用S3來存儲原始輸入數據，用Elastic MapReduce(亞馬遜提供的Hadoop)分析，并用EC2服務于結果。使用云技術使我們能夠快速迭代和快速交付功能原型，而這正是我們需要那種項目。
體系架構
該架構具有三個主要部分：
·數據存儲：用戶保持原始數據(信用卡交易)和得到的Voldemort商店。
·數據處理：Hadoop的工作流程在EMR上運行，執行所有計算并通過Voldemort創建所需要的數據存儲。
·數據服務：一個Voldemort集群從數據處理層提供預先計算好的數據。
每一天，銀行上傳在那一天發生的所有交易到S3上的一個文件夾中。這可以讓我們保留所有的歷史數據——每天所有的信用卡執行的交易。所有的這些數據都被輸入處理層，所以我們每天都會重新計算一切，之后再處理這些數據，我們就能夠非常靈活。如果需求變更或如果我們找到一個愚蠢的錯誤，我們只需要在下一批中更新項目代碼和所有的固定數據就可以了。這讓我們作出了一個開發的決定：
·一個簡化代碼的基礎架構
·靈活性和適應性的變化
·易于操作的人為錯誤(剛剛修復的錯誤，并重新啟動的過程)
每天，控制器都會在EMR上啟動一個新的Hadoop集群以及啟動處理流程。這個流程由約16組MapReduce工作組成，計算各種方案。最后的一部分流程(Voldemort索引)負責構建稍后會部署到Voldemort的數據存儲文件。一旦流程結束，得出的數據存儲文件就會上傳到S3上。控制器關閉Hadoop集群，并發送一個部署請求給Voldemort。然后，Voldemort會從S3上下載新的數據存儲，并執行一個熱交換，完全取代舊的數據。
技術
Hadoop和Pangool
整個分析和處理流程使用Pangool Jobs在Hadoop基礎上。這給我們帶來了良好的平衡性、靈活性和敏捷性。元組的使用使我們在流程之間使用簡單的數據類型(int、string)傳送信息，我們可以把其他復雜對象(如柱狀圖)與他們自己的自定義進行序列化。
而且，因為Pangool仍然是一個低級別API，我們可以在需要時細調大量單個作業。
Voldemort
Voldemort是一個分布式鍵-值(Key-value)存儲系統，是亞馬遜Dynamo的一個開源克隆。
Voldemort背后的主要想法是在組塊中分隔數據。每個組塊都被復制，并擔任Voldemort集群的節點。每個Voldemort守護進程都能夠路由查詢節點，以保持一個特定的鍵值。Voldemort支持快速讀取和隨機寫入，但在這個項目中，我們使用Voldemort作為只讀數據存儲，在每個批處理過程取代所有數據組塊。因為數據存儲預先由Hadoop生成、查詢服務不受部署過程影響。這是使用這種只讀、批處理方法的優點之一。我們也改變集群拓撲結構的相當簡易的方法，并可在需要的時候重新平衡數據。
Voldemort提供了一個Hadoop的MapReduce作業，創建數據存儲在一個分布式集群。每數據塊僅僅是是一個Berkeley DB的B樹。
Voldemort的接口是TCP，但我們想使用HTTP服務數據。VServ是一個簡單的HTTP服務器，它將傳入的HTTP請求轉換為Voldemort TCP請求。負載均衡器負責所有VServs之間的共享查詢。
計算的數據
統計
部分分析包含計算簡單的統計數據：最大值、最小值、平均值、標準偏差、獨特的技術等。他們都使用眾所周知的MapReduce方法來實現，但我們也計算一些柱狀圖。為了有效地在Hadoop實現它們，我們創建了一個自定義的柱狀圖，可以在一次遍歷中計算。此外通過各個業務相應的柱狀圖，我們只需要一步MapReduce，就可以為所有的業務做任何周期的簡單統計。
為了減少柱狀圖所使用的存儲量，并改善其可視化，原來的計算柱狀圖中許多小的項目被轉化成幾個大的不同寬度的項目。下圖顯示了一個特定的柱狀圖轉化的最佳方案：
使用隨機重啟爬山近似算法對最佳柱狀圖進行計算。下面的圖顯示了每個爬山迭代上可能的變動：
該算法已被證明是非常快速、準確的：相比一個精確的動態算法，我們已經實現了99%的準確率，這是高速增長的因素之一。
商務建議
建議使用同現(co-ocurrences)計算。也就是說，如果有人A和B這兩個商店都買了東西，那么A和B之間存在一個同現。只有一個同現考慮，即使客戶在A和B購買了好幾次。
但同現這一簡單想法被使用還需要一些改進。首先，最受歡迎的商店都使用一個簡單的頻率刪減過濾掉，因為幾乎每個人都會在他們那購買，所以沒有價值再推薦它們。按位置、按商店類別或同時進行過濾推薦，也改善了建議。基于時間的同現會產生較熱建議與“總是正確”的建議之間的較量。在可能出現并發行為的地方(用戶在購買后看見推薦商品又買了第二件)限制時間。
盡管一些挑戰不容易克服，但Hadoop和Pangool仍然是計算同現和生成建議的完美工具。特別是如果一個買家在許多商店進行支付行為，這個信貸調用將顯示同現的數量二次增長，使分析不是成線性比例。因為這種情況極少出現，所以我們只限制每張卡的同現的數量，只考慮那些買家在哪買的最多。
成本和一些數字
在Voldemort統計的，在西班牙使用的BBVA信用卡一年的交易信息量270GB。整個處理流程將在一個24“m1.large”集群上運行11個小時。整個基礎設施，包括EC2實例所需要的服務所產生的數據將每月花費3500美元。
雖然仍有優化的空間，但考慮到解決方案是敏捷的、靈活的并且在云中，這個價格還是相當合理的。系統運行在一個內部基礎設施的成本會便宜很多。
結論與未來
幸好有了像Hadoop、Amazon Web Services和NoSQL數據庫這樣的技術，才可以以合理的成本，迅速發展可擴展的、靈活的解決方案。
未來的工作將涉及通過Splout SQL替代Voldemort，將允許部署hadoop生成的數據集，擴展了低延遲的鍵/值到低延遲的SQL。這將減少分析時間并“實時”執行許多聚合的數據量。
