大數據分析解決方案-文庫吧

【正文】 行為也非常近似。所以，我們在金融行業的客戶管理經驗，也可以應用到零售行業。　　以費埃哲公司在中國的業務發展為例，銀行業務是最傳統的領域。但從一年前開始，費埃哲就開始把我們成熟的技術推向保險領域，協助保險公司做理賠的反欺詐。盡管保險行業的業務特點跟銀行不太一樣，但我們的技術是同樣適用的，而且我們在國外的保險行業也有所積累。因此，費埃哲在國內的保險理賠反欺詐的案例就非常成功——客戶回訪時，他們表示，現在能夠通過數據分析，實時抓住大批量的理賠欺詐。　　問：我們也注意到，您提到了信用卡反欺詐這個大數據應用。但相對而言，這都是針對結構化數據的，針對郵件、文本這些非結構化的數據，費埃哲公司將采用哪些解決方案去處理？　　答：大數據的定義當中，包括3個V(高容量、高速度、多類型)。雖然費埃哲的信用卡反欺詐解決方案只是針對結構化數據，但我們已經能夠處理大容量數據和高速的數據。到目前為止，我們還是采用相對傳統的方式，將數據簡化到一個智能的、可操作的層面，然后基于這些數據來做出快速決策。盡管我們現在只能做到這三個V當中的兩個，但我們非常接近完美地來解決這個問題的。隨著基礎架構不斷的完善和演進，費埃哲的解決方案也會發生變化。　　問：在數據爆發的時代，我們進行數據分析的方式需要改變嗎？　　答：我們關于大數據的絕大多數討論都集中在數據的規模，并沒有相應關注在數據分析方式的改變。 “數據流”的分析對于FICO并不陌生，其中最好的應用莫過于我們的反欺詐解決方案——FICO Falcon Fraud Manager。Falcon模型依靠交易特征，它概括了數據在交易過程中的特征，以便計算相關的欺詐特點的變量，而不依賴由此生成的既有數據。　　我們在數據流特征分析領域不斷推動創新，尤其在反欺詐領域。這些創新技術包括：全球智能特征識別技術。它可以自動發現銀行卡交易、ATM和商戶交易中的不正常行為。再比如FICO公司開發的自我校正分析技術，它可以隨著客戶行為模式的改變，服務渠道的改變而改善偵測的準確性。另一個由大數據帶來的變化是分析必須減少對于固有數據的依賴。分析模型將能夠根據數據流中的動態數據自我調整。為了應對不斷增加的數據流中的動態數據，我們集中研發了自我學習的一些技術，包括：自適應分析和自我矯正分析技術。我們堅信這些關鍵技術將彌補傳統方式的不足。自學習技術甚至將可能在某些領域取代傳統的模式。　　最近，我們在自己開發的自我校正分析技術上取得了重大進展。已申請專利的“多層自我校正分析技術”的體系結構與神經網絡模式類似，但與之不同的是新模式可以在數據流中自我校正。使用多層自我校正模式將需要更少的數據采樣，并且可以直接與自適應分析技術聯合使用，可以更為動態地發現欺詐。將“多層自我校對系統”與目前通用的技術相比，我們預見未來的分析技術將大幅提高。　　問：更進一步地說，現在的大數據分析，都是數據進行篩選、過濾到數據倉庫當中，然后進行分析。隨著硬件設備在性能和容量上不斷提升，還有必要對傳統分析技術進行大規模改進嗎？　　答：今天的大數據分析情況確實如你所說的這樣。但我相信，在不遠的將來，我們會需要直接對大數據進行分析。這種分析可能有兩種方式：一種是隨著數據集的不斷增加，我們需要重新建模——在數據集不斷增加的情況下，可能需要考慮應用Hadoop技術進行存儲，否則我們就沒有容量足夠大的存儲空間。另一種方式則是采用基于機器學習的方法，來進行大數據的處理和分析。　　至于硬件的性能，也許現在還不是問題，但當我們考慮所有數據，并從中找出最有價值的地方時，用現有的基礎架構就會顯得遠遠不夠。例如，今天的銀行客戶，他們已經知道，未來他們的數據是分散的、遍布各地的，可能在銀行內部，可能在局域網或者在云里面，他們希望這些數據都能夠被讀取，都對數據進行分析。顯然，這是今天的架構無法完成的，這需要將來才可以實現。　　問：那么，您認為機器學習和傳統模型這兩種數據分析方式，哪種更有發展前途？　　答：大數據的最終目標就是利用各種數據來做出最好的決策。大數據最美的地方，就是我們不再受數據容量的局限，它可以不斷的增加一些變量，然后增加價值，幫助我們做出更好的決策。如你所提到的，現在我們有兩種模型，一種是基于假設的模型，例如前幾年麥肯錫提出來的假設模型，說我們要關注哪些高價值數據，關注相關領域的數據，關注那些能夠提升效率的數據。　　另一種模型就是一種不是基于假設的模型，確切地說，是一種機器學習的模型。這種模型跟假設模型完全不同。我并不認為這兩種模型可以相互替代。從長期來看，一定會有更多的數據需要我們去關注。對大數據來說，它能夠不斷的增加變量，幫助我們基于這些數據做出更好的決策，這是它特別有優勢的一個地方。我個人認為，在比較長的一段時間之后，機器學習的這種方式，有可能會取代假設的這種模型。　　問：在金融領域的機器學習應該具有什么特性？　　答：以小額貸款的機器學習為例，這需要非常快速觀察和衡量，能夠迅速發現壞帳，這樣才能夠快速學習、調整。盡管目前也有一些公司推出了所謂的機器學習，但這是非常有局限性的，主要是用于展示，展示出新科技所帶來的可能性，并告訴客戶這個新科技可以不斷完善，并且最終能夠降低風險。技術基礎：大數據分析技術的發展ZDNet 存儲系統 來源： 賽迪網 2012年05月16日 評論(0)關鍵詞： 大數據 MapReduce Google本文摘要大數據分析技術最初起源于互聯網行業。網頁存檔、用戶點擊、商品信息、用戶關系等數據形成了持續增長的海量數據集。這些大數據中蘊藏著大量可以用于增強用戶體驗、提高服務質量和開發新型應用的知識，而如何高效和準確的發現這些知識就基本決定了各大互聯網公司在激烈競爭環境中的位置。首先，以Google為首的技術型互聯網公司提出了MapReduce的技術框架，利用廉價的PC服務器集群，大規模并發處理批量事務。大數據分析技術最初起源于互聯網行業。網頁存檔、用戶點擊、商品信息、用戶關系等數據形成了持續增長的海量數據集。這些大數據中蘊藏著大量可以用于增強用戶體驗、提高服務質量和開發新型應用的知識，而如何高效和準確的發現這些知識就基本決定了各大互聯網公司在激烈競爭環境中的位置。首先，以Google為首的技術型互聯網公司提出了MapReduce的技術框架，利用廉價的PC服務器集群，大規模并發處理批量事務。利用文件系統存放非結構化數據，加上完善的備份和容災策略，這套經濟實惠的大數據解決方案與之前昂貴的企業小型機集群+商業數據庫方案相比，不僅沒有丟失性能，而且還贏在了可擴展性上。之前，我們在設計一個數據中心解決方案的前期，就要考慮到方案實施后的可擴展性。通常的方法是預估今后一段時期內的業務量和數據量，加入多余的計算單元（CPU）和存儲，以備不時只需。這樣的方式直接導致了前期一次性投資的巨大，并且即使這樣也依然無法保證計算需求和存儲超出設計量時的系統性能。而一旦需要擴容，問題就會接踵而來。首先是商業并行數據庫通常需要各節點物理同構，也就是具有近似的計算和存儲能力。而隨著硬件的更新，我們通常加入的新硬件都會強于已有的硬件。這樣，舊硬件就成為了系統的瓶頸。為了保證系統性能，我們不得不把舊硬件逐步替換掉，經濟成本損失巨大。其次，即使是當前最強的商業并行數據庫，其所能管理的數據節點也只是在幾十或上百這個數量級，這主要是由于架構上的設計問題，所以其可擴展性必然有限。而MapReduce+GFS框架，不受上述問題的困擾。需要擴容了，只需增加個機柜，加入適當的計算單元和存儲，集群系統會自動分配和調度這些資源，絲毫不影響現有系統的運行。如今，我們用得更多的是Google MapReduce的開源實現，即Hadoop。除了計算模型的發展，與此同時，人們也在關注著數據存儲模型。傳統的關系型數據庫由于其規范的設計、友好的查詢語言、高效的數據處理在線事務的能力，長時間地占據了市場的主導地位。然而，其嚴格的設計定式、為保證強一致性而放棄性能、可擴展性差等問題在大數據分析中被逐漸暴露。隨之而來，NoSQL數據存儲模型開始風行。NoSQL，也有人理解為Not Only SQL，并不是一種特定的數據存儲模型，它是一類非關系型數據庫的統稱。其特點是：沒有固定的數據表模式、可以分布式和水平擴展。NoSQL并不是單純的反對關系型數據庫，而是針對其缺點的一種補充和擴展。典型的NoSQL數據存儲模型有文檔存儲、鍵值存儲、圖存儲、對象數據庫、列存儲等。而比較流行的，不得不提到Google提出的Bigtable。Bigtable是一種用于管理海量結構化數據的分布式存儲系統，其數據通常可以跨成千個節點進行分布式存儲，總數據量可達PB級（10的15次方字節，106GB）。HBase是其開源實現。如今，在開源社區，圍繞Google MapReduce框架，成長出了一批優秀的開源項目。這些項目在技術和實現上相互支持和依托，逐漸形成了一個特有的生態系統。這里借用Cloudera所描繪的架構圖來展現Hadoop生態系統。這個系統為我們實現優質廉價的大數據分析提供了堅實的技術基礎。使用Storm實現實時大數據分析！實時Storm大數據摘要：隨著數據體積的越來越大，實時處理成為了許多機構需要面對的首要挑戰。Shruthi Kumar和Siddharth ’s上結合了汽車超速監視，為我們演示了使用Storm進行實時大數據分析。CSDN在此編譯、整理。簡單和明了，Storm讓大數據分析變得輕松加愉快。當今世界，公司的日常運營經常會生成TB級別的數據。數據來源囊括了互聯網裝置可以捕獲的任何類型數據，網站、社交媒體、交易型商業數據以及其它商業環境中創建的數據。考慮到數據的生成量，實時處理成為了許多機構需要面對的首要挑戰。我們經常用的一個非常有效的開源實時計算工具就是Storm—— Twitter開發，通常被比作“實時的Hadoop”。然而Storm遠比Hadoop來的簡單，因為用它處理大數據不會帶來新老技術的交替。Shruthi Kumar、Siddharth Patankar共同效力于Infosys，分別從事技術分析和研發工作。本文詳述了Storm的使用方法，例子中的項目名稱為“超速報警系統（Speeding Alert System）”。我們想實現的功能是：實時分析過往車輛的數據，一旦車輛數據超過預設的臨界值 —— 便觸發一個trigger并把相關的數據存入數據庫。Storm對比Hadoop的批處理，Storm是個實時的、分布式以及具備高容錯的計算系統。同Hadoop一樣Storm也可以處理大批量的數據，然而Storm在保證高可靠性的前提下還可以讓處理進行的更加實時；也就是說，所有的信息都會被處理。Storm同樣還具備容錯和分布計算這些特性，這就讓Storm可以擴展到不同的機器上進行大批量的數據處理。他同樣還有以下的這些特性： 易于擴展。對于擴展，你只需要添加機器和改變對應的topology（拓撲）設置。Storm使用Hadoop Zookeeper進行集群協調，這樣可以充分的保證大型集群的良好運行。 每條信息的處理都可以得到保證。 Storm集群管理簡易。 Storm的容錯機能：一旦topology遞交，Storm會一直運行它直到topology被廢除或者被關閉。而在執行中出現錯誤時，也會由Storm重新分配任務。 盡管通常使用Java，Storm中的topology可以用任何語言設計。當然為了更好的理解文章，你首先需要安裝和設置Storm。需要通過以下幾個簡單的步驟： 從Storm官方下載Storm安裝文件 將bin/directory解壓到你的PATH上，并保證bin/storm腳本是可執行的。Storm組件Storm集群主要由一個主節點和一群工作節點（worker node）組成，通過 Zookeeper進行協調。主節點：主節點通常運行一個后臺程序 —— Nimbus，用于響應分布在集群中的節點，分配任務和監測故障。這個很類似于Hadoop中的Job Tracker。工作節點：工作節點同樣會運行一個后臺程序 —— Supervisor，用于收聽工作指派并基于要求運行工作進程。每個工作節點都是topology中一個子集的實現。而Nimbus和Supervisor之間的協調則通過Zookeeper系統或者集群。ZookeeperZookeeper是完成Supervisor和Nimbus之間協調的服務。而應用程序實現實時的邏輯則被封裝進Storm中的“topology”。topology則是一組由Spouts（數據源）和Bolts（數據操作）通過Stream Groupings進行連接的圖。下面對出現的術語進行更深刻的解析。Spout：簡而言之，Spout從來源處讀取數據并放入topology。Spout分成可靠和不可靠兩種；當Storm接收失敗時，可靠的Spout會對tuple（元組，數據項組成的列表）進行重發；而不可靠的Spout不會考慮接收成功與否只發射一次。而Spout中最主要的方法就是nextTuple（），該方法會發射一個新的tuple到topology，如果沒有新tuple發射則會簡單的返回。Bolt：Topology中所有的處理都由Bolt完成。Bolt可以完成任何事，比如：連接的過濾、聚合、訪問文件/數據庫、等等。Bolt從Spout中接收數據并進行處理，如果遇到復雜流的處理也可能將tuple發送給另一個Bolt進行處理。而Bolt中最重要的方法是execute（），以新的tuple作為參數接收。不管是Spout還是Bolt，如果將tuple發射成多個流，這些流都可以通過declareStream（）來聲明。Stream Groupings：Stream Grouping定義了一個流在Bolt任務間該如何被切分。這里有Storm提供的6個Stream Grouping類型：1. 隨機分組（Shuffle grouping）：隨機分發tuple到Bolt的任務，保證每個任務獲得相等數量的tuple。2. 字段分組（Fields grouping）：根據指定字段分割數據流，并分組。例如，根據“userid”字段，相同“userid”的元組總是分發到同一個任務，不同“userid”的元組可能分發到不同的任務。3. 全部分組（All grouping）：tuple被復制到bolt的所有任務。這種類型需要謹慎使用。4. 全局分組（Global grouping）：全部流都分配到bolt的同一個任務。明確地說，是分配給ID最小的那個task。5. 無分組（None grouping）：你不需要關心流是如何分組。目前，無分組等效于隨機分組。但最終，Storm將把無分組的Bolts放到Bolts或Spouts訂閱它們的同一線程去執行（如果可能）。6. 直接分組（Direct grouping）：這是一個特別的分組類型。元組生產者決定tuple由哪個元組處理者任務接收。當然還可以實現CustomStreamGroupimg接口來定制自己需要的分組。項目實施當下情況我們需要給Spout和Bolt設計一種能夠處理大量數據（日志文件）的topology，當一個特定數據值超過預設的臨界值時促發警報。使用Storm的topology，逐行讀入日志文件并且監視輸入數據。在Storm組件方面，Spout負責讀入輸入數據。它不僅從現有的文件中讀入數據，同時還監視著新文件。文件一旦被修改Spout會讀入新的版本并且覆蓋之前的tuple（可以被Bolt讀入的格式），將tuple發射給Bolt進行臨界分析，這樣就可以發現所有可能超臨界的記錄。下一節將對用例進行詳細介紹。臨界分析這一節，將主要聚焦于臨界值的兩種分析類型：瞬間臨界（instant thershold）和時間序列臨界（time series threshold）。 瞬間臨界值監測：一個字段的值在那個瞬間超過了預設的臨界值，如果條件符合的話則觸發一個trigger。舉個例子當車輛超越80公里每小時，則觸發trigger。 時間序列臨界監測：字段的值在一個給定的時間段內超過了預設的臨界值，如果條件符合則觸發一個觸發器。比如：在5分鐘類，時速超過80KM兩次及以上的車輛。Listing One顯示了我們將使用的一個類型日志，其中包含的車輛數據信息有：車牌號、車輛行駛的速度以及數據獲取的位置。AB 12360North cityBC 12370South cityCD 23440South cityDE 12340East cityEF 12390South cityGH 12350West city這里將創建一個對應的XML文件，這將包含引入數據的模式。這個XML將用于日志文件的解析。XML的設計模式和對應的說明請見下表。XML文件和日志文件都存放在Spout可以隨時監測的目錄下，用以關注文件的實時更新。而這個用例中的topology請見下圖。Figure 1：Storm中建立的topology，用以實現數據實時處理如圖所示：FilelistenerSpout接收輸入日志并進行逐行的讀入，接著將數據發射給ThresoldCalculatorBolt進行更深一步的臨界值處理。一旦處理完成，被計算行的數據將發送給DBWriterBolt，然后由DBWriterBolt存入給數據庫。下面將對這個過程的實現進行詳細的解析。Spout的實現Spout以日志文件和XML描述文件作為接收對象。XML文件包含了與日志一致的設計模式。不妨設想一下一個示例日志文件，包含了車輛的車牌號、行駛速度、以及數據的捕獲位置。（看下圖）Figure2：數據從日志文件到Spout的流程圖Listing Two顯示了tuple對應的XML，其中指定了字段、將日志文件切割成字段的定界符以及字段的類型。XML文件以及數據都被保存到Spout指定的路徑。Listing Two：用以描述日志文件的XML文件。1. TUPLEINFO2. FIELDLIST3. FIELD4. COLUMNNAMEvehicle_number/COLUMNNAME5. COLUMNTYPEstring/COLUMNTYPE6. /FIELD7. 8. FIELD9. COLUMNNAMEspeed/COLUMNNAME10. COLUMNTYPEint/COLUMNTYPE11. /FIELD12. 13. FIELD14. COLUMNNAMElocation/COLUMNNAME15. COLUMNTYPEstring/COLUMNTYPE16. /FIELD17. /FIELDLIST18. DELIMITER,/DELIMITER19. /TUPLEINFO 通過構造函數及它的參數Directory、PathSpout和TupleInfo對象創建Spout對象。TupleInfo儲存了日志文件的字段、定界符、字段的類型這些很必要的信息。這個對象通過XSTream序列化XML時建立。Spout的實現步驟： 對文件的改變進行分開的監聽，并監視目錄下有無新日志文件添加。 在數據得到了字段的說明后，將其轉換成tuple。 聲明Spout和Bolt之間的分組，并決定tuple發送給Bolt的途徑。Spout的具體編碼在Listing Three中顯示。Listing Three：Spout中open、nextTuple和delcareOutputFields方法的邏輯。1. publicvoidopen(Mapconf,TopologyContextcontext,SpoutOutputCollectorcollector) 2. { 3. _collector=collector。 4. try 5. { 6. fileReader=newBufferedReader(newFileReader(newFile(file)))。 7. } 8. catch(FileNotFoundExceptione) 9. { 10.