1.概述

雖然大數據的解決方案不僅只有Hadoop平台，但是目前金融行業基於Hadoop的大數據平台已經得到廣泛和成熟的應用。建設大數據平台需要解決三大問題，首先要有足夠多的數據，包括結構數據、非結構數據、業務數據、第三方數據、行為數據等方方面面的數據，其次需要平台有足夠快的速度處理實時和流動的數據，再有具備對現有數據進行挖掘、分析和學習的能力。

目前互聯網金融行業都比較重視對大數據平台的建設，Hadoop平台技術更新也比較快，各家公司使用的技術選型和架構設計也是各有特點。但最基本的數據倉庫都是基於Hive來構建的，實時處理的框架要不基於日誌埋點flume+kafka+spark+storm,要不基於解析binlog+spark+storm日誌。

2.大數據家族產品

Hadoop平台是Apache開源組織的一個分散式計算開源框架，提供了一個分散式文件系統子項目(HDFS)和支持MapReduce分散式計算的軟體架構。光Hadoop家族下的子項目就有20多個，思緒導圖上僅列了一些常用的大數據開源的項目，當然類似成熟的開源項目還有很多，不同的技術架構下使用的子項目也不一樣。

2.1.Hive

無論你是傳統架構還是互聯網架構，建設大數據平台你都需要首先考慮數據倉庫，Hive是基於Hadoop的一個數據倉庫工具，可以把基於Mysql的結構化的數據文件映射為一張張大的只讀的資料庫表或大寬表，開發人員不用考慮MapReduce，Hive目前已經成為數倉的標配。

Hive適合用來對一段時間內的數據進行分析查詢，Hive不應該用來進行實時的查詢。況且Hive設計的目的，也不是支持實時的查詢，因為它需要很長時間才可以返回結果。

2.2.Hbase

Hbase是構建在HDFS之上的分散式、面向列的存儲系統，可以支持實時的讀寫、隨機訪問超大規模數據集。

Hbase則非常適合用來進行大數據的實時查詢，可以直接使用HQL來進行直接查詢。

數據在 RDBMS 中的邏輯排布

數據在 HBase 中的邏輯排布

在 HBase 中首先會有Column Family 的概念，簡稱為 CF。CF 一般用於將相關的列（Column）組合起來。

2.3.Sqoop

建設數據倉庫時，你需要一個工具把數據從業務資料庫如Mysql導入到Hive里，Sqoop是比較常用的工具。當然Sqoop本身也存在很多問題，我們項目剛開始使用的是Sqoop，後來拋棄工具自己寫的T+1導入數據。

2.4.Flume

一個分布的、可靠的、高可用的海量日誌收集的平台。一般來說大數據平台很多實時數據從業務埋點進來的，業務埋點打日誌後，通過Flume進行日誌收集然後通過Kafka傳到大數據進行後續處理。

2.5.Kafka

Kafka是一個分區的、分散式的、可複製的消息系統。除了提供普通消息功能外還有一些自己獨特的設計。

Kafka將消息以topic為單位進行歸集，producer向kafka發布消息，consumer消費消息。客戶端和服務端通過TCP協議通信。

2.6.Storm

Storm是一個分散式、高容錯的實時計算系統。Storm令持續不斷的流計算變得容易，彌補了Hadoop批處理所不能滿足的實時要求。Stormy主要應用於實時分析，在線機器學習，持續計算、分散式遠程調用等領域。

如果業務場景中需要低延遲的響應，希望在秒級或者毫秒級完成分析、並得到響應，而且希望能夠隨著數據量的增大而拓展。那就可以考慮下，使用Storm了。

2.7.Spark Streaming

與Storm一樣也是實時計算系統，是Spark生態技術棧中子項目，Spark Streaming可以和Spark Core、Spark SQL無縫整合。但與Storm相比僅是秒級的准實時，優點主要是吞度度大。

2.8.Kudu

Kudu的定位是快速更新的數據上進行快速的查詢，同時具備高性能的隨機寫，以及很強大的可用性（單行事務，一致性協議），支持Impala spark計算引擎。

什麼時候使用kudu：

大規模數據複雜的實時分析，例如大數據量的join。

數據有更新。

查詢准實時。

2.9.Impala

Impala大數據實時分析查詢引擎，Impala與Hive都是構建在Hadoop之上的數據查詢工具，Impala適合於實時互動式SQL查詢。對於執行時間過長的SQL，仍舊是Hive更合適。

