1. 要害

1.1. 完成数据质量不能坐而论道，而取得“牢靠数据”取决于数据剖析和工程实践中的其他几个要素

1.2. 数据网格以及数据质量适用的当地

1.3. 数据质量在根据云的数据栈旅程中的效果

1.4. 常识图谱是更易于拜访数据的要害

1.5. 分布式数据架构下的数据发现

1.6. 何时开端进行数据质量操控

2. 为更高的数据质量构建数据网格

2.1. 数据团队期望找到一种更简单的办法来办理安排日益增加的需求，不论是处理永无止境的即席查询流，仍是经过中心ETL管道处理不同的数据源

• 2.1.1. 处理孤立的根底设施局限性，许多数据团队正在向更为分布式的“联邦办理”模型搬运，开端选用数据网格架构

2.2. 数据网格在许多方面都是微服务的数据渠道版别

• 2.2.1. 数据网格是一种数据渠道的架构类型，经过选用面向范畴的自助式规划来运用企业中无处不在的数据

• 2.2.2. 数据网格架构的根底是通用互操作性层，反映了与范畴无关的规范，以及可观测性和办理

• 2.2.3. 数据网格让团队可以跨事务范畴来操作数据，但一起可以跨这些范畴进行规范化办理，以保证数据质量

2.3. 数据网格概念运用了Eric Evans的范畴驱动规划理论，这是一种灵敏、可扩展的软件开发典范，可以将代码的结构和言语与其相应的事务范畴进行匹配

• 2.3.1. 与在一个中心数据湖中处理数据的运用、存储、转化和输出的传统全体数据根底设施不同

• 2.3.2. 数据网格支撑分布式、特定范畴的数据用户并将“数据视为产品”​，而每个范畴都各自处理自己的数据管道

• 2.3.3. 衔接这些范畴及相关数据财物之间的枢纽是运用相同语法和数据规范的通用互操作层

2.4. 三个独立的组件组成

• 2.4.1. 数据源

• 2.4.2. 数据根底设施

• 2.4.3. 由功用一切者办理的面向范畴的数据管道

2.5. 面向范畴的数据一切者和数据管道

• 2.5.1. 数据网格联合了担任将数据作为产品供给的范畴数据一切者之间的数据一切权，一起也促进了跨不同方位的分布式数据之间的通讯

• 2.5.2. 数据根底设施担任为每个范畴供给用于处理数据的处理方案，但范畴的使命是办理数据的吸取、清洗与聚合，以生成可供商业智能运用程序所运用的数据财物

  • 2.5.2.1. 每个范畴都担任具有自己的ETL管道，但一切范畴都应具有存储、编录和保护拜访操控原始数据的才能

  • 2.5.2.2. 一旦数据被供给给一个指定的范畴并由其转化，范畴一切者就可以运用这些数据来满意其剖析或运营需求

2.6. 自助式服务功用

• 2.6.1. 供给自助式数据渠道，答使用户将技能杂乱性抽象化并专心于他们各自的数据用例

• 2.6.2. 在每个范畴中保护数据管道和根底设施所需的工作和技能上的重复

• 2.6.3. 数据网格将与范畴无关的数据根底设施功用搜集并提取到一个中心渠道中，由该渠道来处理数据管道引擎、存储和数据流根底设施

• 2.6.4. 每个范畴担任运用这些组件来运转自界说的ETL管道，给它们供给必要的支撑来轻松地服务其数据并真实掌控流程所需的自主权

2.7. 互操作性与通讯规范化

• 2.7.1. 每个范畴的底层都是一组通用的数据规范，这些规范有助于在必要时促进范畴之间的协作

• 2.7.2. 某些数据都将对多个范畴有价值

• 2.7.3. 为了完成跨范畴间的协作，数据网格必须在格局、办理、可发现性和元数据字段以及其他数据特性方面完成规范化

• 2.7.4. 每个数据范畴都必须界说并赞同它们将“保证”为顾客供给的SLA和质量办法

3. 为什么要施行数据网格

3.1. 具有实时数据可用性和流处理功用的数据湖，其方针是从会集式数据渠道吸取、丰厚、转化并供给数据

3.2. 缺少

• 3.2.1. 中心ETL管道让团队减少了对不断增加的数据量的操控

• 3.2.2. 跟着每个公司都成为数据公司，不同的数据用例需求不同类型的转化，这给中心渠道带来了沉重的担负

3.3. 面向范畴的数据架构（如数据网格）为团队供给了一举两得的办法

• 3.3.1. 会集式数据库（或分布式数据湖）

• 3.3.2. 其间的范畴（或事务范围）担任处理自己的管道

3.4. 数据网格关于具有300名以上职工的运用云渠道的公司来说将变得越来越遍及

3.5. 数据架构可以经过分解成更小的、面向范畴的组件来最简单地进行扩展

3.6. 数据网格为数据一切者供给了更大的自主权和灵敏性，促进了更大的数据试验和立异，一起减轻了数据团队经过单一管道来满意每个数据顾客需求的担负，从而为数据湖的缺陷供给了处理方案

3.7. 数据网格的自助服务根底设施作为一个渠道，为数据团队供给了一种通用的、与范畴无关的、一般是自动化的办法，来完成数据规范化、数据产品沿用、数据产品监控、警报、日志记载和数据产品质量指标（也便是数据的搜集和同享）​

