【2013年2月21日 51CTO外電頭條】使用信用卡進行的支付數(shù)量巨大。很顯然，分析所有交易后得到的數(shù)據(jù)本身就有固有的價值。客戶忠誠、人口統(tǒng)計數(shù)據(jù)、活動熱圖、商店推薦以及其他許多統(tǒng)計數(shù)字對客戶和店家來說都很有用，店家可用來改進與市場的關(guān)系。在Datasalt，我們聯(lián)合西班牙畢爾巴鄂比斯開銀行（BBVA）開發(fā)出了一款系統(tǒng)，能夠分析多年來的數(shù)據(jù)，并且提供不同的低延遲Web和移動應(yīng)用程序方面的洞察力和統(tǒng)計數(shù)字。

除了處理大數(shù)據(jù)輸入外，我們面臨的主要挑戰(zhàn)在于，輸出的也是大數(shù)據(jù)，而且比輸入的大數(shù)據(jù)還要龐大。而且必須在高負載環(huán)境下，迅速提供這種輸出。

我們開發(fā)的解決方案其基礎(chǔ)設(shè)施成本每月只有幾千美元，這歸功于使用了云服務(wù)（AWS）、Hadoop和Voldemort。我們會在下文解釋這個提議架構(gòu)的幾個主要特點。

數(shù)據(jù)、目標(biāo)和首要決策

系統(tǒng)使用BBVA銀行在全球各地商店進行的信用卡交易，作為用來分析的輸入源。很顯然，數(shù)據(jù)是匿名的、非個人的、分離的，目的是為了防止出現(xiàn)任何隱私問題。信用卡號經(jīng)過了散列處理，故意弄亂。任何因而得到的洞察力始終是聚合信息，所以無法從中獲得任何個人的信息。

我們計算了每家商店、每個不同時間段的許多統(tǒng)計數(shù)字和數(shù)據(jù)。下面是其中一些：

■每家商店的支付數(shù)額的直方圖

■客戶忠誠

■客戶人口統(tǒng)計數(shù)據(jù)

■商店推薦（在此購物的客戶還在…購物）。按地點和商店類別等標(biāo)準(zhǔn)來過濾。

該項目的主要目標(biāo)是，通過低延遲的Web和移動應(yīng)用程序，把這一切信息提供給不同的代理人（商店和客戶）。所以一個很高的要求就是，能夠在高負載情況下提供結(jié)果，而延遲不到1秒。又由于這是個研究項目，需要兼顧代碼和需求方面的高度靈活性。

由于每天只更新一次數(shù)據(jù)不是問題，我們選擇了一種面向批處理的架構(gòu)（Hadoop）。我們還選擇了Voldemort，作為只讀存儲區(qū)，用于提供Hadoop生成的洞察力；Voldemort是一種簡單而超快速的鍵/值存儲區(qū)，與Hadoop整合得很好。

平臺

系統(tǒng)搭建在亞馬遜網(wǎng)絡(luò)服務(wù)（AWS）的環(huán)境上。具體來說，我們使用簡單存儲服務(wù)（S3）來存儲原始輸入數(shù)據(jù)，使用Elastic Map Reduce（亞馬遜提供的Hadoop）用于分析，使用彈性計算云（EC2）來提供結(jié)果。使用云技術(shù)讓我們得以實現(xiàn)快速迭代，迅速交付實用原型，這正是我們對這種項目提出的要求。

架構(gòu)

[[64107]]

架構(gòu)有三個主要部分：

■數(shù)據(jù)存儲：用于維護原始數(shù)據(jù)（信用卡交易）和因而獲得的Voldemort存儲區(qū)。

■數(shù)據(jù)處理：在Elastic Map Reduce上運行的 Hadoop工作流程執(zhí)行所有計算，并創(chuàng)建Voldemort所需的數(shù)據(jù)存儲區(qū)。

■數(shù)據(jù)提供：Voldemort集群從數(shù)據(jù)處理層提供預(yù)計算的數(shù)據(jù)。

