1. 程式人生 > 其它 >位元組跳動一站式資料治理解決方案及平臺架構

位元組跳動一站式資料治理解決方案及平臺架構

更多技術交流、求職機會、試用福利,歡迎關注位元組跳動資料平臺微信公眾號,回覆【1】進入官方交流群

“一站式資料治理解決方案及平臺架構”的分享會分為四個部分展開:

首先,明確資料治理的概念,從平臺視角出發,介紹在位元組跳動內部資料治理所服務的目標

其次,介紹位元組跳動內部資料治理的現狀與我們需要解決的問題

第三,介紹當前我們的解決方案

最後分享一站式資料治理的平臺架構

資料治理的概念

資料治理是一種資料管理的概念,確保組織能在資料的全生命週期中具有高質量的資料質量能力,並且實現對資料的完全管理,以支援業務的目標。

在這裡面有些關鍵詞:在一些組織、一些公司內部關注的是資料全生命週期,希望它有一個較高的質量,目標則是用來支援業務。

所以資料治理的目標主要由以下幾點構成:

第一,最大化資料價值。

第二,管理資料的風險。

第三,降低資料的成本。

資料治理是一個比較大的概念。它包括政策、規則、組織結構、治理過程,以及一些技術的支援。領域包括資料質量、資料成本、資料可用性以及資料安全等方面。

所以,在影響資料治理計劃的驅動因素是多樣的,比如說資料法規、隱私政策的限制,資料質量良莠不齊、資料治理成本高,或者是資源受限等等。此外,治理實施的方式和範圍也不同,比如:有可能是由統一的組織,諸如資料治理委員會在整個企業或者公司的範圍內發起一些治理目標與計劃,來推動整個組織的資料治理;也可能是在一些部門、團隊內部去進行有限範圍內的治理。資料治理計劃的目標實現必須得用適當的工具來解決,資料治理的方式也越來越傾向於朝著系統化和工具化的方向來發展。

位元組跳動資料治理背景

在位元組跳動內部,作為統一的資料治理平臺方,我們的目標是:“建立一站式、全鏈路的資料治理解決方案平臺”,治理平臺肩負了四個使命:

第一,讓資料價值最大化。這裡麵包括全生命週期資料質量的保障,既要做到高價值,又能實現低成本。

第二,提供全鏈路解決方案。資料治理在實際過程中會由多個不同角色共同參與,包括了管理者視角和執行者視角。我們希望不同的角色在我們的平臺裡,都能夠運用一些工具、手段來推進治理的執行。

第三,工具和方法論的結合。位元組跳動內部資料治理平臺的建設是以方法論來引導建設,希望工具能夠提供非常完備的治理能力。

第四,提供增強型的治理能力。在系統的能力上可以主動發現一些隱患問題,做一些推薦或者建議的策略來提升治理效率。

在位元組內部,不同角色對資料治理的視角不同。比如,管理者或者是責任者的視角,他們可能會考慮如何去制定一些治理的目標,如何能夠讓組織、團隊來去完成這些治理的指標;他們可能會關注於這個目標什麼時候能夠完成、進度如何;他們也會思考,當他們真得去做了這些治理之後,些資料或者資產是否能夠持續健康。

而從執行者的視角上,則要考慮有資料治理目標下達之後,我該如何去做;我自己有哪些資產,資產有什麼問題;我去做治理的時候,怎麼樣能夠提高治理效率;我能不能及時發現數據資產的問題,並快速治理。

資料治理流程鏈路

因此在整個資料治理的流程中,遵循如下幾個步驟:

第一:我有什麼?比如我的計算任務,資產的儲存,質量的一些規則,SLA的承諾或者一些異常報警,哪些是屬於我的。

第二,清晰知曉治理目標。要知道我要去治理什麼,從哪些開始下手,哪些資產是有問題的,我的一些規則是否是設定的合理的。

第三,怎麼治理。比如在面臨一個具體的治理問題,別人是如何治理的,他們是不是有一些相關的經驗可以借鑑;在具體的實施過程裡,如何去提效治理。

第四,衡量治理效果。也就是我們的治理是否達到了一些目標,或者獲得了哪些收益。

最後,總結與覆盤。做完了整個治理鏈路流程之後的總結,如經驗總結、問題歸納等等。

資料治理解決方案

基於上述是資料治理流程鏈路中涉及到的方方面面,在平臺側我們是如何解決每個流程中對應的問題呢?整體從思路上,劃分為三個維度:

一站式

在建立一站式解決方案裡,我們細分了三層。

第一層:檢視層。這個檢視層就是來滿足我們能夠知道,我們有哪些資產,我們有什麼,我們的目標是什麼,該怎麼制定,這個我們稱之為治理全景層。

第二層:方案層。也就是真正實施去推動這個治理過程的這一層。在這一層裡面我們提出了兩種治理的路徑,一種是主動式的規劃路徑,另二種是系統發現式的路徑。

  • 系統規劃式路徑:契合於從上而下的視角來去滿足於治理的目標,針對它做一些規劃,做了一些規劃之後對相應的資產進行診斷。診斷之後診斷出資產的問題來進行相應的一些問題推進執行,最後到一些收益的統計和總結。這是一個主動規劃的部分。

  • 系統發現式路徑:系統發現這個路徑其實主要解決的是,我怎麼能夠日常的去將我這些資產或者治理問題,能夠持續的進行。日常化治理而不是一個運動式治理方式。這個是基於我們平臺裡面的一些全域性規則來定義,通過系統來去訂閱,定期在系統裡面去進行執行掃描,發現一些資產的問題,通過一些訊息的方式推送到這些資產的責任人,進行一些比如說根因的登記,問題的登記,事故的覆盤,最後進行一些總結和經驗的共享等等;

第三層:工具能力層。即為了滿足於上面的檢視層和方案層,我們在工具側提供的一些能力,包括一些垂直的治理場景和質量,安全成本,穩定性,報警起夜等等方面。還有一些基礎服務來支撐這些我們工具的建設。比如我們會抽出一些訊息的中心,雲資料的中心,規則引擎或者資料服務等等。

上述是我們一站式的思路。

全鏈路

全鏈路是指我們希望治理能夠達到一個閉環的狀態。

在整個鏈路裡面,可能針對於不同的角色,會有一些不同的使用方式,或者是一些執行方式。在整個的路徑裡面會有從資產的檢視來看我們有哪些東西。在這些資產檢視基礎之上去定一些目標和規劃。比如說有些外部驅動的指標,業務驅動的一些指標或者是一些合規或者是政策類的指標等等,來制定我們治理的目標。

針對這些目標,我們去做一些方案的制定。

舉個例子,比如去做一些儲存資產的降低,可能通過一些規則來去圈選出來資產有問題的部分。之後推進這個治理的實施,可能在一些治理決策者或者一些團隊的負責人方面,他可能會去進行一些拉群的督辦,或者是一些定時的訂閱提醒等等。在推進治理方案過程中,還希望資產的責任人,也就是治理的實施者在我們這個平臺工具裡面能夠具體去實施治理的動作,如一些基於SLA的申報、引數的優化、儲存規則的設定、規則的調優等等。

進行了一系列治理之後,我們肯定要有一個驗收的環節,可能會是一個整體指標的驗收,業務是否達標了,指標是否合理,最後進行一些經驗的總結,這個是全鏈路的部分。

當然在全鏈路裡面也包括了剛才所說的這種系統式、掃描式的路徑。這個也是通過一些規則的制定,在系統裡面去發起規則的定義和訂閱。通過系統的掃描去發現一些問題,發現問題之後經過一些實施的治理,可能再反哺到我們具體的一些規則的制定上面去。比如說更進一步配置一些監控規則,來預防治理的一些問題。

這個是全鏈路的部分。

全規則

全規則目標是提供比較完備的治理規則能力,能夠服務於剛才所說的這種規劃式資產組合與響應式資產掃描。這個是在平臺的能力完備性方面的一些考慮。目前我們提供了儲存計算、質量報警等四個維度,現在有數十個這種治理的規則可供任意的圈選和組合。其中包括一些全域性的規則和自定義的規則。

比如全域性規則,比如近7天的產出為空的任務,是否有暴力掃描的任務。或者是一些定義,比如生命週期可以任意選擇一個時間段來去進行掃描或者近xxx天任務為空,把這些任務圈選出來,這些是自定義的部分。

同時還有一些統計類和挖掘類。統計類就是基於資料建設對元資料的應用和加工。舉個例子,比如近90天無訪問表,或者是資料傾斜任務的圈選。挖掘類其實是在元資料的基礎上進行一些更深層次的挖掘,去找到一些資料的問題,比如相似的庫表,相似的任務等。

