元數(shù)據(jù)管理是企業(yè)數(shù)據(jù)治理的基礎。企業(yè)以元數(shù)據(jù)為基石進行數(shù)據(jù)治理，幫助企業(yè)更好地對數(shù)據(jù)資產進行管理，理清數(shù)據(jù)之間的關系，實現(xiàn)精準高效的分析和決策。希望通過本次講解翼支付數(shù)據(jù)治理實踐中元數(shù)據(jù)管理這一內容，能給大家?guī)硪恍┧伎己徒鉀Q思路。

今天的介紹主要從四個方面來展開：

• 元數(shù)據(jù)的定位，主要講元數(shù)據(jù)和數(shù)據(jù)治理之間的關系
• 以元數(shù)據(jù)為基礎的治理體系的構建
• 元數(shù)據(jù)平臺的關鍵技術
• 未來發(fā)展的展望

分享嘉賓｜王平&鮑旭 翼支付

01 元數(shù)據(jù)定位

這個主要是想給大家解釋下數(shù)據(jù)治理與元數(shù)據(jù)的整體關系，這里引用華為的一個數(shù)據(jù)治理之道：“清潔的數(shù)據(jù)成就卓越運營，智慧數(shù)據(jù)驅動有效增長”，這說明了企業(yè)為什么要做數(shù)據(jù)治理。在當下數(shù)字經(jīng)濟蓬勃發(fā)展的過程中，各個企業(yè)都投入很大的精力去做這些事情。數(shù)據(jù)治理最核心的目標就是得到“清潔”的數(shù)據(jù)，元數(shù)據(jù)是數(shù)據(jù)治理的一個基礎設施，在整個數(shù)據(jù)治理過程中起到了非常核心的作用。

首先企業(yè)數(shù)據(jù)治理一般要面臨的問題，也就是數(shù)據(jù)治理要去解決的問題有這些：

數(shù)據(jù)質量和數(shù)據(jù)實效不高：這也是數(shù)據(jù)的使用方經(jīng)常吐槽數(shù)據(jù)部門的一個核心問題。

核心數(shù)據(jù)的識別困難、數(shù)據(jù)一致性表差：例如各個不同系統(tǒng)得到的指標，不同的部門得到指標口徑可能都存在一些差異。

數(shù)據(jù)治理前清后亂：前期剛把數(shù)據(jù)治理好，之后新增的數(shù)據(jù)又開始把所有的數(shù)據(jù)搞亂，難以持續(xù)維持。

數(shù)據(jù)安全風險居高不下：整個國家的法律法規(guī)在不斷完善這一塊，對企業(yè)來講還是面臨著不少風險。

數(shù)據(jù)開發(fā)煙鹵化嚴重，基礎數(shù)據(jù)面臨多次重復建設：重復勞動導致大量的成本浪費。

以上這些都是企業(yè)數(shù)據(jù)治理過程中要去解決的問題，那么元數(shù)據(jù)在治理數(shù)據(jù)過程中要解決什么樣的問題？我們最終把企業(yè)的數(shù)據(jù)治理抽象總結出四個方向的問題：成本、效率、質量、安全。

在成本和效率方面，通過資產元數(shù)據(jù)識別數(shù)據(jù)表的價值，根據(jù)數(shù)據(jù)血緣識別任務鏈路，推進核心任務、低價值任務的等級制度。針對核心的任務做必要的保障，針對一些低價值的任務，推進任務進行下線或者降低它的資源使用。

在數(shù)據(jù)質量方面，可以通過主數(shù)據(jù)治理及數(shù)據(jù)質量的提升來提升數(shù)據(jù)的一致性。

數(shù)據(jù)安全方面，可以通過數(shù)據(jù)分類分級和數(shù)據(jù)安全治理來降低產生和大數(shù)據(jù)側數(shù)據(jù)存儲、傳輸及使用方面一些安全風險。

以上是整個數(shù)據(jù)治理和元數(shù)據(jù)之間的關系。

02 元數(shù)據(jù)治理體系

這部分主要從以下四個方面來介紹：如何去做核心數(shù)據(jù)的保障、主數(shù)據(jù)的治理、數(shù)據(jù)規(guī)范體系建立、整體產品的架構。

1. 核心數(shù)據(jù)保障

