跨域跨平台實時計算引擎V1 0版本

2021-12-30 09:38:51 字數 4250 閱讀 6041

第一章 專案概述

1.1.業務現狀

廣東聯通2023年開始著手進行大資料平台的建設,在2023年初步建成了乙個能夠提供指標標籤服務的大資料基礎平台,並在其基礎上構建了自助工具基本應用,為廣東聯通的大資料發展打下了結實的基礎。但已有的大資料平台,具有如下幾大核心痛點:

圖:核心痛點

1.已支援大量業務使用場景,但未統一管理生產系統資料血緣關係、資料質量和資料安全管理有待進一步規範;

2.已積累大量資料,但未對資料生命週期有效管理、未實現資料跨域查詢與計算;

3.已有基礎的資料開放介面,但未通過開放門戶封裝成有效的資料產品或資料服務;

1.2.專案目標

圖:專案目標

本專案希望通過對大資料平台進行重構擴充套件,實現:1、增加大資料平台的多源異構支撐能力,跨域跨平台的實時資料查詢功能,實現資料融合;2、新增資料治理功能,平台通過統一的元資料模型進行資料的生產管理和許可權控制。3、建立openapi介面應用規範;大資料平台統一資料口徑,打破各系統間資料孤島、以高效計算能力為基礎提供統一的內外部服務,提公升資料利用效率。實現統一的服務匯流排;4、設計元資料模型,所有功能均基於元資料驅動;5、系統設計松耦合,模組功能可插拔,可擴充套件性強;

第二章 平台使用者角色設定

圖:平台用例圖

平台共有4類角色:

1、領導:領導關注資料加工生產過程中的趨勢及存在的問題;關注大資料平台接入的資料資產、應用系統的資料量、訪問量、頻次等資訊;

2、管理員:負責對大資料平台的生產過程進行監控,發現平台運營、生產運營中存在的問題;並對元資料進行管理維護;

3、大資料應用:大資料應用通過平台的服務匯流排獲取應用需要的大資料;也將本應用生產的資料作為資料來源注入平台;應用還提供一些共享api,註冊到平台的應用共享層;

4、業務分析人員:業務分析人員在平台提取資料,進行業務分析;

第三章 當前的專案亮點

3.1.元資料驅動

元資料(metadata),又稱中介資料、中繼資料,為描述資料的資料(data about data),主要是描述資料屬性(property)的資訊,用來支援如指示儲存位置、歷史資料、資源查詢、檔案記錄等功能。元資料算是一種電子式目錄,為了達到編制目錄的目的,必須在描述並資料的內容或特色,進而達成協助資料檢索的目的。

本專案中設計了一套資料資產的元資料模型,使之不僅能描述資料資產的物理資訊,還能準確的描述資料的業務資訊、管理資訊;

圖:業務元資料,物理元資料,管理元資料

通過元資料驅動,使得業務人員和管理人員不再依賴於資料資產的表和字段資訊:

1、使用業務元資料,描述資料資產的業務屬性,通過業務元資料,描述資料分析人員、業務人員能理解的業務屬性:包含但不僅限於:資料是指標還是標籤;資料是連續變數還是分類變數;資料的計算公式,資料的業務口徑等;

2、只對外開放業務元資料,遮蔽物理元資料,業務操作不再受到物理儲存的侷限性:對使用者只公布資料資產的業務資訊,而遮蔽資料的物理資訊;所有的物理資訊由平台進行智慧型轉換;當資料資產發生遷移或變更時,並不會對使用者的使用造成影響,所有的物理資訊於使用者而言都是透明的;

3、基於業務元資料,進行管理元資料的配置,實現資料資產的管理:對管理人員只公布資料的業務資訊,管理員可基於資料的業務名稱對資料資產進行許可權、安全、質量、生命週期等管理;且當該資料資產的物理儲存發生變化時,資料資產的管理規則不需要重新配置,依然可以發生作用;

4、基於業務元資料的資料資產圖譜:對業務人員展示資料資產的資產圖譜;

3.2.跨域跨平台實時計算的資料服務匯流排

圖:跨域跨平台實時計算引擎

3.2.1.1.開發了跨域跨平台的實時引擎,該引擎由3部分組成;

1、服務匯流排:負責接受使用者請求的業務資訊,實現對使用者請求的鑑權、安全控制等,負責將經過處理的請求推送給智慧型sql;負責將智慧型sql返回的資料轉換為使用者請求的資料格式;

2、智慧型sql:負責將使用者請求中的業務元資料轉換為對應的物理元資料;負責根據管理元資料確定資料的許可權與安全規則;負責根據管理元資料呼叫資料的、解密與脫敏演算法;負責根據使用者請求的業務資訊、相關的物理資訊、組合生成可執行的查詢語句;負責將查詢語句推送給查詢引擎;

3、查詢引擎:負責將查詢語句下推到各物理資料庫,負責將各物理資料的資料實時抽取到查詢引擎的記憶體中,負責將抽取到的資料在記憶體中進行資料規約、解密與脫敏;並將獲得的資料集返回到智慧型sql;

3.2.1.2.跨域跨平台的實時計算支撐能力

