数仓系列第10篇：数据治理

Posted 2022-08-23 浊酒南街

目录

• 01数据治理、数据管理与数据管控
• 02系统架构、应用架构和数据架构
• 03数据标准、数据模型、数据资产、数据分布
• 04数据仓库、数据湖与数据中台
• 05数据中台是什么，不是什么，为什么
• 06结语

01数据治理、数据管理与数据管控

在日常工作中，数据“治理”、“管理”和“管控”常常被“混搭”。这种混搭，在不同的文件、报告、沟通层面，可能造成对数据工作的歧义，具体到谁来做、做什么、怎么做，特别需要概念层面澄清。
1.数据治理
是什么：事实上，治理面对的更多是战略层面、组织层面、制度层面的事务，是“make sure it’s be doing”，确立“什么样的决策需要在什么层级制定”。所以，数据治理是一个相对高阶的概念。
谁来做：对应的是一个“数据治理委员会”级别的机构，由这个委员会来建立数据治理的整体组织架构，定义责任主体，落实工作机制。
2.数据管理
是什么：“管理”是对“治理”的贯彻，是通过一系列实际落地的办法去实现“治理”目标的具体过程，是操作和实施层面的概念。
谁来做：数据管理对应的是一个以“数据管理部”级别的职能部门+各个相关职能部门的矩阵化组织。通过内建组织机构和工作机制，有牵头、有配合、有主责、有落实，在各自的职能领域去完成数据管理的具体任务，包括企业级层面的数据标准化、数据资产管理，业务领域层面的数据规范化、数据质量改进等等。
3.数据管控
是什么： “管控”是对“管理”要求在业务过程、产品设计、开发实现层面的具体实施。管控离不开“制度”+“规范”+“工具”+“考核反馈”，每一个管控机制，都应该有一个PDCA的管理循环。
谁来做：数据管控的落地，制度设计和规范定义层面，需要数据管理部门牵头推进，同时，也需要技术部门的工具和系统能力支撑，才能“管得了，管得住，管到位”。

如上图，清洁源头数据就是一个数据治理目标，数据标准管理办法、数据质量管理办法就是帮助实现治理目标所制定的管理制度，在开发过程中的标准管控、在运行阶段的质量管控就是在实际工作当中实现标准、质量管理的具体措施和手段。

02系统架构、应用架构和数据架构

随着企业信息化程度的不断提升，以及有关方面对企业数字化转型的不断深入，“架构”成为热词。这个时候，无论是业务部门还是技术部门，往往会提到好几个架构术语，包括系统架构、应用架构。同时，随着数据治理工作推进，数据架构也映入眼帘，但是他们之间的关系仍然需要不断澄清。
1.系统架构
系统架构是一个相对技术化的专有定义，特指信息系统的物理设施+软件模块+功能组件的关系定义，狭义或低阶的系统架构范围可以是一个或一套业务或技术功能的系统，即所谓的功能级或部门级系统架构；广义或高阶的系统架构可以涵盖到企业级、全领域，形成企业级系统架构。相对而言，系统架构偏IT系统的实施层面，内容多包括软件、硬件、网络、协议等方面。
2.应用架构
应用架构的定义会更加突出“应用导向”，虽然系统架构也会陈述一些IT作业和功能的相互调用关系，但是这些内容是IT实施层面对业务需求层面的具体化，因此反而不容易被业务人员在自己的语言体系内掌握，这时候，需要一种业务化的架构解释，这个就是应用架构。今年以来，随着付晓岩等业界大咖的不断宣（who）传（you）,业务架构一词也浮出水面，业务架构转型，企业级业务（应用）架构规划设计，分领域组件和分层体系的规划建设也不断在理论层面被丰富，在实践层面被完善。
3.数据架构
数据架构是一个古老而又年轻的概念。说古老，在于从IT系统诞生开始，就伴随着软件编码+数据结构，数据是软件的基本功，表结构设计是很多软件设计的第一步。说年轻，在于数字化转型以来，数据的体量规模、质量要求已经从TB发展到PB再到EB，一些领域已经到了ZB，量变带来质变，简单的表结构管理已经无法满足需要，数据架构管理应运而生。
目前，数据架构管理的理论体系初步构建，在DAMA、信通院、金融科技标准化委员会的不断推动下，数据架构的标准化表述已经趋于统一，基本覆盖如下四个方面：数据标准管理、数据模型管理、数据资产管理、数据分布管理。