核心數(shù)據(jù)保障主要是解決數(shù)據(jù)質量和時效不高的問題，現(xiàn)在每個企業(yè)的數(shù)據(jù)體量是相當大，要在海量的數(shù)據(jù)里面保障核心數(shù)據(jù)的一個實效性。每個公司資源有限的情況下，不可能保證所有的任務都會得到保障，所以要優(yōu)先使核心任務得到保障。怎么去保障核心數(shù)據(jù)識別，以及后續(xù)的保障措施流程？翼支付是通過以下四個步驟來逐步推進完成的：

①首先由業(yè)務部門提交他們的核心數(shù)據(jù)表作為我們的一個需求提報到數(shù)倉。????②數(shù)倉基于元數(shù)據(jù)來做上游鏈路的依賴關系識別和分析，上游任務所消耗的資源進行整體的評估，評估完成之后會經(jīng)由大數(shù)據(jù)部門審核。????③審核通過后將這個任務作為優(yōu)先級較高的任務，同時調整整個鏈路的優(yōu)先級為核心。????④運維團隊會做整個的7*24小時的值班，來保障核心任務的計算時效以及整個數(shù)據(jù)產出的數(shù)據(jù)質量。在這個過程中除了流程的管控以外，還有需要有資源分配的方案，簡單從三個方向介紹：

①項目空間的管理：支持多租戶的資源分配，控制每個空間的隊列資源以及優(yōu)先級，還有任務最早的啟動時間來保障整個任務的有序進行。

②隊列的劃分：一般劃分為核心、重要和一般三個隊列，核心隊列由數(shù)倉統(tǒng)一管控，而事業(yè)群只能去調整自己的任務為重要和一般兩種隊列。

③資源策略：在五點之前所有資源優(yōu)先提供給核心隊列進行供應，因為作為電信旗下一家子公司，有一些像集團上報的數(shù)據(jù)有非常高的時效性要求，這種核心任務會優(yōu)先給他分配資源。在五點之后會按照任務的優(yōu)先級以及任務的依賴進行資源分配。這是整體的一個資源分配方案。

2. 主數(shù)據(jù)治理

主要是為了解決一些核心數(shù)據(jù)識別困難以及數(shù)據(jù)一致性差的問題，在翼支付我們希望是通過主數(shù)據(jù)的治理能實現(xiàn)同源的多用，因為主數(shù)據(jù)一般只有一個核心的數(shù)據(jù)源，然后多個系統(tǒng)進行的引用，來保障數(shù)據(jù)的源頭的一致。再加上主數(shù)據(jù)又是核心數(shù)據(jù)，我們要對它進行數(shù)據(jù)質量的提升，來逐步建立起主數(shù)據(jù)的權威。主數(shù)據(jù)的治理也是分四個步驟：

①主數(shù)據(jù)定義和識別：由數(shù)據(jù)部門統(tǒng)一來確定唯一的數(shù)據(jù)源，它是唯一的來源也是最權威的來源。

②質量管控和提升：確定了主數(shù)據(jù)之后，要對它進行數(shù)據(jù)質量的稽核，來提升這個主數(shù)據(jù)的數(shù)據(jù)質量。如果源頭的數(shù)據(jù)質量有問題的話，那我們在下游使用問題肯定會更大，所以要確保主數(shù)據(jù)和源頭的系統(tǒng)數(shù)據(jù)是一致的。

③主數(shù)據(jù)集成和服務：把控以上兩步之后就會進行主數(shù)據(jù)的集成和服務，會推進各個業(yè)務系統(tǒng)進行主數(shù)據(jù)的應用和消費的改造過程。

④主數(shù)據(jù)服務和消費：建立起主數(shù)據(jù)之后，要確保后面的新增系統(tǒng)以及存量系統(tǒng)要按照我們的要求，根據(jù)流程進行改造。如果新增的話，不允許自建主數(shù)據(jù)，必須引用主數(shù)據(jù)的數(shù)據(jù)，it協(xié)同實現(xiàn)數(shù)據(jù)的集成和服務鏈路打通。

3. 數(shù)據(jù)規(guī)范體系建立

數(shù)據(jù)治理投入的成本比較高，如果沒有規(guī)范的約束的話，經(jīng)常會出現(xiàn)數(shù)據(jù)治理的“前清后亂”——前面治理完，后面數(shù)據(jù)又全部亂掉了，整個數(shù)據(jù)治理難以維持。還有就是如何保障數(shù)據(jù)安全，需要有一些數(shù)據(jù)安全相關的規(guī)范。所以基于這個背景，我們構建了整個的數(shù)據(jù)規(guī)范體系。

