数字化转型网数据专题将关注数据治理、数据质量管理、数据架构、主数据管理、数据仓库、元数据管理、数据备份、数据挖掘、数据分析、数据安全、大数据、数据合规、等数据相关全产业链相关环节。
数据治理是一个什么话题呢？
就是上面那些玩意之前开发的时候有历史遗留问题，要把它“治理”成规范的
数据治理总体上分成合规治理和资源治理
合规治理主要是规范上的问题，比如：模型设计规范、元数据定义规范、数据质量方面的保障规范等
资源治理分为存储和计算
比如说存在大量重复数据、无用数据的存储导致我 HDFS 存储不足，那我就需要进行存储资源治理
存在某些任务会消耗大量资源，导致链路中其他任务跑不起来，那这个时候我就需要进行计算资源治理
由于数据仓库在建设过程当中，可能由于急于交付需求就没有考虑过多合规方面的问题，导致遗留下很多隐性的问题
同时每个时期所关注的问题是不一样的，所以需要按照不同的阶段进行精确的治理
探索期：业务往往比较单一，数据量相对较少，整体的核心诉求就是要支持业务
所以这个时期主要就是要保证数仓内部的规范，也就是元数据以及保障数据质量
扩张期：业务飞速增长，会存在大量的指标在多个场景中重复使用，这是需要完善中间层的模型，提高数据的复用程度以及准确性
可以简单理解成，这时候赚到钱啦！需求框框就来啦，指标不搞成通用的就撑不住啦
发展期：经过扩张期之后，进去稳定增长的阶段
这个时候不需要大规模接入数据，要点在于精细化维护，保障指标的异质性、降低数据的使用成本、降低计算、存储资源的消耗、保障任务要稳定产出、保障数据安全
变革期： 这块可能有两部分
一部分是企业开辟新业务，这个时候既要快速满足新业务，又要治理老业务的数据资产；
另一部分是业务方需要提效，比如快速定位指标、模型等，同时可以开发一些提效工具实现自动化
数据治理内容
背景
随着等业务的快速迭代，同时数仓也在早期高速支持业务方（风控策略、运营、数分），产生的数据体量越来越大，划分的数据域也愈来越多，但数仓在初步搭建时都没有确定好数仓分层、数据标准、模型设计规范、没有一套完整数据的生命周期管理体系等因素，从而导致烟囱数据模型大量产生，无规范/无元数据维护的数据模型使用时也存在歧义，数据模型很难发挥出/评估出数据的价值，因此需要对相关域下数据模型进行治理优化。
简单来讲就是之前为了快速支持业务，很多地方可能没按照规范来
现在回头一看，可能存在命名不规范、依赖不规范、指标重复开发等问题，所以需要进行相应的数据模型治理
但是由于数据模型有点多，链路也比较复杂，就如同从兜里拿出来的有线耳机，所以直接上手可能会造成事故，这部分大致的流程如下：
数据标准重制定 -> 无用/临时数据表下线 -> 应用指标公共下沉复用 -> 解决ODS穿透问题 -> 烟囱数据表重构及下线 ->元数据非合规数据表（包括元数据字段信息）修改
整体治理过程可以理解成对城市做“城市规划”，咱们在开始盖楼之前，肯定是需要制定好一套蓝图和规矩，让参与建设的人都有章可循，所以首先进行数据标准非常合理
数据模型合规治理流程
(1) 层级设计：城市功能区的划分
数仓分层就像是给城市划分功能区
ODS层是“原材料进口区”，DWD层是“初加工区”，DWM层是“半成品中转区”，DWS层是“深加工和汇总区”，ADS层就是最终面向市民的“商品展示区和应用市场”，DIM层则是城市里通用的“基础设施信息库”（比如时间维度、地区维度）
每家公司叫法可能不一样，比如有的公司把ADS层叫APP层，没关系，重点是你知道每一层是干啥的，职责分明就行
离线数仓像个大城市，功能区多
实时数仓可能更像个特区”，追求的是“快”，所以层级可能就没那么多，比如可能就ODS、DWD、ADS三层搞定，一切以业务需求和效率为准
测试表就好比“临时施工棚”，这里建议直接搞一个 TMP 库，这样可以非常清楚的知道哪些是正式表、哪些是临时表
(2) 命名规范：给每条街起个名字
命名这块就像城市里每条路叫什么街、什么路，楼房叫什么苑、什么厦，都得有个统一的规则
- • 层级前缀： ods_、dwd_、dim_ 一看就知道是哪个区的
- • 业务域： trade_ (交易)、user_ (用户)，说明这条街是干嘛的
- • 业务过程/实体： order_detail (订单详情)、user_base_info (用户基础信息)，具体到是哪栋楼
- • 分区策略/更新周期： _df (天分区全量)、_di (天分区增量)，告诉我们这栋楼是每天整体翻新还是接着盖
(3) 临时数据模型下线：即使拆除“临时施工棚”
工程建设过程当中，会搭很多临时的“工棚”，工程完工了，这些玩意就得及时拆掉了
这部分可以根据血缘对无用表、临时表进行下线，避免无用的存储和计算的损耗
- • “长期无用表”： 很久没人访问、没人用的表，就像废弃的厂房
- • “下游无血缘且空跑数据模型”： 有个任务每天还在跑，但产出的数据根本没人用
- • “临时表”： 就是咱们开发测试时建的那些，用完了就该删
(4) 应用指标公共下沉复用
数仓刚开始发展的时候，大家可能还没来得及建立一个统一的“指标中心”，每个人都在自己开发很多数据模型来算自己想要的指标
这样很容易导致同一个指标（比如“用户活跃数”），A部门算一个样，B部门算一个样，口径不统一，复用性差，大家都在“重复造轮子”
这一步的核心就是：识别出那些大家都要用的“通用零件”（公共指标），把它们标准化生产出来，放到一个公共的“零件库”（DWS层），谁要用直接去拿就行了
这样既保证了口径统一，又减少了重复计算，大大提高了效率
所以首先需要先看看应用层的指标口径是否都是一致的，如果不一致就需要进行沟通进行修改
然后咱们要把那些通用的、基础的指标，从应用层的具体模型里“抽”出来，“下沉” 到更底层的、更公共的层次，比如DWS层
按照不同的周期进行汇总，按照不同维度进行聚合，将结果作为公共指标存放到 DWS 中
测试没问题之后，ADS 层就可以直接从 DWS 层读取这些已经算好的公共指标了
(5) 解决 ODS 穿透问题
“ODS穿透问题”是个啥？
ODS层是咱们的原始数据层，按理说，下游的ADS、DWS 不应该直接去用ODS层的数据，中间应该经过DWD层的清洗、转换和关联
如果ADS或DWS层直接跳过DWD，去读ODS层的数据，这就叫“ODS穿透”
为什么会有 ODS 穿透？
可能是早期为了快速出报表，图省事，直接就从ODS取数了
也可能是DWD层建设不完善，缺了某些关键数据
ODS 穿透有啥坏处？
首先是破坏了数仓分层的规范，分层的主要目的就是让数仓更具有复用性、经过多个步骤处理将复杂的逻辑简单化
如果全都去 ODS 取数据了那又会发生同一个逻辑计算多次的情况，存在资源浪费，跑得还不一定快，同时一个任务逻辑过多，维护起来也比较乱
同时如果 ODS 的表结构一遍，牵一发而动全身，所有的下游表都得改
怎么解决？
首先通过血缘找到这些跨层依赖的数据模型
然后这里不能粗暴地直接不读 ODS 就完事了，得按照咱们之前在“数据模型建设”聊过的规范完善中间层(DWD、DWS)，然后让 ADS 切换引用的数据模型
(6) 烟筒数据模型重构及下线
不同的业务部门或者不同的开发人员，为了解决类似的问题，各自建了一套数据模型，这些模型之间互不相通，这就是“烟囱数据模型”
这里就可以将公共的指标、通用的字段放到一个或多个数据模型中，从而提高模型的易用性
就好比之前城市里面啥路都有，现在要进行统一规划，修成一条主干道
(7) 元数据非合规的数据模型重构及修改
这里主要针对之前的模型按照新规定的元数据规范进行重构，可以先重构 ODS、DWD、DWS 的元数据信息
然后按照主题域的分工，切换 ADS 的数据模型
数据模型合规治理后维护
治理完成之后可以设定评分机制，按照规范以及价值(查询次数等)进行打分
根据这个分数可以及时进行相应的数据治理，比如分数过低的话就发邮件提醒处理、确立审核机制将不规范现象扼杀在摇篮
数据质量合规治理
背景
就算咱们一开始很小心，代码写得很规范，但随着业务越来越复杂，需求越来越多，各种奇奇怪怪的数据问题还是会冒出来
比如上游系统改了个字段没通知，或者某个逻辑写漏了一个边界条件等等
所以，指望一次性把数据质量搞定是不现实的，数据质量治理是个持续优化的过程
DQC 和 SLA是保证数据质量的两个核心武器，咱们来简单回顾一下：
- • DQC： 可以理解为咱们数仓的“质检部门”，它会主动去检查数据的各种问题
- • SLA ： 这是咱们对下游用户的“承诺书”，比如保证每天早上8点前把报表数据准备好
整体思路可以分为：规范化 -> 强管控 -> 定期扫描 -> 体系化
- 1. 规范化： 一开始，咱们先定规矩，比如开发规范、DQC 规范
- 2. 强管控： 把这些规矩落实到工具和流程上，比如模型上线前必须配置 DQC 规则
- 3. 定期扫描： 要定期去检查这些规矩的执行情况，看看有没有新的质量问题冒出来
- 4. 体系化： 要把整个数据质量治理做成一个完整的体系，有流程、有工具、有责任人、有改进机制，形成一个良性循环
数据质量合规治理的过程
(1) 规范化
模型开发上线流程的“质量关卡”：
设计模型 -> 组内模型评审(大家一起看看图纸有没有问题) -> – 代码编写 -> 提交代码(测试环境) -> 代码审核数据校验( 写完代码，在测试环境跑跑，产出质量报告看看有没有问题) -> 配置 DQC -> 数据初始化(线上环境)
强制DQC检测：
每次代码上线，都应该强制要求做DQC检测，能指望开发人员自觉，万一忘了，数据质量就可能出问题
最好是平台层面就卡住，不通过DQC不让上线
指标变更流程的“质量关卡”：
发现影响，及时沟通： 如果你改了一个字段，或者一个指标的计算逻辑，可能会影响到下游正在用这个数据的报表或者其他表，那你不能自己改完就完事了
多方审核，确认无误再上线，让其他同事帮忙审核代码、审核数据质量，确保没问题了才能发布
如果你的修改影响到了别人的表，一定要在业务群里找到那个表的负责人，通知他你的改动，他确认他的表没问题，或者配合他修改
“扯皮”预案：
如果联系不上负责人，或者负责人不同意你的修改方案，怎么办？
联系不上，就找他 leader，游负责人要确认当天不受影响，如果他不回复，出来问题对方承担责任
如果他不同意你的修改方案，那双方得坐下来好好商量，定好怎么改、什么时候改，重新制定方案
(2) 强监控
DQC的作用
就是在每个数据任务跑完之后，立刻对产出的数据进行检查
如果发现问题，就能及时“卡住”，不让这些“坏数据”流到下游去祸害别人
它就像是生产线末端的“质检员”，每个产品下线都得过他这一关
DQC都能监控些啥呢？
- • 基于数值的监控：
数据量突变： 比如一张表昨天产了100万行数据，今天突然变成了200万行（翻倍），或者只剩1万行了，这可能就有问题了
我们可以设置一个阈值，比如数据量波动超过30%就报警
同环比异常： 比如今天的订单数，跟昨天比（同比）、跟上周同一天比（环比）差距特别大，也可能不正常
空值的监控： 某个重要的字段（比如用户ID、订单金额）是不是有很多空值？或者整张表都是空的？
唯一性的检验： 比如订单号应该是唯一的，如果出现重复的订单号，那肯定有问题。
- • 阈值怎么定？
初期： 刚开始，可以凭经验，或者跟业务方沟通，大概定一个
后期： 等数据跑起来了，系统可以分析过去7天或30天的数据波动情况，给我们一个更合理的阈值建议
动态评估： 甚至可以用算法来长期监测数据的波动，自动调整阈值，让监控更智能
DQC的规则还分“轻重缓急”
- • 强规则：
这是“红线”，一旦触发，比如核心表的关键字段全为空了，那任务就直接停止，不能让它继续往下跑了
同时，立马通过电话、钉钉/飞书消息、邮件等各种方式通知任务负责人和他的 leader，让他们火速来处理
书里举了个例子，一般情况下，数据量波动很少会超过100%（比如翻倍），如果真超过了，那很可能就是个严重问题，适合用强规则
- • 弱规则：
这更像是个“提醒”，比如某个非核心字段的空值率稍微高了一点
触发了弱规则，任务还是会继续跑，但是会通过消息、邮件通知相关人员关注一下
在数据治理的早期，一定要把那些还没来得及配DQC监控的老模型，都给补上监控配置
一旦这些老模型出了问题（比如产了个空表，或者数据量突然翻了好几倍），就会污染整个数据链路
SLA是啥？
就是咱们数仓团队跟下游用户之间的一个“约定”或者“承诺”，核心是保证数据按时产出
比如约定好，每天早上9点前，昨天的销售报表数据一定能查到
这个约定就像“签字画押”一样，得认真对待
为什么会产出晚？
数据量太大： 某天数据量暴增，任务跑慢了
被强DQC拦截了： 前面说的强规则触发，任务停了，数据自然就出不来了
其他因素： 比如上游依赖的任务延迟了，或者集群资源紧张等等
产出晚了怎么办？
通知值班人和任务负责人： 一旦发现数据可能要晚了（比如通过“基线告警”），系统会自动通知当天负责处理这类问题的值班同学，以及这个任务的负责人，让他们赶紧去解决
基线告警时间： 在设置SLA的时候，我们会配置一个“基线告警时间”。比如约定9点产出，那我们可以把基线告警时间设在8点半。如果8点半了，这个任务还没跑完的迹象，系统就开始报警了，提醒相关人员“可能要迟到了，赶紧看看！”
定期扫描
DQC和SLA配置好了，不是就万事大吉了，还得定期去“巡查”，看看有没有新的问题
异常/失败任务： 每天去看看过去7天或15天，有哪些任务跑失败了，或者触发了DQC告警，这些问题是不是都解决了？如果没解决，赶紧处理
DQC规则优化和下线： 根据DQC实际触发的情况，去优化那些不太合理的规则（比如某个规则老是误报），或者把那些已经没用的规则给下线掉
基线告警次数治理： 如果发现某个任务的基线告警（SLA告警）老是响，那说明这个任务的产出时间不稳定，得重点关注，看看能不能优化
开发值班运维手册： 这是个好习惯！把平时值班遇到的各种问题、怎么解决的，都记录下来，形成一个“运维宝典”
这样，新人值班或者夜间值班的同学，遇到问题就能快速找到解决方法，不用手忙脚乱了
体系化
针对数据质量问题进行持续跟踪和反馈
问题收集： 不仅要关注DQC报出来的问题，还要收集来自内部（比如测试发现的）和下游用户反馈的数据问题
流程化跟踪： 对每一个数据质量问题，都要有标准的处理流程：谁负责、怎么处理、处理到什么程度了、什么时候解决，都得清清楚楚
长期监控和定期反馈： 对于那些顽固的、反复出现的数据质量问题，要长期监控。
并且，要定期把数据质量的整体情况、正在处理的问题进度，反馈给下游用户，让他们知道咱们在努力改进，增强他们对数仓的信心
所谓“让下游有体感”，就是让他们能感受到数据质量在变好。
数据安全合规治理
城市里有银行金库、有政府机密档案、有市民的个人隐私
如果这些重要的信息随随便便就能被人看到、被人拿走，那这个城市就毫无安全可言，会出大乱子
权限管控
核心原则： 按需分配，最小权限，不是谁都能看所有数据
管控粒度： 细化到 字段、表、库 级别。例如，你可以看用户表，但手机号字段对你不可见
授权方式： 通常基于 角色/用户组 进行授权，数据负责人拥有审批权。表的敏感等级也会影响审批层级，高级别数据需要更高级别审批
多层级审批： 下载数据需经业务负责人等审批
数据模型分级
数据分级就像给文件盖上“绝密”、“机密”的戳，不同级别的戳对应不同的查阅和审批手续
通过区分数据的敏感程度，实施差异化安全策略
将表、Topic、字段按照不同级别进行划分
数据脱敏
这块给敏感信息打上马赛克，既能满足业务需要，又能有效防止隐私泄露
比如对敏感数据（如手机号、身份证号）进行部分遮盖（如138****1234），保护隐私
大部分在ODS、DWD、DIM层实现，ADS层也可按需进行二次脱敏
数据展示
这块可以根据登录用户的身份，自动过滤和调整其能看到的数据范围和细节
权限控制在最终呈现环节的体现
同一报表，不同用户看到的内容不同
定期扫描
确保安全策略得到持续执行，及时发现和修补漏洞
新上线的表需在短时间内（如3天内）完成安全等级打标
系统自动提醒数据负责人为未打标或打标不明的表/字段进行确认和标记
存储资源治理
为什么存储会紧张？
这里主要是因为历史数据的不合理存储以及大量无用数据在占用资源，所以治理也主要是在围绕着这两个问题在进行操作
整体思路肯定是优先进行那种可以用最低的成本来达到显著效果的操作
可以从这几点优先入手：下线无用数据表节省存储->存储格式及压缩格式配置->分区生命周期优化->根据业务情景实现节省存储即数据模型优化
这里可以通过元数据进行梳理，每个模型的引用情况、生命周期的配置、存储格式等
下线无用表，可以根据表的被引用情况以及被使用情况(读取次数、引用次数)来判断表是否是无用表
存储、压缩格式
存储格式一般是 orc 或者 Parquet
使用 Parquet 作为存储格式的时候，Spark 的效率会更高
压缩格式方面，snappy 的解压速度最快，适用于低延迟场景
gzip 压缩率高但是速度慢，可以作为冷存储使用便于节省存储空间
zstd 算是这俩的一个折中，压缩率高于 snappy 接近于 gzip；速度比 gzip 快 比 snappy 略慢
hadoop 3.x开始支持 zstd，会逐渐成为一个兼顾存储和性能的折中方案
生命周期
这里需要区分表是全量还是增量的
全量表
ODS:小时全量(3天)、天级全量(7-90天)
DWD:小时全量(7-15天)、天级全量(7 – 30天)
DWS:小时全量(7-30天)、天级全量(7-60天)
ADS:小时全量 (7-30天)、天级全量(7-90天)
DIM:小时全量(3天)、天级全量(90-360天)
增量表
ODS:小时增量(30-180天)、天级增量(90-365天 or 永久)
DWD:小时增量(60-180天)、天级增量(180-365天)
DWS:小时增量(60-365天)、天级增量(180-730天)
ADS:小时增量(90-365天)、天级增量(180-730天)
DIM :默认使用全量表
治理后的维护
可以通过对元数据表配置监控、设定一些规则建设健康分形成一套标准
计算资源治理
遇到集群资源跑满、任务产出延迟等问题，很多人第一反应是“机器不够了，加机器吧！”或者“内存给少了吧，加内存！”
但是很多时候，不是物理资源真的不够用，而是我们的任务写得不够好，或者资源调度不合理，导致计算效率低下，白白浪费了资源
盲目加资源，治标不治本，还会增加成本
动手优化之前，得先想清楚从哪下手，按什么顺序来，不能眉毛胡子一把抓
这里同样需要优先进行最容易快速见效的操作，比如调整一下Spark任务的executor内存、并行度等参数，或者把一些不适合用Hive跑的任务切换到Spark上
然后接下来主要是有以下几个问题：小文件过多、高资源消耗任务、任务调度不合理、重复开发任务以及无用任务
针对小文件进行治理，这块咱具体放在后文
高资源消耗任务优化
这块其实就是 spark 任务相关的调优
Map 阶段
这里主要是读取的数据量级的问题，所以主要的操作就是在减少读取的数据量
比如行列裁剪、条件限制这些是最基础的
还可以将数据表改造成二级分区，这样可以减少每个分区的数据量，这样 map 端就会运行得更快
如果上游数据量过大，可以全量改增量，每次只查询对应的增量数据，走增量分区之后效率会比较高
如果我们要读取的数据量过大，并且读到的数据在任务中被多次使用，这里可以采用临时表的方式来将中间数据进行物理存储，这样可以大幅提高整体任务运行的效率
不过这里建议不要反复在任务中创建和删除临时表，可以创建一次之后，每天把数据插入到临时表中
Reduce 阶段
如果任务发生数据倾斜的话，那么暴雷就是在 reduce 端
因为数据倾斜就是某一个分区数据量相比于其他分区过多，导致任务花在这一个分区的时间过长，reduce 阶段就是在处理这每一个分区的数据
针对这种数据倾斜情况的解决思路是：对倾斜分区进行拆解或者直接不让倾斜分区产生
拆解的话可以依靠 spark 的 AQE 特性，会自动识别大分区，将大分区拆成多个小分区由多个 task 进行计算
不让倾斜分区产生的思路就是让数据分批得均匀一些，比如使用 repartition by + distribute by rand() 来进行优化，对分区进行重组，这样原来集中在一个Reduce Task上的数据，就被分散到多个Reduce Task上并行处理了
给 key 加上随机数进行计算最后再将随机数去除再进行计算得到最终结果，比如，如果Key “A” 数据量特别大，可以把它变成 “A_rand1”, “A_rand2”, …, “A_randN”
再或者直接过滤掉大 key 进行单独处理
对于 row_number 排序导致的过慢可以考虑用聚合函数替代排序来求最值
任务调度不合理
所有任务都集中在同一个时间段跑会到这这个时间区间的 CPU 满载，任务互相抢资源，反而都跑不快
这里需要梳理出高峰时间段的表对应的 ODS 和 ADS，识别出那些最重要的核心链路上的任务（比如直接影响公司核心报表的任务），优先保证它们的资源供给和按时产出。可以给这些核心任务更高的调度优先级
那些优先级没那么高的、或者对产出时间要求不那么苛刻的任务，就尽量安排在集群比较空闲的时候去跑
同时，调度优化也不是一劳永逸的，业务在变，数据量在变，任务也在变
需要定期回顾和调整调度策略，持续优化资源利用率
重复开发任务以及无用任务
对于早期开发的烟囱表，需要将指标下沉到 DWS 来提高复用性，同时对于无用任务也要及时下线，从而减少资源的消耗
治理后的维护
可以通过元数据持续评估任务的资源消耗，针对资源消耗、运行时长来对任务进行打标签，比如：高消耗任务、超长任务等
小文件治理
背景
小文件就好比是停车场里停了一辆玩具车
在HDFS里，文件是按“块”（block）来存储的，一个块的默认大小通常是128MB或256MB
即使你的文件只有1KB，它在HDFS上也会占用一个完整的块的元数据开销（NameNode需要记录这个块的信息），虽然实际数据只占1KB，但它“预定”了一个块的位置
MapReduce 或 Spark 等计算引擎在处理数据时，通常会为每个输入分片启动一个task
如果小文件太多，意味着输入分片也会很多，就需要启动大量的task，每个task的启动和销毁本身就有开销，大量的task启动会消耗大量时间
同时，小文件过多也会导致频繁的 IO，因为读数据的时候因为文件小，所以不会在扫描文件上花费太多时间，会导致磁头频繁寻道，IO效率低下
查询时需要频繁访问 NameNode 获取小文件的元数据信息，也会增加NameNode的压力和查询延迟
所以说这里文件过小会导致上述的问题，文件过大可以解决频繁 IO 的问题，但是会导致在一个文件上花费的时间过大，所以文件的大小需要合理把控
小文件的产生
源头上，可能我们的数据源本身就存在大量的小文件，所以导致小文件过多
处理上，任务的 reduce 数量会直接决定输出文件的数量，每个Reduce Task通常会写一个文件到对应的分区目录
再或者说由于数据倾斜，key分布不均，导致少数几个 Reduce Task 处理了绝大部分数据，而其他很多 Reduce Task 只处理了非常少量的数据，这部分 task 输出的文件也会过小
治理
spark 3 的 AQE 特性也能很好的解决小文件的问题，它可以自动合并分区，如果发现输出分区过小，会自动将这些小分区合并到一起
同时，既然 reduce 的数量可以影响输出文件的数量，我们也可以直接限制 reduce 数，
对于分区数据不均匀导致的小文件的产生，也可以使用 Distribute by rand() 控制分区中数据量，保证每个分区的数据量基本一致，均匀分配，能合并部分的小文件
针对数据源就存在大量小文件的现象，可以在 ODS 任务后再接一个 Spark3 的回刷任务，借助 AQE 特性来减少小文件
治理之后，同样可以通过元数据进行持续化的监控
声明：本文来自建鑫Data，版权归建鑫jx所有。文章内容仅代表作者独立观点，不代表数字化转型网立场，转载目的在于传递更多信息。如有侵权，请联系我们。数字化转型网www.szhzxw.cn
数字化转型网数据专题包含哪些内容
数字化转型网数据专题将关注数据治理、数据质量管理、数据架构、主数据管理、数据仓库、元数据管理、数据备份、数据挖掘、数据分析、数据安全、大数据、数据合规、等数据相关全产业链相关环节。
数字化转型网数据专题包含： 数字化转型网（www.szhzxw.cn）
1、数据相关外脑支持：100+数据相关专家、100+数据实践者、1000+相关资料
2、数据研习社：与全球数据相关专家、实践者共同探讨相关问题，推动产业发展！
3、国际认证培训：目前已引进DAMA国际认证CDMP，其他国内外认证也在逐步引进中
4、典型案例参考：与数字化转型网数据要素X研习社社员一起学习典型案例，共探企业数据落地应用
本文由数字化转型网（www.szhzxw.cn）转载而成，来源于建鑫Data；编辑/翻译：数字化转型网萍水。
