數十億筆信用卡在云端交易背后的技術
譯文【2013年2月21日 51CTO外電頭條】使用信用卡進行的支付數量巨大。很顯然，分析所有交易后得到的數據本身就有固有的價值。客戶忠誠、人口統計數據、活動熱圖、商店推薦以及其他許多統計數字對客戶和店家來說都很有用，店家可用來改進與市場的關系。在Datasalt，我們聯合西班牙畢爾巴鄂比斯開銀行（BBVA）開發出了一款系統，能夠分析多年來的數據，并且提供不同的低延遲Web和移動應用程序方面的洞察力和統計數字。
除了處理大數據輸入外，我們面臨的主要挑戰在于，輸出的也是大數據，而且比輸入的大數據還要龐大。而且必須在高負載環境下，迅速提供這種輸出。
我們開發的解決方案其基礎設施成本每月只有幾千美元，這歸功于使用了云服務（AWS）、Hadoop和Voldemort。我們會在下文解釋這個提議架構的幾個主要特點。
數據、目標和首要決策
系統使用BBVA銀行在全球各地商店進行的信用卡交易，作為用來分析的輸入源。很顯然，數據是匿名的、非個人的、分離的，目的是為了防止出現任何隱私問題。信用卡號經過了散列處理，故意弄亂。任何因而得到的洞察力始終是聚合信息，所以無法從中獲得任何個人的信息。
我們計算了每家商店、每個不同時間段的許多統計數字和數據。下面是其中一些：
■每家商店的支付數額的直方圖
■客戶忠誠
■客戶人口統計數據
■商店推薦（在此購物的客戶還在…購物）。按地點和商店類別等標準來過濾。
該項目的主要目標是，通過低延遲的Web和移動應用程序，把這一切信息提供給不同的代理人（商店和客戶）。所以一個很高的要求就是，能夠在高負載情況下提供結果，而延遲不到1秒。又由于這是個研究項目，需要兼顧代碼和需求方面的高度靈活性。
由于每天只更新一次數據不是問題，我們選擇了一種面向批處理的架構（Hadoop）。我們還選擇了Voldemort，作為只讀存儲區，用于提供Hadoop生成的洞察力；Voldemort是一種簡單而超快速的鍵/值存儲區，與Hadoop整合得很好。
平臺
系統搭建在亞馬遜網絡服務（AWS）的環境上。具體來說，我們使用簡單存儲服務（S3）來存儲原始輸入數據，使用Elastic Map Reduce（亞馬遜提供的Hadoop）用于分析，使用彈性計算云（EC2）來提供結果。使用云技術讓我們得以實現快速迭代，迅速交付實用原型，這正是我們對這種項目提出的要求。
架構
架構有三個主要部分：
■數據存儲：用于維護原始數據（信用卡交易）和因而獲得的Voldemort存儲區。
■數據處理：在Elastic Map Reduce上運行的 Hadoop工作流程執行所有計算，并創建Voldemort所需的數據存儲區。
■數據提供：Voldemort集群從數據處理層提供預計算的數據。
該銀行每天把當日進行的所有交易上傳到S3中的一個文件夾中。這讓我們得以保留所有的歷史數據——每一天進行的所有信用卡交易。所有這些數據是處理層的輸入部分，所以我們重新計算一切，每天都是如此。重新處理所有數據讓我們得以非常敏捷靈活。要是需求發生變化，或者要是我們找到了一個愚蠢的錯誤，我們只需更新項目代碼，下一次批處理后，所有數據都得到了修復。這個開發決策為我們帶來了：
■簡化的代碼庫及架構；
■靈活應對變化的能力；
■易于處理人為錯誤的能力（只要修復錯誤，重新啟動過程）。
控制器啟動Elastic Map Reduce上的新Hadoop集群，并啟動處理流程，每天執行一次。這個流程由大約16個計算不同洞察力的Tuple MapReduce作業（http://www.datasalt.com/2012/02/tuple-mapreduce-beyond-the-classic-mapreduce/）組成。流程的***一個部分（Voldemort檢索器）負責創建數據存儲區文件，這些文件以后將部署到Voldemort。一旦該流程完成，因而獲得的數據存儲區文件將上傳到S3。控制器關閉Hadoop集群，并將部署請求發送到Voldemort。然后，Voldemort從S3下載新的數據存儲區，并執行熱交換操作，完全更換舊的數據存儲區。
技術
Hadoop和Pangool
整個分析和處理流程使用基于Hadoop上的Pangool作業（http://pangool.net/）來實現。這讓我們很好地兼顧了性能、靈活性以及敏捷性。使用tuples讓我們得以使用簡單的數據類型（int和string），在流程之間傳輸信息；與此同時，我們可以添加其他的復雜對象（比如直方圖），連同它們自己的自定義序列化。
此外，由于Pangool仍是一種低級API（應用編程接口），我們可以在需要時，對每一個作業進行多次微調。
Voldemort
Voldemort是由LinkedIn開發的一種鍵/值NoSql數據庫，基于亞馬遜的Dynamo（http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html）概念。
Voldemort背后的主要想法是，把數據分成多個部分。每個部分在Voldemort集群的節點中加以復制和提供。每個Voldemort守護程序都能將查詢傳送到為某一個鍵保留值的那個節點。Voldemort支持快速讀取和隨機寫入，但是就這個項目而言，我們使用Voldemort作為只讀數據存儲區，在每個批處理過程后更換所有數據部分。由于數據存儲區由Hadoop預先生成，查詢服務并不受部署過程的影響。這是使用這種只讀批處理方法的優點之一。我們還可以根據需要，靈活地更改集群的拓撲結構，并重新均衡數據。
Voldemort提供了Hadoop MapReduce作業，可以在分布式集群下創建數據存儲區。數據的每個部分只是Berkeley DB B樹（http://en.wikipedia.org/wiki/B-tree）。
Voldemort的接口是TCP，但我們希望使用HTTP來提供數據。VServ是一種簡單的HTTP服務器，可以把進入的HTTP請求轉變成Voldemort TCP請求。負載均衡系統負責在所有VServ之間分配查詢。
經過計算的數據
統計數字
分析過程的一個環節包括計算簡單的統計數字：平均值、***值、最小值、標準差、獨特的計數等。它們使用眾所周知的MapReduce方法來實現。但我們還計算了一些直方圖。為了使用Hadoop高效地實現它們，我們創建了一種自定義直方圖，只需要一遍就可以計算。此外，我們還能計算每次交易的所有簡單統計數字以及與之相關的直方圖，只要使用一個MapReduce步驟，可以是隨意的時間段。
為了減少直方圖所使用的存儲量，并且改進可視化，許多顏色區間（bin）形成的原始的計算直方圖被轉換成顏色區間寬度可變的直方圖。下列圖表顯示了某個直方圖的3個顏色區間的***直方圖。
***直方圖使用一種隨機重復爬山法（random-restart hill climbing）近似算法來計算。下列圖表顯示了每一次爬山迭代過程中可能出現的變化：
事實證明這種算法非常快速、非常準確：與精確的動態算法相比，我們獲得了99%的準確性，而速度提高了一倍。
商務方面的推薦
使用同現（co-ocurrences）來計算推薦。也就是說，如果某人在A商店和B商店都購買了東西，那么A商店與B商店之間就存在一種同現。即使顧客在A商店和B商店都購買了數次，被考慮進來的也只有一次同現。
但需要對這個簡單的同現概念加以一些改進。首先，使用一種簡單的頻切方法（frequency cut），將***的商店過濾出來，因為差不多每個人都在這些商店購物。所以推薦它們毫無意義。可以按地點（彼此挨得很近的商店）、商店類別或這兩者過濾推薦，這也有助于改進推薦。基于時間的同現形成了更熱門的推薦與“總是適用”的推薦。限制同現可能出現的時間帶來了這種商店推薦：人們在***家商店購物后馬上到第二家商店購物。
Hadoop和Pangool是計算同現、生成推薦的***工具，不過一些挑戰并不容易克服。尤其是，如果一個顧客在多家商店支付，該信用卡的同現數量就會呈平方增長，使得分析不呈現線性擴展。由于這是罕見情況，我們完全限制了每張卡的同現數量，只考慮顧客買得最多的情況。
成本和一些數據
就BBVA一年下來在西班牙的信用卡交易而言，用Voldemort提供的信息量是270 GB。整個處理流程在24個亞馬遜EC2“m 1.large”實例組成的集群上需要耗時11個小時才完成。整套基礎設施（包括提供隨后數據所需的EC2實例）成本約為每個月3500美元。
仍然存在有待優化的空間。但是考慮到該解決方案敏捷、靈活，而且在云端，價格相當合理。在一套內部基礎設施上運行的系統其成本將會低得多。
結論與展望
由于使用了Hadoop、亞馬遜網絡服務和NoSQL數據庫等技術，有可能迅速開發出這樣的解決方案：具有可擴展性和靈活性，準備經受得住人為失誤，而且成本合理。
未來的工作將包括把Voldemort換成Splout SQL（http://sploutsql.com/），這便于部署Hadoop生成的數據集，并將低延遲鍵/值擴展到低延遲SQL。這將縮短分析時間以及提供的數據量，因為許多聚合可以“實時”執行。比如說，它允許在任意時間段進行聚合統計分析，如果進行預先計算是不可能實現的。