翼支付整個的數(shù)據(jù)鏈從生產系統(tǒng)模塊中的DB庫抽到大數(shù)據(jù)的數(shù)倉模塊；最先到達ODS層再依次到DWD層、DWS層、DWM層，數(shù)倉將數(shù)據(jù)整合和治理之后，再提供給業(yè)務團隊進行報表展示、業(yè)務分析和數(shù)據(jù)探索的業(yè)務應用、數(shù)據(jù)消費。這是整個數(shù)據(jù)鏈路過程。

一般數(shù)據(jù)治理的核心肯定在數(shù)倉和消費端，但是如果要保證數(shù)據(jù)整個的完備和避免數(shù)據(jù)“前清后亂”，在生產的源頭系統(tǒng)也要對它有相應的約束，整個數(shù)據(jù)規(guī)范體系是針對整個生產鏈路，從生產系統(tǒng)->大數(shù)據(jù)側->消費系統(tǒng)應用都要求統(tǒng)一進行規(guī)范。這個規(guī)范可以分兩個大的方向：

第一個是基礎的數(shù)據(jù)規(guī)范，包括主數(shù)據(jù)的標準、元數(shù)據(jù)的標準，還有數(shù)據(jù)開發(fā)規(guī)范。

第二個方面是我們數(shù)據(jù)安全的規(guī)范，它最核心的是依賴于我們數(shù)據(jù)的分類、分級標準。在這基礎上有了數(shù)據(jù)安全的規(guī)范，包括我們數(shù)據(jù)的存儲使用還有傳輸相關的一些要求、數(shù)據(jù)權限的管控的一些要求。制定了相應的規(guī)范之后，確保規(guī)范執(zhí)行落地，需要有一套強有力的數(shù)據(jù)質量稽核和通報機制。

數(shù)據(jù)質量稽核：就是要在各個數(shù)據(jù)里面，通過it的形式加人工抽查的形式去審核數(shù)據(jù)有沒有按照要求來實施。

通報機制：則根據(jù)各個公司的不同形式來保障；同時也對其他部門有一些約束。這個數(shù)據(jù)規(guī)范不能只是針對數(shù)據(jù)側的一個數(shù)據(jù)規(guī)范。

要保證整體的數(shù)據(jù)的“清潔”，還要從數(shù)據(jù)生成源頭做質量把控，堅持生產源頭治理并行，從三個方向來做：

①數(shù)據(jù)安全治理（存儲、傳輸、使用）。

②生產元數(shù)據(jù)治理（庫表字段命名規(guī)范統(tǒng)一），不能統(tǒng)一的話，那生產側也要有一套相應的規(guī)范，而不是讓我們的開發(fā)人員隨意去命名他的庫表。

③主數(shù)據(jù)的識別和應用，主數(shù)據(jù)在數(shù)倉的應用是一方面，更多的時候在生產的各個應用系統(tǒng)之間也是會廣泛的應用，所以這個要提前去抓。

4. 產品架構

前面給大家介紹了元數(shù)據(jù)的治理體系，要支持這個治理體系的落地需要我們產品能力的支持。以元數(shù)據(jù)為基礎的整體架構視圖給大家簡單講解一下，它總共分為三層：

最上面一層是數(shù)據(jù)消費層，主要是把我們治理好的“清潔”數(shù)據(jù)提供給需求方實現(xiàn)數(shù)據(jù)應用報表的可知化和自助分析。

中間一層是數(shù)據(jù)治理體系層，就包括前面給大家介紹的數(shù)據(jù)規(guī)范體系、基礎數(shù)據(jù)治理、主數(shù)據(jù)治理、數(shù)據(jù)安全治理、數(shù)據(jù)質量提升的一些策略。

最下面一層是數(shù)據(jù)平臺層，要保障上層數(shù)據(jù)治理體系的落地，也需要產品工具進行協(xié)同，產品工具最核心的一部分就是元數(shù)據(jù)平臺。它主要提供兩種能力：一個是面向我們的數(shù)據(jù)人員提供了一些產品功能：數(shù)據(jù)目錄、元數(shù)據(jù)查詢、血源分析、元數(shù)據(jù)注冊，讓數(shù)據(jù)人員更好去解讀我們的數(shù)據(jù)；二是管理和服務，因為除了我們元數(shù)據(jù)平臺以外，像數(shù)據(jù)資產平臺、核心的數(shù)據(jù)開發(fā)平臺、數(shù)據(jù)總線等也是要基于我們元數(shù)據(jù)平臺，由元數(shù)據(jù)提供血緣、權限、元數(shù)據(jù)查詢等服務。

