第十二章 元数据管理10分

12.1 引言

如果没有元数据，组织可能根本无法管理其数据。
ISO/IEC11179 元数据注册标准。
元数据管理原则：应归尽归，应收尽收。衡量标准：目录是否完整。（去第十二章 元数据管理）。
主数据管理：主要的数据先入手。（去第十章 主数据与参考数据）。

Q1：元数据的主要功能？
A1：2 部分：查询、分析与报告（影响分析、血缘关系分析）。

Q2：上游系统改了内容，对下游系统有什么影响？
A2：影响分析。Q3：报告错了怎么办？A3：血缘关系分析，往回追溯。

Q4：系统中销售额字段有多个，如何确定是哪一个？
A4：查元数据。

Q5：主动型元数据管理（Active Metadata：Gartner 观点）【会考】
A5：(1)主动元数据平台始终是最新的。
(2)主动元数据平台不仅仅收集元数据，他们从元数据中创建智能。【表经常用，73是否能分区】。
(3)主动元数据平台不仅仅局限于智能，他们推动行动。【提供建议】。
(4)主动元数据平台是由 API 驱动的，支持嵌入式协作。

12.1 元数据建设步骤【5 个步骤，建议看看，重在理解】

1.定义元数据战略（P）

启动元数据战略计划、组织关键利益相关者访谈、评估现有元数据资源和信息架构、开发未来元数据架构、分阶段实施计划。

2.理解元数据需求（P）

对业务、技术、操作三类元数据有不同的需求，功能需求：更新批次、同步情况、历史信息、访问权限、存储结构、集成要求等。
（1）业务人员需求。
（2）技术人员需求。

3.定义元数据架构（P）【4 种架构】

支持扫描不同元数据源和定期的更新元数据存储库。支持手工更新元数据、请求元数据、查询元数据和不被用户组查询。
（1）创建元数据（D）。
（2）应用元数据标准（C）。
（3）管理元数据存储（C）。

4.创建和维护元数据【形成网址】

责任：流程的执行者对元数据的质量负责；
标准：执行、审计、应用数据标准；
改进：建立机制，持续改进不准确和不及时元数据。
（1）整合元数据（O）。
（2）分布和共享元数据（O）。
常见的传递机制包括【中心化网址，元数据内部网站、数据治理、数据战略、数据安全制度】。

 元数据内部网站，提供浏览、搜索、查询、报告和分析功能； 报告、术语表和其他文档；
 数据仓库、数据集市和 BI（商务智能）工具；
 建模和软件开发工具消息传输和事务；
 Web 服务和应用程序接口（API）
 外部组织接口方案（如供应链解决方案）。

5.查询、报告和分析元数据

在商业智能、商业决策、业务语义方面使用元数据，为业务、开发人员提供不同的界面，以供查询和获取元数据。

12.2 F4&Q 数据资产目录和元数据目录、和数据资产目录的关系

【重要】元数据=数据资源目录≠数据资产目录，资源到资产需要赋予价值（登记、认可、价值评估、进入流通环境）
1. 元数据=数据资源目录
2. 并非所有的数据都是资产，作为资产：
（1）所有权或者使用权
（2）价值体现：
i. 数据赋能
ii. 数据交易
3. 数据资产目录建立在元数据基础之上
（1）数仓相关的元数据
（2）数据湖相关的元数据
（3）交换和交易平台相关的元数据
（4）非结构化数据，特别是文档相关的元数据

注：业务元数据指向的那些有可能成为数据资产【资产建立在资源基础上，操作元数据、技术元数据指向的数据很难成为数据资产，往往只是一种材料】。

12.3 数据血缘关系→从下到上追溯【影响分析→从上到下分析】

杭州消费银行（数据血缘关系），（基于阿里巴巴）数据贴源层→数据模型层→接口表→转换表→出数表→基础指标→衍生指标。
指标管理目的：管理指标的数据字典，进行血缘及影响分析，做到报表口径有迹可循；通过指标口径及存储映射的管理，做到指标的自动化获取；指标总分关系自动联动钻取。

12.4 元数据可能存在的问题

