qData数据中台专业版v2.6.0全流程系统演示原创

大家好，欢迎观看本次科代的专业版数据中台全功能讲解。本次演示将以河道水平监测为业务场景，带大家完整的了解数据从接入、平台加工生产、数据治理到资产发布和业务使用的全流程。接下来我们就从这个业务目标出发，逐步完成数据接入、数据生产、数据治理、数据资产、数据服务和智能论述，最终形成一条完整可持续运行的数据链路、治理链路。接下来，我们会将分散在达梦、MYSQL等业务数据库中的河道水禽数据统一接入QD，并按照ods DMD w ddws和ADS五层树汤体系。完成数据规划、清洗、加工、统计汇总和应用数据建设，在此基础上，再通过主数据、原数据、数据质量和数据安全建立完整的数据治理闭环，最后将治理后的数据发布为数据资产API。

和智能论述能力，为不同的业务场景提供服务。通过这条主线，大家会看到科贷的解决的不只是把数据搬进来，而是让分散、口径不一、质量不可控的业务数据逐步转化为统一、可信、可追溯、可管理。可服务的数据资产。在搭建之前，先看这条数据链路最终交付的成四项成果，第一是数据资产的资产地图，将技术表整理为带有业务说明、质量评分、血缘关系和安全等级的数据资产，二是质量报告，通过质量规则发现异常，展示质量评分和问题数据，支持问题定位与整改，第三是标准的API。

为地图、移动端和外部系统提供数据，并支持授权、限流、监控和审计。四是智能问述。业务人员可以直接用自然语言提问，平台自动生成circle口L，并返回文字、图表和明细结果。接下来我们将依次完成ods DM dwdd ws和ADS数据加工，在进入数据治理、资产管理和数据服务。我们先看一下Q盖的工作台顶部导航栏，用于切换技术管理数据、建模数据、研发数据、治理数据资产数据、服务数据可视化。智能问述，还有系统管理。左侧呢，展示的是模块菜单，中间为操作区域，多页签，方便在不同的任务之间进行切换。那么系统管理里面Q代的采用两层权限体系平台及权限控制，用户可以访问哪些模块？

菜单和按钮项目及权限控制。用于控制。用户在项目可以使用哪些数据连接任务和研发。例如，用户即使拥有了数据开发的权限，没有加入到基础数据组的项目。也无法操作该项目中的任务系统。管理中用户用于维护。账号角色用于分配权限，菜单用于控制功能入口。实际应用中可以按照平台管理员、项目管理员。开发、质量分析和运维等去分别授权部门岗位字典、参数通知及其日志。

等功能，共同保障了平台可管理、可控制、可审计。进入数据生产之前呢，我们先需要回答三个问题，数据从哪儿来？平台通过什么方式方式进行访问？这些资源有哪个项目进行负责？在Q中分别对应来源系统、数据连接，还有项目管理。那么首先呢，我们先看一下来源系统，来源系统描述数据的业务归属，它不只是数据库连接名称，也是后续原数据分类、资产检索和资产最终的重要依据。这里已经登记了嗯，内部文件管理系统以及otsdm dwdd ws ADS五个数仓层级，同时还包括内部文件管理系统。后续进行云数据采集和资产管理的时候，可以通过来源系统数快速的找到不同业务和数仓分层中的数据。接下来我们来看一下数据连接。

数据连接解的决的是平台如何去访问数据。现That可以通过统一的管理关型数据库、分析型数据库、文件no circle数据队列、持续数据库等。多种连接类型。本次演示重点使用两个连接，一个是MYS口河道水平监测库，用于存储河流、河段、断面、测站以及水位、流量和雨量等业务的数据，另一个是Doris。当瑞斯数仓用于承载odsdm DW d d ws和ADS5层模型及加工结果。接下来我们看一下项目管理，项目用于隔离成员角色、数据连接任务和研发资源，项目负责人负责项目内的资源管理、成员协作和最终交付。通过基础管理的讲解，我们已经配置了可访问的数据连接，建立了独立的项目空间，并准备好了统一的类目和规则资源。下一步我们进入数仓建模，开始规划河道水禽的5层数仓体系。

很多数据项目直接从写色扣开始，但是没有先统一标准数仓分层和业务边界，任务越多，数据口径越容易混乱。因此在正式的开发之前，我们需要先完成数据建模。首先我们先看一下数据标准平台，可以检索国家标准。行业行业标准、地方标准和团体标准。查看我们的标准名称、发布机构、适用范围和具体的内容内容。接下来我们来看一下标准数据源。标准数据源将业务标准转化为可直接引用的字段定义，包括中英文名称、数据类型、字段长度、是否必填业务说明和代码值等内容，模型设计时直接可以引用数据源。

可以减少重复的配置，并保证同一字段在不同模型中的名称、类型和口径是一致的。然后我们再看一下数仓分层，本次河道水清场景采用了odsdmd w DD ws和ADS五层体系，Ods保留原端结构和原始数据，用于数据追溯、DM统一河流、河段、断面和测站等基础对象，DWS完成数据清洗、标准化和维度补充。DWS形成日、旬、月、年及趋势等汇总结果。

ADS面向一张图、水情简报和趋势分析等业务应用，通过统一的分层，可以明确每张表的职责，避免明细汇总和应用数据混在一起。接下来我们来看一下业务分类，选择我们的河道水禽业务，并规划数据域和主题，根据业务的内容，我们可以规划它的基础对象、实时监测等主题，这样我们可以将技术模型和业务语义对应起来。业务人员不。需要记住物理表明也能够按照对应的。分类和主题快速的查找到数据，然后我们首先去再看一下逻辑模型，首先呢，我们先创建，嗯，编辑一个和。

河流的为表。维护我们河流为表。可以维护它的数仓分层、业务分类表的中文名称、英文名称、完整的表明等。然后我们还需要再看一下我们本一个业务，还需要去创建一个实时的流量明细模型。这个实时的流量模型，我们可以看到它有测站的一些中文名称，有河流编码、河流名称、河段编码等，这些用于去下游直接统计分析，然后其次我们还有一个日均流量的模型。那么日均流量模型呢？按照测站和日期进行汇总，计算平均流量、最大流量、最小流量及日水量。

