万字讲述如何通过Doris构建数据中台
目錄
基于Apache doris怎么構建數據中臺(一)-什么是數據中臺
基于Apache doris怎么構建數據中臺(二)-數據中臺建設內容
基于Apache doris怎么構建數據中臺(三)-數據資產管理
基于Apache doris怎么構建數據中臺(一)-什么是數據中臺
這是數據中臺系列的第一篇文章，主要闡述數據中臺概念，從技術和業務視覺看數據中臺及數據中臺要解決的問題
1.什么是數據中臺
數據是從業務系統產生的，而業務系統也需要數據分析的結果，那么是否可以把業務系統的數據存儲和計算能力抽離，由單獨的數據處理平臺提供存儲和計算能力？這樣不僅可以簡化業務系統的復雜性，還可以讓各個系統采用更合適的技術，專注做本身擅長的事。這個專用的數據處理平臺即數據中臺。
數據中臺是一個用技術連接大數據計算存儲能力，用業務連接數據應用場景能力的平臺。
“連接能力”是數據中臺的精髓。作為一個處在中間層的能力平臺，“連接”是其根本任務。在業務層面需要盡可能連接各種數據源作為其生產資料；同時，由于生產數據的場景越來越多，覆蓋了線上線下等多渠道，各數據生產資料之間也需要進行連接，才能形成全域的數據；數據在數據中臺這個平臺上按照標準的模型進行規范加工處理后需要服務于多種場景，同樣需要我們提供標準的數據服務接口將數據與應用場景連接起來。因此，連接是數據中臺的根本能力，也是數據中臺的價值所在。
數據中臺通過數據技術，對海量數據進行采集、計算、存儲、加工，同時統一標準和口徑。
數據中臺把數據統一之后，會形成標準數據，再進行存儲，形成大數據資產層，進而為客戶提供高效服務。這些服務跟企業的業務有較強關聯性，是這個企業獨有且能復用的
2.數據中臺解決什么問題
1、效率問題：為什么應用開發增加一個報表，就要十幾天時間？為什么不能實時獲得用戶推薦清單？當業務人員對數據產生一點疑問的時候，需要花費很長的時間，結果發現是數據源的數據變了，最終影響上線時間。
2、協作問題：當業務應用開發的時候，雖然和別的項目需求大致差不多，但因為是別的項目組維護的，所以數據還是要自己再開發一遍。
3、能力問題：數據的處理和維護是一個相對獨立的技術，需要相當專業的人來完成，但是很多時候，我們有一大把的應用開發人員，而數據開發人員很少。
3.數據中臺和數據倉庫、數據平臺的區別
1、數據中臺是企業級的邏輯概念，體現企業 D2V（Data to Value）的能力，為業務提供服務的主要方式是數據 API；
2、數據倉庫是一個相對具體的功能概念，是存儲和管理一個或多個主題數據的集合，為業務提供服務的方式主要是分析報表；
3、數據平臺是在大數據基礎上出現的融合了結構化和非結構化數據的數據基礎平臺，為業務提供服務的方式主要是直接提供數據集；
4、數據中臺距離業務更近，為業務提供速度更快的服務；
5、數據倉庫是為了支持管理決策分析，而數據中臺則是將數據服務化之后提供給業務系統，不僅限于分析型場景，也適用于交易型場景；
6、數據中臺可以建立在數據倉庫和數據平臺之上，是加速企業從數據到業務價值的過程的中間層。
4.技術視覺的數據中臺
數據從生產到應用的整體流程是任何一個數據從業者都繞不開的主題，即便是非數據領域的產品和運營同學，同樣也應該對業務中數據的流向有個初步的認識。要展開描述，我們必須從數據的技術視角思考兩個問題：
需要解決的問題是什么？
如何保證數據流中不同階段的最優解？
4.1. 需要解決的問題是什么？
1、數據供給：提供便捷的數據生產方案，以數據產生為起點，規范數據整個主體的供給，為夯實數據平臺的基礎提供保障；
2、數據產出：保證數據在產出層面的普遍適用性。該階段包括分析報表，自動化分析工具，查詢入口等的建設；
3、過程管理：保證數據的完整性、準確性、時效性，實現數據從產生到應用全流程的高效管理。
4.2. 數據流的不同階段如何解決
不同企業所處的業務發展階段不同，所面對的問題會不一樣。同樣，業務本身特性及企業對數據建設的資源傾斜程度不同，也會直接影響數據全流程處理的差異。最重要的還是立足于現狀，站在更高的戰略視角去思考整體的解決方案。下面從技術視角來看我們數據中臺做什么：
4.2.1 數據產生
數據產生，這個階段是最適合向業務方宣灌數據生產應用流程的階段，因為該階段的優劣將會直接影響之后的各環節。該階段的關鍵字是數據規范錄入，需要給數據上游的業務方提供可行的數據埋點規范。
4.2.2 數據采集
數據采集：這是最被動的一個環節，也是最出力不討好的環節，最容易被甩鍋和背鍋的環節，
數據部門會提供給業務方不同場景下的模塊日志采集方案清單，業務方只需按照現有清單選擇模塊上報，數據部門會自動收集；
數據部門會提供模塊日志注冊系統，形成良性注冊機制，讓數據部門提前感知，自動化收集模塊數據。
4.2.3 數據處理
數據處理、清洗是數據輸入到倉庫的前置階段，該階段最主要的是規則，目的是建立符合業務需要的數據清洗方案。比如什么格式的數據該被過濾；哪些用戶是要被過濾掉等。
4.2.4 數據倉庫
數據倉庫面向應用而生，為了保證數據的普遍適用性及拓展性，會對倉庫進行分層，通常分為：ODS、DW、DWS、ADS。常見數據倉庫模型為“星型模型”，我們在進行維度建模的時候會建一張事實表，這個事實表就是星型模型的中心，然后會有一堆維度表，這些維度表就是向外發散的星星。
4.2.5 數據計算
數據計算是數據變活的過程，主要分為離線和實時計算。會按照不同業務單元的需要，設計數據指標，并按照不同場景中的業務邏輯確定統計規則，最終由系統實現例行計算。
4.2.6 數據應用
數據的應用是數據最終產生價值的部分，基于數據流前面的流程處理，該環節最終會提供給應用方業務報表、數據訪問、自動化工具、統計模型等應用；
在數據應用方面我們應當關注的問題：
1、是否能提供完善的業務分析指標體系
2、是否能提供完善的精細化運營工具；
3、現有數據是否足夠支撐業務分析，是否能依據現有數據發現更多的業務問題
4、是否能洞察潛在的商業機會
4.2.7元數據管理
元數據管理貫穿整個數據流程始終，是一個較為寬泛的概念，元數據治理的好壞將直接決定了整個數據平臺的品質。元數據管理主要分為兩部分：技術元數據、業務元數據
5業務視覺的數據中臺
基于立場的不同，導致了從業務視角與從技術視角看到的表現層內容會不一樣，但究其本質是相通的。無論數據在應用層面以何種方案最終呈現，最終都是為了解決問題而存在,
1、為什么需要數據團隊解決？
2、需要解決的問題是什么？
3、該通過什么方式解決？
5.1 為什么需要數據團隊解決？
業務技術團隊的定位是服務于業務一線，數據團隊的定位是提供專業性的數據解決方案，二者分工上的差異性決定了解決問題的最佳路徑。如下列舉了需要數據團隊解決幾類問題：
數據類型：數據產生場景復雜、數據類型多（訂單、客戶、商品，倉儲，物流等），數據結構復雜（結構化/非結構化/半結構化數據）；
數據量級：存儲量級大，傳統關系型數據庫不能解決；
數據處理：清洗規則多，計算任務流程長，計算血緣關系復雜等；
數據應用：行為分析，多維交叉分析，實時多維分析，豐富的可視化等。
5.2需要解決的問題是什么？
（1）業務是什么
不同業務單元依據自身業務屬性，需要數據團隊解決的數據問題也不一樣。如市場團隊關注應用市場投放相關的數據，客戶端團隊關注設備/應用版本/用戶轉化相關的屬性數據，運營團隊關注活動相關數據，風控團隊關注風控相關數據等。
（2）如何衡量它們
團隊屬性的不同，也決定了量化到數據指標的衡量標注不同。各業務團隊擁有自己的關鍵唯一指標和對應拆解/下鉆的指標體系。
（3）如何讓數據驅動業務
市場團隊通過衡量不同渠道來源用戶的質量，評估渠道ROI，優化投放策略；客戶端團隊通過觀察不同產品方案的轉化效果，改進注冊及其他核心行為發生的主流程設計；運營團隊通過用戶細分，評估不同用戶群在活動對的轉化效果，進行精細化運營等。
5.3 通過什么方式解決？
以下從業務視角來看數據中臺產品解決方案：
實時監控
專注于關鍵核心指標的實時表現，如客戶、商品、訂單，倉儲，運輸等。視具體情況會將關鍵指標維度下鉆后進行實時監控
離線分析
核心看板：核心看板著重關注公司戰略層核心指標在核心維度上的趨勢及構成表現
業務看板：業務看板服務于不同業務團隊，亦可視作各業務單元的核心看板
客戶分析及畫像：客戶構成、客戶留存、客戶轉化、行為、生命周期等場景的分析、
商品分析：商品構成、庫存、售出、質量、商品生命周期等場景的分析
精細化運營工具
留存分析：按照留存模型，起始行為精分客戶群體，依據精分客戶群交易行為、頻次、額度等的表現，觀測各層客戶的留存
畫像分群：按照不同主體拆分屬性，通過屬性組合，篩選目標分群，進行精細化運營
交易分析：分析客戶的訂單行為
SQL查詢控制臺：可視化SQL查詢
預警及分析
實時異常分析：實時異常分析基于歷史數據，獲取當前時間點的可能數值范圍，當實際值在該范圍以外時，即認為數據異常。關鍵要求是及時和準確
智能分析：具體策略是對關鍵核心指標進行維度拆解，尋找出影響核心指標波動中不同維值的“貢獻度”，最終定位問題
6. 平臺建設目的
大數據時代的到來，讓越來越多的企業看到了數據資產的價值。將數據視為企業的重要資產，已經成為業界的一種共識，企業也在快速探索應用場景和商業模式，并開始建設技術平臺。
為了解決企業業務在實際中存在的以下問題：
1、各個業務數據重復開發浪費存儲與計算資源
2、數據標準不統一，存在數據質量問題，數據使用成本高
3、業務數據孤島問題嚴重業務協同能力弱，數據利用效率低
4、缺乏精準模型支撐，數據分析能力不足，數據應用價值不高
基于四個統一，統一數據采集，統一數據處理，統一數據存儲，統一數據服務，基于計算及存儲基座，提供標準統一、可連接萃取的數據中臺，包含數據采集與研發、數據連接與萃取、數據資產管理及統一數據服務，服務于上層業務，如經營分析、消費者營銷洞察等場景
在實際數據開發應用中存在，不知數據在什么地方，數據是什么意思，拿到一個報表怎么開發，數據怎么獲取，最后數據怎么能快速的可視化呈現出來這五個難題，我們建設這個數據中臺就是要解決：找數據，理解數據、問題評估、取數及可視化展現這五個問題，整個平臺的故事也是圍繞這個五個點。從根本上解決：
找數：數據從什么地方來到什么地方去，將數據和業務過程結合起來，實現數據的快速查詢
理解數據：通過數據的血緣關系，數據關聯關系及數據的說明信息，讓數據開發人員，業務人員快速理解數據
問題評估：數據分析人員拿到需求，可以通過該平臺實現問題的自動評估，大大提高數據分析效率
取數：用戶可以不再關心數據的來源，不再擔心數據的一致性，不再依賴RD的排期開發。通過所選即所得的方式，滿足了用戶對業務核心指標的二次加工、報表和取數訴求
數據可視化：依托于我們的BI可視化系統和數據中臺的打通，數據分析人員可以快速的將數據中臺創建的數據模型快速的轉換成可視化報表。
基于Apache doris怎么構建數據中臺(二)-數據中臺建設內容
這次主要是將基于Doris的數據中臺建設內容及系統架構設計
圍繞著上次將的我們要解決的五個問題：找數，理解數據，問題評估，取數及數據可視化，給出一個概要的設計及框架
數據中臺建設內容
數據規范統一：采用維度事實建模理論進行嚴格的，規范化、標準化的定義，保障數據質量，避免數據指標的二義性。
一站式研發體驗：從數據接入、建模、研發、運維、數據查找及探查等過程提供高效一站式統一的研發立案率。
系統化構建數據體系：以標準的技術框架，系統地構建規范可讀的業務化數據體系，形成數據資產，方便業務查找及應用。
可視化數據資產：系統化構建業務數據資產大圖，還原業務系統，提取業務知識，快速提取業務關鍵環節及業務。
數據使用簡單可依賴：定義及服務，研發構建的業務主題式數據邏輯表可被直接，快速查詢及訪問，簡化查詢代碼。
數據中臺架構
數據中臺系統架構
數據中臺技術架構
對用戶來說，Doris 的優點是功能強大，易用性好。功能強大指可以滿足我們用戶的需求，易用性好主要指?兼容 Mysql 協議和語法，以及 Online Schema Change。兼容 Mysql 協議和語法讓用戶的學習成本和開發成本很低， Online Schema Change 也是一個很吸引人的 feature，因為在業務快速發展和頻繁迭代的情況下，Schema 變更會是一個高頻的操作。
對平臺側來說，Doris 的優點是易運維，易擴展和高可用：
易運維指 Doris 無外部系統依賴，部署和配置都很簡單。
易擴展指 Doris 可以一鍵加減節點，并自動均衡數據。
高可用值 Dors 的 FE 和 BE 都可以容忍少數節點掛掉。
所以這里數倉是使用Doris作為核心組件來構建
架構說明：
數倉整體以Doris為核心構建公司企業級數據倉庫，（后期會根據實際需要還可能會引進Hive、ClickHouse等其他組件）
通過統一的數據采集系統，多種數據采集手段，包括Mysql binlog解析（Cannal），日志采集Flume（Doris審計日志）、埋點接口等實現多種異構數據的采集，針對Mysql，Kafka數據源我們封裝了零代碼入倉，可視化完成
將采集的數據統一通過消息隊列（Kafka）完成高并發的數據吞吐，同時實現數倉及計算引擎的解耦
Flink計算引擎完成數據的ETL處理及實時數據的統計，并將數據推送到Kafka及Doris（Stream Load）
對外通過doris和消息隊列對外提供數據服務
數據質量管理是實現對從數據采集到數據ETL處理，數據存儲及數據服務全生命周期的數據管理，包括元數據，數據質量，數據規范、數據安全
血緣關系的構建是基于Doris的審計日志，這塊我會在后面數據資產的元數據管理里講解
系統架構數據管理及數據流向
3.1.4 數據中臺功能整體規劃
數據中臺功能整體規劃
這是我們數據中臺的整體功能規劃，我會在后續展開每個功能
基于Apache doris怎么構建數據中臺(三)-數據資產管理
前面我們講了什么是數據中臺，及數據中臺的架構及功能規劃，這次我們開始從數據資產開始拆解每個功能模塊做的內容
數據資產管理平臺可以定量評估數據資產的成本，價值，質量。幫助企業優化存儲成本，節約計算資源。精細化的數據生命周期管理，幫助企業更好的管理數據的生產到銷毀的整個生命周期。
在管理方面：管理者在規劃數據文化建設時，對企業數據資產的全局構成、使用形式、 使用效果都需要詳細的指標輸入，往往這些指標都沒有被統籌起來；在組織保障上， 需要多少資源、運作機制應該如何制定才能保障數據文化的落地，也需要運營指標來 輔助決策，所以管理者通常需從以下幾個方面的問題進行思考：
數據如何被用起來？
數據保值后如何增值？
組織已不再滿足變化所需？
管理體系如何建立？
在治理方面：企業擁有大量的數據資產之后，由于分工不同，一般的數據生產者、數據 消費者之間會隨著時間推移、人員變動等因素，造成數據資產的信息成為無人維護的 靜態狀態，數據的存儲成本、檢索的理解成本會越來越高。這些數據資產分布在一片 數據沼澤中，難以分辨數據資產的成本、價值，更難以進行生命周期管理，甚至給數據 消費者帶來難以跨越的信息鴻溝；數據治理通常關注以下幾個方面的問題：
數據的成本如何降低？
數據生命周期如何管理？
數據質量低，如何保證可用？
數據價值如何評估？
在運營方面：數據資產從被建立，到數據內容的生產、到被使用，各環節用戶各自所關注的、所進行的工作重點不一致；從數據管理視角、數據生產視角、數據應用視角來 看，各個視角之間的目標實現、工作重點、協作方式，不再以點對點的形式存在，而是 貫穿于整個數據鏈路中，數據運營正是為了從以上角度來發現問題、解決問題，作用是：數據運營會從“戰略、執行、目標拆解、跟蹤實現”各個階段進行統籌，對運營目標 負責。數據運營通常關注以下幾個方面的問題：
有限的資源如何科學分配？
數據的關系如何互相影響？
如何發現最迫切的問題？
數據運營缺乏工具、渠道；
在使用方面：數據只有被用起來，才能發揮其應有的價值。然而當前部分的企業使用 數據的情況并不樂觀。根據調研統計，只有約 14%的企業數據相關的從業人員認為使用 數據是方便的。數據使用是否方便，可從兩個維度來判斷，一是工具：是否能夠具備 “順暢的、快捷的、容易完成的”數據使用場景的工具集；二是時間：是否可以快速地查找、信任、理解數據。根據調研統計，有不低于 80%的時間消耗在“查找-理解-信任”數據的過程中；這兩個現狀成為阻礙數據使用的最大的瓶頸。我們歸納了數據使用的幾 大問題點，如下所示：
數據孤島亟需打破；
發現、理解、使用數據耗時費力；
知識經驗無法共享、迭代；
溝通不暢、權責不明；
個人信息無法歸檔；
數據安全如何保障；
本次只介紹數據資產管理的核心元數據管理及數據資產數據地圖，及數據生命周期管理，其他相關模塊：數據接入，數據處理，數據服務等后面介紹
資源管理
實現集中對各種數據資源的管理，包括數據庫，消息隊列等的管理
實現數據庫數據源管理：屬性包括：所屬業務名稱，業務技術負責人，數據源IP，端口、數據庫名稱，用戶名、密碼，數據庫類型（Mysql、oracle、SQLServer、Doris等），創建時間，創建人
實現Kafka數據源管理：屬性包括：Kafka集群名稱，Kafka Broker Server地址（示例：172.22.197.123:9020），對應zookeeper地址（示例：172.22.197.123:2181）,創建時間，創建人，集群負責人
元數據管理
元數據管理是整個系統的核心，所有的功能及業務流程都是圍繞這個進行的，也是整個系統數據治理的核心
元數據主要解決三個問題：首先，通過建立相應的組織、流程和工具，推動業務標準的落地實施，實現指標的規范定義，消除指標認知的歧義；其次，基于業務現狀和未來的演進方式，對業務模型進行抽象，制定清晰的主題、業務過程和分析方向，構建完備的技術元數據，對物理模型進行準確完善的描述，并打通技術元數據與業務元數據的關系，對物理模型進行完備的刻畫；第三，通過元數據建設，為使用數據提效，解決找數據，理解數據，問題評估難題以及取數和數據可視化難題
元數據管理系統架構
這里元數據分為物理元模型和血緣元模型
元數據采集
元數據采集分為人工錄入和自動抽取，通過人工錄入的方式實現物理表的準確歸屬（包括該表屬于倉庫哪一層、對應的主題、業務過程、星型模型關系等）以及指標的采集，從而完成技術元數據和業務元數據的采集，通過自動抽取的方式完成生產元數據的采集和使用元數據的采集，主要包括：物理模型的依賴關系、存儲占用、熱度等信息
血緣關系：這塊因為我們數倉是用的Apache doris，實現起來相對月Hadoop架構的簡單了很多，通過Flume采集每個Doris Fe節點的審計日志（fe.audit.log）中的sql，通過阿里開源的數據庫連接池Druid進行解析自動生成，這里同時還可以對SQL操作進行一些安全審計，比如Delete，truncate，drop及sql執行成功失敗，執行時間等進行審計預警
元數據管理功能
1.業務數據元數據同步采集
實現對業務數據庫數據表的元數據自動采集同步，包括建表語句中的中文備注信息，并將中文備注信息填寫到對應的中文字段名稱中，界面提供元數據修改功能，主要修改是添加業務技術負責人、修改表的中文名稱、備注說明等信息，表的字段名稱，類型、長度等信息不允許修改
2.數據倉表元數據采集
實現對數倉數據庫數據表的元數據自動采集同步，包括建表語句中的中文備注信息，并將中文備注信息填寫到對應的中文字段名稱中，界面提供元數據修改功能，主要修改是添加數倉表對應技術負責人、修改表的中文名稱、備注說明等信息，表的字段名稱，類型、長度等信息不允許修改
3.元數據版本管理
因為數據庫表存在結構變更，這里需要提供元數據多的歷史版本管理，可以查詢元數據歷史版本信息
4.業務元數據變更管理及預警
對業務元數據的變更（主要是Mysql數據庫），通過flink監控binlog的schema變更時間，一旦發現及時發送消息通知，后端監控變更消息隊列，取到變更信息，發出元數據變更預警，并自動修改相應的元數據，生成版本信息。
5.元模型構建
分為以物理表為核心的基礎元模型構建，以及以血緣為中心的血緣元模型。
基礎元模型構建以物理表為中心，打通其與技術元數據（主題、業務過程、Schema）的關系，實現了物理表的清晰歸屬，打通其與生產元數據的關系，要加上物理表查詢熱度、資源消耗、查詢密級等生產使用信息，打通其與指標、維度和應用的對應關系，為上層的取數應用建立了完備的元數據。
血緣元模型以血緣為中心，通過監控Doris審計日志，通過sql解析完成自動的血緣關系構建，不僅要構建從上游業務表到倉庫表的物理血緣，而且要打通倉庫表到下游對應報表的血緣，為后續的影響評估構建了完備的元數據基礎
6.虛擬庫及表的管理
對于通過API接口方式對接的數據，要通過頁面手動添加庫，添加表及表字段類型，字段名稱，字段中文名稱，字段長度等等，這樣的目的是為了統一元數據管理方式
業務元數據
數據域主題管理
數據倉庫是面向主題（數據綜合、歸類并進行分析利用的抽象）的應用。數據倉庫模型設計除橫向的分層外，通常也需要根據業務情況進行縱向劃分數據域。數據域是聯系較為緊密的數據主題的集合，是業務對象高度概括的概念層次歸類，目的是便于數據的管理和應用。
數據域是指面向業務分析，將業務過程或者維度進行抽象的集合。為保障整個體系的生命力，數據域需要抽象提煉，并長期維護更新。在劃分數據域時，既能涵蓋當前所有的業務需求，又能讓新業務在進入時可以被包含進已有的數據域或擴展新的數據域。數據域的劃分工作可以在業務調研之后進行，需要分析各個業務模塊中有哪些業務活動。
數據域可以按照用戶企業的部門劃分，也可以按照業務過程或者業務板塊中的功能模塊進行劃分
數據域的管理本質是一個分類管理，暫定二級分類
數據域主題作用于數倉內部數據表的管理及數據指標的分類管理
數據維度管理
建立統一的維度管理系統，實現對維度信息的統一管控，并為公司的數據產品提供統一的維度數據服務，包含維度開發管理，維度信息管理及維度數據服務三個方面。
維度管理：基于數據維度管理規范，對維度新增、修改、發布等生命周期進行統一管理。
維度服務：基于數據倉庫ODS層模型源數據，建立服務化的維度表模型，在模型基礎上建立維度，包括系統維度和手工維度定義，支持離線和實時大數據量的維度查詢服務，維度創建完成后為各數據產品提供高可用，高性能的數據服務
1， 選擇業務過程 根據業務場景以及可用數據源 2， 聲明粒度 根據事實表及應用場景，確定匯總粒度，一般盡可能的用最細粒度 3， 確定維度 根據確定的粒度，定義對應的維度，最細粒度，也是最低層次的維度 4， 確定事實 確認將哪些事實放到事實表中，維度表只是做關聯，不做維度數據的查詢服務。
維度定義：?維度按集團產業進行指標一級業務域劃分，包括：智能工廠、供應商、采購、銷售、門店、倉儲、運輸、POS等；在各業務域下，對維度進行主題分類，主要有：時間類（DT）、組織類（OG）、產品（PD）、銷售平臺（SP）、經營方式（BM）、終端(TM)、業務渠道(BC)、營銷(MK)、會員(MB)、采購模式(PM)、地點(AD)等。
維度管理：
維度：維度平臺要支持快速定義維度,通過設置維度的基本信息，選擇維度映射的維度表，做好維度與維度表的映射，設定維度的一些特性（布爾維度，時間維度，雜項維度等），檢測維度的定義結果。達到了讓業務人員能夠只是通過頁面操作就可以制定需要的維度。
維度表：數據開發人員可以通過維度庫平臺定義維度表，定義好之后可以集成數據倉庫的同步任務一鍵將倉庫的數據同步到維度表中，將維度表與維度做映射關系。
維度層級：維度庫平臺支持定義維度層級，只要是維度庫平臺上有的維度表并且做好維度與維度的映射關系之后，就可以定義需要的維度層級，根據維度層級提供維度值的上卷下鉆查詢服務。
維度血緣：提供了維度，指標，報表的血緣關系，以及還準備做的維度數據的血緣，維度，指標，報表調用次數的血緣等等。
數據地圖
數據地圖提供數據檢索能力，致力于提供蜀海生態內豐富數據源的檢索服務。完成找數據的過程，通過該平臺，用戶可以以較小成本找到所需數據，無論是業務數據、數倉數據庫表或字段、數據指標，數據服務都可以通過該功能完成檢索，對業務及數據開發使用人員能很快的找到需要的資源，并根據搜索的結果展示了解數據
1.找表
通過統一的查詢頁面，通過輸入關鍵字完成數據表的檢索
在檢索的結果頁面找到符合自己的數據，進去查看表的詳情頁信息，詳情頁展示內容包括
表的詳情信息
表的字段信息
表的數據預覽（最多10條）
表的血緣關系（包括表的上下游依賴，表的關聯關系）
表的使用情況統計
表的建表語句
表評論信息，對于表有不理解的地方可以在這塊進行提問
表的分區信息
表的使用說明
收藏及使用足跡記錄
表明細
2.找維度
通過統一的維度檢索頁面，通過輸入關鍵字檢索字段信息，點擊字段列表數據，可以查看該字段的信息
維度所在表的信息
維度關聯表的信息
維度說明信息
該維度關聯的指標數據信息
維度評論
3.找指標
通過統一的指標檢索頁面，通過輸入關鍵字檢索指標信息，點擊指標列表數據，可以查看該指標的信息
顯示指標的基本信息
指標的生產鏈路
指標技術邏輯
指標字段信息（按維度和指標分開）
指標數據預覽
指標使用說明
指標評論
指標明細：
4.找服務
通過統一的服務檢索頁面，通過輸入關鍵字檢索服務信息，點擊服務列表數據，可以查看該服務的信息
數據服務接口基本信息
數據接口參數及響應說明
數據接口使用說明
接口權限
5.找報表
數據生命周期管理
主要是為了完成數據從產生、采集、處理、存儲、加工、使用及歸檔銷毀的全生命周期的各個階段的管理
根據數據的使用情況或者根據 用戶設定的數據生命周期，及時幫用戶銷毀數據，在大數據研發中大部分用戶關注的是數據怎么進入數據倉庫，但是很少有用戶會關注數據的銷毀。隨著時間持續性發展之后數據會無限量增加，數據倉庫慢慢的成為一個很大的成本負擔。數據生命周期管理，關注于數據整個鏈路的生命周期管理，及時推薦無效數據下線。在數據下線的過程中，很多用戶會擔心數據誤刪，完備的數據下線機制，在有效期限內可以對數據進行恢復，確保數據誤刪的情況。
主要是通過數據接入，數據ETL、數據地圖、元數據、數據指標各個系統在使用過程中的使用日志數據，對數據進行一個全面的采集及分析，生成數據在各個階段的數據指標。
生命周期管理關注以下內容：
數據歸檔管理：對符合歸檔的數據進行歸檔到冷存儲上，減少存儲及計算成本
統計在數據每個階段的數據變化趨勢
業務庫DDL變更趨勢
數據熱度排名：數據庫，數據表的使用熱度統計
數據庫數據量排名，
庫內數據表數據排名
根據數據的使用情況或者根據 用戶設定的數據生命周期，及時幫用戶銷毀數據
在大數據研發中大部分用戶關注的是數據怎么進入數據倉庫，但是很少有用戶會關注數據的銷毀。隨著時間持續性發展之后數據會無限量增加，數據倉庫慢慢的成為一個很大的成本負擔。數據生命周期管理，關注于數據整個鏈路的生命周期管理，及時推薦無效數據下線。在數據下線的過程中，很多用戶會擔心數據誤刪，完備的數據下線機制，在有效期限內可以對數據進行恢復，確保數據誤刪的情況
數據資產全景視圖
數倉界的360，可以定量評估數據資產的成本，價值，質量。幫助企業優化存儲成本，節約計算資源。精細化的數據生命周期管理，幫助企業更好的管理數據的生產到銷毀的整個生命周期。
資源視圖
數據庫統計
表統計
表引用統計
數據在各個生命周期階段的資源使用情況
文件數量：總文件數，累計存儲量，當月優化存儲量
Job統計
優化建議等
足跡
數據問答
我們為數據地圖中的找表，找維度，找指標，找服務，找報表都提供了數據問答功能，通過評論問答功能，幫助用戶可以快速得到問題反饋：如果用戶看了信息后還是感到有問題，提供評論問答的功能，用戶通過這個功能可以進行提問，會有相應的負責人進行回復。對于重復問反復問的問題，用戶通過查看其它人的提問和回復就能找到答案。并且負責人還會定期的將問答信息沉淀到對應的元數據里，不斷地對元數據進行補充和完善
下一講會講解怎么基于Apache doris實現快速數據接入，零代碼數據接入系統
文章來源：https://zhuanlan.zhihu.com/p/397252278總結
以上是生活随笔為你收集整理的万字讲述如何通过Doris构建数据中台的全部內容，希望文章能夠幫你解決所遇到的問題。