該銀行每天把當(dāng)日進行的所有交易上傳到S3中的一個文件夾中。這讓我們得以保留所有的歷史數(shù)據(jù)——每一天進行的所有信用卡交易。所有這些數(shù)據(jù)是處理層的輸入部分，所以我們重新計算一切，每天都是如此。重新處理所有數(shù)據(jù)讓我們得以非常敏捷靈活。要是需求發(fā)生變化，或者要是我們找到了一個愚蠢的錯誤，我們只需更新項目代碼，下一次批處理后，所有數(shù)據(jù)都得到了修復(fù)。這個開發(fā)決策為我們帶來了：

■簡化的代碼庫及架構(gòu)；

■靈活應(yīng)對變化的能力；

■易于處理人為錯誤的能力（只要修復(fù)錯誤，重新啟動過程）。

控制器啟動Elastic Map Reduce上的新Hadoop集群，并啟動處理流程，每天執(zhí)行一次。這個流程由大約16個計算不同洞察力的Tuple MapReduce作業(yè)（http://www.datasalt.com/2012/02/tuple-mapreduce-beyond-the-classic-mapreduce/）組成。流程的***一個部分（Voldemort檢索器）負責(zé)創(chuàng)建數(shù)據(jù)存儲區(qū)文件，這些文件以后將部署到Voldemort。一旦該流程完成，因而獲得的數(shù)據(jù)存儲區(qū)文件將上傳到S3?？刂破麝P(guān)閉Hadoop集群，并將部署請求發(fā)送到Voldemort。然后，Voldemort從S3下載新的數(shù)據(jù)存儲區(qū)，并執(zhí)行熱交換操作，完全更換舊的數(shù)據(jù)存儲區(qū)。

技術(shù)

Hadoop和Pangool

整個分析和處理流程使用基于Hadoop上的Pangool作業(yè)（http://pangool.net/）來實現(xiàn)。這讓我們很好地兼顧了性能、靈活性以及敏捷性。使用tuples讓我們得以使用簡單的數(shù)據(jù)類型（int和string），在流程之間傳輸信息；與此同時，我們可以添加其他的復(fù)雜對象（比如直方圖），連同它們自己的自定義序列化。

此外，由于Pangool仍是一種低級API（應(yīng)用編程接口），我們可以在需要時，對每一個作業(yè)進行多次微調(diào)。

Voldemort

[[64108]]

Voldemort是由LinkedIn開發(fā)的一種鍵/值NoSql數(shù)據(jù)庫，基于亞馬遜的Dynamo（http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html）概念。

Voldemort背后的主要想法是，把數(shù)據(jù)分成多個部分。每個部分在Voldemort集群的節(jié)點中加以復(fù)制和提供。每個Voldemort守護程序都能將查詢傳送到為某一個鍵保留值的那個節(jié)點。Voldemort支持快速讀取和隨機寫入，但是就這個項目而言，我們使用Voldemort作為只讀數(shù)據(jù)存儲區(qū)，在每個批處理過程后更換所有數(shù)據(jù)部分。由于數(shù)據(jù)存儲區(qū)由Hadoop預(yù)先生成，查詢服務(wù)并不受部署過程的影響。這是使用這種只讀批處理方法的優(yōu)點之一。我們還可以根據(jù)需要，靈活地更改集群的拓撲結(jié)構(gòu)，并重新均衡數(shù)據(jù)。

Voldemort提供了Hadoop MapReduce作業(yè)，可以在分布式集群下創(chuàng)建數(shù)據(jù)存儲區(qū)。數(shù)據(jù)的每個部分只是Berkeley DB B樹（http://en.wikipedia.org/wiki/B-tree）。

Voldemort的接口是TCP，但我們希望使用HTTP來提供數(shù)據(jù)。VServ是一種簡單的HTTP服務(wù)器，可以把進入的HTTP請求轉(zhuǎn)變成Voldemort TCP請求。負載均衡系統(tǒng)負責(zé)在所有VServ之間分配查詢。

經(jīng)過計算的數(shù)據(jù)

統(tǒng)計數(shù)字