那么我们把模型创建好之后，可以通过我们的模型发布，选择到对应的一个嗯，Doris数据连接，我们要核对一下数据库物理表明和字段结构之后进行发布，首次呢，首次发布呢，我们会去采用创建新表，然后增量发布，我们是用于新增字段或者是调整兼容结构，删除重建会清除原表数据，重新发布用于再次执行发布。生产环境中涉及删除表或者是影响已有的数据的操作，需要提前确认范围并做好备份。本章呢，我们总结一下，我们通过数据建模完成了我们的河道水情五层数仓规划，统一了业务分类，数据分域，主题规划，还有我们的标准字段。

并通过核心的模型，通过创建模型和发布模型，将模型发布到了Doris。到这里，数据应该放在哪一层，每张表承担什么样的职责，职责字段采用什么样的标准，我们都已经明确了。下一章我们将通过主数据管理，进一步解决河流河段断面和测站编码不统一的问题。我们看一下主数据模型解决了数据应该长什么样，主数据管理解决的则是核心业务对象应该以谁为准。在不同的水利系统中，同一条河流可能使用不同的编码，同一个测站也可能存在名称、缩写、坐标差异或者是状态不同步，如果这些问题不解决，实体实际的那个流量即使成功的入仓，也无法稳定的关联到正确的河流和河段。主数据管理的目标就是建立一个统一的标识、统一的属性和统一的分发机制。那么我们首先先看一下主数据模型的类目，我们按照基础的对象去搭建一个河流、河段断面、雨量站、水位站的流量站等的类目，类目呢，用于去组织实体模型，也方便不同人员去维护。

职职责管理。也方便不同维护人员按照职职责去进行管理。那么我们先再打开一个河段的一个实体模型。这个实体模型呢，维护的既有我们的系统预设字段，也有业务。字段配置，然后我们先看一下它的系统预设字段，有主数据ID，数据来源是否有效等这些字段，那么我们再看一下这一个河段的这一张这实体模型表里面有。

记录ID、河段编码、河段名称、河段编码、河流编码、河流名称等这些业务字段，那么我们可以看到它的记录ID是必填的。然后我们可以看一个未发布的一个。实体模型，那么未发布的实体模型我们可以针对于某一个字段去进行修改，并且去绑定标准数据源，或者是绑定标编码规则。然后我们把实体模型维护好之后，可以通过这边的发布按钮进行发布，发布成功表示主数据维护表和相关的结构都已经准备好了，发布的时候可以选择发布到的具体的数据库的一个名称里面去。然后下面有一个标准数据源，刚刚我们讲到实体模型在未发布，在编辑的情况下，可以去绑定标准数据源，可以去引用标准数据源，它呢主要是查看主数据字段与标准数据源之间的关系，以断面类型和启用标识为例，引用关系能够帮助研发人员理解字段的含义，也能够为后续的标准符合性检查提供依据。然后我们就进入到了主数据维护，我们可以按照实体模型的名称，实体模型的编码以及状态。

进行快速的筛选，然后我们还可以新增和修改记录，启用或者是停用我们的某一个对象，在这个位置可以针对于啊我们的主数据进行维护数据。我们可以在这里新增新增一条数据。

这样是可以在我们的主是已经发布的实体模型里面进行去维护数据。那么我们把主数据建立好了之后，还要需要统一的将结果分发给需要使用它的一个系统，所以我们就有了主数据推送，然后主数据推送呢，需要去配置选择下游的系统，主数据对象我们要去发哪一个已经发布的实体模型，然后推送的范围是启用数据还是全部数据，这边还可以选择它的推送模式，是增量还是全量，这边就是你们瑞特接收的一个配置，一个下游的接收地址，进邮方式，认证方式，超时时间，还有它的token，如果失败了，需要配置我们失败的，失败是是是，是否自动重试，如果重试的话，重试几次，间隔时间是多少，如果超出了，那么失败重次的次数是停止任务还是转人工。

下面就是我们的字段映射，我们模型字段对应的你在这个接收地址里面的下游字段是哪一个去配置就可以了。那么经过这一章呢？我们可可以知道河流、河段、断面和测站已经有了统一的主数据，后面的ods到DWD加工就可以用这些统一的对象补充和校验实时监测记录。那么我们现在模型和主数据已经准备好了，下一步我们就可以进入到数据研发的项目，建立实际开发所需要的成员、权限、类目和连接。那么进入到我们的基础数据组项目之后，先看一下我们的项目成员。成员决定了哪些人可以参与到我们的这一个项目，那么项目角色决定每一个人能够做什么。项目管理员负责成员角色和资源的分配，数据开发人员负责集成和开发任务，质量评估人员负责规则和报告，数据分析人员主要使用资产查询和可视化的能力，运维人员关注实例日志和异常处理。这种分工的意义是把能进入平台和能够修改生产任务分开。比如分析人员可以查看已经授权的数据资产，但不一定有权限下线实施的任务，运维人员他可以去跑重失败的实力，但是他不一定能够修改模型的字段。接着我们看一下数据集成、数据开发和作业管理的类目。

建议呢，我们的类目与业务的链路要保持一致。例如我们可以按照。基础对象、实时监测、历史监测、指标统计和应用产品来划分。后面在任务列表中，我们可以通过类目快速的定位到相关的任务，也可以将类目用于权限和责任的划分。那么项目级的数据连接主要用于我们的数据研发模块，在数据连接模块我们可以查看数据连接的名称、连接的类型、连接的状态，还有负责人这边在操作列里面也有我们的测试连接，用于验证当前连接是否可用启停。

操作用于控制项目内是否可用，那么详情页呢？是展示了我们连接的一个使用情况。可以看到有运行监控，读写日志，告警记录，告警规则和这一个连接的一个基本信息，那么针对于我们已经上线或者是已经关联了任务的时候，我们在进行去删除这一个连接的时候会受到权限保护。到这里我们的基础数据组已经具备了成员角色，任务分类和可用连接，我们可以正式的开始始数据接入。

那么数据接入阶段，我们分别演示整库同步和可视化的数据集成，两者都能够把数据从原端送到目标端，但适用的场景不同。人工同步适用于我们多表批量的迁移，可视化的数据集成呢，适合需要字段选择、清洗转换、条件判断和流程编排的复杂任务。那么首先呢，我们先看一下整库同步，那么整库同步这个模块我们可以按照任务名称、原数据库、目标数据库进行快速快速的筛选。我们的列表里面呢，也直接展现了任务的基本信息，包括我们整户同步步的一个任务名称，任务同步了多少张表，然后这边是一个整户同步的一个描述，然后数据链路它是从哪一个原数据库同步到了目标的数据库，包括它的运行状态，调度周期等，我们可以把这个任务状态关闭。

