從數(shù)倉到數(shù)據(jù)中臺,談技術選型最優(yōu)解
本文根據(jù)顏博老師在〖Deeplus直播第218期〗線上分享演講內容整理而成。
顏博
馬蜂窩數(shù)倉研發(fā)總監(jiān)
現(xiàn)任馬蜂窩數(shù)據(jù)倉庫團隊負責人,曾供職于京東、IBM、亞信等公司。
數(shù)據(jù)行業(yè)老兵一名,歷經(jīng)傳統(tǒng)數(shù)據(jù)倉庫、大數(shù)據(jù)平臺到數(shù)據(jù)中臺的發(fā)展。
大家好,今天分享的議題主要包括幾大內容:
帶大家回顧一下大數(shù)據(jù)在國內的發(fā)展,從傳統(tǒng)數(shù)倉到當前數(shù)據(jù)中臺的演進過程;
我個人認為數(shù)據(jù)中臺的核心組成,以及一些技術選型參考;
數(shù)據(jù)研發(fā)是數(shù)據(jù)中臺很重要的一環(huán),會分享一些我們在數(shù)據(jù)研發(fā)方面的實踐,主要是數(shù)據(jù)倉庫架構與研發(fā)方面。
一、大數(shù)據(jù)演進,從數(shù)據(jù)倉庫到數(shù)據(jù)中臺
21世紀的第一個10年,企業(yè)級數(shù)據(jù)倉庫(EDW)從萌芽到蓬勃發(fā)展,“IOT”( IBM、Oracle、Teradata)占領了大部分市場,提供數(shù)據(jù)倉庫建設從硬件、軟件到實施的整體方案。
這個時代的數(shù)據(jù)倉庫實施不僅需要購買大(中、?。┬蜋C,配套商用的關系型數(shù)據(jù)庫(Oracle、DB2、SQL Server)以及一些ETL/OLAP套件,實施成本相對高昂,數(shù)據(jù)倉庫建設主要集中在金融、電信、大型零售與制造等行業(yè)。
數(shù)據(jù)倉庫的應用主要通過為企業(yè)提供報表、分析等數(shù)據(jù),輔助企業(yè)的經(jīng)營決策。像電信行業(yè)的經(jīng)營分析系統(tǒng)、銀行的風控管理等,都是這個期間比較典型的應用。
2010-2015年,大數(shù)據(jù)平臺階段,移動互聯(lián)網(wǎng)的飛速發(fā)展帶動Bigdata(大數(shù)據(jù))的發(fā)展。其中Hadoop生態(tài)技術開始逐步在國內大范圍使用,企業(yè)只要基于Hadoop分布式的計算框架,使用相對廉價的PC服務器就能搭建起大數(shù)據(jù)集群。
數(shù)據(jù)湖的概念也是這個階段誕生(主要是為降低傳統(tǒng)數(shù)倉較為復雜的中間建模過程,通過接入業(yè)務系統(tǒng)的原始數(shù)據(jù),包括結構化、非結構數(shù)據(jù),借助hadoop生態(tài)強大計算引擎,將數(shù)據(jù)直接服務于應用)。這個階段不只是金融、電信這些行業(yè),國內主流互聯(lián)網(wǎng)企業(yè)也紛紛搭建起大數(shù)據(jù)平臺。
大數(shù)據(jù)應用更為豐富,不僅限于決策分析,基于APP/門戶站點的搜索推薦、以及通過A/B Test來對產(chǎn)品進行升級迭代等是這個階段常規(guī)的應用點,用戶畫像在這個階段也得到重視,主要應用于企業(yè)的營銷、運營等場景。
就是我們現(xiàn)在所處的階段,數(shù)據(jù)中臺以及云上大數(shù)據(jù)階段,通過前10多年不斷的技術積累,大數(shù)據(jù)在方法和組織的變革上也有了新的沉淀,主要體現(xiàn)在幾個方面:
1)數(shù)據(jù)統(tǒng)一化
其核心思想是數(shù)據(jù)流轉的所有環(huán)節(jié)進行統(tǒng)一化,如從采集到存儲到加工等過程,在這些過程中通過建立統(tǒng)一的公共數(shù)據(jù)模型體系、統(tǒng)一的指標與標簽體系,提高數(shù)據(jù)的標準性、易用性,讓數(shù)據(jù)本身更好地連通,提升使用效率。
2)工具組件化
數(shù)據(jù)在采集、計算、存儲、應用過程中涉及多業(yè)務線條,多場景,將這些場景與工具(采集工具、管道工具、計算&調度工具、數(shù)據(jù)服務工具,數(shù)據(jù)管理工具、可視化工具等)進行沉淀,研發(fā)出通用、高效的組件化工具,避免重復開發(fā),降低研發(fā)成本。
3)應用服務化
之前大數(shù)據(jù)應用的數(shù)據(jù)調用比較混雜,有些直接訪問數(shù)倉數(shù)據(jù)表,有些調用臨時接口等。通過數(shù)據(jù)中臺應用服務化建設,提供標準的應用服務,以數(shù)據(jù)可視化產(chǎn)品、數(shù)據(jù)API工具等服務,支撐應用的靈活調用。
4)組織清晰化
數(shù)據(jù)中臺團隊專注于數(shù)據(jù)內容&數(shù)據(jù)平臺開發(fā),提供各種基于數(shù)據(jù)的能力模塊,而其他部門人員如業(yè)務產(chǎn)品、運營、分析等角色,只需要借助工具/產(chǎn)品有效地使用數(shù)據(jù),發(fā)揮其價值,無需關注數(shù)據(jù)加工的過程,做到各盡其職,充分發(fā)揮各自專長,同樣也能達到降本提效目的。大數(shù)據(jù)團隊內部本身組織和職責也傾于清晰化,比如按照職責分為平臺(工具)研發(fā)、數(shù)據(jù)研發(fā)、數(shù)據(jù)產(chǎn)品、數(shù)據(jù)分析等不同組織。
數(shù)據(jù)應用到各個角落,除了之前可以支撐的決策分析以外,大數(shù)據(jù)與線上事務系統(tǒng)(OLTP)的聯(lián)動場景非常多,比如我們在電商平臺查詢個人所有歷史訂單,再比如一些刷單、反作弊的實時攔截,以及一些實時推薦等,這些都是通過將數(shù)據(jù)的運算交給數(shù)據(jù)中臺部門處理,前臺部門直接通過API進行結果調用。數(shù)據(jù)中臺的集中化建設也更好地支撐起創(chuàng)新業(yè)務,比如通過大數(shù)據(jù)+分析建立起商業(yè)化數(shù)據(jù)變現(xiàn)產(chǎn)品,進行數(shù)據(jù)售賣,把數(shù)據(jù)變成新的業(yè)務。
大家知道共享復用是中臺建設中很關鍵的一個詞,這也是為什么我們很多數(shù)據(jù)中臺下面會包括共享數(shù)據(jù)組,公共數(shù)據(jù)組等。實際上共享復用并不是大數(shù)據(jù)發(fā)展的一個新詞,在早期數(shù)據(jù)倉庫(建立公共數(shù)據(jù)模型)、大數(shù)據(jù)平臺(研發(fā)一些組件化工具)的建設中,也是滿足共享復用的。
如上提到,數(shù)據(jù)中臺本身是組織,方法的升級與變革,更多是利用技術的進步更好地支持這些升級變革,如果你當前的建設還是數(shù)據(jù)平臺+數(shù)倉(數(shù)據(jù)湖等)但是已經(jīng)具備這些方法和特性,我個人認為也是合理的。
數(shù)據(jù)中臺的建設也需要相應的成本與門檻,例如集群搭建、工具建設等。云計算的發(fā)展可以快速提供數(shù)據(jù)中臺建設的能力,例如企業(yè)無需自己搭建機房,使用云計算的彈性計算存儲能力以及豐富的工具,可以支撐數(shù)據(jù)中臺的快速搭建。
關于數(shù)據(jù)中臺的合理性也一直頗有爭議,大型(集團型)公司有相互獨立的子公司,數(shù)據(jù)之間不需要太多連接與共享,分別構建自己子數(shù)據(jù)中臺也是合理的架構,集團層面可以利用數(shù)據(jù)子中臺進行數(shù)據(jù)上報解決集團層面數(shù)據(jù)大盤、統(tǒng)計、分析、財務等訴求。再比如一些小型公司是否需要在一開始就按照數(shù)據(jù)中臺的架構進行建設,也是存有一些爭議。
數(shù)據(jù)中臺是2015年阿里提出來的雙中臺的概念其中的一個重要組成,阿里作為先驅者,提供了數(shù)據(jù)中臺架構、以及非常多的建設思路供大家參考。從目前的建設效果來看,很多公司在數(shù)據(jù)中臺建設中有不錯的成效(尤其是大中型公司),數(shù)據(jù)中臺整體思路得到了驗證。但是數(shù)據(jù)中臺本身還算一個新鮮事務,這個新鮮事務目前還沒有標準答案,只有參考答案。
二、數(shù)據(jù)中臺架構與技術選型
我認為的數(shù)據(jù)中臺核心架構包括四大組成部分,具體是:
底座是數(shù)據(jù)基礎平臺,包括數(shù)據(jù)采集平臺&計算平臺&存儲平臺,這些可以自建也可以使用云計算服務;
中間部分兩大塊是中臺的公共數(shù)據(jù)區(qū),公共數(shù)據(jù)區(qū)包括數(shù)據(jù)倉庫(數(shù)據(jù)湖) ,主要負責公共數(shù)據(jù)模型研發(fā),還包括統(tǒng)一指標(標簽)平臺,負責把模型組織成可以對外服務的數(shù)據(jù),例如數(shù)據(jù)指標、數(shù)據(jù)標簽;
上層是數(shù)據(jù)應用服務層,主要將公共數(shù)據(jù)區(qū)的數(shù)據(jù)對外包裝并提供服務,包括數(shù)據(jù)接口平臺、多維查詢平臺,數(shù)據(jù)可視化平臺、數(shù)據(jù)分析平臺等。
另外,數(shù)據(jù)研發(fā)平臺和數(shù)據(jù)管理平臺貫穿始終,其中:
1)數(shù)據(jù)開發(fā)平臺包括數(shù)據(jù)開發(fā)的各類工具組合,例如:數(shù)據(jù)管道工具(比如數(shù)據(jù)接入、數(shù)據(jù)導出)、模型設計工具、腳本開發(fā)工具、數(shù)據(jù)調度工具等。
2)數(shù)據(jù)管理平臺包括統(tǒng)一元數(shù)據(jù)管理、數(shù)據(jù)質量管理、數(shù)據(jù)生命周期管理。針對數(shù)據(jù)全鏈路的數(shù)據(jù)管理,保證數(shù)據(jù)中臺可以監(jiān)控數(shù)據(jù)鏈路中的數(shù)據(jù)流向、數(shù)據(jù)使用效果、數(shù)據(jù)生命周期,以衡量數(shù)據(jù)的價值與成本。
以上是數(shù)據(jù)中臺的核心部分,數(shù)據(jù)中臺的組成也可以更加豐富,比如包括:數(shù)據(jù)資產(chǎn)平臺、算法平臺等等。
在數(shù)據(jù)中臺的建設中一定不要忽視的是與業(yè)務的銜接,因為數(shù)據(jù)來源于業(yè)務并最終應用于業(yè)務,在數(shù)據(jù)中臺的建設中需要有一系列的流程制度明確與業(yè)務的充分銜接,以保障數(shù)據(jù)源&數(shù)據(jù)產(chǎn)出的質量。
在搭建數(shù)據(jù)中臺方面,基于開源技術的選型,尤其是Hadoop生態(tài)圈有非常多的選擇,從數(shù)據(jù)整體流向來看各大層級的選型。
數(shù)據(jù)抽取層:sqoop和flume是兩大主流工具,其中sqoop作為結構化數(shù)據(jù)(關系型數(shù)據(jù)庫)離線抽取,flume作為非結構化日志接入;
數(shù)據(jù)存儲層:Hadoop文件系統(tǒng)Hdfs大家都比較了解,而kafka作為流式數(shù)據(jù)總線應用也非常廣泛;
計算與調度層,包括:
離線計算:離線計算主要是hive,spark,也有部分選用tez
實時計算:前些年storm,spark比較流行,最近幾年大家紛紛往Flink轉型
數(shù)據(jù)調度:除了像Airflow Azkaban Oozie等,易觀開源的Dolphin-scheduler也非?;钴S
數(shù)據(jù)引擎層:也就是我們常說的OLAP層,我們看到這一層里的選擇非常多,就不一一列舉了,(業(yè)務需求帶動技術進步的典型,選擇豐富主要是可以適配不同的數(shù)據(jù)應用場景)。從概念上講分為ROLAP、MOLAP以及兩者混搭。MOLAP提前做一些預計算,以生成Cube的方式,達到空間換取查詢效率;而ROLAP是即查即用,效率完全取決于查詢引擎的性能,我個人認為從將來看,ROLAP的趨勢會更加明顯,因為沒有中間的數(shù)據(jù)鏈路。但目前看來,沒有一個統(tǒng)一的引擎足以支撐各類數(shù)據(jù)場景(這或許是將來的機會~);
數(shù)據(jù)可視化層:比較主流的有Metabase、Superset、Redash,也可以選擇阿里、百度的一些開源控件。
在開源技術的選擇里,我們看到各層里都有越來越多國內開源的工具(也充分體現(xiàn)了我們在大數(shù)據(jù)技術領域的進步)。除了以上列舉的這些,整個Hadoop生態(tài)圈的技術選擇非常多,可以結合自己的實際場景選擇自己的架構,在選型層面可以參照的一些原則,比如:
是否有鮮活的成功案例,優(yōu)先找自己類似業(yè)務場景;
接口的開放性,與其他組件的兼容性;
社區(qū)活躍性度&發(fā)展趨勢。
當然,數(shù)據(jù)中臺的選型不只是開源技術,開源本身也不是完美的,例如維護開發(fā)成本較高,升級迭代不好把控,通過開源技術去建立數(shù)據(jù)中臺還是有一定研發(fā)門檻。
所以也有很多商業(yè)化的套件、以及基于云的數(shù)據(jù)組件可以選擇,包括數(shù)據(jù)采集、處理、分析、數(shù)據(jù)可視化全過程,國內外有很多廠商都提供了豐富的選擇。尤其在大數(shù)據(jù)可視化這塊,國內有許多非常專業(yè)的商業(yè)套件。
三、數(shù)據(jù)研發(fā)實踐
下面是一個簡單的數(shù)據(jù)處理架構演進過程:
最早數(shù)據(jù)倉庫的計算只支持批處理,通常是按天定時處理數(shù)據(jù),在后期逐步進化到準實時,本質上還是批處理,只是處理頻度上得有提升,到小時級,或者15分鐘這種。
隨著技術不斷進步,后期演化出一條新的流處理鏈路,這個鏈路和之前的批處理分別處理,然后在服務層面利用大數(shù)據(jù)的計算能力進行合并,向外提供離線+實時數(shù)據(jù)服務,這也是著名的lambda架構。
最近幾年隨著Flink等技術的發(fā)展,有一個趨勢是流批一體化,在接入層統(tǒng)一采用流式接入,計算層采用統(tǒng)一套框架支持實時計算+離線計算,批處理僅僅作為流處理的一個特殊場景進行支持。整體上可以做到流處理、批處理的自由切換。
流計算和批處理在需求場景上有一些本質區(qū)別,前者主要用于支持線上業(yè)務場景(比如互聯(lián)網(wǎng)的推薦、搜索、風控等),而批處理更多是支持離線統(tǒng)計分析。
日出而作,日落而息,大家針對大數(shù)據(jù)的統(tǒng)計分析習慣不會發(fā)生根本性變化,最簡單的T+1批處理方式也還是數(shù)據(jù)應用必不可少的環(huán)節(jié)。在使用同一套架構上,由于數(shù)據(jù)源變化&維度變化的多樣性,批處理往往面臨一些復雜場景,這是采用同一套框架上的一些難點,充分支持好批處理也是將來流批一體框架的發(fā)展方向。
1)數(shù)倉分層
與傳統(tǒng)ETL不同的,我們采用的是ELT的數(shù)據(jù)架構,較為適合在互聯(lián)網(wǎng),總體分為業(yè)務數(shù)據(jù)層、公共數(shù)據(jù)層、應用數(shù)據(jù)層三大層次。
① 業(yè)務數(shù)據(jù)層(ODS層)
原始數(shù)據(jù)經(jīng)過緩沖層(STG)的加載,會進入數(shù)倉的業(yè)務數(shù)據(jù)層,這一層采用范式建模,基本保持與數(shù)據(jù)源完全一致的結構,對于變化的數(shù)據(jù),使用數(shù)據(jù)拉鏈加工與存儲。
這一層選用范式建模,是指保持源系統(tǒng)(例如關系數(shù)據(jù)庫)的范式結構,好處主要是:
一次性接入數(shù)據(jù)源結構,針對需求的變動不用頻繁去與數(shù)據(jù)源對接;
便于業(yè)務研發(fā)更好地理解數(shù)據(jù),同時是也是公司的原始數(shù)據(jù)資產(chǎn)。
針對變化數(shù)據(jù)采用數(shù)據(jù)拉鏈的好處:
保留歷史數(shù)據(jù)的同時,盡可能少占用存儲空間,長期來看,拉鏈存儲比起每天全量保留歷史節(jié)約大概90%空間;
快速、高效地獲取歷史任意一天業(yè)務系統(tǒng)的快照數(shù)據(jù)。
② 公共數(shù)據(jù)層(包括公共明細層DWD,公共匯總層DWS)
公共數(shù)據(jù)層是數(shù)據(jù)倉庫的核心層,是整個數(shù)倉中使用率最高的,這一層主要采用的維度建模思路進行設計,類型包括事務事實、周期快照、累積快照。同時為了方便下游對數(shù)據(jù)的使用,我們會設計一系列的寬表模型,將不同業(yè)務過程中的事實進行統(tǒng)一整合,包括縱向整合&橫向整合;對于商品、用戶主數(shù)據(jù)類可能分散在不同的源系統(tǒng)中采用縱向整合;橫向整合主要包括交易、內容等行為數(shù)據(jù)不同業(yè)務過程的整合,比如:用戶(用戶信息、注冊信息)購買(下單、支付、結算、覆約、完成)商品(商品信息,商家信息,等),我們會把訂單流轉業(yè)務過程整合放到一張明細表里,同時會研發(fā)一些基于用戶、或者商品視角的輕度匯總寬表。
寬表非常便于理解和易用,下游應用調用也方便。我們之前也做過一些統(tǒng)計,在調用分布來看,寬表的使用占到70%以上。
雖然寬表的使用在數(shù)倉建模中非常普遍,但是也有一些缺陷:
數(shù)據(jù)冗余較多,在存儲、計算、調用較為占資源,建議盡量還是按場景去使用;
寬表整合的信息較多,數(shù)據(jù)權限不好控制。建議可以根據(jù)需求,在有限范圍內開放整體寬表權限,或者通過視圖或者子表的方式建立不同權限的數(shù)據(jù)范圍,適應不同組織的需求;
寬表通常依賴比較多,會影響數(shù)據(jù)的產(chǎn)出的時效。
③ 應用數(shù)據(jù)層(DWA層)
顧名思義,就是偏向應用的數(shù)據(jù)加工,也可以叫集市層,這一層的設計可以相對靈活,貼近應用即可,總體設計思想仍然可以按維度建模思想為主。
2)主題分類
數(shù)倉架構的數(shù)據(jù)分類兩個視角,包括主題視角與業(yè)務視角。
① 數(shù)據(jù)主題視角
最重要的一個視角,也就是咱們經(jīng)常提到的數(shù)倉主題,主題是將企業(yè)的業(yè)務進行宏觀數(shù)據(jù)抽象,是數(shù)據(jù)倉庫里數(shù)據(jù)的主要組織形式,劃分方法如下:
參照波特價值鏈,分析企業(yè)本身經(jīng)營的業(yè)務(基本活動、支持型活動),分別對應哪些數(shù)據(jù);
參照業(yè)界通用模型,例如像IBM、TD等針對大型行業(yè)(如電信、金融、零售)有一些數(shù)據(jù)主題的通用劃分方法;
對企業(yè)的內部數(shù)據(jù)(線上數(shù)據(jù)模塊、數(shù)據(jù)字典)進行摸底,確認對應到哪些主題。
劃分結果會按照三個層級:主題域--》主題--》子主題。
第一級是主題域,針對相對穩(wěn)定的主題進行合并,歸攏到主題域,利于數(shù)據(jù)的理解與建立全局的數(shù)據(jù)資產(chǎn)目錄;
第二級是主題;
第三級是子主題,主要針對有些主題下分類較多,比如供應鏈主題下會包含采購、倉儲、配送等子主題。
數(shù)據(jù)主題劃分建議完全互斥,不建議重復。
② 數(shù)據(jù)業(yè)務視角
數(shù)據(jù)業(yè)務域是根據(jù)企業(yè)經(jīng)營的具體業(yè)務,結合企業(yè)的組織架構進行劃分,層次和分類可以相對靈活,子分類可以允許重復,因為兩條不同的業(yè)務域可能經(jīng)營相同的業(yè)務,例如電商、內容下都有會員這個業(yè)務。
上圖是一個比較典型的內容+電商的數(shù)據(jù)主題與業(yè)務分類。
以上一橫一縱兩個視角,將數(shù)據(jù)進行更好的歸類,在數(shù)據(jù)模型設計中會打上相應分類標簽,從而讓數(shù)據(jù)研發(fā)&數(shù)據(jù)使用人員統(tǒng)一認知。以上兩種分類方式主要應用于核心的公共數(shù)據(jù)層。
業(yè)務數(shù)據(jù)層、應用數(shù)據(jù)層并不需要遵循以上分類規(guī)則,比如業(yè)務數(shù)據(jù)層(ODS層)是按照數(shù)據(jù)源進行分類,應用數(shù)據(jù)層(DWA)是根據(jù)具體的應用進行分類。
除了合理的架構之外,數(shù)據(jù)研發(fā)的流程也很重要,總體流程如下:
包括需求分析/數(shù)據(jù)調研、數(shù)據(jù)模型設計、數(shù)據(jù)開發(fā)&測試、上線發(fā)布等流程。
在之前數(shù)據(jù)中臺的核心架構提到不閉門造車,數(shù)據(jù)研發(fā)需要與業(yè)務部門充分銜接,比如在數(shù)據(jù)調研中要與業(yè)務研發(fā)同學進行線上數(shù)據(jù)&結構訪談;在數(shù)據(jù)開發(fā)中,與分析&業(yè)務同學共同確認標準口徑;在數(shù)據(jù)研發(fā)完成后對數(shù)據(jù)使用方進行數(shù)據(jù)發(fā)布與培訓。
以上流程中,除了需求調研,其他部分我們都進行了線上化,包括數(shù)據(jù)的模型設計,早期我們會手寫mapping文檔,后期我們逐步把mapping文檔進行了線上化,整體的數(shù)據(jù)模型設計通過模型設計工具完成,包括從概念模型、邏輯模型到物理模型的設計。模型設計完成后,可以一鍵生成數(shù)據(jù)知識文檔。
數(shù)據(jù)研發(fā)完成,還需要關注數(shù)據(jù)生命周期,一方面數(shù)據(jù)量的飛速增長不僅僅需要占用大量存儲,比如像自建機房,會涉及擴充機柜、機房,往往會面臨一些瓶頸;另外一方面,大量的數(shù)據(jù)會降低數(shù)據(jù)的計算效率,所以從數(shù)據(jù)的生成開始,我們就需要考慮生命周期,并且結合數(shù)據(jù)的使用情況制定數(shù)據(jù)歸檔、數(shù)據(jù)銷毀等管理策略。
針對數(shù)據(jù)已經(jīng)占用了大量存儲資源,可以采取一系列措施進行成本控制,例如:
降存量:通過數(shù)據(jù)壓縮技術、降副本等方式,以及在數(shù)據(jù)模型更合理的設計,將存量數(shù)據(jù)存儲降低;
控增量:根據(jù)數(shù)據(jù)重要性,可恢復性等考量角度,確認數(shù)據(jù)的保留周期,并根據(jù)周期自動歸檔或刪除;
攤成本:可以通過一些算法,比如數(shù)據(jù)調用分布、需求來源等,把成本分攤到相應業(yè)務部門,讓相關業(yè)務部門關注到成本。
數(shù)據(jù)安全也是數(shù)據(jù)生命周期管理重的一個重要課題,比如針對用戶敏感信息,需要在接入時考慮如何加密。一種做法是通過一個獨立的物理集群對敏感數(shù)據(jù)進行隔離與強管控;數(shù)據(jù)使用中,也需要將數(shù)據(jù)劃分不同的安全或敏感等級(例如有些財務數(shù)據(jù)的非常敏感,需要謹慎對外開放),根據(jù)不同的等級設定不同的訪問審批機制。另外,在數(shù)據(jù)歸檔、銷毀也需要制定好配套的安全管理措施,避免安全風險。
數(shù)據(jù)質量管理主要包括3個角度:準確性、及時性、一致性。
管理的環(huán)節(jié)包括:事前、事中、事后、以及事故管理。
針對數(shù)據(jù)運維的告警發(fā)送,傳統(tǒng)的方式主要是短信、郵件、電話;隨著移動辦公工具功能逐步的強大,可以將運維告警以數(shù)據(jù)接口的方式與這些工具進行對接,將告警發(fā)送到企業(yè)內部的即時通訊工具。
數(shù)據(jù)研發(fā)最終還是需要賦能到業(yè)務&應用,一個合理的數(shù)據(jù)應用架構是非常關鍵的,這張圖是一個應用架構的簡圖參考:
從數(shù)據(jù)的流向上分:
數(shù)據(jù)倉庫(或者數(shù)據(jù)湖):負責原始數(shù)據(jù)的計算,主要將數(shù)據(jù)落地到HDFS;
數(shù)據(jù)引擎層:數(shù)據(jù)加工完成之后,會將數(shù)據(jù)推送到不同的引擎中,這一層之前提到選擇非常多,可以根據(jù)自己的場景選擇一個混搭組合,比如我們目前選擇的有Presto,Kylin,Druid,Mysql;
數(shù)據(jù)服務層:通過統(tǒng)一化的SQL調用服務,屏蔽底層不同的數(shù)據(jù)引擎,為上層統(tǒng)一查詢提供標準接口;
指標平臺:指標平臺是一個非常關鍵的產(chǎn)品,定位于銜接數(shù)據(jù)研發(fā)與數(shù)據(jù)應用,包括指標的標準定義、邏輯、計算方式、分類等各項內容。指標分類上我們分為標準指標(指標口徑經(jīng)過審核過)、以及非標準指標;
多維查詢:這是我們的一個即席查詢工具,查詢的數(shù)據(jù)主要來源指標平臺,可以選定不同的指標維度組合進行結果呈現(xiàn),用戶可以一次性查詢得到結果,也可以將查詢結果配置成可視化的報表進行固化。
中間是統(tǒng)一元數(shù)據(jù)管理:對整個架構中可以對外提供服務的元數(shù)據(jù)進行統(tǒng)一管理(包括數(shù)倉的元數(shù)據(jù)、查詢引擎的元數(shù)據(jù)、指標元數(shù)據(jù)等),以及監(jiān)控這些元數(shù)據(jù)的調用情況。
最右側是權限管理:權限管理關乎到數(shù)據(jù)安全,在設計上需要考慮周全,比如針對表級、指標級、維度級別都可以進行控制;同時產(chǎn)品層面也需要靈活配置權限審批級別與人員。
在面向用戶使用層面,我們主要開放的是多維查詢&可視化,用戶通過多維去查詢各類指標&維度數(shù)據(jù),得到數(shù)據(jù)結果列表,再選擇可視化配置面板,完成各類圖表、表格的自主配置,并發(fā)布到個人看板或者業(yè)務大盤目錄里。也可以將配置的數(shù)據(jù)看板進行靈活組合,定制成一個小型的數(shù)據(jù)產(chǎn)品。
在數(shù)據(jù)研發(fā)中,也要考量數(shù)據(jù)的ROI,下面是一個簡單的ROI模型:
根據(jù)活躍度(調用次數(shù)等)、覆蓋度(通過血緣關系找出依賴數(shù)量),以及貢獻度(依賴數(shù)據(jù)的重要等級)來確認數(shù)據(jù)的價值。同時會評估數(shù)據(jù)的成本指數(shù)(例如計算成本、存儲成本等)。
通過以上兩者相除,綜合得到數(shù)據(jù)的ROI,針對ROI可以將數(shù)據(jù)分為不同等級,并相應進行數(shù)據(jù)治理。比如針對價值低,成本高的數(shù)據(jù),可以考慮下線等。
數(shù)據(jù)研發(fā)趨勢&關注點
提效:目前借助工具的研發(fā)可以把絕大部分數(shù)據(jù)研發(fā)工作線上化,將來借助AI等能力,實現(xiàn)數(shù)據(jù)處理中包括開發(fā)、運維的自動化,提升處理效率;
靈活:流批一體化,包括流處理與批處理自由切換,之前已經(jīng)提到過,個人認為也是一個發(fā)展的趨勢;
降本:數(shù)據(jù)研發(fā)鏈路的成本控制,在數(shù)據(jù)建設的早期通常不太引起關注,隨著數(shù)據(jù)量不斷的積累,往往存儲、計算成本成為瓶頸。針對數(shù)據(jù)建設成本需提前考慮;
算力:我們看到Google,IBM和阿里都在研究量子計算,將來的數(shù)據(jù)中間層(比如數(shù)倉的公共模型)是否可以考慮虛擬化(比如只保留規(guī)則&數(shù)據(jù)結構),具體數(shù)據(jù)內容在應用發(fā)起時,即調即用,更多時候可以不需要占用存儲資源。算力的不斷提升,有可能會顛覆一些傳統(tǒng)數(shù)據(jù)建設的思路。
Q&A
Q1:請問貴公司如何壓縮數(shù)據(jù)?又如何刪除副本呢?
A:我們主要使用parquet +snappy壓縮;另外,如果發(fā)現(xiàn)壓縮率較低,可以通過排序來調整數(shù)據(jù)分布,降副本可以了解下EC糾刪碼技術。
Q2:對于批處理效率低的問題該怎么處理?
A:具體可以看什么原因導致,如果是整體效率低,可以看資源利用是否集中,如果集中,可以考慮任務分等級錯峰進行隊列隔離等;如果是個別任務問題,那就要考慮邏輯和加工鏈路是否有問題,比如說可以全量改增量處理,邏輯參數(shù)優(yōu)化;如果傾斜導致可以針對具體傾斜原因采取不同的優(yōu)化方式。
Q3:請問基于Hadoop生態(tài)組件構建DW存在哪些不足?與MPP比較?
A:如果之前一直是按照傳統(tǒng)商業(yè)套件進行建設,可能在數(shù)據(jù)不能直接update這個點上不習慣。另外大部分技術都是經(jīng)歷反復演進才達到穩(wěn)定的,所以最好能選用成熟組件。與MPP比較,MPP橫向擴充到一定規(guī)??赡軙衅款i,而Hadoop集群可以靈活擴充節(jié)點來增加算力,比如現(xiàn)在國內單集群幾千臺、上萬臺的場景都有。
Q4:數(shù)據(jù)中臺建設團隊的KPI怎么評定?
A:需求響應效率、前臺數(shù)據(jù)調用效率、數(shù)據(jù)覆蓋度、數(shù)據(jù)準確性、及時性、用戶滿意度、成本控制效果等。
Q5:您對HATP在行業(yè)應用趨勢和方向如何看?
A:HATP我個人沒有研究;如果HATP能解跨不同環(huán)境之間的數(shù)據(jù)連通性,應該可以替代一些當前大數(shù)據(jù)的應用場景。
Q6: 對于搭建數(shù)據(jù)中臺的生態(tài)工具,有什么建議嗎?
A:文中有一些常規(guī)的選型(主要調研了當前一些主流工具),基本上都是經(jīng)過了驗證過,更多還是找適合自己場景的工具。
Q7:請問現(xiàn)在對提效方面有什么好的開源的線上工具嗎?
A:建模、開發(fā)中的一些提效小工具成本不高可以考慮自研,但是復雜一些例如任務調度完全可以找到成熟的開源工具。
Q8:范式建模層,是否會形成統(tǒng)一數(shù)據(jù)模型,即one model?
A:不會,范式主要應用在業(yè)務數(shù)據(jù)層,原則上我們不對外提供這一層的服務,主要用于加工DW層。
Q9:業(yè)務數(shù)據(jù)層,如果設計成拉鏈表,抽取數(shù)據(jù)是肯定是做更新插入操作,增量和存量數(shù)據(jù)做比對,很耗性能,特別是存量數(shù)據(jù)是海量的情況下,請問下如何處理此類問題?
A:大表拉鏈效率慢優(yōu)化可以考慮減少計算數(shù)據(jù)量,例如把穩(wěn)態(tài)數(shù)據(jù)進行歸檔,不參與計算?;蛘呖梢試L試通過冷熱數(shù)據(jù)分離,再視圖合并。
Q10:請問mapping是建模管理的?是否用用ERWIN或者PD工具吧?
A:以前我們是通過excel模版建模并生成mapping文檔,現(xiàn)在只是把這個模版搬到線上,這個小工具可以連通到建表,并且發(fā)布到數(shù)據(jù)知識系統(tǒng)。我們沒有使用ERWIN或者PD,模型之間的關系會輔助用一些思維導圖軟件。
Q11:為什么要基于Hive建數(shù)倉?它不支持索引、更新、事務。
A:Hive 搭建數(shù)倉當前來看處理效率、穩(wěn)定性都是經(jīng)過驗證過的。更新可以通過高效的insert over write來解決。
Q12:數(shù)據(jù)湖是什么技術?跟數(shù)倉的關系是啥?
A:跟數(shù)倉是兩個獨立的概念,通過直接接入源系統(tǒng)的原始數(shù)據(jù)(包括結構化、非結構化),利用大數(shù)據(jù)強大的計算能力,直接將數(shù)據(jù)服務于應用。主要為縮短傳統(tǒng)數(shù)倉的中間建模與處理(ETL)過程,目前有看到一些云+數(shù)據(jù)湖的方案。
Q13:業(yè)務元數(shù)據(jù)、技術元數(shù)據(jù)在中臺中如何統(tǒng)一對應管理?
A:通過統(tǒng)一元數(shù)據(jù)管理工具例如指標元數(shù)據(jù)管理工具、數(shù)據(jù)表元數(shù)據(jù)管理工具,可以將業(yè)務元數(shù)據(jù)對應到技術元數(shù)據(jù),建議可以在工具中設置一些強規(guī)范,來保證統(tǒng)一對應。
Q14:使用kylin做olap很不靈活,貴公司是使用kylin嗎?您認為kylin主要是用于什么場景?
A:是的,大部分場景使用的是kylin,kylin主要使用用業(yè)務形態(tài)相對穩(wěn)定、計算的維度指標矩陣相對固定、原始數(shù)據(jù)量較大且有去重類指標計算的情況。通過一些模型設計和技術手段可以相對降低kylin靈活性差的問題,比如:模型設計的抽象化、底層使用視圖、使用Hybrids進行橋接等。
Q15:貴司數(shù)據(jù)治理工具用的哪個?
A:目前沒有專門的工具,從一開始保持數(shù)據(jù)的規(guī)范化建設、合理的架構,可以降低治理的工作;如果要治理可以考慮通過全鏈條元數(shù)據(jù)管理過程配合數(shù)據(jù)治理。
Q16:所講的體系如何保障數(shù)據(jù)業(yè)務化的、端到端的實時應用?
A:我們目前的場景還不多,可以了解其他互聯(lián)網(wǎng)場景豐富一些方案。如果是支撐端到端的實時應用,要保證穩(wěn)定性需要在服務層有多種調用方案,例如針對同一個應用,可以有常規(guī)API調用以及降級API。
Q17:關于指標體庫如何設計?以及ad-hoc查詢場景的支持。
A:我們預計在5、6月會組織一次《數(shù)據(jù)模型設計實踐》以及《指標體系與ad-doc》的直播分享,會有專門負責這塊數(shù)據(jù)架構的小伙伴來給大家介紹。
特別推薦一個分享架構+算法的優(yōu)質內容,還沒關注的小伙伴,可以長按關注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!