“數聚雲端·智馭未來”——阿裡雲資料庫創新上雲峰會暨第3屆資料庫性能挑戰賽決賽頒獎典禮已圓滿結束，更多幹貨内容歡迎大家觀看峰會直播回放。
峰會直播回放📎
https://developer.aliyun.com/live/247301 幹貨PPT下載下傳📎 https://developer.aliyun.com/topic/download?id=7986一、核心痛點
随着資料的爆炸，企業資料應用需求的急驟提升和資料技術的快速發展，在資料庫與資料倉庫這兩個關鍵系統産生強烈的關系。無論是Inmon模型還是Kimball模型中，都強依賴于各種資料庫與資料倉庫及連接配接其間的資料內建與處理産品、同時還牽涉到資料資産管理及安全的難題，這一系列核心元件密切配合才能完成哪怕是企業一個最簡單的報表需求，其他複雜的需求自不必說。
同時我們還看到市場的發展趨勢，據Gartner分析，企業要求資料內建、分析從離線到實時化趨勢明顯，預計2025年實時資料占比 30%，2022 年新業務超過50%将會采用實時分析。
目前的數倉建構過程中，整個流程非常的長，複雜度很高，這就與目前企業想要簡單快速實作數字化産生了沖突，主要問題包括：
- 資料孤島中資料庫及各種日志種類繁多，缺少最佳設計開發與維護實踐；
- 資料互聯互通困難，缺少簡單可靠的資料通道，尤其是實時資料通道；
- 資料加工處理的ETL過程複雜，實時性不足，技術棧多且難以維護；
- 資料治理能力缺乏，安全問題凸出；
二、解決方案
對于這些問題及雲原生+實時化的市場趨勢，在阿裡過去10年的資料庫與數倉的建構與實時化的開發與應用經驗基礎上，我們推出全新的一站式的資料管理産品DMS(DMS+DTS)，提供了包含全域資料資産、資料庫設計與開發、資料內建、資料開發、資料可視化及資料服務等能力。通過内置阿裡巴巴資料研發規範及資料安全最佳實踐，DMS可幫助企業實作高效靈活、安全可靠的資料生産、處理及消費。本文将就其中的關鍵能力進行技術解讀。
三、關鍵能力
接下來将從實時資料流技術、庫倉一體資料處理、分布式能力、資産管理與安全四部分描述。
實時資料流技術
1. 背景
資料內建能力是建構數倉的基礎能力，包括存量資料抽取、增量資料抽取、以及資料轉換（資料清洗/資料轉換/資料富化）等方面。存量資料抽取相對簡單，直接使用資料庫/檔案/或第三方應用提供的标準接口進行資料拉取和存儲；資料轉換部分可分為單記錄處理、Arregation處理、多流關聯處理等類型，這一部分側重資料本身的轉換，可應用于存量、增量資料；增量資料抽取側重于實時性和業務的無入侵性，通過與資料源高度耦合的方式，盡可能實作一種極緻實時的、對資料源影響最小的、且應用代價最低的增量擷取技術。在增量資料捕獲後，會實時入倉。新DMS強大的實時資料流技術來自DTS， 本章主要讨論增量資料捕獲技術，同時以DMS為例說明實時資料流的技術全貌和核心要點。
2. 增量資料擷取的技術流派
按照增量資料的擷取方式，可以将實時資料流技術分為4類：即基于業務字段拉取、Trigger捕獲、CDC（change data capture）、以及WAL解析。
2.1 基于業務字段拉取
假定資料源中帶有時序字段，則可以通過周期性查詢來提取出差異資料。這種時序字段最普遍的就是時間屬性的，如modify_time。下圖為基于這一字段進行的問題資料拉取的示例：
這種技術實作的優點是簡單，但對業務的依賴程度高，擷取的增量資訊有限，且隻能做到分鐘或小時級别的實時性。
2.2 Trigger捕獲
Trigger捕獲方式是通過資料源自身的機制将資料操作記錄到增量表中，增量抽取通過周期性查詢增量表來擷取增量資料。如下圖所示：
這種技術實作能夠擷取每次的資料變化，但對源庫有入侵，且實時性很難保障。
2.3 CDC
CDC（Changed Data Capture）技術是資料源提供的一種技術，可以在表級别開啟。對于開啟CDC的表，資料源會基于源表名生成一張CDC表，用以記錄源表的增量資料變化。增量抽取通過周期性查詢CDC表來擷取增量資料。
CDC方式整體上看與Trigger捕獲方式非常相似，但核心差別是CDC表的資料是資料源通過WAL日志挖掘解析生成，其性能要高于Trigger捕獲。目前常見的商業資料庫均提供了CDC技術（如Oracle/DB2/SQLServer等）。
CDC技術的優點是高效、簡單，但對多表、及DDL的支援不好。
2.4 WAL解析
WAL解析高度依賴資料源的行為，雖然在具體實作上千差萬别，但拉取通用資料庫層面，其技術實作還是非常統一和一緻的。下圖為其基本形态：
增量抽取通過資料源的主備複制協定擷取到Master的WAL日志，随後進行WAL日志的資料解析。
WAL解析方式的優點是實時，對資料源、業務都是0入侵的，但是實作的技術難度很大，對于每種資料源，都需要深入的了解、并且精通其WAL格式才有可能做到。
3. 實時資料流技術要點
從傳統T + 1數倉到實時數倉，其背後反映的是業務對資料實時性的要求越來越高。而在技術路徑上，實時資料流是其必由之路。目前，業内對實時資料流的建構方式尚未形成标準。在這裡，我們僅以DMS的實踐經驗來說明。
3.1 實時性是實時資料流的核心
我們将實時定義為秒級延遲，隻有當實時資料流達到這個延遲級别，基于次建構的實時數倉才能做到分鐘級、甚至秒級的資料分析，幫助業務實時決策，将資料的價值發揮到極緻。
DMS為了做到秒級延遲，在技術路線上選擇了WAL解析方式，通過這一方式，DMS在衆多資料庫上達到了實時的要求。而為了做到秒級的實時性，需要進行衆多技術點的突破，按照DMS的實踐經驗，總結如下圖所示。
DReader為DMS中的增量捕獲子產品，DWriter為DMS中的增量資料寫入子產品。為了應對實時性的要求，DReader通過并發解析、前鏡像推導等技術達到的毫秒級延遲；而DWriter通過并發寫入、分布式擴充、以及熱點資料合并等技術，達到了百萬級RPS的寫入能力。進而在整體上，實時資料流做到了秒級延遲。
3.2 穩定性是實時資料流大規模應用的必要條件
高性能、實時性是實時資料流的特性和優勢，但穩定性卻是一項技術是否能在核心場景應用、是否能大規模推廣的必要條件。為了達到工業級穩定性的要求，DMS實時資料流在增量資料捕獲、增量資料寫入等方面進行了大量的優化。
源自對各個資料庫核心的深度了解和據握，同時也接受了多年雙11場景的考驗。在商業資料源方面，DMS實時資料流針對Oracle/DB2/SQLServer建構了完整的資料類型、DML等測試場景，支援了公有雲、專有雲數萬商業資料庫執行個體。本節以DMS在SQLServer資料源上做了一個優化進行說明。
SQLServer資料庫中的表分為聚簇索引表和堆表兩類，堆表本身的一些資料更新不記錄VLF日志。主備複制協定的性能最高，但由于其是基于VLF日志，無法擷取到堆表中的完整記錄；同時，通過反查方式可能造成回查錯誤資料等問題。為此，DMS在穩定性和性能上進行平衡，在實時資料流中首次引入了WAL解析和CDC混合模式，如下圖所示：
主備複制協定解決80%以上表的日志增量拉取，剩餘少量的特殊表（如SQLServer的堆表）采用CDC方式。這種混合模式在保障穩定性的同時，也提供了極高的實時性。
3.3 DDL自适應
想要在生産環境長期的穩定運作，DDL自适應能力必不可少。DMS實時資料流通過對資料源的DDL進行解析和映射，不僅能保障自身的穩定運作，同時也能夠将一些不适應數倉場景的DDL（如DROP）排除到資料流之外。
庫倉一體資料處理
1.背景
在資料存儲的發展過程中，分别有兩大領域。一個是資料庫陣營，負責存儲業務的線上資料，通過事務的ACID特性保障線上業務的強可靠性和穩定性。一個是資料倉庫陣營，負責存儲業務線上資料的鏡像，通過一系列的大資料分析元件對資料進行挖掘、分析、資料模組化等。
通常這兩個領域是有兩套不同的方法論以及系統元件來支撐的，而兩大領域中間通過資料內建或者資料ETL(Extract-Transform-Load)進行銜接，資料在這兩大領域内流動。
圖1. 庫倉間資料流
在這兩大領域之間，存在非常大的資料交換需求。資料傳輸服務(Data Transmission Service，簡稱DTS)支援多種資料庫的遷移、訂閱以及實時同步，在6年間支撐了大量的資料庫到資料倉庫的資料內建鍊路。在今年DTS+DMS形成全新産品DMS5.0上線，內建了資料管理、資料內建、資料ETL等多方面能力，形成一站式線上資料處理平台, 可以實作庫到倉的物化視圖能力。
本章節介紹在DMS5.0在資料處理部分新的功能。
在庫倉一體的場景下，通常有兩種資料處理需求。第一類是資料從資料庫到實時資料倉庫的鍊路建構，第二類是離線數倉T+1的處理場景，以下分别介紹。
2.數倉計算場景
2.1 場景一：資料實時ETL
資料從資料庫到資料倉庫過程中，需要配置一條DTS資料內建鍊路，在新DMS5.0場景下除了相容原有的資料內建鍊路功能，還提供了新的資料ETL能力。也就是在資料傳輸過程中進行資料的預處理，包括普通的資料字段過濾、資料字段變換、資料流表join、資料維表join等複雜ETL功能。
目前這部分的能力可以基于畫布，通過拖拉拽的方式配置，樣例如下：
1、資料的直接同步
畫布中有輸入，輸出表，直接拖拽到畫布上即可配置一條資料同步鍊路
圖2. ETL畫布配置同步
2、資料的過濾操作
在資料源表和目标表之間插入一條字段電腦
圖3. ETL畫布配置字段計算
3、資料流表和維表Join
圖中的兩張原始表都是MySQL資料庫表，左邊作為流表輸入，通過采集binlog來拉取資料變更流，右側維表輸入，直接通過左側流表按字段直接join右側維表。該場景下通常是用固定的維表字段補充流表中的資料内容，并輸出到目标表。
圖4. ETL畫布配置流、維表Join
4、資料流表和流表Join
圖中的兩張原始表都是MySQL資料庫表，左右兩側表都為流表。通過拉取流表的binlog，并且在一定的時間視窗内進行流表的join。
圖4. ETL畫布配置流表之間的Join
畫布中的節點，有輸入節點、轉換節點、輸出節點。每個節點都可以配置響應的參數，對應不同的庫、表、字段以及計算算子，且在不斷豐富中。
而畫布的背後會将具體的計算轉換為Flink Sql語句，直接送出Flink Job形成流計算任務運作。一條資料庫和資料倉庫間的流式ETL鍊路就建立起來了。
在上述案例中，我們采用最常見的MySQL作為源庫、AnalyticDB作為目标庫。形成庫倉之間的無縫銜接外支援資料的豐富計算。
2.2 場景二：資料T+1快照
2.2.1 傳統數倉方案
在傳統數倉領域，存在一個強需求。就是對每天、每小時的資料做快照，為了對過去某個時間的快照資料進行回溯分析。
對于快照表的實作通常有兩種方式：
1、全量快照：每天/每小時提取最新的一份資料，保留最近的S份
2、拉連結清單：使用拉連結清單作為中間過渡的臨時表，然後根據拉連結清單來還原出某個小時、某一天的快照資料
第一種方式最簡單，但是每次的計算量非常大，而且最終需要消耗的數倉存儲開銷非常大。在小資料量情況下采用，而海量資料場景下通常使用的是拉連結清單。
拉連結清單适用的場景有以下特征：
1、表的資料量很大，比如一張使用者資訊表，大約100一條記錄，50個字段，這種單标存儲會超過1TB
2、表中的記錄變化的比例和頻率不是太大，每天僅有10%不到的比例資料會發生變化
傳統數倉的拉連結清單以Hive或者ODPS等離線資料存儲作為目标端存儲，資料通常按小時或者天分區，計算任務也是按小時和天來進行排程。
相對傳統數倉方案，隻能根據小時和天級别粒度生成拉連結清單，這對源端的庫會産生定時的資料讀取壓力，同時資料産生的時間性太慢，不能滿足比如直播中資料報表的快速生成與商業決策，實作的業務場景很可能需要分鐘級甚至秒級的報表生成。
2.2.2 DMS5.0 任意快照能力
DMS5.0的任意快照能力基于DTS的實時資料流與處理技術+DMS的排程與DDL處理能力+ADB的實時數倉能力實作，可實作天級、小時級、分鐘級、秒級的報表生成。：
圖5. DMS5.0拉連結清單T+1快照架構
拉連結清單
拉連結清單主要涉及核心ETL部分的變化，特定鍊路内ETL，通過modify_time（實際表中固定字段——dts_sync_modify_time)和end_time(實際拉連結清單中固定字段——dts_sync_end_time)來标記目前記錄的修改時間以及是否過期。
拉連結清單建立：以原表主鍵+modify_time為主鍵，添加modify_time和end_time列
原表操作對應拉連結清單操作：
拉連結清單示例如下：
快照表
快照表主要涉及DMS任務編排中的固定的定時任務，有天級别、小時級别。表生命周期可設，依靠ADB自身的資料過期機制。
是否能做快照需要依賴前置檢查拉連結清單——拉連結清單的writer時間點位是否已經超過目前整點，拉連結清單最新記錄modify_time、end_time是否超過目前整點。滿足立刻執行，不滿足等待一個固定逾時時間，例如10分鐘後執行
2.2.3 DMS5.0拉連結清單方案數倉方案對比
3.總結
DMS5.0提出庫倉一體概念。在DDL同步、庫倉一體化資料鍊路管理、細粒度快照表支援、ETL可視化處理等方面具備核心技術優勢。
除了傳統的資料庫內建到數倉的鍊路外，DMS5.0目前已經形成跨庫倉的資料ETL鍊路，拉連結清單支撐下的資料T+1快照處理。在資料庫、資料倉庫發展達到一定成熟度之後，兩者之間的融合會帶來新的使用者價值，為資料存儲、計算、處理分析帶來新的改變。我們拭目以待！
分布式能力
全新的DMS通過資料傳輸服務DTS支援關系型資料庫、NoSQL、大資料(OLAP)等資料源的遷移、訂閱以及實時同步。
過去，在資料遷移和同步這類場景中，分布式類型的資料庫一般是作為目标端比較多，例如單機資料庫無法滿足性能要求的情況下，會同步到分布式資料庫中。而近些年，随着分布式資料庫的蓬勃發展，分布式資料庫作為源端的場景越來越多了,例如Lindorm、PolarDB X、MongoDB叢集版、Redis叢集版等各類資料庫及各類中間件的分表分庫的産品。典型的如：将32個節點的PolarDB X(原DRDS)同步到AnalyticDB中進行分析。
把分布式資料庫作為源端進行同步或者訂閱，面臨很多新的挑戰：
- 分布式資料庫多種多樣，如何盡量标準化接入？
- 如何一鍵建立分布式同步任務并簡單有效的運維？
- 分布式資料庫的特點之一就是資料量大，包括存量與增量，如何快速完成存量遷移、并且確定增量實時同步？
- 分布式資料庫的庫表/執行個體、Shard結構如何遷移？
本部分主要介紹DTS在對接分布式資料庫方面的思考與實踐，以及如何通過一系列的機制設計保障鍊路的整體穩定。
2. 标準化分布式資料源對接能力建設
對于DTS而言，支援某個場景或者某種資料源的的資料同步和訂閱固然重要。但更重要的是需要建設标準化的對接架構，讓絕大多數的資料源能夠通過統一的架構，友善高效地對接進來，同時還要兼顧性能、運維等方面，就像我們建設AnyToAny架構一樣。
2.1 分布式資料源同步
我們先看看非分布式資料源的DTS同步鍊路，它為什麼無法直接使用？
如上圖，DTS任務中，從預檢查到增量遷移，每個子產品都是單機版的，計算、存儲、網絡等方面的性能受限于單機性能，無法滿足類似PolarDBX這類分布式資料庫的資料同步和存儲需求。
還有許多其它問題，例如很多分布式資料庫沒有統一的Binlog資料，是以DTS必須要有抓取分布式Binlog的能力。
分布式資料庫為源的同步，對原來的DTS的同步鍊路進行了拆分，形成了父子任務的模式，将原來存在性能瓶頸的增量資料服務(讀取+存儲)、全量遷移、增量遷移這幾個部分拆到子任務中，結構遷移這種性能開銷較小的子產品，在在父任務中完成。從理論上來說，RDS MySQL都是單機版的，對應到DTS的每一個子產品，也是單機版本，兩邊機器一樣的情況下，性能不會成為瓶頸。
上面是以PolarDBX-1.0為例，但它并不能代表所有分布式類型的資料源。如果換成其它分布式資料源應該怎麼做呢？
像HBase、Tablestore、Lindorm、MongoDB、MyCat、Redis等類型的資料庫，它們也都有自己的分區或者分片方式，DTS提供接口，各資料源按自己的方式擷取拆分邏輯，對應到DTS的子任務即可。
2.2 分布式排程
DTS鍊路進行拆分以後，就變成了父子任務，每個任務之間以及任務内的各個子產品之間需要按嚴格的順序執行，DTS的Master子產品負責把拆分後的鍊路按從左至右的順序排程起來，父子任務以及他們的子子產品會交替執行，這樣就完成了一次分布式資料源到其它資料庫的同步或者遷移過程。
相比非分布式DTS任務的排程而言，分布式任務的排程主要難點在多條鍊路之間需要協同。例如子任務進行增量遷移之前，必須等父任務把後置結構遷移完成。
2.3 分布式DDL同步問題
針對DDL(Data Definition Language 資料定義語言)，DMS對于單執行個體資料庫到單執行個體資料庫的同步是比較簡單的，直接同步DDL到目的執行個體即可（當然要考慮online DDL同步的情況），但是對于分布式資料源的DDL同步是比較難的一個點。以PolarDBX1.0為例，簡單描述下問題：當源端進行了一個删除列的操作，對應到PolarDBX1.0下面的每個RDS上都會執行一次删除列的操作(水準拆分模式)，因為DTS的子任務增量遷移子產品是并行執行的，子任務同步的進度不會完全一緻，如果不作處理，可能會出現這樣的現象，【子任務1】進度快，它對目标庫進行了删除列操作，【子任務2】進度慢，它還在對這個列進行寫入，導緻最終同步出錯。
處理這個問題的一種辦法也是對DTS子任務進行協同，當有DDL需要同步的時候，隻在一個子任務中進行同步，這個子任務等待其它子任務的DDL也到達的時候，再由它去對目标表執行DDL，其它子任務等它執行完以後再繼續後面的同步。
2.4 庫表映射問題
某些分布式資料庫，是以分庫分表的形式對資料進行打散存儲的，例如PolarDBX1.0、MyCat等。DTS讀取這類資料庫的時候，讀取到的是它的實體執行個體中的實體庫表，同步到目标端以後，需要把實體庫表映射為邏輯庫表。這個事件在【結構遷移】、【全量遷移】、【增量遷移】這些步驟中都需要去做。
但是對于不同的資料源，處理方式上會不太一樣。簡單抽象成兩類，第一類是在資料流同步過程中，由DTS的核心子產品實時擷取映射關系，這是最理想的情況，因為它能相容同步過程中庫表變化的情況；第二類是在生成子任務的時候先擷取映射關系，存儲起來，在資料流執行過程中按存儲好的關系進行映射，這類适用于處理資料流的時候不友善讀取的場景，如DMS邏輯庫。
2.5 修改同步對象
『同步對象』指的是需要同步的庫表資訊。在同步過程中，修改同步對象是一個常見需求，也是一個剛需。DTS分布式任務對于修改同步對象後産生的變化是：産生子任務。由子任務去同步新增的庫表，子任務無延遲後合并到他的主任務。當然，如果修改同步對象沒有增加新的庫表，就不需要産生子任務。
3. 一體化生命周期
使用者隻需要進行一次配置，就能生成好一條分布式的資料同步或者訂閱鍊路。從控制台上來看，主任務隻有一個。DTS會把子任務資訊彙總到主任務上，包括進度等等方面。
子任務在任務詳情頁面中有清單顯示，也能進行詳情的檢視。
任務的暫停、修改同步對象、重新開機、釋放這些操作都是在父任務中統一進行，DTS會把相關指令下發給子任務，内部進行協同處理，對于使用者而言，隻需要在父任務上進行操作即可。
同樣的，對于報警、監控、診斷這些運維能力，DTS也會把它們集合到父任務上面，友善使用者運維管理。
3.1 分布式資料源訂閱
分布式資料源訂閱與分布式資料源同步一樣，也是對DTS任務進行拆分，相對于同步來說，訂閱的服務端處理過程會更簡單，因為沒有【結構遷移】、【全量遷移】和【增量遷移】。其它部分與分布式資料源同步基本是一樣的思路，這裡不再展開。
3.2 訂閱SDK
在原來非分布式資料源訂閱的基礎上，我們對訂閱SDK進行了更新，通過多線程的方式并行消費，這樣使用者隻需要啟動一個Client就能完成分布式資料庫的訂閱。
和上節【分布式資料同步】中【庫表映射】描述的問題類似，在訂閱的時候，SDK這一層也需要對庫表進行映射，把擷取到的實體庫表映射為邏輯庫表。
資産管理與安全
1. 背景
資産管理是諸多安全管理中的基礎，同時資産管理可以幫助企業更及時、準确的發現安全風險，并通過管理元件來執行有效的安全控制措施。發現與納管資料、優化資料成本與品質、確定資料被安全流轉和使用是資料管理中的主要三部分内容。
資訊時代資料的安全性以及如何管理資料成為企業重點關心的内容，同時在安全合規的要求上資料加密和脫敏同樣備受關注。在資料資産的生命周期過程中，企業主要面臨以下幾類問題：
（1）資料分散在各個地方，沒有有效的統一管理手段。
（2）資料授權難以維護，包括資料庫授權和分散在各處的賬号。
（3）授權粒度過粗，無法有效保護資料，授權粒度過細，管理成本極高。
（4）全域敏感資料的一緻性保護。
（5）資料洩露後的應急處理無法追溯和快速止血。
（6）傳遞和分享資料時的安全問題。
2. 發現與納管資料
資料一般存儲在資料庫、檔案以及應用中。資料庫部分具體可以細分為關系型資料庫、非關系型資料庫以及資料倉庫中；檔案一般為靜态存儲，比如利用阿裡雲的OSS來存儲日志檔案、Excel等。除了資料類型之外，資料的網絡存儲位置也有多樣的特征，比如公有雲、VPC網絡、自建網絡甚至是本地伺服器。
資料資産采集
DMS支援27種以上的資料源的發現和納管，為資産的收集打下基礎。
1、掃描特定網絡環境内的IP和端口來發現資料庫執行個體。
2、掃描執行個體資訊與schema資訊
例如MySQL執行個體：
擷取執行個體版本資訊：select version();
其他中繼資料資訊從information_schema下的各個表中擷取。
3、資料采樣
通過采樣少量資料來做資料分類分級。
4、孤島環境的資料發現
利用資料庫網關DG發現和統一納管孤島環境的資料。
3. 優化成本與品質
統一納管是資料資産管理的第一步，在此基礎之上，對資料進行類目、品質、血緣、分級分類等管理需要，以用于發現不必要的資料拷貝、低品質的資料和發現資料安全威脅等。
建構資料資産知識圖譜
1、資料資産關系識别
分别從中繼資料的實體關系、邏輯關系、ETL內建任務、加工血緣關系、Schema matching技術、工單與資料庫變更關系、應用與中間件關系、人與資料庫的權限關聯關系等幾類關系進行圖譜建構。
2、繪制圖譜
圍繞資源與資源、人與資源、人與權限、人與工單等幾個“點”來進行繪制各個關系的“邊”。
3、線上圖譜存儲
将繪制好的圖譜資料存儲到阿裡雲的圖資料庫GDB中。
4、資料資産服務
基于線上知識圖譜，可以提供資産檢索、變更風險關聯分析、資料安全風險關聯分析、變更預警、資料安全預警等。比如當資産表T要做結構變更時，上下遊的依賴及時關聯或提醒關聯風險，對上下遊的資料消費穩定性非常有益。
4. 安全流轉與使用
資料的分類分級與敏感資料識别
資料的分類重點強調資料類型的不同按照屬性和特征進行的劃分，分級則側重于具體的标準，對同一類别的屬性按照高低大小不同程度進行級别的劃分。比如根據GDPR标準中定義的分級标準進行劃分等。在相關法規中DMS除了滿足GDPR要求之外，也遵循了等保2.0、資料安全法、個人資訊保護法等法規要求。
1、配置分類分級模闆與定義敏感資料
一般認為資料的分類是有共識的，比如具有手機号特征的定義為個人資訊手機号類别。此配置主要用來配置該類别的分級政策以及敏感資料的定義。DMS提供了一系列法案模闆簡化該配置。
2、配置定時掃描規則
通常資料資産是在不斷增長和結構演進的，及時發現并進行分類有利于降低敏感資料洩露風險。定時的掃描任務可及時發現資料中存在的敏感資料并進行保護。
通常資料的分類主要以中繼資料資訊比如列名、表名、備注名等為基礎，補充抽樣資料來加強識别。
有以下幾種方式來進行資料分類：
基于關鍵字；
基于通配符；
基于正規表達式；
基于機器學習；
5. 敏感資料保護
被定義為敏感資料的目的是為了在流轉和使用過程中進行全方位的資料保護和防洩漏。通常做法為資料脫敏保護，脫敏分為兩類：靜态和動态脫敏。
1、配置脫敏算法
對資料的脫敏方式進行定義，比如DMS支援15+脫敏算法，涵蓋遮掩、替換、轉換、hash等算法分類。比如手機号采用中間四位的遮掩方式。
2、配置脫敏政策
對不同場景下使用資料時的脫敏方式進行定義，可以細分為簡單查詢、資料導出、資料分析等場景。以配置不同的脫敏算法。
3、靜态脫敏與動态脫敏
靜态脫敏利用脫敏算法将資料在同步過程中進行脫敏，以保護資料不在目标端存在。比如當做DTS資料傳輸時進行脫敏，下遊無法擷取到敏感資料進行消費。
動态脫敏上DMS安全通路代理相容HTTP及MySQL協定，使用者可以直接通過安全通路代理層通路資料庫。基于安全通路代理通路資料庫的過程中，DMS會充分檢測通路權限有效性，并檢測攔截違反研發規範、安全規則的資料操作行為，并進行敏感資料的安全脫敏。
5.1 權限管控
資料資産涵蓋了企業内的所有資料，不同的部門、人員以及業務之間的通路應該受安全管控。單也應該兼顧長期通路、短期通路、資産下大顆粒度、小顆粒度通路等需求。
比如DMS在資料庫之上建構了一套邏輯的權限體系來做通路控制。通過對資料、人、權限三者的抽象實作細粒度權限管控能力。控制粒度從大到小依次是執行個體、庫、表、列、行。同時對操作做了以下三種權限類型：查詢、變更、導出。權限時間可自定義到分鐘級。通過賬号托管的手段，避免研發人員直接接觸到資料庫的賬号密碼資訊，進而提高資料安全性。
5.2 操作審計
所有對資料資産發起的SQL以及資料結果元資訊都應記錄并形成審計記錄。保障操作可審計可追溯，在SQL操作上，可以根據人員發送的查詢請求，分别記錄下請求方的IP、請求方的人員資訊、操作時間、SQL内容、SQL操作造成的影響行數、以及目标庫資訊，全面的記錄和審計操作人和被操作資料庫的資訊。
同時日志要進行加密和具備防篡改的一緻性校驗，避免日志被修改利用。
四、總結
一站式資料管理DMS提供完善的統一資料管了解決方案，相容資料存儲類型和地域的複雜性，實作從資料的生産、存儲、傳輸、加工到計算的全生命周期管理；同時需支撐資料生産環節的資料庫設計開發及資料采集、資料傳輸環節的實時及離線資料內建、資料使用加工環節的資料開發及加工能力、資料使用環節的資料服務能力。其中資料源覆寫度、資料安全和治理、資料庫DevOps、資料傳輸時效性、資料開發的靈活性都是主要考量點。
本文讨論了一站式資料管理DMS的部分關鍵能力，希望為廣大的使用者深入了解和使用産品提供抛磚引玉的作用。