看一下我们如何去配置或者是新增一个整库同步的任务，首先可以去编辑我们整库同步的任务名称，还有这一个整库同部的一个负责人，然后这边会自动读取你的责任人的一个电话。在这里可以先去选择一个员库的类型，那么我们现在这个类型选择的是MYSQL，然后源数据库MYSQL我们要读取哪一个库，我们这里已经选了河道水情系统，那么你整库同步肯定是从源库读到目标库，那这边你就可以选择目标库的一个类型是do瑞斯，目标库的数据库是数据中台的原始库，然后我们再看下一边。那么我们在来源表里面就读取到了我们在数据库信息里面选择的源库类型的源库的源数据库这边就是那个原数据库里面的所有表，你可以在这个位置去选择，你对应需要整同步到另一个下。

对象的那个库的。表放到下面这一位置，然后选择完表之后就可以去配置它的一些映射关系，还可以自动去匹配我们的目标表，然后匹配目标表默认的前缀，在这里可以去编辑一个前缀。这边就会自动去。帮你把你所勾选的前缀都显显示上，然后还可以去设置我们的目标分区，目标分统的设置。然后列表重置，就会清空我们刚刚所有的一些信息。然后如果你还需要将还需要在目标表里面新增加一些字段，可以在这个位置直接去点新增去追加就OK了，那么我们下一步如果你把你的所有的配置多表映射的关系都配置好了，就可以去配置我们这一个整库同步的一个调度，一个属性。

首先是调度周期，可以手动的去执行，也可以选择表达式去配置我们的调度周期。然后下面是异常处理的策略，有错误错误处理策略和脏数据的处理策略，你们都可以按需去选择。下面是执行参数的一些配置，在这里你可以为任务设置执行引擎、失败处理策略以及运行所需要的计算资源。配置好这一个整库同步的任务之后，如果你把任务状态打开之后，你可以去执行一次，也可以将调度周期打开，就会按照你自己配置的一个调度周期去执行这一个任务。那么我们整个同步讲完了，那么还有一个可视化的数据集成。

模块在我们数据集成里面，左边是我们集成的类目，上面可以按照任务名称，任务状态，执行状态等快速的进行筛选，那么同样的我们也按照我们的数据治理的一个顺序，讲一下我们怎么去使用我们的数据集成。那么在任务的列表里面，我们先打开一个任务，也就是我们的河道水型基础库到ods水水位站全量每日基础对象。那么像我们这个任务名呢，它同样是采用了统一的一个命名规则，由业务主题、数据流向、任务内容、同步方式、调度频率和任务分类组成的。那么其中河道水平表示的是所属的一个业务主题，基础部到ods表示的是数据的来源和目标层级，水位站呢表示的是本次同步的数据对象，全量则表示每次执行都会读取完整的一个数据，每日则表示任务的一个调度周期。通过这样的一个命名方式，开发人员呢，不需要打开任务就能够大致的判断出来您这个任务处理了什么样的数据，从哪里去读取，写到哪里，以及采用什么样的方式进行同步。那么我们可以把这个任务关掉，进入到我们的配置页，可以看一下我们的一个任务配置，在这里我们可以维护任务的名称。

所属的类目、负责人和任务描述。对于任务数量较多的项目，建议统一配置负责人和类目，便于后续的任务查询、问题定位和日常的维护。然后我们查看一下我们的执行策略。我们执行策略包括了并行、串行、等待串行、抛弃串行优先，而且我们可以去配置我们的任务的调度周期。

失败重试的间隔、work分组等这些资源参数。对于每日或每小时运行的离线任务，我们重点需要关注一下调度周期、失败重试和执行节点。对于实时的任务，除了运行方式以外，还需要重点关注并并行度、检查点和资源配置。不能够只看任务是否配置了调度，并行度会影响数据处理能力，检查点用于保存任务运行状态，而资源配置则会直接影响到任务运行的一个稳定性。然后我们看一下我们的一个画布，画布最左侧是我们的表输入节点，它负责定义数据从哪里进入到了任务，打开我们的一个表输入组件。我们可以选择对应的原数据库的连接和原数据的一个数据表。

在下面的属性字段的数据预览之里面，我们也可以看到这一张表的一些具体的字段的内容，可以看到有测站编码、测站名称和流编码等这些信息通过业通过预览，我们可以在任务开发阶段确认数据连接是否正常，原表是否通过可以是否可以访问以及。读取到的字段是否符合我们的预期，然后数据进入任务后，会依次经过中间的字段处理组件字段选择和修改节点，用于保留本次任务需要的字段，也可以调整字段名称、数据类型和字段类型。校验和转换组件择负责完成基础的数据处理。例如我们有转换组件，照应组件，然后转换组件里面可以新增新清洗规则，我们内置6大类清洗规则。

然后再去通过表输出组件配置数据写入的位置，在表输出节点选择对应的一个目标表数据连接和目标表。然后去配置来源表字段和目标表字段之间的映射关系。然后一条可视化的数据集成任务核心就是三个部分，第一，数据从哪里来，第二，数据在中间经过了哪些的处理，第三，处理后的数据最终写到了哪里。只要理解这三部分，我们就可以快速的看懂大多的数据，大多数的可视化的数据集成任务，那么除了当前任务中所使用的表输入、表输出，那么我们的输入组件可以对接不同类型的数据库、文件、消息队列和接口。数据转换组件可以完成我们的。字段选择、字段修改、数据过滤、格式转换、数据合并和数据拆分。

用于标一些标准组件无法完成的特殊逻辑，还可以通过Java脚本组件。自定义处理规则，还有我们的条件分发组件。可以根据不同的条件将数据发送到不同的处理分支子流程组件可以将已经建设好的公共处理流程复用到不同的其他的任务里面去，然后我们的输出组件呢？用于将处理后的数据写入到数据库、文件、消息队列和其他的目标系统中。然后我们看一下我们的数据集成的一个任务，我们看一下我们下一个河道水历史库，到我们还是看这个吧。我们先看一下我们表输入组件里面这一张表的一个信息。去找到我们这一张表，输入表。