• 3.7.1. 传统数据架构一般因吸取者和顾客之间缺少数据规范化而遭到阻止

3.8. 选不选网格

• 3.8.1. 新架构的选用也带来了对数据网格真实实质以及怎么构建数据网格的误解

• 3.8.2. 处理许多数据源和需求进行数据试验（也便是快速转化数据）的团队最好考虑运用数据网格

3.9. 核算你的数据网格分数

• 3.9.1. 数据源的数量

• 3.9.2. 数据团队的规划

• 3.9.3. 数据范畴的数量

• 3.9.4. 数据工程的瓶颈

• 3.9.5. 数据办理

• 3.9.6. 分数越高，则公司的数据根底设施要求就越杂乱和严苛，而公司就越有或许从数据网格中获益

4. 数据质量在数据网格中的效果

4.1. 可以从单一处理方案构建数据网格吗

• 4.1.1. 数据网格不是一个技能处理方案，乃至也不是技能的子集，而是咱们怎么办理和操作数据的安排范式，由多种不同的技能组成，无论是开源技能仍是软件即服务

• 4.1.2. 你无法仅运用数据库来构建微服务架构，而且你也不会只运用数据仓库或商业智能工具来构建数据网格

• 4.1.3. 数据网格四项根本元素

  • 4.1.3.1. 将数据的一切权从一个会集的团队下放给最适合操控它的人

  • 4.1.3.2. 赋予这些团队长时刻的责任感，并让他们具有将数据视为产品的思想

  • 4.1.3.3. 为团队供给自助式数据根底设施

  • 4.1.3.4. 处理新的联合数据办理模型或许呈现的新问题

  • 4.1.3.5. 保证你的数据网格从一开端就走上正确的路途

4.2. 数据网格是数据虚拟化的另一种表达吗

• 4.2.1. 答应运用程序跨多个数据孤岛来检索和操作数据

• 4.2.2. 猜测剖析和对前史趋势进行建模需求的都是天壤之别的数据视图

• 4.2.3. 虚拟化坐落OLTP体系和微服务或运营型数据库之上，并按原样揭露该数据，或仅仅进行一些小的转化

4.3. 每个数据产品团队是否办理自己独立的数据存储

• 4.3.1. 数据存储一般由一个中心数据工程或数据根底设施团队来保护，该团队担任保证数据网格在每个范畴中都能正常运转

• 4.3.2. 不是办理数据根底设施的人，而这些根底设施才能让数据剖析、数据科学和机器学习成为或许

4.4. 自助式数据渠道与涣散式数据网格是一回事吗

• 4.4.1. 数据渠道经常被优化用于与数据网格无关的意图

• 4.4.2. 支撑数据网格所构建的数据渠道若要被优化，应当赋予事务范畴团队自主权，并赋予通才技能人员创立数据产品的才能

• 4.4.3. 数据渠道应该让团队可以具有端到端地办理数据的才能，并直接服务于数据顾客，即数据剖析师、数据科学家和其他终端用户

4.5. 数据网格适用于一切的数据团队吗

• 4.5.1. 数据网格的前期选用者往往以工程为要点，而且乐意出资“构建和购买技能，因为并不是一切元素都可以买到的”​

• 4.5.2. 假如你的利益相关方在寻觅和运用正确的数据方面遇到问题，而且立异周期正在放缓，那么你或许是考虑选用数据网格的恰当人选

4.6. 团队中的某个人会“具有”数据网格吗

• 4.6.1. 整个安排的文明支撑

• 4.6.2. 当安排的首席数据官或首席数据剖析官直接向CEO汇报时，该安排在大规划选用数据网格时一般会更有用

• 4.6.3. 当你测验在安排中选用数据网格时，你的团队需求取得1～3个与该愿景相共同的事务范畴的支撑，作为推进规划和施行数据网格向前开展的倡导者

4.7. 数据网格是否会引起数据工程师和数据剖析师之间的冲突

• 4.7.1. 因为数据网格要求下放数据一切权，因而选用这种分布式的、面向范畴的模型一般会在此前曾存在冲突的范畴带来杰出的和谐

• 4.7.2. 数据网格的数据办理通用规范可以保证各方在环绕数据质量、数据发现、数据产品形式以及数据健康和了解的其他要害要素方面可以达到共同

• 4.7.3. 自助式服务功用

  • 4.7.3.1. 静态和动态数据加密

  • 4.7.3.2. 数据产品的版别操控

  • 4.7.3.3. 数据产品形式

  • 4.7.3.4. 数据产品发现、目录注册和发布

  • 4.7.3.5. 数据办理和规范化

  • 4.7.3.6. 数据出产沿用

  • 4.7.3.7. 数据产品的监控、警报和日志记载

  • 4.7.3.8. 数据产品的质量指标

4.8. 许多公司运用数据网格概念的时刻都比他们意识到的要长

• 4.8.1. 他们仅仅没有找到适宜的词来描述它

4.9. 树立一家数据驱动型公司是一场马拉松，而不是一场短跑

• 4.9.1. 跟着越来越多的安排选用数据网格和分布式架构，在立异、功率和可扩展性方面带来的时机从未如此巨大