最初Impala主要支持HDFS，Kudu發布之後，Impala和Kudu做了深度集成。數據可以從實時計算平台中實時的寫入Kudu，上層的Impala提供BI分析SQL查詢，對於數據挖掘和演算法等需求可以在Spark迭代計算框架上直接操作Kudu底層數據。

2.10.Canal

Canal是阿里巴巴旗下的一款開源項目，純Java開發。基於資料庫增量日誌解析，提供增量數據訂閱&消費，目前主要支持了MySQL。

上面介紹Sqoop工具並不支持實時的數據抽取。MySQL Binlog則是一種實時的數據流，用於主從節點之間的數據複製，我們可以利用它來進行實時的數據抽取。使用Canal項目，我們能夠非常便捷地將MySQL中的數據抽取到大數據平台中。

2.11.Kylin

Kylin是ebay中國團隊開發的一套OLAP系統並貢獻至開源社區，主要用於支持大數據生態圈的數據分析業務，它主要是通過預計算的方式將用戶設定的多維立方體緩存到HBase中。通過預計算的方式緩存了所有需要查詢的的數據結果，需要大量的存儲空間（原數據量的10+倍）。一般我們要分析的數據可能存儲在關係資料庫、HDFS上數據、文本文件、excel等。

2.12.Spark mlib

MLlib是Spark的機器學習（Machine Learning）庫，旨在簡化機器學習的工程實踐工作，並方便擴展到更大規模。MLlib由一些通用的學習演算法和工具組成，包括分類、回歸、聚類、協同過濾、降維等，同時還包括底層的優化原語和高層的管道API。

具體來說，其主要包括以下幾方面的內容：

演算法工具：常用的學習演算法，如分類、回歸、聚類和協同過濾；

特徵化公交：特徵提取、轉化、降維，和選擇公交；

管道(Pipeline)：用於構建、評估和調整機器學習管道的工具;

持久性：保存和載入演算法，模型和管道;

實用工具：線性代數，統計，數據處理等工具。

2.12.TensorFlow

TensorFlow是世界上最受歡迎的開源機器學習框架，它具有快速、靈活並適合產品級大規模應用等特點，讓每個開發者和研究者都能方便地使用人工智慧來解決多樣化的挑戰。

TensorFlow能夠讓你直接解決各種機器學習任務。目標就是在一般情況下，無論你遇到什麼問題，TensorFlow都可以在一定程度上提供API的支持。

總的來說TensorFlow就是為了快而設計的，所以它針對你實際使用的硬體和平台做了優化。

其中在機器學習框架方面，TensorFlow的真正獨特之處在於，能夠在5行或者10行代碼中構建模型。然後應用這個模型，進行擴展做出產品。

因此，你能夠在幾十甚至幾百個機器的簇上進行訓練。從而用該模型進行非常低的延遲預測。

3.大數據架構

3.1.數據源

做大數據平台，首先需要考慮的是數據從那裡來。有足夠的數據源才能作後續的工作。

3.1.1.業務數據

比較重要的數據來源，一般都是結構化的業務數據如客戶、訂單、貸前、貸中、貸後、風險信審等數據，還有部分非結構化的如照片、視頻、報文等數據。

3.1.2.第三方數據

如人行徵信數據、第三方徵信反欺詐問題如同盾、百融、芝麻、鵬元等數據。

3.1.3.用戶行為數據

對用戶行為的數據進行篩選、統計、分析，從而發現用戶的一些使用習慣，操作規律。從用戶行為和使用習慣上也可以建立反欺詐模型。

3.1.3.1.實現方案

1、APP或H5頁面通過埋點實時發送用戶行為數據至後端server，app直接調用http介面，server通過logback直接輸出日誌文件

2、flume通過tail命令監控日誌文件變化

3、flume通過生產者消費者模式將tail收集到日誌推送至kafka集群

4、kafka根據服務分配topic，一個topic可以分配多個group，一個group可以分配多個partition

5、storm實時監聽kafka，流式處理日誌內容，根據特定業務規則，將數據實時存儲至cache，同時根據需要可以寫入hdfs

6、kafka直接寫入hdfs

3.1.3.2.採集數據

1、用戶下載APP、註冊和登陸信息

2、終端信息：

操作系統：系統版本、系統類型

聯網模式：網路(wifi或者移動網路)

終端特性：解析度、機型

應用版本：當前版本

3、行為信息：