那么通过右击slack查询，可以快速的查看我们这一张表里面的所有的数据。然后我们再看一下它的一个写入，表示ods的这一张表。那么我们也可以通过select查询一下我们的输出表，那么我们现在在没有经过数据集成任务去同步的前提下，我们这一章目标表示好，那么我们现在呢，可以去回到我们的数据集成里面，把我们这个的任务状态打开，打开之后可以在操作的更多里面去。进行运行一次的操作，运行之后，这里面会展示我们运行的一个结果，然后我们可以看到它是运行成功了，那我们同样呢，在这里面可以看到我们的运行实例，运行实例这里展示出来了，我们在8月12号的6:57已经运行成功了，那么成功之后呢，就代表我们已经把我们输入表里面的数据写到了我们的ods这一张输出表里面，那么我们怎么看数据有没有过来呢？我们继续回到我们的数据查询去查一下我们这一张ods的表里面是否有数据，然后点一下查询，然后我们就看到了我们的数据已经写到了输出表里面去，那么我们的任务配置完了之后，我们还想要基于我们当前这个任务去快速的创建一条类似的数据链路，那么我们就可以使用这里的克隆任务的一个功能，然后可以基于现有的任务快速的去建立是新的水位站、流量站或者。

还是与量战的同步任务？减少了我们一些重复性的配置工作，但是你的任务克隆完成之后，必须需要检查修改任务的名称、原表、目标表和调度的参数，特别是目标表和写入的方式。如果没有及时的修改，可能会导致多个任务同时向一张表写入数据。我们在数据集成这一个模块，通过我们的数据集成的任务，可以将河流、河段、断面和测站等基础对象批量的同步到ods的一个天元层，实时的流量数据也已经完成了从业务数据库到ods层的实时同步，并为后续进入DWD明细层进行质量检查和数据的补充做好了准备。到这里我们解决的是数据如何从不同的来源进入数仓数据仓库的问题。下一章我们将进入数据开发的ID。

继续完成从ods到DWD再到DWS和ADS的数据清洗、统计、汇总和应用加工。那么完成了数据集成之后，接下来我们进入到数据开发的IDE，继续建设从ods到DWD再到DWS和ADS的数据链，数据加工链路。在任务列表里面可以去按照我们的任务的类目、任务名称、任务状态、数据连接类型进行去筛选。对于任务数量多的，治理链路比较复杂的项目，建议统一任务名称命名，并结合类目进行管理。

例如我们河道水禽历史库到ods历史雨量明细增量每小时监测数据，这一个名称是由业务主题、加工链路、任务内容、同步方式、调度频率和任务分类组成的。开发人员看到这个任务名称之后，就能够快速的判断这个任务是做什么的，数据是从哪里来的，写到哪里去的，以及采用什么样的方式。那么现在呢，我们先打开我们的IDE的一个工作台。

左侧是资源数，用于管理任务和SQL脚本，中间支持同时打开多个我们同时打开多个任务标签页，SQL编辑区用于编写和修改代码，参数区域用于配置运行参数和变量，页面下方则展示我们的运行日志和结果集。开发人员可以在同一个页面完成代码编写、任务运行、问题排查和结果验证，不需要在多个页面之间来回切换数据开发目前支持Spark circle flink、批处理、flink流处理等多种执行引擎，可以根据实时处理、实时离线统计和复杂计算等不同场景选择合适的任务类型。那么弗Li可流处理任务首先我们来看一下河道水禽ods。到DWD实时流量明细实时外部表到DWD这一个任务，这个任务呢用于处理和到实时流量的数据。前面的数据集成任务已经将第三方数据库中的ST-R-ST-Q-R实时同步到了ods层中的ods-RH-RTW-ST-R-Q。当前任务继续读取ods层的数据，对流量值进行质量检查，过滤流量为负数的异常记录，同时补充测站河流和。

段和断面等基础信息，最后呢，把结果写入到我们这一张表里面去，DWD-RH-RTW-ST-Q-R。首先我们看一下这一个任务配置的一页面，查看这一个任务的数据连接，执行的引擎是flink流处理，然后和我们的运行的一些参数，包括我们运行的一个调度周期，最后我们查看对应的flink SQL的代码。接下来我们进行一次实时的数据验证。

我们先看一下我们这一个河道水禽的一个任务。它是状态是打开的，然后我们可以看一下它的一个。表。我们可以看到我们这一个任务。他的。原表是这一张表，我们看一下原表的一个字段，在这个位置呢，我们去放了一个可以看一下这个字段，这边有一个碧川河放了一个W。然后这边有正的有负的，我们先把这个B川和改成负的。然后我们改完之后呢，可以看一下它的。

Ods层的一个数据表，然后它的数据就被同步过来。然后我们再看一下DWD，现在在没刷新之前呢，因为我们B川和W这一条数值原先是一个正的值，然后没有刷新之前它是在的，然后经过我们的任务去执行之后，那么因为我们去把赋值给筛选掉了，那么他就没有了，通过这个过程我们可以直观的看到实时同步数据校验和明细加工的完整链，那么接下来我们再看一个弗林可批处理的一个任务。这个任务呢，我们是由我们的这一张表按照我们的测站编码和月日进行分组，在对于不同年份同一天的水位数据进行比较，计算多年的平均水位、历史水位和历史最低水位，计算结果写入到多年的平均水位统计表中。先查看我们任务的flink circle的代码，重点查看分组维度，平均值计算和历史。

极值计算逻辑，最后呢，我们可以看一下。我们的执行的一个结果。这是我们最后执行之后，他会把值都按照同一个测站在不同年份相对相同的月日的水位数据已经被汇总为多年平均值和历史极值，为后续的水位趋势分析和统计对比提供了数据基础。接下来我们再看一个。Spark SQL批处理的一个任务。这个任务的来源表是历史流量明细表，目标表是日流量统计表。Circle口L按照测站的编码和统计日期进行分组，计算每个测站平每天的平均流量、最大流量、最小流量以及日累积流量。现在我们看一下circle，查看具体的一个分组聚合和写入逻辑。相比实施任务，Spark circle更适合历史数据加工、批量统计和相对复杂的离线计算场景。除了刚刚演示的flink流处理、flink批处理和Spark circle批处理平台还可以根据实际的项目需要扩展其他的执行引擎和任务类型，满足不同数据规模、处理时效的和计算场景的要求。通过以上的任务，我们已经完成了。

一条较为完整的数据加工链路，首先将3第三方的数据同步到了ods的天源层，然后通过数据开发任务完成数据清洗、校验和信息补充。

形成了DWD明细数据，接着基于DWD明细数据进行统计汇总，形成DWS汇总数据，最后在基于DWS数据开发面向地地图展示、趋势分析、统计报表和数据服务的ADS应用层的数据。目前这些任务还是相互独立运行的，下一步我们将这些独立的任务按照上下游依赖关系编排起来，形成一条完整的数据产品作业。前面我们已经完成了整库同步。数据集成和数据开发，但业务需要的是一条按照依赖自动执行的一个完整链路，那么作业管理就是把这些不同类型的任务组合成一个统一调度的数据产品作业，我们打开我们的河道水情、雨水为统计数据产品每日作业这一个作业。