表里只有系统名称、系统代码、系统模块、表英文名、表描述，但是没有中文；字段有表中文名、字段序号、字段英文名、字段类型，但是字段中文名缺失，字段中文名含义不明确等。

12.7 元数据架构

【4 种架构优缺点，参考 3 种架构 DMBOK2 P330】

Q：元数据架构有哪几种？数据治理架构有哪几种？A：元数据架构 4 种（集中式、分布式、混合式、双向），数据治理架构3种（集中式、分布式、联邦式）。

1.集中式元数据架构【参考阿里】

集中式元数据架构由单一的元数据存储库组成，包含来自各种不同源的元数据副本。
集中式存储库的优点：
（1）高可用性，因为它独立于源系统；
（2）快速的元数据检索，因为存储库和查询功能在一起；
（3）解决了数据库结构问题，使其不受第三方或商业系统特有属性的影响；
（4）抽取元数据时可进行转换、自定义或使用其他源系统中的元数据进行补充，提高了元数据的质量。
集中式存储库的缺点：
（1）必须使用复杂的流程确保元数据源头中的更改能够快速同步到存储库中；
（2）维护集中式存储库的成本可能很高；
（3）元数据的抽取可能需要自定义模块或中间件；
（4）验证和维护自定义代码会增加对内部 IT 人员和软件供应商的要求。

2.分布式元数据架构【参考华为】

一个完全分布式的架构中维护了一个单一的接入点。
分布式存储库的优点：
（1）元数据总是尽可能保持最新且有效，因为它是从其数据源中直接检索的；
（2）查询是分布式的，可能会提高响应和处理的效率；
（3）来自专有系统的元数据请求仅限于查询处理，而不需要详细了解专有数据结构，因此最大限度地减少了实施和维护所需的工作量；
（4）自动化元数据查询处理的开发可能更简单，只需要很少的人工干预；
（5）减少了批处理，没有元数据复制或同步过程。
分布式存储库的缺点：
（1）无法支持用户定义或手动插入的元数据项，因为没有存储库可以放置这些添加项；
（2）需要通过统一的、标准化的展示方式呈现来自不同系统的元数据；
（3）查询功能受源系统可用性的影响（若数据源头有问题，影响较大）；
（4）元数据的质量完全取决于源系统。

3.混合式元数据架构【参考央企】（DAMA 内部不一致）

混合架构结合了集中式和分布式架构的特性，元数据仍然直接从源系统移动到集中式存储库，但存储库设计仅考虑用户添加的元数据、重要的标准化元数据以及来通过自手工来源添加的元数据。【联邦式】。
优点：
该架构得益于从源头近乎实时地检索元数据和扩充元数据，可在需要时最有效地满足用户需求。
混合方法降低了对专有系统进行手工干预和自定义编码访问功能的工作量。基于用户的优先级和要求，元数据在使用时尽可能是最新且有效的。混合架构不会提高系统可用性。
缺点：
源系统的可用性是一个限制，因为后端系统的分布式特性处理查询。在将结果集呈现给最终用户之前，需要用额外的系统开销将这些初始结果与中央存储库中的元数据扩展连接起来。

4.双向元数据架构

允许元数据在架构的任何部分（源、数据集成、用户界面）中进行更改，然后将变更从存储库（代理）同步到其原始源以实现反馈。【联邦式】
存在挑战： 强制元数据存储库包含最新版本的元数据源，并强制对源的更改管理，必须系统地捕获变更，然后加以解决；必须构建和维护附加的一系列处理接口，以将存储库的内容回写至元数据源。

12.5 F3 元模型是什么？ 【基本会买软件】

元模型：存储元数据的模型。

12.6 F1 元数据来源，从哪梳理和收集元数据？特别是数仓的元数据该怎样梳理？

【14+and，重要】最重要 3 个：业务术语表、数据字典、数据库管理和系统目录。

元数据管理的软件系统应该有的功能

1.元数据采集
2.元数据查询
3.元数据分析
4.元数据变更管理
5.元数据浏览视图
6.元数据版本管理
基于现在云计算崭新的趋势，增加主动元数据原理、权限管理

12.8 Active Metadata：Gartner 观点【PPT 翻译，理想化】

去掉了被动型元数据管理，留下主动性元数据管理。