03数据标准、数据模型、数据资产、数据分布

1.数据标准管理
就是将系统级、项目级的数据规范提升到企业级层次和全领域范围，着力解决基本的业务定义和基础的数据整合，统一企业级范围内的数据指标、数据标签、图数据关系的基本定义和口径管理。
2.数据模型管理
目前一般是业务交易过程的模型管理和数据运营应用过程的模型管理，传统的解释是OLTP类数据模型+OLAP类数据模型，国外的典型的代表是IBM-FSDM（金融数据模型）+TERADATA-FSLDM（金融数据逻辑模型），国内的典型代表有建设银行的C模型+阿里的数据中台逻辑模型。
前一种模型的共同特点在于，和业务过程、产品设计相对应的，主要是应用于前台交易、业务运营类的系统的数据结构设计；后一种模型的特点则在于从数据整合、用户画像、指标体系、图计算和AI计算等方面出发，从数据的海量采集、存储、计算、流转，从数据资源的生命周期管理方面出发而进行的数据结构设计。
数据模型管理，往最“实”了说，离不开“表结构”；但是，什么地方用三范式或者退化三范式，什么地方用维度表，什么地方用雪花表，什么地方用图关系表，这个是数据模型的要点。
3.数据资产
和数据资产对应的概念是数据资源。所有存量IT系统中的数据，都是资源，正如石油埋在地下，是资源。但是资源要发挥价值，需要开采、需要提炼、需要产品化，才能成为可用资产。没有经过产品化的资源，还不能成为资产；而如果产品化成本过高，无法有效利用的资源，则可能成为垃圾。
就数据而言，编目清晰、接口规范、口径准确、责任明确的数据，可以列入数据资产。企业的数据资产可以包括数据标签、数据指标、图数据关系、固定报表、数据服务API以及规范化后的元数据等。这些资产，有利于后续的数据加工和应用，而只有通过有效的数据加工应用，数据资源才能产品化为数据资产。
4.数据分布
在系统架构管理中，强调的是“高内聚+低耦合”，软件功能上的集约化；在应用架构管理中，强调的是“功能聚集性+职能责任制”，尽量统一、集约、纯粹。在数据架构中，同样对于数据的存储分布、流转路径有自身的架构原则，尤其是在于数据中台层面，归纳而言就是数据分布上“只存一份、只算一次”。
只存一份，是针对过去数据分析应用环境的系统竖井，各自为政的多重数据COPY，各自取数的加工路径，要求在企业级数据架构规划中，大规模海量数据要去除冗余，加强存储管理，并尽量推动“存+算”分离的技术架构来保障架构规划的落地。只算一次，就是数据加工过程和口径管理，数出同源。

04数据仓库、数据湖与数据中台

1.数据仓库

数据仓库是一个存在已久并且已经面临更替的概念。传统上，因为数据分析、报表加工的需要，将源业务系统的数据采集汇集到数据仓库，通过数据清洗、加工、整合，然后形成方便后续使用的数据应用。
数据仓库架构还没有完全过时，但是已经面临巨大的冲击和挑战。首当其冲就是成本，传统数据仓库的领头羊是TERADATA等厂商，数据存储容量PB级，很难继续在物理上扩展，成本费效比下降很快；其次就是应用领域，数据仓库不能满足非结构化数据的存储和应用需要，埋点数据分析所依托的海量数据无法存储在传统的数据仓库中；第三就是时效性，传统数据仓库层层加工的数据层次，掌握技能的人员太少，处理转换路径太长，时效性也不能满足要求。
2.数据湖
数据湖和数据仓库的区别，一种理解是数据仓库是结构化数据存储，数据湖是按原样存储数据，无需事先对数据进行结构化处理。相比于数据进入数据仓库需要进行入仓前的模型化处理，数据湖增加数据会更快捷、方便。
而更为重要的区别在于，数据仓库是“弱数据治理”时代的产物，大部分企业没有建立企业级的数据治理架构和组织，数据仓库疲于在技术层面去做数据的整合。数据湖的背景则是“强数据治理”，“问渠那得清如许，为有源头活水来”，如果“入湖”的数据不清洁，那么数据湖就是“数据沼泽”；但是如何做到入湖的数据是清水，就需要对企业级源系统的数据治理，加强底层清理、提高入湖标准。如果做不到这一点，那么数据湖采集的数据越多，数据垃圾越多。
3.数据中台
数据中台是以数据应用为导向，以数据治理为保障，以数据湖底座为支撑，以数据服务和数据分析为具体价值输出的一个整体性的数据体系。
数据中台的建设，应该有整体规划。尤其是，数据中台是企业数据能力积累和建设的综合表现，需要企业大数据基础设施、大数据技术栈能力建设和大数据团队建设的不断优化。
数据中台的实施，在项目层面，可以采取“以用带建”的方式，在基础能力整体规划建设的基础上，通过业务应用项目的推进来倒推数据中台具体数据输出内容。