一站式資料治理平臺架構

上面介紹了我們應對資料治理的解決方案,包括全規則、全鏈路和一站式。接下來,介紹具體的平臺架構。

整體架構

首先在整體的架構部分,這是治理平臺內整體的架構圖。

其中灰色的部分是在平臺透出給使用者的產品能力,包括治理全景。治理全景對應於剛才在一站式的檢視層能夠告訴使用者,有哪些資產,這些資產的情況是怎麼樣的。然後是治理的工作臺。工作臺的部分是針對於治理的實施者,他能夠快速定位或者跳躍到相關一些治理的方案和平臺去進行治理。這個是一些包括待辦項和這些資產的分析等等。之後是一些診斷規劃的部分。也就是服務於主動式規劃這條路徑的一個模組。它會對我們這些資產進行一些規則式的組合,來進行一個最終的診斷。還有一些資源的優化,報警與訂閱和SLA保障等幾個垂直類的治理場景。最後有一個覆盤管理部分,是做經驗總結和沉澱的一個模組,以系統的方式進行記錄。

中間的部分是基於全規則的思想,將儲存規則、計算規則、質量規則和報警規則,呈現在平臺裡,讓使用者來進行自由圈選,達到靈活、全面的目的。

下面綠色層是系統元件層面的一些抽象服務,我們會針對資料治理的典型場景,在底層的基礎設計上做一些抽象,達到靈活適新的規則或者治理場景的目的。

元資料建設

在資料治理裡面,我們認為元資料其實是治理的核心,治理其實是需要元資料來去驅動的。在我們治理工作裡面,元資料建設治理主要有以下五個方面:

第一,元資料的採集。我們會採集底層元件架構的一些資料,yarn佇列,Hive、Spark、Flink等各種元件的資料,以及一些平臺級的元資料採集,包括排程系統,資料地圖、血緣、許可權、任務、儲存、資料應用等平臺的一些元資料,在採集之後,會進行一些系統化的加工,我們遵循於資料倉的層級規範的建設來提升資料的應用性。同時,在加工的過程中也完全遵循於資料治理理念保障資料都是高質可靠。

第二,元資料應用。在元資料應用部分我們會通過元資料倉庫為基礎,給上游的產品平臺提供更多應用的能力支援。

第三,分析部分。我們會制定很多業務的核心指標和一些內部指標,通過一些治理場景使用者的行為分析來發掘一些潛在的資料問題。另外就是會在各個維度去建設各類分析看板。

第四,挖掘部分。這個是在資料上更高一層的應用,我們會推動一些挖掘演算法和機制,去發現一些可治理的問題,比如我們可能會對於一些資料資產的相似性進行挖掘。基於歷史資料對未來的一些預測,比如說一些資料錶行數的不動值預測,一些提效的推薦類挖掘。

最後是元資料的開放部分。我們會和位元組跳動內部各個資料團隊來去合作共建按需開放,提供元資料能力。

產品模組

下面介紹平臺側的產品模組,同樣也可以在火山引擎DataLeap產品中看到。

第一、治理全景。解決有哪些資產問題。目前在平臺上有一些大盤,包括資料的SLA大盤、儲存大盤、計算大盤、報警大盤等等,這些大盤針對於不同的治理場景會有一些不同維度的展示,包括一些資料趨勢,一些佔比列表,或者是一些聚合明細等資料。支撐治理全景的是我們底層的元資料倉庫以及剛才說的資料應用的部分,對資料進行一些加工。

第二、健康分。我們希望健康分能夠衡量資產的健康度,讓資產持續健康。在健康分的建設裡面,我們遵循幾個步驟。第一是首先在健康分的建設裡面,通過元資料倉庫提供健康分的各維度的分析建設,包括一些成員排名。第二個部分是有了這些健康分之後提供更多的維度分析,以及扣分項分析,成本分析,能夠將健康分拆解,拆分成可治理的這樣的專案,有了這些可治理的專案之後,具體關聯到一些資料治理的操作和方案的設計。比如,我們可以針對於一些健康分的扣分項,來跳轉到一些垂直治理的場景介面來去進行一些操作設定或者是做一些規劃式治理方案的關聯。這個是健康分的一些思路。