1.主动性元数据管理 4 个特性：

（1）主动元数据平台始终是最新的。
（2）主动元数据平台不仅仅收集元数据，他们从元数据中创建智能。【表经常用，热点是否能分区】。
（3）主动元数据平台不仅仅局限于智能，他们推动行动。【提供建议，分区，增加索引】。
（4）主动元数据平台是由 API 驱动的，支持嵌入式协作。

2.现代数据模型的数据层的 5 大趋势和变化

（1）现代数据模型成为主流，提供了一系列前所未有的快速、灵活的云原生工具。【不再是仅基于数仓为主，云端目前只有一家厂家在做】。
（2）数据团队比以往任何时候都更加多样化，导致混乱和协作开销。上下文是关键，元数据是解决方案。【业务人员也需要用到数据】。
（3）数据治理正在重新构想，从自上而下的集中规则到自下而上的分散举措–这需要对元数据平台进行类似的重新构想==【去中心化】==。
（4）随着元数据成为大数据，元数据湖在今天和明天都有无限的用例。
（5）被动元数据系统正在被废除，取而代之的是主动元数据平台。

3.现代数据架构

（1）现代数据架构需要考虑
①Self-service for a diverse range of users 自助服务。
②“Agile” data management – dataops 敏捷数据应用【dataops 数据架构搞敏捷是不太可能的，数据应用搞敏捷，现在是一边应用一边开发】。
③Cloud-first and cloud-native 考虑上云端数据【DCMM中未考虑cloud云端数据】。
特征：
Super fast set-up 超快速设置、
Pay as you go 现收现付、
Plugandplay即插即用、
Elastic compute 弹性计算、
No monoliths 没有巨石（没有很大的阻碍）、
Always available 始终可用。
内容：
Data ingestion 数据摄入 ETL：fivetran/stitch/singer/airbyte；【崭新引擎，针对现代数据架构】。
Data warehouse 数据仓库：snowflake【星型设计、雪花模型】amazonredshift。
Data lake 数据湖：starburst/amazon athena。
Data lakehouse 数据湖仓：databricks【bill innom是独立董事】。
Data transformation 数据转换 ETL 的 T：dbt/matillion/airflow/R/python。
Business intelligence 商业智能：looker/tableau/mode/thoughtspot。
Data science 数据科学：jupyter/datarobot。
Data access&goverance 数据访问：data discovery/datacataloging/data observability/visual query workbench/metricsrepository/data lineage&RCA。
Atlan（云端）/acceldata/transform/datahub/monte carlo/amundsen。
（2）数据用户的多样性【以前是 IT 在用，现在业务人员也在用】。
（3）数据治理的新态势和新目标。
Data governance→“Data and analytics”governance 数据治理→数据和分析治理（大数据杀熟）。
Centralized approach→Decentralized，community-led approach集中式思考→去中心化、社区主导的方法。Afterthought→Part of daily workflows 经过思考→日常工作流程的一部分。
（4）元数据的数据湖的兴起。

12.9 F2 怎样应用元数据？ （DMBOK2 P338）

元数据指导如何使用数据资产：在商务智能（报表和分析）、商业决策（操作性、运营型和战略型）以及业务语义（业务所述内容及其含义）方面使用元数据。元数据存储库应具有前端应用程序，并支持查询和获取功能，从而满足以上各类数据资产管理的需要。提供给业务用户的应用界面和功能与提供给技术用户和开发人员的界面和功能有所不同，后者可能会包括有助于新功能开发（如变更影响分析）或有助于解决数据仓库和商务智能项目中数据定义问题（如数据血缘关系报告）的功能。
（1）用于查询，
（2）分析和报告，如影响分析、血缘关系分析。

12.10 F5 元数据上线后如何维护？

需要及时更新，上游有改动，下游需更新。

12.11 F6&Q 元数据系统应该具有哪些功能？ 【非常重要】购买元数据管理系统。

Q：元数据系统应该具有哪些功能？【重要】→主数据应该有哪些功能【参考第十章】
A：8 个功能，
元数据采集、
元数据查询、
元数据分析、
元数据变更管理、
元数据浏览视图、
元数据版本管理。（←都是必须要有的）基于云计算趋势，应该增加主动性元数据管理功能，权限管理。

