# 分析數十億筆信用卡交易并在云中提供低延遲的見解 > 原文： [http://highscalability.com/blog/2013/1/7/analyzing-billions-of-credit-card-transactions-and-serving-l.html](http://highscalability.com/blog/2013/1/7/analyzing-billions-of-credit-card-transactions-and-serving-l.html)  *這是 [Ivan de Prado](http://www.linkedin.com/in/ivanprado) 和 [Pere Ferrera](http://www.linkedin.com/in/pedroferrera) 的來賓帖子， [Datasalt](http://www.datasalt.com) 的創始人， [Pangool](http://pangool.net) 和 [Splout SQL](http://sploutsql.com) 大數據開源項目。* 使用信用卡支付的金額巨大。 顯然，可以通過分析所有交易得出數據中的內在價值。 客戶忠誠度，人口統計，活動熱點圖，商店推薦以及許多其他統計數據對于改善客戶與商店之間的關系都非常有用。 在 [Datasalt](http://www.datasalt.com) ，我們與 [BBVA 庫](http://www.bbva.com)合作開發了一個系統，該系統能夠分析多年的數據并為不同的低延遲 Web 和移動應用程序提供見解和統計信息。 除了處理大數據輸入外，我們面臨的主要挑戰是**的輸出也是大數據，甚至比輸入**還大。 并且此輸出需要在高負載下快速提供服務。 由于使用了[云（AWS）](http://aws.amazon.com)， [Hadoop](http://hadoop.apache.org/) 和 [Voldemort](http://www.project-voldemort.com/voldemort/) ，我們開發的解決方案每月的基礎設施成本僅為數千美元。 在下面的幾行中，我們將解釋所提出的體系結構的主要特征。 ## 數據，目標和首要決策 該系統使用 BBVA 在世界各地的商店中進行的信用卡交易作為分析的輸入源。 顯然，數據是匿名的，非個人的，并且可以進行隔離以防止任何隱私問題。 信用卡號被散列。 任何產生的見解始終是匯總，因此無法從中獲得任何個人信息。 我們為每個商店和不同時間段計算許多統計數據和數據。 這些是其中一些： * 每個商店的付款金額直方圖 * 客戶保真 * 客戶人口統計 * 店鋪推薦（在這里購買的客戶也可以在...購買）。 按位置，商店類別等過濾。 該項目的主要目標是通過低延遲的 Web 和移動應用程序向所有代理（商店，客戶）提供所有這些信息。 因此，一項苛刻的要求是能夠在高負載下以亞秒級的延遲提供結果。 由于這是一個研究項目，因此需要處理代碼和要求方面的高度靈活性。 因為一天僅更新數據不是問題，所以我們選擇了面向批處理的架構（Hadoop）。 我們選擇 Voldemort 作為只讀存儲來提供 Hadoop 生成的見解，這是一個簡單但超快速的鍵/值存儲，可以與 Hadoop 很好地集成。 ## 該平臺 該系統基于 [Amazon Web Services](http://aws.amazon.com/) 構建。 具體來說，我們使用 S3 存儲原始輸入數據，使用 Elastic Map Reduce（亞馬遜提供的 Hadoop）進行分析，并使用 EC2 提供結果。 使用云技術使我們能夠快速迭代并快速交付功能原型，這正是我們這類項目所需的。 ## 架構  該體系結構包含三個主要部分： * **數據存儲**：用于維護原始數據（信用卡交易）和生成的 Voldemort 存儲。 * **數據處理**：在 EMR 上運行的 Hadoop 工作流，執行所有計算并創建 Voldemort 所需的數據存儲。 * **數據服務**：Voldemort 群集，用于服務來自數據處理層的預先計算的數據。 銀行每天都將當天發生的所有交易上載到 S3 中的文件夾中。 這使我們能夠保留所有歷史數據-每天執行的所有信用卡交易。 所有這些數據都是處理層的輸入，因此我們**每天都重新計算所有內容**。 重新處理所有數據可以使我們變得非常敏捷。 如果需求發生變化或發現一個愚蠢的錯誤，我們只需更新項目代碼，并在下一批之后修復所有數據。 這是一項發展決定，為我們帶來了： * 簡化的代碼庫&架構， * 靈活性&適應變化， * 輕松處理人為錯誤（只需修復錯誤并重新啟動過程）。 每天一次，控制器在 EMR 上啟動新的 Hadoop 集群并啟動處理流程。 此流程由大約 16 個[元組 MapReduce 作業](http://www.datasalt.com/2012/02/tuple-mapreduce-beyond-the-classic-mapreduce/)組成，這些作業計算各種洞察力。 流的最后一部分（Voldemort 索引器）負責構建數據存儲文件，該文件隨后將部署到 Voldemort。 流程完成后，結果數據存儲文件將上傳到 S3。 控制器關閉 Hadoop 集群，然后將部署請求發送到 Voldemort。 然后，Voldemort 從 S3 下載新的數據存儲并執行熱交換，完全替換舊的數據。 ## 技術 ### Hadoop 和 Pangool 整個分析和處理流程是使用 Hadoop 之上的 [Pangool Jobs](http://pangool.net) 實現的。 這使我們在性能，靈活性和敏捷性之間取得了良好的平衡。 元組的使用使我們能夠使用簡單的數據類型（int，字符串）在流之間傳遞信息，同時我們還可以將其他復雜的對象（如直方圖）包含在其自己的自定義序列化中。 另外，由于 Pangool 仍然是低級 API，因此我們可以在需要時對每個 Job 進行很多微調。 ### 伏地魔  [Voldemort](http://www.project-voldemort.com/voldemort/) 是 LinkedIn 基于 [Amazon Dynamo](http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html) 概念開發的鍵/值 NoSql 數據庫。 Voldemort 背后的主要思想是將數據分成多個塊。 每個塊都被復制并在 Voldemort 群集的節點中提供服務。 每個 Voldemort 守護程序都可以將查詢路由到保留特定鍵值的節點。 Voldemort 支持快速讀取和隨機寫入，但是對于此項目，我們將 Voldemort 用作只讀數據存儲區，在每次批處理之后替換所有數據塊。 因為數據存儲是由 Hadoop 預先生成的，所以查詢服務不受部署過程的影響。 這是使用這種只讀批處理方法的優點之一。 我們還具有靈活性，可以在需要時更改集群拓撲并重新平衡數據。 Voldemort 提供了一個 Hadoop MapReduce 作業，該作業在分布式集群中創建數據存儲。 每個數據塊只是一個 [Berkeley DB](http://www.oracle.com/technetwork/products/berkeleydb/overview/index-093405.html) [B 樹](http://en.wikipedia.org/wiki/B-tree)。 Voldemort 的接口是 TCP，但我們想使用 HTTP 服務數據。 VServ 是一個簡單的 HTTP 服務器，它將傳入的 HTTP 請求轉換為 Voldemort TCP 請求。 負載平衡器負責在所有 VServ 之間共享查詢。 ## 計算數據 ### 統計 分析的一部分在于計算簡單的統計信息：平均值，最大值，最小值，標準偏差，唯一計數等。它們是使用眾所周知的 MapReduce 方法實現的。 但是我們也計算一些直方圖。 為了在 Hadoop 中有效地實現它們，我們創建了一個自定義直方圖，該直方圖只能通過一次計算。 而且，我們可以在一個 MapReduce 步驟中，在任意數量的時間段內，為每個商務計算所有簡單的統計數據以及相關的直方圖。 為了減少直方圖使用的存儲量并改善其可視化效果，將由許多分箱組成的原始計算出的直方圖轉換為可變寬度的分箱直方圖。 下圖顯示了特定直方圖的 3 槽最佳直方圖：  使用[隨機重啟爬山](http://en.wikipedia.org/wiki/Hill_climbing)近似算法計算出最佳直方圖。 下圖顯示了每次爬山迭代中可能的移動：  該算法已被證明非常快速和準確：與精確的動態算法（由[本文](http://cosco.hiit.fi/Articles/aistat07.pdf)實現）相比，我們達到了 99％的精度，速度提高了一個因子。 ### 商業建議 推薦使用共現進行計算。 也就是說，**如果有人在商店 A 和 B 中都購買了商品，則存在 A 和 B 之間的同現**。 即使購買者在 A 和 B 都購買了幾次，也僅考慮一次共現。給定商店的頂級共同商店是該商店的推薦。 但是需要對共現這一簡單概念進行一些改進。 首先，因為幾乎每個人都在其中購物，所以通過簡單的降頻來過濾掉最受歡迎的商店。 因此，推薦它們沒有任何價值。 按位置（商店彼此靠近），商店類別或兩者過濾推薦也可以改善推薦。 與“總是真實的”建議相比，基于時間的同現產生了更熱烈的建議。 限制共現的時間會導致人們建議在第一次購買后立即購買的商店。 Hadoop 和 Pangool 是計算共現并生成建議的理想工具，盡管有些挑戰并不容易克服。 特別是，如果一個買家在許多商店付款，則此信用通知的同現次數將顯示二次增長，從而使分析不能線性擴展。 因為這種情況很少見，所以我們只考慮每張卡的并發數量，只考慮購買者購買最多的那些卡。 ## 成本&一些數字 BBVA 在西班牙進行的一年信用卡交易在 Voldemort 上提供的信息量為 270 GB。 整個處理流程將在 24 個“ m1.large”實例的群集上運行 11 小時。 整個基礎設施，包括為生成的數據提供服務所需的 EC2 實例，每月費用約為 3500 美元。 仍有優化的空間。 但是考慮到該解決方案敏捷，靈活且可在云中運行，價格相當合理。 在內部基礎架構中運行的系統的成本將便宜得多。 ## 結論&的未來 由于使用了 Hadoop，Amazon Web Services 和 NoSQL 數據庫等技術，因此可以快速開發可擴展，靈活的解決方案，并準備以合理的成本承受人為的失敗。 未來的工作將涉及用 [Splout SQL](http://sploutsql.com) 代替 Voldemort，它允許部署 Hadoop 生成的數據集，并將低延遲鍵/值擴展到低延遲 SQL。 由于可以“即時”執行許多聚合，因此可以減少分析時間并減少數據量。 例如，它將允許在任意時間段內匯總統計信息，而這是無法預先計算的。 在“ LinkedIn 開發的鍵/值 NoSql 數據庫”之后，我停止閱讀 對那些什至不知道如何添加用戶密碼哈希的白癡都不感興趣。 這是一個令人困惑的描述，并且體系結構似乎布局/解釋不當。 另外，如何處理節點故障？ 回答“ dev”的評論：EMR 下的節點故障由 Amazon 透明處理，而 Voldemort 群集中的節點故障由 Voldemort 的故障轉移功能處理。 我們只需要指定所需的復制因子，就可以相應地部署數據塊。 隨意問您可能感興趣的其他問題，并且您認為這些解釋不夠充分。 感謝 Ivan 和 Pere，這非常有趣！ 我有一個快速的問題。 270 GB 的數據集并不是很大，并且由于您最終要使用 HTTP，所以我想知道是什么導致您選擇 Voldermort 而不是像 Sofadb 這樣的東西？ 我也對 Splout（您似乎是內部開發的）感到好奇。 在給定數據量的情況下，這似乎代表了相當大的工程努力-您能解釋一下 Splout 在此特定用例與（敢于說）分片 RDBMS 的優勢嗎？ 非常感謝！ 嗨斯蒂芬，謝謝你的評論和問題。 我們選擇 Voldemort 的原因有三個：速度，簡單性以及與 Hadoop 的良好集成。 我們認為很少有數據庫可以有效地從 Hadoop 提取數據。 我們對那些其數據結構可以由 Hadoop 預先生成并且可以以全有或全無的方式部署 Hadoop 文件且不影響查詢服務的數據庫感興趣。 這為系統增加了安全層，并使后端與前端完全脫開。 反過來，這使體系結構更簡單，從而消除了在處理和服務之間逐漸增加流狀態的需要。 ElephantDB 是另一個可以滿足這些要求并且可以選擇的數據庫，但是我們以前在 Voldemort 方面已有過積極的經驗。 我不確定您的問題是否更像我們是否可以使用以 CouchDB 為中心的系統來替代 Hadoop + Voldemort。 如果真是這樣，我們目前沒有足夠的 CouchDB 經驗來判斷這是否是一個有趣的選擇。 關于 Splout SQL，實際上您實際上可以將其視為分片的 RDBMS，但它是只讀的，并且與 Hadoop 緊密集成，這正是我們所需要的。 通過成為只讀文件，它實際上比傳統的 RDBMS 變得更易于管理，并且通過將其與 Hadoop 集成，我們使應用程序能夠輕松，安全地將數據從處理過程轉移到服務過程中，而這正是我上面提到的所有好處。 關于數據大小，請考慮到 270 GB 僅是西班牙的一年數據，但是該應用程序可能會服務數年和多個國家/地區的數據。 此外，由于需求變化很快，因此輸出幅度仍然未知，因為每次添加新功能時輸出幅度可能都會增加。 希望這能回答您的問題，否則請隨時提出。 謝謝 Pere，這很有道理-我現在意識到 Splout 或 ElephantDB 的優點是不必通過 MR 對初始數據存儲進行處理，然后再將 ETL 轉換為需要自己維護和明顯的性能優勢的單獨存儲 是只讀+（我想）要維護的代碼庫較小（顯然 Elephant 是 2k LoC！）。 干杯! 這是一個有趣的問題，但我只是希望對它進行更多的解釋。 使用這種類型的數據時（除規模之外），您遇到的最困難的事情是什么？ 我自己花了 10 多年的時間分析信貸/借記數據，我很好奇:) 謝謝 Jon Wren