在作业列表里面，我们可以查看我们所属的类目执行的策略调度周期作业的一个调度和。做调度状态。作业状态表示的是当前定义是否可用，调度状态表示的是系统是否会按照计划计自动的触发，两者需要明确的确认。然后我们进入到作业的一个画布，左侧的类目数会展示项目内可用的整库同步数据集成和数据开发任务。先把河流河段断面和测站维度准备任务放在上游。然后将实时水位、流量和雨量接入，可以组成并行的一个分支，每条分支完成ods到DWD，清洗后再汇集到ADS。一张图生成任务，点击节点可以去查看我们节点的引用任务失败策略、超时设置和重试配置连线表示的是执行的依赖，不代表数据字段的映射。保存前使用流程需要检查确定没有孤立的节点循环依赖或者是未配置的任务画布的缩放。

从事视角导出功能都可以看一下，方便复杂作业的设计、评审和文档沉淀，然后我们可以进入到我们的一个作业的一个详情。可以查看定义和版和版本。进入运行实例则可以看到我们的。每一个节点的开始时间、结束时间、状态和日志入口，通过作业管理，原来分散的任务已经成为了可统一调度、可统一监控的数据产品流水线。接下来我们从运维的视角查看它是否稳定运行，以及出现的问题如何去定位。运维管理数据链路上线之后，关注重点会从任务能不能运行转向任务是否稳定，异常后能否快速的定位和恢复运行管理，统一展示整个同步数据集成数据开发和作业的运行实例，方便查看运行状态、执行耗时、处理数据量和异常日志。整库同步实例首先查看整库同步的。

实例可以按照任务类目、实例名称、执行状态和运行时间进行筛选，并查看开始时间、结束时间、负责人、执行耗时和执行结果。对于多表同步任务，不只能够去查看整体的是否成功，还可以查看。每张表的读取量和写入量是否基本一致，以及是否存在部分成功、部分表失败的情况。如果实例成功但数据量异常，则需要检查过滤规则、字段映射和目标端写入的数日志。那么我们的数据集成的实例。打开任务实例后，可以先查看任务及的实例，确定实例是否启用使用的执行引擎、当前运行阶段和最终状态，再下转到我们的节点。

判断问题发生在源端读取字段处理数据转换，还是目标端写入原端异常，重点检查我们的数据连接权限。和网络转换异常检查字段类型的处理规则，写入异常检查目标表结构字段映射和写入权限，通过任务及日志先缩小范围，再通过节点日志定位具体的原因，那么我们的数据开发的实例数据开发实例。主要关注SQL的编译、资源的申请、任务执行和结果的写入。运行前是运行前失败的时候。检查SQ的语法字段、数据类型和表是否都存在长时间等待时，检查执行资源和任务队列，任务完成但结果异常的时候，检查写入语句分区条件、过滤条件和目标表权限。结合运行日志和结束过数据可以判断问题出现在哪一个阶段。

作业实例，最后是检查我们的作业实例，作业实例会整体的展示所有任务节点的运行状态，作业失败后呢，可以先通过画布查到查找到我们的失败节点，再去对应到我们的整个同步数据集成或数据开发的任务查看的日志。接下来呢，我们把数据库、数据表和字段的信息纳入到原数据管理，建立一个数据资源的一个目录。紧接着我们看一下数据治理。原数据管理前面我们已经完成了数据接入、数据开发和作业编排，5层数仓中的数据表也已经够持续运行，但是呢，数据库中有了表并不代表这些数据已经能够被理解和使用。随着数据表和字段越来越多，开发人员和业务人员通常会遇到几个问题，平台中到底有哪些数据表？每一个字段代表什么含义？表结构是否发生过变化？某一个字段是什么时候新增或者是修改的？要解决这些问题呢？就需要对原数据进行统一的管理。原数据可以理解为初据资产的地图和说明书，它描述数据来自哪里，存放在哪里，包含哪些字段，以及结构发生了哪些改变。附带的将原数据管理分为了采集任务、采集实例、最新原数据库表、最新原数据文件和定版原数据这四个环节。采集任务呢，解决的是原数据如何进入到。

平台采集的实例记录每一次采集是否成功，最新原数据呢？展示当前的数据结构和结构变化，地板原数据则保留经过确认的稳定版本，那么原数据采集任务这里已经分别配置了ods dim.

DWDDWS和ADS五个Doris原数据采集的任务，同时还配置了一个业务系统内部文件数据采集的一个采集任务，通过不同的任务分别采集各个数仓分层，可以让原数据的目录更加清晰，也方便后续按照数仓分层进行查询和管理。现在我们打开一个Doris的一个原数据采集的任务，在任务的详情中可以查看。我们的来源系统，数据连接等，我们的一些基本的一些信息来源系统呢，用于标识这些。原数据属于哪一个业务系统数据连接决定用于哪个数据库读取结构，信息采集范围呢则用于控制我们这一个采集任务。

采集范围则用于控制具体的采集哪些数据库和数据表。采集的范围可以选择整个数据源或者是自定义库。对于表结构变化频繁的研发的环境，可以适当的去提高一下我们的采集频率，及时的去发现我们的字段新增或者是类型的调整。对于结构相对稳稳定的一些生产库，可以降低采集的频率，减少不必要的连接和扫描压力。配置完成后呢，可以通过调度自动的进行执行，也可以点击我们的执行一次。立即发起一轮原数据采集。原数据实例。我们点过执行一次之后，可以看到我们的采集实例，每一条采集实例都代表一次具体的云数据采集的过程，在实例的列表里面，我们可以看到任务的一个名称、来源、系统、采集表数量、执行状态、开始时间和执行耗时等信息。通过采集表的数量可以初步的判断本次。

采集范围是否符合预期，如果原本需要采集100张表，但实例中只采集到了几十张表，就需要进一步的检查任务的范围、连接的权限或者是数据库中的实际对象。如果采集失败，可以直接查看实例日志，也可以复制或者是下载日志进行分析。常见的问题包括数据连接超时，数据库账号权限不足，目标库不存在，或者是配置的表已经都被删除。通过采集实例可以确认每一次采集是否正常的完成，并且保留完整的执行记录。最后，最新的原数据采集成功之后。会进入到最新原数据，这里展示的是各个来源系统最近一次采集到的数据结构。左侧来源系统数会按照业务的。

