大資料的智慧處理和資料視覺化實踐

講師介紹

吳仕櫓， 匯豐科技 資料分析經理。曾任職於Accenture負責對M&G的大型系統整合系統的研發和交付，主要採用Spring Integration並對其進行封裝同時採用SOAP架構，近幾年來，任職於HSBC Technology投資銀行部，致力於大型前臺系統的開發和運維，從2019年開始專注於大資料方面包括資料安全、資料處理、資料視覺化等自研平臺的研發以及團隊的DevOps轉型。

大家常經常把資料比喻成石油。但是石油真正有價值的，是通過一些相應的技術提煉後得到的產品，比如煤油、汽油、機油以及一些通過進一步催化、裂化等技術得到的像凡士林之類產品。

因此，在看大資料時，我會把石油處理的整個工業化思路套入其中，再展開去看。一方面，大資料需要有一個技術平臺的支撐；另一方面，它需要有各種各樣的資料。技術平臺支撐資料的處理，資料通過平臺去實現業務價值。也就是工藝創造可重複利用的資料資產，然後在這些資料資產的基礎上進一步帶來更多更長遠的業務價值。

一、業務洞察和分析

這個圖就是我看大資料的第三個維度： 資料的流水線，也就是我們常說的data pipeline。 圖中的s1s2s3相當於我們的石油開採廠，負責開採資料，然後通過運輸管，把採集到的資料輸送到相應的目標點進行儲存。 在我們的場景中，這個目標點就是資料湖。

資料儲存起來之後，需要有相應的工藝對它進行加工。我們的資料工廠相當於石油的煉製工廠，它會通過蒸餾、催化裂化的技術對資料進行相應的處理，產出可重複利用的資料資產。這時候的資料資產可以怎麼用呢？我們可以將它應用在很多維度。比如直接使用，因為這個階段這些資料資產就好比石油煉製出來的煤油、汽油、機油等可以直接用在燃油機上，我們可以用這些資料資產來做報表或表格的直接呈現。

往更深的資料處理維度，也就是資料的insight。一個特別的例子就是資料科學，科學家可以在這個維度入場，在這些已經清理過並且處理得很漂亮的資料上建立機器學習的模型，從中帶出更多的business insight。在這裡我們會有一個疑問：這時候這些insight可以用來做什麼呢？答案是幫公司省錢,或者帶來新的業務價值。

我們回過頭來講一講大資料平臺的搭建。大資料平臺中的部件很多，包括資料的採集平臺或工具等。資料採集這部分我最不喜歡，因為我覺得它比較單一，簡單粗暴地講就是把資料進行copy 和paste。但是如果想把它做好，這也可以是個技術活。設想一下，每天上千個系統的資料會通過離線和實時的方式注入資料湖中，所以它涉及到的資料量和工作流的排程，對它併發性的要求會特別高，所以喜歡做高併發的系統的小朋友們可以在這方面進行研究。

資料注入後，接著是資料的清洗、智慧治理、數管理、安全性、視覺化等，每一個都是可以展開講的大話題，我今天只是拿其中的一兩個來講一講。

二、資料和分析執行

圖中展示的是我們的一個data pipeline，以使用者案例作為視覺切入點。 在這上面，我們有資料注入、資料清洗、資料連線、資料科學家進行資料分析、將最終的insight發給使用者去consume。 在這裡我想著重講一下關於link的這部分。 在我們的部門裡，我們用到了一個技術叫做Entity Resolution，主題思想可以參考：http://www.datacommunitydc.org/blog/2013/08/entity-resolution-for-big-data。