03? 元數(shù)據(jù)平臺技術介紹

1. 元數(shù)據(jù)設計理念

谷歌在2003年和2004年先后發(fā)布了被稱為大數(shù)據(jù)三架馬車的三篇重要論文，分別是MapReduce、GFS、BigTable；正是谷歌的“三架馬車”掀開大數(shù)據(jù)時代的序幕，而在2016年谷歌也發(fā)表了一篇論文《Goods：Organizing Google's Datasets》[1]，從多個方面介紹了谷歌內部的一個元數(shù)據(jù)管理系統(tǒng) Goods。

Goods的架構如上圖所示，數(shù)據(jù)存入到他的Catalog中，并以此為基礎對外提供查詢、監(jiān)控、血緣關系、展示等服務。

Goods的數(shù)據(jù)類別如表所示：包括了基礎元數(shù)據(jù)、基于內容的元數(shù)據(jù)、血緣數(shù)據(jù)等。

通過這篇論文我們總結了以下幾點：

①Goods 是一個 post-hoc 系統(tǒng)，也就是事后處理系統(tǒng)，所謂事后處理系統(tǒng)就是指在用戶創(chuàng)建和更新數(shù)據(jù)以后再采集元數(shù)據(jù)，不干擾用戶的正常使用。但是論文在feature work中也提到了，他希望在將來用戶在創(chuàng)建和更新數(shù)據(jù)的同時就能夠將元數(shù)據(jù)進行注冊。

②Goods 使用了 BigTable 作為元數(shù)據(jù)的存儲介質，BigTable 的開源實現(xiàn)就是HBase，為什么使用 BigTable？因為它一個非常重要的特性：“blind writes”，所謂“blind writes”即不區(qū)分insert和update，可以直接將數(shù)據(jù)進行寫入并且?guī)в袝r間戳的屬性，這樣就極大地縮短了元數(shù)據(jù)的同步時間。

③Goods有大量的批處理任務，包括離線的采集元數(shù)據(jù)信息以及離線的處理元數(shù)據(jù)信息。

④構建評分機制，對用戶的搜索結果進行排序；谷歌評分機制相對比較完善，表的屬性、所屬的類別、血緣關系、用戶評分多個維度對搜索結果進行一個排序。

2. 架構設計

我們以這篇論文為設計基礎，結合公司的實際情況，并在落地過程中也參考了業(yè)內的多個開源平臺，如上圖所示就是翼支付元數(shù)據(jù)平臺架構圖，主要分為三層：

①存儲層

利用了不同的存儲系統(tǒng)存儲不同的數(shù)據(jù)，首先利用HBase存儲各類元數(shù)據(jù)信息；利用Elasticsearch存儲索引信息用于搜索；利用圖數(shù)據(jù)庫存儲血緣關系信息。

②服務層

用存儲的各類數(shù)據(jù)信息提供服務，比如在元數(shù)據(jù)平臺上進行表的查詢，還有表和字段的血緣關系的展示和分析。同時給外部平臺包括ETL平臺、BI平臺、AI平臺提供元數(shù)據(jù)的查詢服務。

③接收層

適配不同的數(shù)據(jù)源，從數(shù)據(jù)源中采集元數(shù)據(jù)信息并進行處理。

3. 元數(shù)據(jù)模型

元數(shù)據(jù)主要包括四類：

①基礎元數(shù)據(jù)

主要包括表名、類型、大小、文件數(shù)、最近一次修改時間等，這些元數(shù)據(jù)通常是從數(shù)據(jù)源直接獲取，直接寫入到HBase當中。

②資產元數(shù)據(jù)

主要包括表的一些業(yè)務描述，所屬的業(yè)務域、層級、表的owner等，通常是由開發(fā)者在生產過程中手動維護。

③安全元數(shù)據(jù)

主要包括權限信息、分類分級、是否包含隱私數(shù)據(jù)等，這些數(shù)據(jù)通常是根據(jù)相關法律法規(guī)以及公司的規(guī)范由表的數(shù)據(jù)內容決定。

④血緣元數(shù)據(jù)

包含上游表、下游表，通常是由數(shù)據(jù)同步和數(shù)據(jù)加工任務產生。