系统数据源和数仓分层组成原数据方便在ods DMD wdd ws和ADS等不同层级之间进行切换。页面的顶部可以按照表名称、表述式、表注式所属的数据库名进行筛选，快速的找到相对应的数据表。我们现在打开一张表的详情。在详情里面可以看到字段的列表、版本与变更和基本信息。在C段字段的列表里面可以查看字段的名称。字段的类型、字段的注释、字段长度、字段精度、字段小数、是否必填等基本的一些信息。当字段的数量比较多的时候，我们也可以经过分页去查找我们具体的字段。版本与变更。每次完成云数据的采集之后。平台都会将最新的结构与上一次的采集结果进行比较。

通过版本的对比，可以查看两次采集之间发生了什么变化。例如我们有新增字段，或者是删除修改字段，然后字段的长度进行调整，都会在这个位置去表示出来。红色的就代表这个字段，如果这边的字对比字段是红色的，那就代表这个字段被删除了，如果是绿色的就代表是新增的，黄色的就代表是修改的。这样，数据库的结构发生了变化，就不再依靠开发人员口头说明或者是人工的回忆，而是形成了可以查询或者是追溯的变更记录，或者是当前表结构正确后，可以执行确定版本。确定，可以确定当前的版本为定版。也可以将当前的原数据固化为正式的一个版本。原数据定版之后，我们可以进到我们的定版原数据这一个列表。定版原数据的列表查询和详情查看方式与最新原数据基本一致，但两者代表的含义是不一样的。最新原数据反映的是最近一次采集到的当前的结构，可能会随着下一次的采集继续的发生变化，并版原数据则代表某一个时间点。

确认的稳定的一个版本不会因为后续的采集自动被覆盖。因此呢，地板原数据可以作为数据结构的正式基准。当接口出现字段不兼容、系统升级后数据异常或者需要追溯历史表结构时，可以通过地板原数据查看当前使用的一个正式版本，它既可以用于历史审计，也可以为接口开发、版本升级和故障排查提供依据。原数据管理的阶段总结一下是通过原数据的采集任务，我们将不同的来源系统和5层数仓中的表结构自动采集到平台里面，再通过我们的采集实例可以查看每一次采集过程是否成功，通过最新原数据可以统一的查询当前表字段结构信息，再通过我们的版本对比和定版管理可以记录。

结构变化，并保留经过确认的稳定版本。到这里呢？Odsdmd wtd ws和ADS五个出仓层级中的数据表字段信息和结构变化变更历史已经全部的纳入到了我们的统一的原数据管理里面，我们已经解决了数据在哪里，包含什么以及结构如何变化的问题，接下来是我们的数据治理的数据质量。数据质量呢，是原数据管理解决有哪些表，有哪些字段的问题，数据质量管理则进一步的判断数据是否完整、唯一、有效、一致并按时到达。本章呢？我们以河道水情实时流量数据机质量稽查为例进行一个演示。

完整性、唯一性、有效性、一致性和时效性。检测完整性呢是检测关键字段是否为空。唯一性检查业务记录是否重复，有效性，检查格式、范围和精度是否合理，一致性检查业务编码和能能否与主数据进行匹配，时效性的检查数据是否按时的到达。让我我们编辑一个任务。可以看到，我们编辑的质量任务DWD层已经完成了基础的清洗和标准化，也是下游统计分析直接使用的数据，因此更适合作为质量稽查的对象。配置质量稽查，查看问题数据阶段总结，通过数据质量任务可以对实时的流量进行完整唯一完整性、唯一性和有效性的等进行检查，然后我们配置完稽查检质量任务之后可以通过。

我们的执行一次去执行这一个质量任务，执行完质量任务之后，我们可以看到在这个位置有质量报告，可以查看我们的质量报告。质量报告呢，又用于整体的判断规则明细，用于定位问题。异常。数据可以追溯或者是加工任务，这样就形成了发现问题。定位问题，完整的整改，重新验证的质量闭环。使数据从已经入仓进一步变为质量可信问题可信结果可验证。然后紧接着我们看一下数据安全，数据安全数据质量解决的是数据准，准不准，能不能放心的使用数据安全呢？进一步解决的是什么人可以看到什么样的数据，以及能够看到什么程度。在河道水情数据中，测站精确的经纬度、责任人姓名和联系方式等字段可能具有不同的使用边界，如果缺少统一的安全控制，这些信息可能在数据查询、资产预览或者是接口调用，或者是数据导出的时候直接被暴露，因此需要通过数据分类、数据分级、脱敏规则以及白名单授权，建立起一套完整的数据安全管理机制。那么数据分级。

可以维护L一到L4等不同的安全等级，也可以自行去新增数据分级定位每一个等级定义对应的使用范围和保护要求。例如，普通公开的数据可以去设置为较低的一个等级，内部业务数据需要限制在组织内部进行使用，涉及精确地位、精确位置、人员位人员的信息或者是重要的业务的数据则可以设置更高的一个等级。通常情况下，数据的等级越高，对于数据访问、查询、导出、共享和对外服务的权限限制也就越严格。需要注意的是，分级标准不应该由平台单独的去决定，而应该与组织现有的数据安全制度保持一致。平台的作作用是将治理中的制度中的定义、等级定义和保护要求落实到具体的数据表和字段上。

数据分类主要用于描述数据属于哪一种脱敏信息、敏感信息。例如我们可以去建立系统，运用运行日志、审计日志等这种分类，然后测站的经纬度可以归于空间位置信息。责任人姓名可以归属于个人的基本信息，手机号则可以归于人员联系方式。数据分类和数据分级解决的是两个。

不同的问题。分类回答的是这是什么类型的数据，分级回答的是这类数据需要保护到什么程度。只有分类与分级结合起来，才能够形成具体可执行的数据安全策略。那么，脱敏规则用于控制敏感字段向普通用户展示的具体形态。用于测站经纬度可以只保留有限小数。或者是精确到地标转换为区间值，降低通过数据直接定位位置风险。对于手机号，可以保留前3位或后四位，中间部分使用星号去代替。例如原始的号码为123星，星星5678，使用者可以识别号码的大致信息。然后我们配置脱敏规则的时候，还需要设置规则的名称、适用的字段、脱敏方式，规则的优先级、启用状态和适用范围。如果同一个字段同时命中了多条脱敏规则，系统会根据优规则优先级确定最终执行哪一条。因此呢，配置完成后需要检查规则之间是否存在冲突，避免同一个字段在不同的页面中出现不同的脱敏结果，敏感数据识别。

