本文根據顔博老師在〖deeplus直播第218期〗線上分享演講内容整理而成。（文末有擷取本期ppt&回放的途徑，不要錯過）
顔博
馬蜂窩數倉研發總監
現任馬蜂窩資料倉庫團隊負責人，曾供職于京東、ibm、亞信等公司。
資料行業老兵一名，曆經傳統資料倉庫、大資料平台到資料中台的發展。
大家好，今天分享的議題主要包括幾大内容：
帶大家回顧一下大資料在國内的發展，從傳統數倉到目前資料中台的演進過程；
我個人認為資料中台的核心組成，以及一些技術選型參考；
資料研發是資料中台很重要的一環，會分享一些我們在資料研發方面的實踐，主要是資料倉庫架構與研發方面。
一、大資料演進，從資料倉庫到資料中台
第一階段
21世紀的第一個10年，企業級資料倉庫（edw）從萌芽到蓬勃發展，“iot”( ibm、oracle、teradata)占領了大部分市場，提供資料倉庫建設從硬體、軟體到實施的整體方案。
這個時代的資料倉庫實施不僅需要購買大（中、小）型機，配套商用的關系型資料庫（oracle、db2、sql server）以及一些etl/olap套件，實施成本相對高昂，資料倉庫建設主要集中在金融、電信、大型零售與制造等行業。
資料倉庫的應用主要通過為企業提供報表、分析等資料，輔助企業的經營決策。像電信行業的經營分析系統、銀行的風控管理等，都是這個期間比較典型的應用。
第二階段
2010-2015年，大資料平台階段，移動網際網路的飛速發展帶動bigdata(大資料)的發展。其中hadoop生态技術開始逐漸在國内大範圍使用，企業隻要基于hadoop分布式的計算架構，使用相對廉價的pc伺服器就能搭建起大資料叢集。
資料湖的概念也是這個階段誕生（主要是為降低傳統數倉較為複雜的中間模組化過程，通過接入業務系統的原始資料，包括結構化、非結構資料，借助hadoop生态強大計算引擎，将資料直接服務于應用）。這個階段不隻是金融、電信這些行業，國内主流網際網路企業也紛紛搭建起大資料平台。
大資料應用更為豐富，不僅限于決策分析，基于app/門戶站點的搜尋推薦、以及通過a/b test來對産品進行更新疊代等是這個階段正常的應用點，使用者畫像在這個階段也得到重視，主要應用于企業的營銷、營運等場景。
第三階段
就是我們現在所處的階段，資料中台以及雲上大資料階段，通過前10多年不斷的技術積累，大資料在方法群組織的變革上也有了新的沉澱，主要展現在幾個方面：
1）資料統一化
其核心思想是資料流轉的所有環節進行統一化，如從采集到存儲到加工等過程，在這些過程中通過建立統一的公共資料模型體系、統一的名額與标簽體系，提高資料的标準性、易用性，讓資料本身更好地連通，提升使用效率。
2）工具元件化
資料在采集、計算、存儲、應用過程中涉及多業務線條，多場景，将這些場景與工具（采集工具、管道工具、計算&排程工具、資料服務工具，資料管理工具、可視化工具等）進行沉澱，研發出通用、高效的元件化工具，避免重複開發，降低研發成本。
3）應用服務化
之前大資料應用的資料調用比較混雜，有些直接通路數倉資料表，有些調用臨時接口等。通過資料中台應用服務化建設，提供标準的應用服務，以資料可視化産品、資料api工具等服務，支撐應用的靈活調用。
4）組織清晰化
資料中台團隊專注于資料内容&資料平台開發，提供各種基于資料的能力子產品，而其他部門人員如業務産品、營運、分析等角色，隻需要借助工具/産品有效地使用資料，發揮其價值，無需關注資料加工的過程，做到各盡其職，充分發揮各自專長，同樣也能達到降本提效目的。大資料團隊内部本身組織和職責也傾于清晰化，比如按照職責分為平台（工具）研發、資料研發、資料産品、資料分析等不同組織。
目前階段
資料應用到各個角落，除了之前可以支撐的決策分析以外，大資料與線上事務系統（oltp）的關聯場景非常多，比如我們在電商平台查詢個人所有曆史訂單，再比如一些刷單、反作弊的實時攔截，以及一些實時推薦等，這些都是通過将資料的運算交給資料中台部門處理，前台部門直接通過api進行結果調用。資料中台的集中化建設也更好地支撐起創新業務，比如通過大資料+分析建立起商業化資料變現産品，進行資料售賣，把資料變成新的業務。
大家知道共享複用是中台建設中很關鍵的一個詞，這也是為什麼我們很多資料中台下面會包括共享資料組，公共資料組等。實際上共享複用并不是大資料發展的一個新詞，在早期資料倉庫（建立公共資料模型）、大資料平台（研發一些元件化工具）的建設中，也是滿足共享複用的。
如上提到，資料中台本身是組織，方法的更新與變革，更多是利用技術的進步更好地支援這些更新變革，如果你目前的建設還是資料平台+數倉（資料湖等）但是已經具備這些方法和特性，我個人認為也是合理的。
資料中台的建設也需要相應的成本與門檻，例如叢集搭建、工具建設等。雲計算的發展可以快速提供資料中台建設的能力，例如企業無需自己搭建機房，使用雲計算的彈性計算存儲能力以及豐富的工具，可以支撐資料中台的快速搭建。
關于資料中台的合理性也一直頗有争議，大型（集團型）公司有互相獨立的子公司，資料之間不需要太多連接配接與共享，分别建構自己子資料中台也是合理的架構，集團層面可以利用資料子中台進行資料上報解決集團層面資料大盤、統計、分析、财務等訴求。再比如一些小型公司是否需要在一開始就按照資料中台的架構進行建設，也是存有一些争議。
資料中台是2015年阿裡提出來的雙中台的概念其中的一個重要組成，阿裡作為先驅者，提供了資料中台架構、以及非常多的建設思路供大家參考。從目前的建設效果來看，很多公司在資料中台建設中有不錯的成效（尤其是大中型公司），資料中台整體思路得到了驗證。但是資料中台本身還算一個新鮮事務，這個新鮮事務目前還沒有标準答案，隻有參考答案。
二、資料中台架構與技術選型
1、資料中台架構核心組成
我認為的資料中台核心架構包括四大組成部分，具體是：
底座是資料基礎平台，包括資料采集平台&計算平台&存儲平台，這些可以自建也可以使用雲計算服務；
中間部分兩大塊是中台的公共資料區，公共資料區包括資料倉庫(資料湖) ，主要負責公共資料模型研發，還包括統一名額（标簽）平台，負責把模型組織成可以對外服務的資料，例如資料名額、資料标簽；
上層是資料應用服務層，主要将公共資料區的資料對外包裝并提供服務，包括資料接口平台、多元查詢平台，資料可視化平台、資料分析平台等。
另外，資料研發平台和資料管理平台貫穿始終，其中：
1）資料開發平台包括資料開發的各類工具組合，例如：資料管道工具（比如資料接入、資料導出）、模型設計工具、腳本開發工具、資料排程工具等。
2）資料管理平台包括統一進制資料管理、資料品質管理、資料生命周期管理。針對資料全鍊路的資料管理，保證資料中台可以監控資料鍊路中的資料流向、資料使用效果、資料生命周期，以衡量資料的價值與成本。
以上是資料中台的核心部分，資料中台的組成也可以更加豐富，比如包括：資料資産平台、算法平台等等。
在資料中台的建設中一定不要忽視的是與業務的銜接，因為資料來源于業務并最終應用于業務，在資料中台的建設中需要有一系列的流程制度明确與業務的充分銜接，以保障資料源&資料産出的品質。
2、資料中台技術選型參考
在搭建資料中台方面，基于開源技術的選型，尤其是hadoop生态圈有非常多的選擇，從資料整體流向來看各大層級的選型。
資料抽取層：sqoop和flume是兩大主流工具，其中sqoop作為結構化資料（關系型資料庫）離線抽取，flume作為非結構化日志接入；
資料存儲層：hadoop檔案系統hdfs大家都比較了解，而kafka作為流式資料總線應用也非常廣泛；
計算與排程層，包括：
離線計算：離線計算主要是hive，spark，也有部分選用tez
實時計算：前些年storm，spark比較流行，最近幾年大家紛紛往flink轉型
資料排程：除了像airflow azkaban oozie等，易觀開源的dolphin-scheduler也非常活躍
資料引擎層：也就是我們常說的olap層，我們看到這一層裡的選擇非常多，就不一一列舉了，（業務需求帶動技術進步的典型，選擇豐富主要是可以适配不同的資料應用場景）。從概念上講分為rolap、molap以及兩者混搭。molap提前做一些預計算，以生成cube的方式，達到空間換取查詢效率；而rolap是即查即用，效率完全取決于查詢引擎的性能，我個人認為從将來看，rolap的趨勢會更加明顯，因為沒有中間的資料鍊路。但目前看來，沒有一個統一的引擎足以支撐各類資料場景（這或許是将來的機會~）；
資料可視化層：比較主流的有metabase、superset、redash，也可以選擇阿裡、百度的一些開源控件。
在開源技術的選擇裡，我們看到各層裡都有越來越多國内開源的工具（也充分展現了我們在大資料技術領域的進步）。除了以上列舉的這些，整個hadoop生态圈的技術選擇非常多，可以結合自己的實際場景選擇自己的架構，在選型層面可以參照的一些原則，比如：
是否有鮮活的成功案例，優先找自己類似業務場景；
接口的開放性，與其他元件的相容性；
社群活躍性度&發展趨勢。
當然，資料中台的選型不隻是開源技術，開源本身也不是完美的，例如維護開發成本較高，更新疊代不好把控，通過開源技術去建立資料中台還是有一定研發門檻。
是以也有很多商業化的套件、以及基于雲的資料元件可以選擇，包括資料采集、處理、分析、資料可視化全過程，國内外有很多廠商都提供了豐富的選擇。尤其在大資料可視化這塊，國内有許多非常專業的商業套件。
三、資料研發實踐
1、資料處理架構
下面是一個簡單的資料處理架構演進過程：
最早資料倉庫的計算隻支援批處理，通常是按天定時處理資料，在後期逐漸進化到準實時，本質上還是批處理，隻是處理頻度上得有提升，到小時級，或者15分鐘這種。
随着技術不斷進步，後期演化出一條新的流處理鍊路，這個鍊路和之前的批處理分别處理，然後在服務層面利用大資料的計算能力進行合并，向外提供離線+實時資料服務，這也是著名的lambda架構。
最近幾年随着flink等技術的發展，有一個趨勢是流批一體化，在接入層統一采用流式接入，計算層采用統一套架構支援實時計算+離線計算，批處理僅僅作為流處理的一個特殊場景進行支援。整體上可以做到流處理、批處理的自由切換。
流計算和批處理在需求場景上有一些本質差別，前者主要用于支援線上業務場景（比如網際網路的推薦、搜尋、風控等），而批處理更多是支援離線統計分析。
日出而作，日落而息，大家針對大資料的統計分析習慣不會發生根本性變化，最簡單的t+1批處理方式也還是資料應用必不可少的環節。在使用同一套架構上，由于資料源變化&次元變化的多樣性，批處理往往面臨一些複雜場景，這是采用同一套架構上的一些難點，充分支援好批處理也是将來流批一體架構的發展方向。
2、數倉分層與主題分類
1）數倉分層
與傳統etl不同的，我們采用的是elt的資料架構，較為适合在網際網路，總體分為業務資料層、公共資料層、應用資料層三大層次。
① 業務資料層（ods層）
原始資料經過緩沖層（stg）的加載，會進入數倉的業務資料層，這一層采用範式模組化，基本保持與資料源完全一緻的結構，對于變化的資料，使用資料拉鍊加工與存儲。
這一層選用範式模組化，是指保持源系統（例如關系資料庫）的範式結構，好處主要是：
一次性接入資料源結構，針對需求的變動不用頻繁去與資料源對接；
便于業務研發更好地了解資料，同時是也是公司的原始資料資産。
針對變化資料采用資料拉鍊的好處：
保留曆史資料的同時，盡可能少占用存儲空間，長期來看，拉鍊存儲比起每天全量保留曆史節約大概90%空間；
快速、高效地擷取曆史任意一天業務系統的快照資料。
② 公共資料層（包括公共明細層dwd，公共彙總層dws）
公共資料層是資料倉庫的核心層，是整個數倉中使用率最高的，這一層主要采用的次元模組化思路進行設計，類型包括事務事實、周期快照、累積快照。同時為了友善下遊對資料的使用，我們會設計一系列的寬表模型，将不同業務過程中的事實進行統一整合，包括縱向整合&橫向整合；對于商品、使用者主資料類可能分散在不同的源系統中采用縱向整合；橫向整合主要包括交易、内容等行為資料不同業務過程的整合，比如：使用者（使用者資訊、注冊資訊）購買（下單、支付、結算、覆約、完成）商品（商品資訊，商家資訊，等），我們會把訂單流轉業務過程整合放到一張明細表裡，同時會研發一些基于使用者、或者商品視角的輕度彙總寬表。
寬表非常便于了解和易用，下遊應用調用也友善。我們之前也做過一些統計，在調用分布來看，寬表的使用占到70%以上。
雖然寬表的使用在數倉模組化中非常普遍，但是也有一些缺陷：
資料備援較多，在存儲、計算、調用較為占資源，建議盡量還是按場景去使用；
寬表整合的資訊較多，資料權限不好控制。建議可以根據需求，在有限範圍内開放整體寬表權限，或者通過視圖或者子表的方式建立不同權限的資料範圍，适應不同組織的需求；
寬表通常依賴比較多，會影響資料的産出的時效。
③ 應用資料層（dwa層）
顧名思義，就是偏向應用的資料加工，也可以叫集市層，這一層的設計可以相對靈活，貼近應用即可，總體設計思想仍然可以按次元模組化思想為主。
2）主題分類
數倉架構的資料分類兩個視角，包括主題視角與業務視角。
① 資料主題視角
最重要的一個視角，也就是咱們經常提到的數倉主題，主題是将企業的業務進行宏觀資料抽象，是資料倉庫裡資料的主要組織形式，劃分方法如下：
參照波特價值鍊，分析企業本身經營的業務（基本活動、支援型活動），分别對應哪些資料；
參照業界通用模型，例如像ibm、td等針對大型行業（如電信、金融、零售）有一些資料主題的通用劃分方法；
對企業的内部資料（線上資料子產品、資料字典）進行摸底，确認對應到哪些主題。
劃分結果會按照三個層級：主題域--》主題--》子主題。
第一級是主題域，針對相對穩定的主題進行合并，歸攏到主題域，利于資料的了解與建立全局的資料資産目錄；
第二級是主題；
第三級是子主題，主要針對有些主題下分類較多，比如供應鍊主題下會包含采購、倉儲、配送等子主題。
資料主題劃分建議完全互斥，不建議重複。
② 資料業務視角
資料業務域是根據企業經營的具體業務，結合企業的組織架構進行劃分，層次和分類可以相對靈活，子分類可以允許重複，因為兩條不同的業務域可能經營相同的業務，例如電商、内容下都有會員這個業務。
上圖是一個比較典型的内容+電商的資料主題與業務分類。
以上一橫一縱兩個視角，将資料進行更好的歸類，在資料模型設計中會打上相應分類标簽，進而讓資料研發&資料使用人員統一認知。以上兩種分類方式主要應用于核心的公共資料層。
業務資料層、應用資料層并不需要遵循以上分類規則，比如業務資料層（ods層）是按照資料源進行分類，應用資料層（dwa）是根據具體的應用進行分類。
3、資料研發流程
除了合理的架構之外，資料研發的流程也很重要，總體流程如下：
包括需求分析/資料調研、資料模型設計、資料開發&測試、上線釋出等流程。
在之前資料中台的核心架構提到不閉門造車，資料研發需要與業務部門充分銜接，比如在資料調研中要與業務研發同學進行線上資料&結構訪談；在資料開發中，與分析&業務同學共同确認标準口徑；在資料研發完成後對資料使用方進行資料釋出與教育訓練。
以上流程中，除了需求調研，其他部分我們都進行了線上化，包括資料的模型設計，早期我們會手寫mapping文檔，後期我們逐漸把mapping文檔進行了線上化，整體的資料模型設計通過模型設計工具完成，包括從概念模型、邏輯模型到實體模型的設計。模型設計完成後，可以一鍵生成資料知識文檔。
4、資料生命周期管理
資料研發完成，還需要關注資料生命周期，一方面資料量的飛速增長不僅僅需要占用大量存儲，比如像自建機房，會涉及擴充機櫃、機房，往往會面臨一些瓶頸；另外一方面，大量的資料會降低資料的計算效率，是以從資料的生成開始，我們就需要考慮生命周期，并且結合資料的使用情況制定資料歸檔、資料銷毀等管理政策。
針對資料已經占用了大量存儲資源，可以采取一系列措施進行成本控制，例如：
降存量：通過資料壓縮技術、降副本等方式，以及在資料模型更合理的設計，将存量資料存儲降低；
控增量：根據資料重要性，可恢複性等考量角度，确認資料的保留周期，并根據周期自動歸檔或删除；
攤成本：可以通過一些算法，比如資料調用分布、需求來源等，把成本分攤到相應業務部門，讓相關業務部門關注到成本。
資料安全也是資料生命周期管理重的一個重要課題，比如針對使用者敏感資訊，需要在接入時考慮如何加密。一種做法是通過一個獨立的實體叢集對敏感資料進行隔離與強管控；資料使用中，也需要将資料劃分不同的安全或敏感等級（例如有些财務資料的非常敏感，需要謹慎對外開放），根據不同的等級設定不同的通路審批機制。另外，在資料歸檔、銷毀也需要制定好配套的安全管理措施，避免安全風險。
5、資料品質管理
資料品質管理主要包括3個角度：準确性、及時性、一緻性。
管理的環節包括：事前、事中、事後、以及事故管理。
針對資料運維的告警發送，傳統的方式主要是短信、郵件、電話；随着移動辦公工具功能逐漸的強大，可以将運維告警以資料接口的方式與這些工具進行對接，将告警發送到企業内部的即時通訊工具。
6、資料應用架構
資料研發最終還是需要賦能到業務&應用，一個合理的資料應用架構是非常關鍵的，這張圖是一個應用架構的簡圖參考：
從資料的流向上分：
資料倉庫（或者資料湖）：負責原始資料的計算，主要将資料落地到hdfs；
資料引擎層：資料加工完成之後，會将資料推送到不同的引擎中，這一層之前提到選擇非常多，可以根據自己的場景選擇一個混搭組合，比如我們目前選擇的有presto，kylin，druid，mysql；
資料服務層：通過統一化的sql調用服務，屏蔽底層不同的資料引擎，為上層統一查詢提供标準接口；
名額平台：名額平台是一個非常關鍵的産品，定位于銜接資料研發與資料應用，包括名額的标準定義、邏輯、計算方式、分類等各項内容。名額分類上我們分為标準名額(名額口徑經過稽核過)、以及非标準名額；
多元查詢：這是我們的一個即席查詢工具，查詢的資料主要來源名額平台，可以標明不同的名額次元組合進行結果呈現，使用者可以一次性查詢得到結果，也可以将查詢結果配置成可視化的報表進行固化。
中間是統一進制資料管理：對整個架構中可以對外提供服務的中繼資料進行統一管理（包括數倉的中繼資料、查詢引擎的中繼資料、名額中繼資料等），以及監控這些中繼資料的調用情況。
最右側是權限管理：權限管理關乎到資料安全，在設計上需要考慮周全，比如針對表級、名額級、次元級别都可以進行控制；同時産品層面也需要靈活配置權限審批級别與人員。
在面向使用者使用層面，我們主要開放的是多元查詢&可視化，使用者通過多元去查詢各類名額&次元資料，得到資料結果清單，再選擇可視化配置面闆，完成各類圖表、表格的自主配置，并釋出到個人看闆或者業務大盤目錄裡。也可以将配置的資料看闆進行靈活組合，定制成一個小型的資料産品。
7、資料roi評估
在資料研發中，也要考量資料的roi，下面是一個簡單的roi模型：
根據活躍度（調用次數等）、覆寫度（通過血緣關系找出依賴數量），以及貢獻度（依賴資料的重要等級）來确認資料的價值。同時會評估資料的成本指數（例如計算成本、存儲成本等）。
通過以上兩者相除，綜合得到資料的roi，針對roi可以将資料分為不同等級，并相應進行資料治理。比如針對價值低，成本高的資料，可以考慮下線等。
資料研發趨勢&關注點
提效：目前借助工具的研發可以把絕大部分資料研發工作線上化，将來借助ai等能力，實作資料進行中包括開發、運維的自動化，提升處理效率；
靈活：流批一體化，包括流處理與批處理自由切換，之前已經提到過，個人認為也是一個發展的趨勢；
降本：資料研發鍊路的成本控制，在資料建設的早期通常不太引起關注，随着資料量不斷的積累，往往存儲、計算成本成為瓶頸。針對資料建設成本需提前考慮；
算力：我們看到google，ibm和阿裡都在研究量子計算，将來的資料中間層（比如數倉的公共模型）是否可以考慮虛拟化（比如隻保留規則&資料結構），具體資料内容在應用發起時，即調即用，更多時候可以不需要占用存儲資源。算力的不斷提升，有可能會颠覆一些傳統資料建設的思路。
> > > >
q&a
q1：請問貴公司如何壓縮資料？又如何删除副本呢？
a：我們主要使用parquet +snappy壓縮；另外，如果發現壓縮率較低，可以通過排序來調整資料分布，降副本可以了解下ec糾删碼技術。
q2：對于批處理效率低的問題該怎麼處理？
a：具體可以看什麼原因導緻，如果是整體效率低，可以看資源利用是否集中，如果集中，可以考慮任務分等級錯峰進行隊列隔離等；如果是個别任務問題，那就要考慮邏輯和加工鍊路是否有問題，比如說可以全量改增量處理，邏輯參數優化；如果傾斜導緻可以針對具體傾斜原因采取不同的優化方式。
q3：請問基于hadoop生态元件建構dw存在哪些不足？與mpp比較？
a：如果之前一直是按照傳統商業套件進行建設，可能在資料不能直接update這個點上不習慣。另外大部分技術都是經曆反複演進才達到穩定的，是以最好能選用成熟元件。與mpp比較，mpp橫向擴充到一定規模可能會有瓶頸，而hadoop叢集可以靈活擴充節點來增加算力，比如現在國内單叢集幾千台、上萬台的場景都有。
q4：資料中台建設團隊的kpi怎麼評定？
a：需求響應效率、前台資料調用效率、資料覆寫度、資料準确性、及時性、使用者滿意度、成本控制效果等。
q5：您對hatp在行業應用趨勢和方向如何看？
a：hatp我個人沒有研究；如果hatp能解跨不同環境之間的資料連通性，應該可以替代一些目前大資料的應用場景。
q6: 對于搭建資料中台的生态工具，有什麼建議嗎？
a：文中有一些正常的選型（主要調研了目前一些主流工具），基本上都是經過了驗證過，更多還是找适合自己場景的工具。
q7：請問現在對提效方面有什麼好的開源的線上工具嗎？
a：模組化、開發中的一些提效小工具成本不高可以考慮自研，但是複雜一些例如任務排程完全可以找到成熟的開源工具。
q8：範式模組化層，是否會形成統一資料模型，即one model？
a：不會，範式主要應用在業務資料層，原則上我們不對外提供這一層的服務，主要用于加工dw層。
q9：業務資料層，如果設計成拉連結清單，抽取資料是肯定是做更新插入操作，增量和存量資料做比對，很耗性能，特别是存量資料是海量的情況下，請問下如何處理此類問題？
a：大表拉鍊效率慢優化可以考慮減少計算資料量，例如把穩态資料進行歸檔，不參與計算。或者可以嘗試通過冷熱資料分離，再視圖合并。
q10：請問mapping是模組化管理的？是否用用erwin或者pd工具吧？
a：以前我們是通過excel模版模組化并生成mapping文檔，現在隻是把這個模版搬到線上，這個小工具可以連通到建表，并且釋出到資料知識系統。我們沒有使用erwin或者pd，模型之間的關系會輔助用一些思維導圖軟體。
q11：為什麼要基于hive建數倉？它不支援索引、更新、事務。
a：hive 搭建數倉目前來看處理效率、穩定性都是經過驗證過的。更新可以通過高效的insert over write來解決。
q12：資料湖是什麼技術？跟數倉的關系是啥？
a：跟數倉是兩個獨立的概念，通過直接接入源系統的原始資料（包括結構化、非結構化），利用大資料強大的計算能力，直接将資料服務于應用。主要為縮短傳統數倉的中間模組化與處理（etl）過程，目前有看到一些雲+資料湖的方案。
q13：業務中繼資料、技術中繼資料在中台中如何統一對應管理？
a：通過統一進制資料管理工具例如名額中繼資料管理工具、資料表中繼資料管理工具，可以将業務中繼資料對應到技術中繼資料，建議可以在工具中設定一些強規範，來保證統一對應。
q14：使用kylin做olap很不靈活，貴公司是使用kylin嗎?您認為kylin主要是用于什麼場景？
a：是的，大部分場景使用的是kylin，kylin主要使用用業務形态相對穩定、計算的次元名額矩陣相對固定、原始資料量較大且有去重類名額計算的情況。通過一些模型設計和技術手段可以相對降低kylin靈活性差的問題，比如：模型設計的抽象化、底層使用視圖、使用hybrids進行橋接等。
q15：貴司資料治理工具用的哪個？
a：目前沒有專門的工具，從一開始保持資料的規範化建設、合理的架構，可以降低治理的工作；如果要治理可以考慮通過全鍊條中繼資料管理過程配合資料治理。
q16：所講的體系如何保障資料業務化的、端到端的實時應用？
a：我們目前的場景還不多，可以了解其他網際網路場景豐富一些方案。如果是支撐端到端的實時應用，要保證穩定性需要在服務層有多種調用方案，例如針對同一個應用，可以有正常api調用以及降級api。
q17：關于名額體庫如何設計？以及ad-hoc查詢場景的支援。
a：我們預計在5、6月會組織一次《資料模型設計實踐》以及《名額體系與ad-doc》的直播分享，會有專門負責這塊資料架構的小夥伴來給大家介紹。
推薦閱讀：12.scala的模式比對必讀｜聊聊大資料産品經理flink在滴滴的應用與實踐進化版