除了這4大類數(shù)據(jù)以外，我們還有一些衍生的元數(shù)據(jù)：包括查詢次數(shù)、變更記錄等等。

4. 元數(shù)據(jù)采集

元數(shù)據(jù)的采集平臺會適配不同的數(shù)據(jù)源，開發(fā)不同的采集插件，采集插件采集元數(shù)據(jù)后會推入到消息隊列中，由下游的 Metadata Processor 服務進行處理。Metedata processor 服務接收到消息后會直接寫入到 HBase 中，并對元數(shù)據(jù)進行比較，判斷是否有增加或刪除；如果有，就將相應的變動推入到消息隊列中，下游的 Metadata Change Processor 服務接受到消息后會更新到 Elasticsearch 中相應的索引。

5. 全鏈路血緣

全鏈路的字段級血緣，就像前面所說，血緣數(shù)據(jù)通常是由數(shù)據(jù)同步任務和數(shù)據(jù)加工任務產生，對于數(shù)據(jù)同步任務可以由相關的平臺直接將相關的血緣信息推到消息隊列當中，平臺接收到消息后進行處理并存入到圖數(shù)據(jù)庫中。而對于數(shù)據(jù)加工任務，我們采用了 hook 的機制對計算引擎的執(zhí)行計劃進行分析，從而獲取到字段的血緣關系，并推送到消息隊列中進行處理。

04 未來展望

主要是三個方面來規(guī)劃：

第一個是支持多源異構數(shù)據(jù)的管理，現(xiàn)階段大部分都是基于結構化的數(shù)據(jù)，包括我們的數(shù)據(jù)源也是 Hive、ClickHouse 這種存儲結構化數(shù)據(jù)的數(shù)據(jù)源，除了結構化數(shù)據(jù)以外我們公司未來會有更多的非結構化的數(shù)據(jù)，比如說圖片、聲音、文本，而這些數(shù)據(jù)通常會存儲在分布式存儲系統(tǒng)（譬如Ceph）中，這些分布式存儲系統(tǒng)的元數(shù)據(jù)也需要進行管理。

第二個是多集群跨dc的容災，作為存儲了數(shù)據(jù)的元數(shù)據(jù)平臺，要考慮自身的一個容災的問題，然后進行架構升級。

第三個是智能推薦，除了表的搜索以外，還要通過推薦讓用戶更快更好更方便地找到自己想要的一些表。

引用：

[1] Alon Halevy, Flip Korn, Natalya F. Noy, Christopher Olston, Neoklis Polyzotis, Sudip Roy, & Steven Euijong Whang (2016). Goods: Organizing Google's Datasets international conference on management of data.

https://readpaper.com/paper/2438792749

05? Q&A環(huán)節(jié)

Q1：核心數(shù)據(jù)是指的主數(shù)據(jù)嗎？

A1：核心數(shù)據(jù)跟主數(shù)據(jù)是有差別的，核心數(shù)據(jù)這個定義是按業(yè)務來定義。我們在生產使用過程中是按最后業(yè)務方來定義的，比如我們某個部門經(jīng)營的核心 kpi 的一個指標，這個指標表對業(yè)務來說是他非常核心的數(shù)據(jù)。把這個業(yè)務的核心指標的結果表就是可以定位一個核心數(shù)據(jù)。那我們在做這個鏈路保障的時候，就要把這個指標表對應以及上游的所有鏈路數(shù)據(jù)納入核心數(shù)據(jù)來做優(yōu)先級的調控，這是針對核心數(shù)據(jù)。主數(shù)據(jù)的定義是在多個系統(tǒng)跨系統(tǒng)引用，多個系統(tǒng)都要用到相同的一份數(shù)據(jù)；比如我們的員工數(shù)據(jù)，那我們可能在各個的數(shù)據(jù)平臺的系統(tǒng)里面都要用到這個員工數(shù)據(jù)，那這個員工數(shù)據(jù)它本身就是主數(shù)據(jù)，它跟核心數(shù)據(jù)是從兩個維度去表達的。我解釋的不知道能不能解答這個同學的問題。

Q2：任務整個鏈路的優(yōu)先級指的是離線處理、實時處理、資源分配都是優(yōu)先其他的任務處理嗎？