它的理念簡單來說就是：通過智慧的方式實現資料連線和去重。為什麼我們需要這樣的技術？大多時候，我們處理的資料是沒有一個唯一的ID用來連線和串起所有的資料的。Entity Resolution就是這樣的一個演算法，在我們沒有唯一ID的情況下，把所有資料組織成一個網。比如作為一個網際網路使用者，我有在攜程、支付寶、微信或者是其他的一些平臺的資料，但這些系統很可能並不互通，我無法通過一個唯一的ID把它們連線起來。所以，Entity Resolution的作用就是：將不同系統的資料連線起來，同時給這些連線起來的資料產生一個唯一的ID。

這部分聽起來有點像：對一個數據庫裡的表進行挑選後再 distinct一下，將資料進行合併，同時去掉重複資料。理論上的確是這樣，但事實上，在做大資料的時候，比如我們公司會去外部買很多資料回來，像過年的企查查或者一些國外的關於企業的資料等。這些外部的資料再加上自己公司內部的數百個系統的資料，將會達到一個相當可觀的量級，這時候我們想把這些資料進行合併就會十分困難。特別是在銀行業，許多核心繫統一般都有二三十歲。那些系統不像如今我們網際網路的系統一樣設計得非常完善，所以，當我們需要把這些系統的資料合併起來時，也沒辦法像關係型資料庫那樣，以一種連結的方式來實現。

舉個例子，比如說我們對應的是一個企業級的客戶，在這裡我們假設它的名字是阿里巴巴集團。當然這裡的阿里巴巴集團並不是指市場上的某一家大廠，我們只是做個假設。阿里巴巴它是一個集團公司，它旗下可能有幾百上千個子公司，像菜鳥可能就是其他其中的一家子公司。我們整個的Entity Resolution中解決的點就是：把這些資料來源裡面和阿里巴巴集團相關的Entity，包括它的子公司和子公司的子公司等全部link起來，然後，我只需要找到其中一個，比如菜鳥，我就可以接著追溯到相應的父公司，它的父公司的父公司，還有它自己的子公司或者親友公司等，這是它解決的一方面。

另一方面我們叫做 Connected Party，Connected Party就是把公司跟公司、公司跟個人等之間的關係給link起來，比如某人是某公司的總監，或者某公司在某月份付給了另外一個公司一定數額的錢等。舉個例子，我跟X老師都受僱於H公司，同時，X老師是A公司的總監，我是B公司的總監，X老師的A公司給C公司轉了1百萬美金。

接下來講一下Entity Resolution最後的一個功能點，以阿里巴巴為例，它也許是我們公司的客戶，也許不是。 如果它是我們的客戶，那我們可以在我們所有內部和外部的系統中，把它所有的資訊都連結起來，比如它有什麼樣的account、買了什麼樣的產品、做了什麼樣的交易、財務情況怎樣等等，所有這些資訊都可以把它們呈現、連結起來。

把資料做這樣的處理，它背後的潛在價值是什麼？ 我想以客戶盡職調查做為例子。 傳統上來講，對公業務的盡職調查的時長比較長，同時也需要對很多檔案進行審查。 在資料化之後，潛在的可能就是，能夠把客戶盡職調查變成秒調。

舉個例子，比如說現在阿里媽媽還不是我們的客戶，但有一天它突然來找我們的一個客戶經理，說想跟我們銀行做生意。這個時候，如果我們已經全部都數字化了，所有的資訊都可以link起來，我拿阿里媽媽這個名字，通過我剛剛丟出來的這一整個模型，就可以查出它的信用評級、它在企查查的評分、有什麼樣的風險、是不是跟阿里巴巴有父子關係等。這樣一來，操作人員就可以快速地判斷這個客戶從而幫它開戶，客戶也就不用再花一兩個月的時間來等待盡職調查的結果。

通過這資料化驅動的方式，把盡調的時間縮短到最少。更進一步挖掘這資料，也許我們可以再邀請資料科學家創造出一個模型，通過模型將這些資料進行進一步提煉，給出參考評分？

