“数聚云端·智驭未来”——阿里云数据库创新上云峰会暨第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快照处理。在数据库、数据仓库发展达到一定成熟度之后，两者之间的融合会带来新的用户价值，为数据存储、计算、处理分析带来新的改变。我们拭目以待！

分布式能力

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的部分关键能力，希望为广大的用户深入了解和使用产品提供抛砖引玉的作用。