之后呢，我们进入到我们的敏感清单，脱敏清单呢用于集中管理已经识别出来的通敏感的数据表和敏感字段。平台可以基于原数据中的字段名称、字段注释和字段类型进行识别。例如我们可以通过一些精度、纬度、手机号、联系人等信息发现可能的敏感字段。识别完成之后呢，可以对结果进行人工的核查，确定字段是否所所属的敏感分类、安全等级以及适用的脱敏规则。通过敏感清单呢，可以将安全要求与原数据、数据资产或者是下游的一些数据服务关联起来，同一个敏感字段无论出现在数据查询、资产预览还是接口服务中，都可以按照统一的一个安全规则进行管控制。

那么我们的脱敏白名单呢？是用于处理经过授权的例外使用的一些场景，普通用户在数据查询、资产预览或者是数据服务中，只能够看到按照规则处理后的一些透明规则。配置白名单的时候，我们需要明确授权用户、授权对象。以及我们的使用范围、有效期限和申请的一个原因。白名单呢，并不是为了关闭安全规则，也不是让用户永久的绕过脱敏的控制，而是一种有明确范围，有有效期限，经过权限并且可以追溯的一个另外的一个机制，授权到期的时候应及时取消原始数据访问的权限，避免临时权限长期保留。验证安全策略的最后对配置结果进行验证。首先使用普通账号，我们可以看到一些数据预览的页面，查看一些经纬度的手机号，可以看到一些普通账号经过脱敏之后处理的数据。然后我们如果要切换到在白名单的账号的话，再查看同一张表，同一个数据，它就会受到他的权限管控，无法去查看到一些具体的一些信息。

那么我们总结一下我们的数据安全，我们明确数据，明确了数据属于哪一种敏感信息之后，我们可以通过数据的分级明确数据。需要采用什么样的级别进行去保护，然后通过我们的敏感识别和数据分类、透明规则等，可以控制敏感字段在查询或者预览和服务中的展示方式，然后还可以通过白名单的机制。为经过授权的特殊场景提供了有范围、有期限、可追溯的原始数据访问能力。到这里呢？我们的数据安全已经从制度中的原则要求转变为可以配置、可以执行、可以验证和可以审计的安全管理链路。

然后我们看一下数据资产。前面呢，我们已经完成了数据建模，数据加工以及原数据质量和安全治理。但是这些内容呢，目前更多的还是数据库、数据表和字段等技术的对象，对于业务人员来说，我们需要进一步的去回答。平台里面有哪些可以使用的数据？这些数据呢？解决什么样的一个业务问题？数据的质量呢？是否可靠？申请的权限应该如何的去使用？数据？资产管理的作用就是把技术对象整理为业务人员能够发现、申请和使用的正式的一个数据资产。我们先看一下我们的数据管理。数据管理呢，主要去定义我们一些字段的一些含义去解决。

不同部门和不同项目出现的那种口径不统一、不一致的问题，用于去维护统一的业务名称、标准定义、同义词和负责负责人适用范围。然后我们的资产标签呢，是主要是针对于我们不同的一个资产去给他打上一个标签，标签更加的灵活，可以根据我们的数据特征，质量的一些状态，使用的热度或者是运行的要求，进行动态的一个调整，然后我们再看一下我们的资产地图，资产地图左侧呢，是可以按照我们的业务分类。按照主题域、出仓、分层不同的视角去浏览我们的一个数据，质量数据的一个资产，然后在资产的列表中可以查看资产的名称，业务的描述，所属的分层，资产的标签、发布状态和质量评分等信息。对于业务人员呢，这里重点不是要记住像我们这个ODS等等等这样的一个物理的表明，而是通过我们的资产名称，业务的一个描述。

然后资产的状态和更新的一个方式判断这个数据。解决了一个什么样的问题，以及适合什么样的应用场景？那么我们可以看一下我们的资产的一个详情，资产的详情包含这一个资产的一些基本信息，包含它的表的英文名称，表的中文名称，资产的类型，归属的一个层级，还有描述，下面就是针对于这一个资产。有哪一些资产字段还可以看到这一个资产里面有哪些数据可以去绑定我们的资产的一个。质量的任务，然后可以看到我们质量的一个评分，还有我们的学员。这个学员呢，我们等会儿会在学员管理里面，主要的讲一下我们的学员有哪些可以去追踪的东西，然后下面就是我们的资产预览。

自然预览我们集中的去展示了一下我们在数据集市里面去的一些信息数据，这是我们的资产地图，然后看一下资产的血缘管理，血缘管理呢包含了四个模块，一个是血缘地图，血缘维护，来源分析和影响分析。那么血缘地图里面，我们整个数据中台的一个学员的一个全景，然后我们单击某一个节点，右击某一个节点，可以看到我们的一个节点详情。然后右击某一个节点，我们还可以进行这一个节段，节点进行来源分析，影响分析，选维护，或者是查看我们这一个节点的字段的一个详情，然后我们先看一下来源分析，来源分析的话就可以看到可以沿着当前的一个资产进行向上的一个追溯。

查看它有哪些原表，经过了哪些ods dwd的加工的任务，以及依赖了哪些基础维度的数据，然后我们还可以看一下，我们可以去看一下它的影响分析，影响分析的话，可以沿着当前资产向下去查看，判断他被哪些任务数据表或者是API业务应用使用。然后如果我们发现我们的来源或者是分析有问题的话，可以直接进入到我们的血缘维护里面，可以针对于学员维护去拖入他的一个输入或者是。中间组件等等，可以去进行手动人工的去编辑这一个学员，然后保存学员，我们就会自动去保存下来你手动编辑的一个学员。然后我们看完血缘之后，回过头看一下我们的数据集市这一个功能。数据集示我们数据资产在。

生产地图这个位置。发布到集市之后呢，就会通展示在我们的数据集市里面，数据集市面向的是数据的使用者，集中的展示了已经发布并且可以申请使用的数据资产用户呢可以按照业务分类、主题域标签和资产名称查找数据，也可以进入详情查看资产的说明字段信息，数据质量、更新频率和使用方式。如果用户已经拥有权限了，那么他就可以直接在详情里面看到某一个资产的资产字段，然后数据预览API的接口文档和文件，文件可以进行下载。那么如果当这个用户还没有这一个资产预览的权限，他也可以去申请资产预览，可以先申请一下，选择一下他申请的一个周期是多少，然后申请的理由是什么，然后会有审核人员在审批工单里面会去进行审批，驳回同意，或者是查看一下这一个资产的一个详情。