在健康分的設計方面,我們遵循了一個三層架構的思路。首先第一層是比較大巨集觀的資產層。包括儲存的健康分,計算健康分,資料質量等等。第二層是針對於這一類自辦的一些聚合類指標,包括比如說儲存健康分裡面的無效資料,或者是高效儲存的問題。計算健康分裡面無效任務和高效計算的問題。資料質量方面的SLA或者是監控保障的問題。最後一層是比較詳細的規則層。包括儲存裡面TTL設定,或者是無查詢的一些資產。比如說計算裡面的連續失敗任務或者是資源利用率比較低的一些任務。資料質量裡面的一些SLA的事故數或者是一些監控的缺失、無效報警等等。

在有了資產全景和看板之後,我們其實可以進行一些治理操作,對應於一站式裡面的第二層治理操作的部分。前面介紹到我們其實有兩種路徑,第一類是規劃類的路徑,可能是從一個比較高的視角來去拆解治理的問題。這個路徑裡面,我們是要目標明確,過程可拆解,收益可量化,結果可驗收。

系統設計

最後我們來說一下系統是如何來支撐規劃式的架構呢?

規劃式架構:

在底層的基礎架構設計方面主要有幾個模組。

首先在後端是一個主邏輯的操作部分,包括了剛才所說的規則,治理規則、治理域,一些圈選的能力,資產的查詢和收益的統計,治理目標的制定,治理結果的檢視,治理的催辦和具體的治理操作。

支撐於後端邏輯的部分,有幾個抽象的服務模組。第一個模組是資料查詢服務,主要解決的一個問題是底層不同儲存異構的適配。將這些原資料經過一些上層應用的加工,放到不同應用的儲存裡面來適應不同的查詢型別。通過這個服務來進行一些解耦。這個服務裡面資料的來源就是事件的收集服務,我們會做一些格式的轉換,訊息的處理,包括一些底層元件的關聯和系統回撥和資料採集等等。

同時與這個服務有關聯的就是治理具體實施的模組,這個和系統裡面治理的操作有關。

舉個例子,比如進行一些表的生命週期設定,或者是刪除表等等操作。這些操作都會以訊息的形式,經由執行模組去進行一些任務的下發和底層的元件進行呼叫。通過一些狀態來把治理是否得到一些收益,訊息是否成功,也由剛才的事件收集服務來放到查詢服務裡面,形成收益可查詢的資料。

最後在治理規則和治理域的部分,提供了全規則能力,這部分我們提供了一些規則引擎的服務,包括對規則進行一些解析、查詢轉換,查詢提交以及結果彙總,這個是底層架構對於上述功能的一些支援。

響應式架構:

接下來是響應式的流程,這個和主動式的流程非常像。包括訊息觸發,問題分析,推進治理,問題登記,總結覆盤等等流程。響應式流程的框架和規劃其實也是非常像。

主要有幾個不同的部分。第一是左側有個訊息服務,因為我們這個路徑其實是以訊息來處發的,我們會打通與研發平臺,質量平臺,自然平臺等很多處發訊息和報警的一些平臺,將他們的訊息和報警統一收歸到我們這個服務裡面進行下發。下發的渠道可以有,比如說位元組跳動用的飛書,或者郵件、電話、簡訊等等。這些訊息形成的一些資料也會經由資料的收集放到查詢服務裡面,去做一些報警的展示。另外在訊息這裡,我們會和覆盤模組進行強關聯,對問題進行登記核准覆盤。

最後是工作臺,主要為了提效,解決待治理項,比如說現在有一些待治理的部分需要去處理,能夠儘快去發起這個治理或者說我個人的一些資產情況,這個是工作臺的核心思想。

治理場景的部分主要有質量、資料SLA、資源和報警的部分。

在資源優化場景上的目標主要是能夠提供自主分析和低門檻優化能力。

現在主要集中在儲存和計算兩個方面,並提供了很多的垂直治理的能力。比如,可以在平臺裡面直接設定一些這種溫存、降副本、TTL設定。計算方面,可以直接跳轉任務詳情做分析,任務下線和引數調整建議等等。

最後也談談我們的未來工作展望,如圖所示:

第一個方面是繼續加強我工具閉環能力。第二個方面是從通用資料治理的問題解決到更精細化的一些治理,包括自定義的指標、方案,以業務的視角來看待實際的問題。最後是增強型的資料治理,我們希望是能夠在資料側通過一些統計類、挖掘類,上升為一些演算法和智慧型的這種平臺。

立即跳轉火山引擎大資料研發治理套件 DataLeap 官網瞭解詳情!