錄入：錄入速度、出錯概率

操作路徑：界面停留時間、界面跳轉路徑、界面跳轉次數

操作行為：啟動次數，使用時長，激活量，卸載量

4、錯誤信息：

錯誤摘要

錯誤次數

發生時間

5、GPS：

各操作頁面GPS和時間

3.1.4.互聯網數據

互聯網特別是移動互聯網時代的來臨，互聯網上存在無數數據，與用戶相關的、與行業相關的數據。我們可以合規的使用爬蟲去抓取很多有用的數據，比如百度貼吧、金融門戶網站等數據，來擴充公司強大的數據體系和數據寬度。

3.2.數據採集

3.2.1.實時採集

實時採集的來源主要是三個方面：

1、通過日誌Flume+kafka然後實時分析或者直接存入hdfs。

2、通過Canal分析mysql的bilog日誌，放到kafka或者直接存入hdfs。

3、靠爬蟲去抓取互聯網數據後保存到hdfs。

3.2.2.T+1

1、使用Sqoop從業務數據直接導入HIVE，導入頻率也可以設為2小時一次，但對生產庫有影響，可以考慮從mysql備庫導入。

2、自己寫工具導入HIVE。

3.3.數據融合和清洗

這塊工具最複雜而且需要消耗大量的資源，數據質量如果比較差的情況下，到數據應用那一層會很艱難。前面偷懶而欠的債後期肯定是要還的。

數據倉庫具體分幾層主要看業務特性和數據情況，分3層、7、8層都有，具體不會的架構方案有不同的分法。

3.3.1.ODS

ODS層是數據分層中的第一層，需要保持大量初始狀態的數據，你可以想像ODS就是一個大倉庫，所有的數據都先堆放在這裡。

ODS需要保存數據每天的更新和歷史。

3.3.2.數據清洗

ODS層海量的原始數據中存在著大量不完整、不一致、有異常的數據，嚴重影響到數據應用和建模的執行效率，甚至可能導致數據應用的偏差，所以進行數據清洗就顯得尤為重要，數據清洗同時進行數據集成、變換、規約等一系列的處理。

數據清洗一方面是要提高數據的質量，另一方面是要讓數據更好地適應特定的數據應用和數據建模。

數據清洗的目的：

1、數據的完整性

2、數據的唯一性

3、數據的權威性

4、數據的合法性

5、數據的一致性

數據清洗的手段

1、糾正錯誤

2、刪除重複項

3、統一規格

4、修正邏輯

5、轉換構造

6、數據壓縮

7、補足殘缺/空值

8、丟棄數據/變數

3.3.3.數據建模

根據業務要求和數據應用建設數據主題模型。包括增減欄位，增緯、減緯、行列轉換、拆分表、合併表、統一類型（格式轉換）、欄位日期和數字計算及轉換、列數據拆分為行數據、行數據合併為列數據。

如主題模型：

1、客戶主題

2、帳戶主題

3、產品主題

4、客戶事件主題

3.4.數據應用

3.4.1.SAS

SAS目前是金融行業風險部門必不可少的分析工具，SAS可以直接訪問hdfs，架構設計中應該建設風險的數據集市，把SAS用所需要使用的數據和部分模型在數據集市裡加工出來，風險分析數據就會輕鬆很多，最起碼沒有那麼痛苦。

3.4.2.OLAP

OLAP的作用就是儘可能將所有的維度條件及聚合值都準備好，供業務人員分析時可以按照任意維度來分析。Kylin從Hive中讀取源數據，使用MapReduce作為Cube構建的引擎，並把預計算結果保存在HBase。業務可以使用SQL語句或者其它分析工具訪問構建好的結果。

3.4.3.報表

T+1一般使用Spark來處理，把分析後的數據放到mysql里，報表工具直接讀取mysql展示就可以了。

實時報表使用Storm從kafka里讀取數據，一條一實時分析處理，數據結果可以放在mysql和redis，報表工具或應用作展示。

註：用戶畫像和客戶挖掘不在這樣講了，後面我們單獨講解。

4.小結

大數據時代，你不僅需要知道你的數據在那裡、還要有能力實時採集、存儲、清洗、分析、建模這些流動的數據。

數據質量、數據規模、業務建模、數據處理效率都是我們所需要關心的工作。基於Hadoop體系下開源的工具和子項目比較多，技術更新迭代比較快，大量的解決方案不夠成熟或者需要你投入相應的研發資源。

END

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！