分析過程的一個環(huán)節(jié)包括計算簡單的統(tǒng)計數(shù)字：平均值、***值、最小值、標(biāo)準(zhǔn)差、獨特的計數(shù)等。它們使用眾所周知的MapReduce方法來實現(xiàn)。但我們還計算了一些直方圖。為了使用Hadoop高效地實現(xiàn)它們，我們創(chuàng)建了一種自定義直方圖，只需要一遍就可以計算。此外，我們還能計算每次交易的所有簡單統(tǒng)計數(shù)字以及與之相關(guān)的直方圖，只要使用一個MapReduce步驟，可以是隨意的時間段。

為了減少直方圖所使用的存儲量，并且改進可視化，許多顏色區(qū)間（bin）形成的原始的計算直方圖被轉(zhuǎn)換成顏色區(qū)間寬度可變的直方圖。下列圖表顯示了某個直方圖的3個顏色區(qū)間的***直方圖。

[[64109]]

***直方圖使用一種隨機重復(fù)爬山法（random-restart hill climbing）近似算法來計算。下列圖表顯示了每一次爬山迭代過程中可能出現(xiàn)的變化：

[[64110]]

事實證明這種算法非?？焖佟⒎浅?zhǔn)確：與精確的動態(tài)算法相比，我們獲得了99%的準(zhǔn)確性，而速度提高了一倍。

商務(wù)方面的推薦

使用同現(xiàn)（co-ocurrences）來計算推薦。也就是說，如果某人在A商店和B商店都購買了東西，那么A商店與B商店之間就存在一種同現(xiàn)。即使顧客在A商店和B商店都購買了數(shù)次，被考慮進來的也只有一次同現(xiàn)。

但需要對這個簡單的同現(xiàn)概念加以一些改進。首先，使用一種簡單的頻切方法（frequency cut），將***的商店過濾出來，因為差不多每個人都在這些商店購物。所以推薦它們毫無意義?？梢园吹攸c（彼此挨得很近的商店）、商店類別或這兩者過濾推薦，這也有助于改進推薦?；跁r間的同現(xiàn)形成了更熱門的推薦與“總是適用”的推薦。限制同現(xiàn)可能出現(xiàn)的時間帶來了這種商店推薦：人們在***家商店購物后馬上到第二家商店購物。

Hadoop和Pangool是計算同現(xiàn)、生成推薦的***工具，不過一些挑戰(zhàn)并不容易克服。尤其是，如果一個顧客在多家商店支付，該信用卡的同現(xiàn)數(shù)量就會呈平方增長，使得分析不呈現(xiàn)線性擴展。由于這是罕見情況，我們完全限制了每張卡的同現(xiàn)數(shù)量，只考慮顧客買得最多的情況。

成本和一些數(shù)據(jù)

就BBVA一年下來在西班牙的信用卡交易而言，用Voldemort提供的信息量是270 GB。整個處理流程在24個亞馬遜EC2“m 1.large”實例組成的集群上需要耗時11個小時才完成。整套基礎(chǔ)設(shè)施（包括提供隨后數(shù)據(jù)所需的EC2實例）成本約為每個月3500美元。

仍然存在有待優(yōu)化的空間。但是考慮到該解決方案敏捷、靈活，而且在云端，價格相當(dāng)合理。在一套內(nèi)部基礎(chǔ)設(shè)施上運行的系統(tǒng)其成本將會低得多。

結(jié)論與展望

由于使用了Hadoop、亞馬遜網(wǎng)絡(luò)服務(wù)和NoSQL數(shù)據(jù)庫等技術(shù)，有可能迅速開發(fā)出這樣的解決方案：具有可擴展性和靈活性，準(zhǔn)備經(jīng)受得住人為失誤，而且成本合理。

未來的工作將包括把Voldemort換成Splout SQL（http://sploutsql.com/），這便于部署Hadoop生成的數(shù)據(jù)集，并將低延遲鍵/值擴展到低延遲SQL。這將縮短分析時間以及提供的數(shù)據(jù)量，因為許多聚合可以“實時”執(zhí)行。比如說，它允許在任意時間段進行聚合統(tǒng)計分析，如果進行預(yù)先計算是不可能實現(xiàn)的。

原文鏈接：http://highscalability.squarespace.com/blog/2013/1/7/analyzing-billions-of-credit-card-transactions-and-serving-l.html