12.12 Q 元数据应该包括数据的哪些属性？特别是数据质量和数据安全属性

A：除了现有数据类型、约束等内容 ，还需至少再打2 个标签：质量属性及安全属性。→主动性元数据管理内容，在元数据搜集来之后，每个表及字段主动打标签。

12.13 Q 集团数字化转型应该从哪个领域开始？

数据管理需要元数据，理想化的情况下，集团数字化转型从元数据开始。

12.14 F7 如果元数据没有管理好，会怎样？【重点 DMBOK2 P322】

1.冗余的数据和数据管理流程；
2.重复和冗余的字典、存储库和其他元数据存储；
3.不一致的数据元素定义和与数据滥用的相关风险；
4.元数据的不同版本相互矛盾且有冲突，降低了数据使用者的信心；
5.怀疑元数据和数据的可靠性。

12.15 元数据有助于【DMBOK2 P322】

1.通过提供上下文语境和执行数据质量检查提高数据的可信度；
2.通过扩展用途增加战略信息（如主数据）的价值；
3.通过识别冗余数据和流程提高运营效率；
4.防止使用过时或不正确的数据；
5.减少数据的研究时间；
6.改善数据使用者和 IT 专业人员之间的沟通；
7.创建准确的影响分析，从而降低项目失败的风险；
8.通过缩短系统开发生命周期时间缩短产品上市时间；
9.通过全面记录数据背景、历史和来源降低培训成本和员工流动的影响；
10.满足监管合规。

12.16 补充元数据方法

1、血缘分析： 告诉你数据来自哪里，都经过了哪些加工。其价值在于当发现数据问题时可以通过数据的血缘关系，追根溯源，快速地定位到问题数据的来源和加工过程，减少数据问题排查分析的时间和难度。这个功能常用于数据分析发现数据问题时，快速定位和找到数据问题的原因。血缘分析是一种技术手段，用于对数据处理过程的全面追踪，从而找到某个数据对象为起点的所有相关元数据对象以及这些元数据对象之间的关系。元数据对象之间的关系特指表示这些元数据对象的数据流输入输出关系。在元数据管理系统成型后，我们便可以通过血缘分析来对数据仓库中的数据健康、数据分布、集中度、数据热度等进行分析。
2、影响分析： 告诉你数据都去了哪里，经过了哪些加工。其价值在于当发现数据问题时可以通过数据的关联关系，向下追踪，快速找到都哪些应用或数据库使用了这个数据，从而避免或降低数据问题带来的更大的影响。这个功能常用于数据源的元数据变更对下游 ETL、ODS、DW 等应用应用的影响分析。在开发中，我们经常会遇到以下问题：如果我要改动某个表、ETL，会造成怎样84的影响？如果没有元数据，那我们可能需要遍历所有的脚本、数据。才能得到想要的答案；而如果有成熟的元数据管理，那我们就可以直接得到答案，节省大量时间。
3、冷热度分析： 告诉你哪些数据是企业常用数据，哪些数据属于“僵死数据”。其价值在于让数据活跃程度可视化，让企业中的业务人员、管理人员都能够清晰的看到数据的活跃程度，以便更好的驾驭数据，激活或处置“僵死数据”，从而为实现数据的自助式分析提供支撑。
4、关联度分析： 告诉你数据和其他数据的关系以及它们的关系是怎样建立的。关联度分析是从某一实体关联的其它实体和其参与的处理过程两个角度来查看具体数据的使用情况，形成一张实体和所参与处理过程的网络，从而进一步了解该实体的重要程度，如：表与 ETL 程序、表与分析应用、表与其他表的关联情况等。本功能可以用来支撑需求变更的影响评估。
5、数据资产地图： 告诉你有哪些数据，在哪里可以找到这些数据，能用这些数据干什么。通过元数据可以对企业数据进行完整的梳理、采集和整合，从而形成企业完整的数据资产地图。数据资产地图支持以拓扑图的形式进行可视化展示各类元数据和数据处理过程，通过不同层次的图形展现粒度控制，满足业务上不同应用场景的数据查询和辅助分析需要。