如果他要驳回的话，这边可以去填写一下驳回的一个理由，然后用户就可以看到他这一个资产被驳回的理由是什么，如果同意的话，点确认就可以了，也会有一个确认的一个审批的一个意见，那么如果用户他把数据集市里面的资产申请过来了，可以使用了，那么他就可以通过我们的数据查询。去查看资产里面的一些信息，通过我们快速创建的搜狗语句，就可以查看相对应的一些表里面的信息。然后我们总结一下我们数据资产这一个模块。我们通过数据查询之后呢，可以直接验证审批后的数据使用链路是否正常，包括用户是否能够访问目标表敏感字段，是否按照脱敏规则进行脱敏，以及结果导出是否受到权限的一个控制。这也说明呢，数据资产不是一份静态的一个数据目录，它最终需要在质量、安全、权限和审计的约束下被实际的去查询、分析和使用。

然后让他够能够真正的产生业务价值。数据资产阶段呢，总结的是通过业务术语，通过我们数据背后的业务概念和口径，通过分类主题和标签，建立了便于查找的数据组织方式。通过资产地图和资产的详情，业务人员可以理解数据用途、字段含义、质量情况和更新方式，通过我们的资产的一个血缘，可以追溯数据的来源，也可以判断结构调整对下游任务和应用的一个影响。然后通过我们的数据解释、审批和数据查询，完成了从发现、申请到实际使用的一个完整流程。到这里呢，实际流量已经从一张DWT的技术表转化为一项具备业务说明、标准术语、质量结果、血缘关系、安全规则和使用方式的正式的一个数据资产。下一章呢，我们将这一项数据资产发布为API，为河道的水禽P图和外部的业务系统提供统一的一个数据服务。

那么我们的数据资产呢，解决的是平台内部的数据发现、申请和使用问题，数据服务呢，则是进一步的将这些数据能力封装为标准的一个接口，提供给河道水平地图移动端和外部业务的一个调用。通过数据服务可以统一的完成接口分类、配置、测试、发布、授权、限流和调用审计。我们看一下我们的服务分类，首先可以选择我们的一些河流水平服务，服务分类用于按照业务主题组织接口调用方可以快速的查找所属需的一个服务。管理人员呢，也可以按照分类统一的进行授权统计和日常运营。那么我们的API管理基本配置下，可以打开我们已经配置好的一个API，然后我们就看一下这个根据行政区划查询河流表的一个API，我们在这里面。

可以配置一下，我们选择我们这一个API的一个类目，API的名称，API地址，请求方式等等，还有版本是否限流等等这些信息，我们API配置的方式，我们QT是支持单向表导示。还有SQL脚本时和第三方转发发这三种方式。单表向的是适合基于一张数据表快速的去配置查询条件和返回的字段，SQ脚本式适合多表关联分组及统计和复杂查询的一个场景，第三方转发则可以将已有的一个服务接入到我们的平台，统一的进行分类、授权、限流和调用。

然后下面我们可以看到我们的一些请求参数，然后ID呢，就是我们数据记录的一个标识，可以用于查询指定的河流记录，然后我们这一个ADVCD这一个是行政区划的一个编码，也就是这条接口的主要查询的一个条件，调用方传入行政区划编码之后返回的接口可以。返回我们这一个行政区域范围内的一些河流的列表，配置我们的返回参数的时候，需要明确我们的参数的名称、数据的类型，是否允许为空参数说明视力值和默认值。

然后我们把这些参数都配置好之后，可以进到我们的下一步，下一步的话，我们可以去配置我们的请求数据，去配置一些参数值，然后我们可以点一下上面的接口调用，可以测一下这一个接口是否是可用的，然后我们把这一个API创建好之后呢。可以在我们的调用记录里面可以查看我们一些授权完成使用应用身份发起一次真正的调用，调用成功之后进入调用记录，这里可以查看到我们的一个调用的应用，调用者的IP接口的地址，请求的时间，还有我们返回的一些数量等等的一些基本的一些信息。如果我们的外部的系统返回接口响应比较慢，就可以通过调用记录查看当前当次的请求的执行耗时和返回的一个数据量，如果接口调用失败，也可以判断问题是否来自身份认证、参数配置、权限状态，执行超时还是什么的一些问题。

通过我们的一个调用的记录，可以将我们每一次外部请求的追溯到具体的应用、具体的接口和具体的时间，然后数据服务阶段总结。除了根据行政区划查询河流列表、当前河流场景，还可以提供综合态势、实时流量、流量统计和地图点位等接口。这些接口虽然查询的内容不同，但都沿用了一套服务分类、接口配置、在线测试和应用授权、权限控制和调用审计。我们通过我们的数据服务，河道水禽数据已经从平台内部的数据资产进一步的转化成了标准化、可授权、可监控、可审计对外服务的一个服务能力。接下来我们看一下我们的智能论述，通过智能问述，业务人员可以直接使用自然语言查询数据，平台自动完成SQL的生成查询。

和结果的展示。总结到这里，河道水情监测场景的全流程建设已经完成了。最后呢，我们回到数据连链路的总览，回顾我们今天的主要内容。在数据接入阶段，我们完成了数据连接来源系统和项目配置，然后并通过我们的整库同步和可视化数据集成，将河流、河段、断面、测站以及水位、流量、流量等数据接入到了平台。在数据生产的阶段，我们按照了odsdm dwddws和ADS五层体系进行了建模，通过我们的数据开发，完成了数据的清洗、明细加工、统计汇总和应用数据的生成再利用，我们的作业管理将不同的任务编排为可统一调度的数据产品链。在数据治理的阶段，我们统一管理表和字段的信息。

记录结构变化，通过我们的质量任务发现空值、重复异常值和数据不一致的问题，并利用分类分级和我们的脱敏白名单控制敏感数据的使用范围。在我们的数据消费阶段，我们将治理后的数据发布为业务可理解的数据资产，并通过数据查询、数据服务，还有智能论述，为地图报表、外部系统和业务分析提供数据支持。现在再看我们最初的问题分散在分散的数据已经统一的接入，数据的口径得到了规范，异常的问题能够发现和整改，实时与历史指标可以稳定的生产，数据成果也能够通过资产和接口持续对外提供，这就使我们QD的数据中台形成了完整闭环，它不仅完成了数据接入和加工，更加更让。

数据经过生产、治理、管理和服务，最终成为可以持续使用和运维的业务资产。感谢大家观看本次科泰的专业版数据中台全功能讲解，快来访问QD的官网申领试用吧。