Entity Resolution裡面會用到哪些技術呢？ 業界會推薦一些像k mean之類的model去做 linkage。 我們用了Apache的Spark Graph X來進行圖計算，圖計算簡單地來說就是： 點跟點之間通過邊的關係連線起來。 在這個例子裡，資料來源就是相應的點，而邊指的是資料之間的關係，我們通過這些關係實現資料的連線。

三、資料安全與管理

接下來是大家可能比較感興趣的，關於資料安全方面和資料管理方面的內容，這兩個其實也都是很大的話題。這裡的資料安全主要以我們自己 build的一個叫Data Guardian的產品為例，它主要用來把控誰可以看和用到什麼樣的資料。舉個例子，比如我現在是廣州天河某支行的客戶經理，手上有10位客戶在由我做客戶關係管理，按照整個的設計，我只能看到與這10位客戶相關的一些資訊，而關於收支方面的資料我不可以看到。那麼我在進入系統時，我們的Data Guardian就會通過整個的資料的所有元素，從源頭收集它的元資料，並對相應的特點做標籤。

四、資料交換

Data Exchange是一個基於微服務架構的平臺，主要是一個Data Consumption層。 在傳統行業中，特別是在銀行業，資料會由處於內部更深層的防火牆圍著。 資料的安全得到了保護，但這一做法也導致了對資料讀取和運用的極大阻礙。 一方面，從流程上需要層層安全性的審批； 另一方面，技術上的實現除了不斷地朝防火牆開埠，沒有其它更好的做法。 所以，Data Exchange應運而生。

在面向使用者層，我們運用F5作為負載均衡。當用戶有訪問時，它會通過網路層面的負載均衡，把它路由到不同的服務中去。同時後端的服務會去訪問我們的資料儲存層，這裡儲存的就是最終被處理提煉過的資料。所以，在Data Exchange裡可以釋出各種各樣的API以及sftp等服務，讓使用者或者系統consume我們的資料。

五、資料視覺化

業界有很多商業或開源的資料視覺化方案，比如Apache的superset，使用者可以在上面配置相應的資料來源，然後通過寫類sql的語言來實現視覺化資料；商業方面有像 Looker或 Power BI型別的產品，可以實現資料的視覺化，但商業的一般很貴。後來，經過我們的思考和調研，對一些中小型的使用者案例以及我們的日常需求進行分析，得出我們需要一個實用的視覺化工具的結論。因此，我們開發了Rapid V，通過拉拽不同的資料來源，快速配置實現相應的、各種型別的視覺化圖案。

這是我們當時的想法，你可以看到，它主要有4個不同的部件。一個專門用於配置不同的資料來源，你可以把API、csv或者推送的檔案作為資料來源上傳上去，也可以配一個Oracle或者 PostgreSQL，Elasticsearch。通過上面的一些部件，對相應的資料來源進行拉取，這就相當於把它們給連結起來，然後我就可以在旁邊做配置。像這一個圖，我想通過 sum或者count等方式去做聚合。當我們將自己的視覺化版面設定調配好後，就可以選擇對它進行儲存和釋出。

Rapid V的另外一個比較重要的功能是modelling，我們能夠通過它把不同的資料來源以配置的方式將資料進行合併。這背後主要是用了Trino來做了一個虛擬化的層次，藉助它我可以通過標準化的sql，讓它把不同資料來源裡面的資料進行合併，從而組裝成一個新的資料來源。

Rapid V最後一部分的功能是報表的統一管理。 當用戶配置好自己的報表，並將要進行釋出時，使用者可以選擇自己的可見度，也可以把它分享給授權的人看到。

這是我們的一個例子，當時我們在驅動相應的招聘男女比例，希望通過招到更多女生從而達到更好的男女平衡。 而通過這個報告，它可以帶來許多insight，像收到的CV裡面性別的分佈是什麼樣的？ 最終通過面試比例的男女比例等。 這是我們當時用來驅動整個部門在做招聘時的想法。

> > > >

Q&A

↓點這裡可下載本文PPT，提取碼：i9qs