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

語言: CN / TW / HK

本文根據 吳仕櫓老師在 2021 Gdevops全球敏捷運維峰會-廣州站 〗現場演講內容整理而成。

(點選文末“閱讀原文”可獲取完整PPT)

講師介紹

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

分享概要

一、 業務洞察和分析

二、資料和分析執行

三、 資料安全與管理

四、資料交換

五、Rapid-V 

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

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

一、業務洞察和分析

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

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

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

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

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

二、資料和分析執行

圖中展示的是我們的一個data pipeline,以使用者案例作為視覺切入點。 在這上面,我們有資料注入、資料清洗、資料連線、資料科學家進行資料分析、將最終的insight發給使用者去consume。 在這裡我想著重講一下關於link的這部分。 在我們的部門裡,我們用到了一個技術叫做Entity Resolution,主題思想可以參考:https://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

Q:匯豐內部有幾百個系統,有一些因為年代的不同,它們的底層系統甚至資料庫或資料的格式可能都不一樣。匯豐如何處理這些不同資料格式之間的收集和有效資料的驗證?

A1: 我們其實有自己研發了一個專門用來資料採集的系統,用它來做各種不同資料來源的資料採集,包括離線的和實時的。比如資料來源是Oracle、PG、DB、MySQL、SQL Server、Solace、 Kafaka、普通檔案、雲端儲存等等。在我們的設計裡,我們用Hdfs來做資料著陸的系統,以統一的Parquet的格式存放檔案,同時會把資料載入到Hive以便於對原始資料的分析和處理。每一次資料採集後,都會經過兩步資料的驗證,第一步是資料的checksum,第二步是採集到的資料跟原系統資料的reconciliation,確保資料沒有丟失。

Q2::銀行中有很多不同的業務部門,其中有不同的業務資料,但同時它也有可能有自己的資料平臺。我想請問,怎麼才能有動力讓它把業務資料放到你們的平臺裡面?

A2: 舉個例子,我們有 Market部門, Market部門中有product、trade,但client資料是在 banking這條線裡。如果banking自己去做,它既沒有Market那邊的product相關資料,也沒有Market那邊的trade的資料。再者,風控部門擁有的是交易風險、市場風險等資料,財務部分擁有財務相關資料,各自的資料互為聯絡,沒有了彼此,就做不到以客戶為中心的360度資料。所以這就是大家的動力所在,如果我把這些所有的資料都拿進來了,我就可以做到客戶的360度。

Q3:一個公司中,不同部門之間的資料往往相互獨立,當我們要對這些資料進行跨部門的修改呼叫時,可能會涉及到一個複雜而漫長的審批流程。我們怎麼才能把這個流程簡化,縮短審批時間?

A3: 我相信貴公司應該有一個類似 CDO的部門存在,就是Chief Data Office。在這個部門裡面,比如說我們公司就有CDO這樣的一個部門,Data Management就是其中的一個職能和分支,他們也會負責專門去解決像把資料上傳到雲端、資料跨國家分享這樣的一些問題。所以問題中說到的部門與部門之間的資料跨越,這部分痛點倒不是很大。更大的痛點在於:怎麼去實現資料的跨國分享?或是如何將資料上傳到雲端?因為這涉及到資料的外包問題,我們的這個部門就是負責跟監管打交道,同時確保我們不那麼敏感的資料可以上雲。

↓點這裡可下載本文PPT,提取碼:i9qs