1、支援ods、edw的融合計算:通過分析資料特性和使用要求,選擇合適的異構資料來源進行儲存,而不是將他們集中到單一的資料倉儲中;優點是:能更好的滿足各類資料的使用要求;傳統資料倉儲大量的構建模式是基於單一資料倉儲的基礎之上開始etl,即要從各大業務系統中把資料都抽取到乙個資料倉儲中,要聚合、我要轉換、我要到哪個地方去,甚至需要對不同**的資料進行分析。構建專案的人力、時間、金錢的成本都非常高,而且需要耗費大量的人力去做重複性的工作。

2、支撐本地與雲計算的融合計算:在同乙個企業之下,你可以解決本地資料與雲端資料的融合問題;

3、支援歷史資料和實時資料的融合計算:在同乙個請求中,可以解決歷史資料和實時資料的融合查詢;

3.2.1.3.跨域跨平台的實時計算引擎的效能

如圖:與其他方式的資料庫連線相比;

3.3.資料全流程的資料治理

圖:資料全流程

3.3.1.1.資料全流程:廣東聯通的資料全流程包括:

1、資料來源:各業務系統的資料儲存空間,作為大資料的資料來源;

2、etl生產:etl工具,對資料來源的資料進行抽取,清洗,轉換;

3、大資料儲存:etl生成的資料檔案,通過大資料平台的採集流程採集進入大資料儲存;大資料儲存中的資料根據使用要求會分為不同的儲存形式;資料在儲存中不是一成不變的,根據資料性質的變化,資料也會在不同的儲存形式中進行轉換;其中日誌庫有hadoop、oracle、檔案集群,他類似於ods,指標庫也有hadoop、redis、iq等多個集群,他類似於edw但不限於edw,他是以實體為物件進行儲存;各大資料應用通過服務匯流排從指標庫、日誌庫中抽取資料,可以在本應用中進行快取作為應用的dm層;

4、大資料應用:各大資料應用,通過服務匯流排、應用共享層,向大資料儲存獲取資料,並依據這些資料開發出各種專業的大資料應用系統;

3.3.1.2.資料全流程監控:

1、資料來源監控:監控各大業務系統新生成的資料來源的變動情況;

2、etl生產過程監控:監控資料從資料來源,通過etl抽取、清洗、加工後生成資料檔案的過程;

3、資料採集監控:監控將etl生成的檔案存入大資料儲存的過程;

4、大資料儲存轉換監控:監管大資料在大資料儲存中進行轉換的過程;

5、資料服務監控:監控大資料應用通過服務匯流排和應用共享層從大資料儲存獲取資料的過程;

3.3.1.3.全面的質量審核:

1、元資料審核:支援對元資料進行審核;包括非空性、唯一性、關聯性、型別約束、完整性、真實性等;

2、字段審核:支援對錶中的資料進行審核,包括完整性、合理性、及時性、一致性、準確性、唯一性等;

3.3.1.4.全流程的血緣分析:

1、血緣分析:貫穿資料來源、etl、大資料儲存、大資料應用全流程的字段級血緣關係;

2、影響分析:通過分析任一節點中的異常,判斷後續資料的影響;

3、資料地圖:以圖形化的形式展示資料的全流程及血緣關係;

第四章 後續優化

4.1.自定義資料的查詢演算法優化

使用者可對已有的資料進行自定義加工,加工的層次一多,為保證查詢效能,需考慮對演算法進行優化;

4.2.實時資料的查詢演算法優化

類似於上網日誌,1天有10t的資料產生;為保證實時重新整理資料,需考慮對演算法進行再優化;

4.3.第三方應用資料介面的相容

通過**,與其他第三方應用的資料介面實現相容,需要考慮不同應用之間的設計理念的差別;

4.4.運營全檢視

1、生產運營檢視:資料全流程中四個環節的任務量、完成率、及時性、故障率等資訊的全面展示;以及資料異常波動、告警、響應、處理記錄的展示;

2、平台運營檢視:大資料平台的日常服務的訪問量、頻次、及時性、故障率等資訊的全面展示;以及資料異常波動、告警、響應、處理記錄的展示 ;

多平台頭像跨域解決

近年來,h5遊戲逐漸興起,重度遊戲也越來越多,客戶端的資源一般都放在cdn上,不然自己的伺服器扛不住,也解決了很多問題,但是由此帶來的問題便是頭像跨域,我們自己的伺服器允許跨域,但是平台方那邊卻不一定了,造成使用者的頭像無法正確顯示。開始,我們的解決辦法是把使用者頭像轉存到本地伺服器上,使用者頭像直...

跨域iframe高度計算

一 同域獲取iframe內容 這裡有兩個細節 1.取iframe內的文件物件,標準瀏覽器使用 contentdocument屬性,ie低版本 ie6,7,8 使用 document屬性。2.calcpageheight函式計算頁面的實際高度,標準瀏覽器使用document.documenteleme...

實時計算引擎處理延遲的排查過程

推薦 debug hacks 實時計算引擎在處理實時資料時,要保證新到來的資料被及時得到處理。例如,對於 的訪問日誌資料,假設每一分鐘有乙個日誌檔案,那麼實時計算引擎必須滿足能夠在一分鐘之內處理完這一分鐘的日誌資料檔案,否則會導致日誌檔案堆積而不能被及時處理。前幾天,量子後端團隊排查了一次實時計算引...