A2：這個任務優(yōu)先級是針對主要以離線任務為主，因為實時任務其實沒有優(yōu)先級的概念，它是所謂的只要數(shù)據(jù)來了之后就會立馬進行計算，所以它沒有優(yōu)先級的概念；它的資源是一直要保留資源一直計算的。而針對離線任務，因為我們不同的任務節(jié)點之間，它是有依賴關系的，所以優(yōu)先級主要是針對離線任務這個板塊。

Q3：整個核心任務的識別是自動的嗎？

A3：核心任務的識別不是自動的，核心任務分兩個角度來講；第一個是哪些表、哪些的結果任務需要優(yōu)先保障，這個是由業(yè)務提報過來；由大數(shù)據(jù)數(shù)倉同學審核之后才能生效的，這是一個人為的流程管控；但比如一個指標的結果表作為一個核心的任務節(jié)點了，再把當前的節(jié)點和上游所有節(jié)點任務的調成高優(yōu)先級，這個調整的過程是自動的。但前面識別出哪些是核心的數(shù)據(jù)，這個不是自動的。

Q4：數(shù)據(jù)安全治理主要包括哪些內容？

A4：數(shù)據(jù)安全治理可能各家公司不一樣，就講一下翼支付的實際吧。數(shù)據(jù)安全治理我們包含數(shù)據(jù)安全規(guī)范的一個建立，數(shù)據(jù)存儲加密改造就包含一些敏感性的加密存儲，還有一些數(shù)據(jù)運營的管理；包括數(shù)據(jù)的使用下載，像數(shù)據(jù)下載這種就是非常高危的一個操作。我們會建立一個統(tǒng)一的下載中心，所有的平臺的數(shù)據(jù)下載都要走這個平臺進行下載，在這個臺上會做好數(shù)據(jù)的管控、安全審計。當然有些公司還有第四個板塊就是合作數(shù)據(jù)的一個管控，要跟第三方進行的數(shù)據(jù)合作，這個數(shù)據(jù)它是不是合規(guī)的，在這個層面如果也要公司有的話，它屬于數(shù)據(jù)融通的一個過程，也是有安全和合規(guī)的一些要求的。一般是會從這四個方向去做那個數(shù)據(jù)安全的治理。

Q5：元數(shù)據(jù)采集使用的是 logstash 嗎？

A5：logstash 就是類似于一種實時采集的時候使用，比如元數(shù)據(jù)發(fā)生變動，這里其實主要是分成兩部分：第一個部分是離線采集，其實是一個跑批的過程。那么以 HIVE 為例，我們的跑批可能是指以一個比較長的時間里面去批量地采集 HIVE Metadata 的 mysql 數(shù)據(jù)庫里面的數(shù)據(jù)信息進行一個存儲。然后那個 logstash 是屬于比如說實時更新，那么它的元數(shù)據(jù)有實時更新變動的話，那我們會接收到這相應的數(shù)據(jù)，然后去作為一個實時更新。所以其實采集分為兩部分：一個是實時采集，一個是離線采集；然后我們離線采集使用的是直接去讀元數(shù)據(jù)庫進行采集；然后那個實時采集這邊是類似于就像你說的 logstash，因為 logstash 比如像是 mysql、oracle。然后像 HIVE 其實它是有 HIVE Metadata 的服務通知機制去實現(xiàn)代替了。

Q6：原數(shù)據(jù)是具體怎么存在 Hbase 的？表結構如何設計的？

A6：這個其實我可以建議他去了解一下 Hbase 的一個相關原理，因為其實Hbase 是一個 k-v 形式的一個存儲，它不是一個關系型存儲數(shù)據(jù)庫，它是有一個 CF（column family） 的概念，在 column family 的下面還有一個 column qualifier，Hbase 除了在那個 ppt 里面講到了一個“盲寫”的特性，可以不管是 insert 和 update 就直接寫入了一個特性以外；還有個特性可以通過數(shù)據(jù)的插入直接去更新 column qualifier。也就說如果像類似于 mysql，我要去新增一個字段去更改表結構，做DDL操作去更新。但是 Hbase 是不需要的，它里面的 column qualifier 是取決于你的數(shù)據(jù)，也就說你數(shù)據(jù)里面有這個 column qualifir，它就會自動去幫你添加，不需要特別的去設計他的表結構。也就是說只要設計好 cf，那么 cf 下面的一些表的一些字段信息是取決于我們的插入的數(shù)據(jù)，這取決于元數(shù)據(jù)平臺的具體設計了。這個也是 Hbase 的一個比較好的特性。