05数据中台是什么，不是什么，为什么

1.简单微服务和传统数据仓库不是数据中台
简单微服务只是解决API的调用封装，扒开微服务看，竖井还是竖井，时间越长管理难度越高，经年累月后就成为一堆乱麻，谁也不敢动。传统数据仓库更多是T+N级别的数据批量整合，缺实时性、缺大数据，对当前营销、风控、智能领域的数据需求无法响应。以上两者，包括两者的组合，都不是数据中台。
2.数据中台的基本背景就是企业级数据治理
数据中台的建设，先导是数据治理。只有数据在企业级范畴内完成基础梳理、标准体系建设，最大限度地形成源系统数据清洁和质量保障机制，形成数据溯源和血缘管理，数据中台建设才具备一个长期推进和迭代演进的基础。
在所有的数据中台规划中，数据资产管理平台或者数据治理平台是核心组件，承担对企业级的数据治理工作的平台落实和流程贯彻，数据资产盘点清理和目录化服务的基本功能，是企业级数据标准体系的具体呈现。
3.数据中台的技术底座是大数据平台和数据湖
数据中台的技术底座不再是类似TERADATA等一家单一厂商的单一产品，而是大数据技术栈组成的大数据平台，包括MPP、HIVE、HBASE、ES、CUBE、FLINK、图和AI等多种技术组件，共同构成的数据平台支撑体系。数据中台的性能，包括存储、计算、流转、大规模数据服务响应、实时性数据服务响应等参数指标，取决于技术平台的打造和能力建设。
数据中台的数据底座是数据湖，是大数据基础支撑下，海量数据的采集和存储，包括结构化、非结构化数据，包括企业内部数据和外部数据，包括批量采集数据和实时采集数据。数据湖的“闸口”是数据质量保障机制，一方面是在源系统的质量规则检验机制，一方面是在“入湖”口的数据质量监控和报告机制。数据湖的“清洁度监控”，还有赖于数据加工流转的血缘管理，这需要元数据管理工具的支持。
4.数据中台的四大特征是统一治理、统一计算、统一服务、统一分析
数据中台是数据能力的集中和集约，在数据治理的背景下，在大数据技术的支撑下，面向海量、智能、实时的数据应用需求，数据中台的四大基本能力建设就是治理能力、计算能力、服务能力和分析应用能力。
统一治理就是要将散落在企业各处的内、外部数据进行梳理及整合，使其成为企业级可用资源，为统一计算提供干净的底层数据。
统一计算就是要做到对主要数据应用，客户画像、经营管理指标、图和人工智能应用的统一数据构建，具体而言就是在进行基础数据高度整合，在ONE DATA基础上对数据标签、数据指标、图关系变量等的统一计算，解决“数出多源”问题，去除“同义不同名、同名不同义”问题。
统一服务就是要将数据计算的结果，面向高性能、大规模的业务应用，面向开放银行、规则引擎、营销和欺诈模型等机器级调用的需要，将数据进行产品化、服务化封装，以数据API等方式提供系统级调用服务，方便业务中台、前台系统的数据取用。
统一分析就是要将数据计算的结果，包括整合数据的明细内容，以分租户、分环境的方式，通过数据资产目录的开放共享，提供数据环境+分析工具+数据资产的配套机制，方便数据分析团队+数据科学家进行数据分析应用，挖掘数据价值，为各种业务规则、模型的构建进行数据赋能。

06结语

通过本次概念层面的梳理，我们将数据工作的体系框架、架构规范、平台管理等方面进行了一些总结。目前，数据中台建设的落地工作也在推进，4P平台的建设工作正在有序实施，也希望上面的概念梳理能够给大家对相关工作的理解提供一些帮助。欢迎关注公众号，一起进步！