1. 让元数据为事务服务

1.1. 在曩昔十多年中，数据团队越来越拿手搜集很多的数据

1.2. 公司现在正在搜集越来越多关于其数据的数据，也便是元数据

• 1.2.1. dbt等ETL处理方案让盯梢和运用元数据变得简单，而云服务供给商则使栈中数据处理方案之间的元数据的互操作性变得愈加无缝

• 1.2.2. 没有与之对应的布景信息的数据只不过是一堆数字相同，元数据自身并没有用，它仅仅关于其他信息的更多信息

1.3. 元数据的真实力气在于咱们运用它的地址、时刻和方法

• 1.3.1. 怎么将它使用于咱们正在企图处理的特定且亟须处理的问题

2. 经过数据发现开释元数据的价值

2.1. 数据仓库和数据湖的考量

• 2.1.1. 在曩昔几年中，云数据仓库和数据湖已成为现代数据栈的必备要素

• 2.1.2. 数据发现东西（或联合目录）能够供给协助来保证你的数据环境不会变成数据沼地

• 2.1.3. 数据湖具有无限的灵活性和可定制性，来支撑广泛的用例，但跟着这种更强的敏捷性而来的是与数据安排和管理相关的一系列其他问题

• 2.1.4. 跟着数据运营的老练和数据管道变得越来越杂乱，传统的数据目录往往达不到你所希望的数据发现东西答复这些问题的方法

2.2. 数据目录或许吞没在数据湖乃至数据网格中

• 2.2.1. 数据目录常常被用作元数据的清单，并供给有关数据健康状况、可拜访性和方位的信息

• 2.2.2. 协助数据团队答复有关在哪里查找数据、数据代表了什么以及要怎么运用数据的问题

• 2.2.3. 假如咱们不知道这些数据是怎么安排的，那么咱们一切最好的方案（或管道）都是白费的

• 2.2.4. 从历史上看，许多公司都运用数据目录来加强数据质量和数据管理规范，由于他们一般依靠于数据团队手动输入和更新目录信息以盯梢数据财物的演化状况

• 2.2.5. 在数据湖中，数据是分布式的，因而很难记载数据在其生命周期进程中的演化状况

• 2.2.6. 存储在传统数据目录中的数据也难以扩展和演化，以满意分布式数据架构（如数据网格）的需求

2.3. 从传统的数据目录过渡到现代的数据发现

• 2.3.1. 跟着时刻的推移，了解不同数据财物之间的联络至关重要，但这中心往往缺少传统数据目录的维度

• 2.3.2. 公司仍需求知道他们的数据存放在哪里以及谁能够拜访它，并能够评价其全体健康状况

• 2.3.3. 尽管许多数据目录都有以用户界面为中心的工作流，但数据工程师需求具有以编程方法与数据目录进行交互的灵活性

• 2.3.4. 数据能够经过多个进口点进入数据湖，而工程师需求一个能够适应该状况并阐明每个进口点的数据目录

• 2.3.5. 与数据在输入前进行清洗和处理的数据仓库不同，数据湖在不对端到端健康状况做任何假定的状况下就接收了原始数据

  • 2.3.5.1. 假如没有数据发现东西和数据沿用，那么数据湖中的毛病或许会变得紊乱且难以确诊

  • 2.3.5.2. 在数据湖中，能够经过多种方法与数据进行交互，而数据目录有必要能够供给对正在运用的内容和未运用内容的了解

• 2.3.6. 数据发现，换句话说，联合数据目录，是一种植根于Dehghani数据网格模型中提出的分布式面向范畴架构的新方法

• 2.3.7. 填补了传统数据目录缺乏的空白

  • 2.3.7.1. 跨数据湖的主动化扩展

    2.3.7.1.1. 运用机器学习，数据发现东西来主动盯梢表级和字段级沿用，映射上游和下流的依靠联络

  • 2.3.7.2. 供给对数据健康状况的实时可见性

    2.3.7.2.1. 数据发现东西供给对数据当时状况的实时可见性，而不是其“编目”或抱负状况

  • 2.3.7.3. 运用数据沿用了解数据的事务影响

    2.3.7.3.1. 数据发现东西的灵活性和动态性让其成为将数据沿用带入数据湖的抱负载体，让你能够在正确的时刻取得正确的信息，并在许多或许的输入和输出之间树立联络

  • 2.3.7.4. 支撑跨范畴自助式服务的数据发现

    2.3.7.4.1. 数据发现东西还支撑自助式服务，让人们无须专门的支撑团队即可轻松运用和了解他们的数据

  • 2.3.7.5. 保证跨数据湖的管理和优化

    2.3.7.5.1. 现代数据发现东西让公司不只能够了解在数据生命周期中正在运用、消费、存储和弃用哪些数据，还能够了解这些进程是怎么进行的

• 2.3.8. 数据发现东西还能够让利益相关方轻松识别出最重要的数据财物（也便是常常被查询的数据）​，以及那些未被运用的数据财物

  • 2.3.8.1. 一些最好的数据目录越来越多地选用分布式特定范畴的数据发现，为团队供给了在数据生命周期的各个阶段彻底信赖并运用数据所需的可见性

• 2.3.9. 假如你不信赖数据，那么不管数据多具有“可发现性”也没什么用

  • 2.3.9.1. 尽早确认数据质量在公司数据之旅中的优先级会很有协助，以避免不必要且带来费事的数据宕机

3. 决议何时开端处理公司的数据质量问题

3.1. 更关心要怎样才能推进收集数据，让这个事发动并运转起来

3.2. 构建数据渠道是一个多阶段的进程，而数据团队有必要统筹数十个相互竞争的优先事项

3.3. 假如公司不运用或不信赖你的数据，那么你为数据渠道控制而拟定的最佳方案就成为白日梦

3.4. 七个抢先目标

• 3.4.1. 在最近搬迁到云端

  • 3.4.1.1. 不管出于何种原因进行搬迁，你都有必要在坚持速度的一起树立对数据渠道的信赖

  • 3.4.1.2. 应该花更多的时刻来构建数据管道，而不是把时刻用在编写测验以避免呈现问题上

• 3.4.2. 数据栈跟着更多的数据源、更多的表和更高的杂乱性而扩展

  • 3.4.2.1. 数据产品的规划不是出资数据质量的唯一规范，但的确是一个重要要素

  • 3.4.2.2. 出资数据可观测性前应该具有多少数据源、数据管道和数据表方面并没有硬性规定，但一个较好的辅导原则是具有50张以上的表

  • 3.4.2.3. 重要的考虑要素是数据栈添加的速度

• 3.4.3. 数据团队正在扩大

  • 3.4.3.1. 招聘更多的数据专家，并将现代东西使用到你的数据栈中

  • 3.4.3.2. 技能债将随时刻渐渐堆集，而你的数据团队将投入很多时刻来清洗数据问题

• 3.4.4. 团队至少花费了30%的时刻来处理数据质量问题

  • 3.4.4.1. 数据工程师花费了太多的名贵时刻来修正问题而不是进行立异

• 3.4.5. 团队具有比一年前更多的数据顾客

  • 3.4.5.1. 数据为你的招聘决议计划、产品功用和猜测剖析供给了支撑

  • 3.4.5.2. 快速添加会导致事务相关方对数据的依靠程度添加，数据需求变得愈加多样化，而终究导致需求更多的数据

  • 3.4.5.3. 更多的数据也会带来更大的职责，由于不良数据进入你的数据生态系统的或许性也添加了

  • 3.4.5.4. 越是数据驱动型的安排反而越会有更多的数据顾客来发现数据中呈现的任何过错

• 3.4.6. 公司正在转向自助式服务剖析模型

  • 3.4.6.1. 公司正在转向自助式服务剖析模型，以便为数据工程师腾出时刻，并答应每个事务用户直接拜访数据并与之进行交互

  • 3.4.6.2. 到最后假如你的终究用户不信赖数据，那么转向自助式服务剖析模型的意图就会失败

  • 3.4.6.3. 跟着数据越来越成为数据驱动型安排日常运营不可或缺的一部分，对牢靠数据的需求只会添加

  • 3.4.6.4. 两种类型的数据质量问题

    3.4.6.4.1. 你能够猜测的（已知的不知道）

    3.4.6.4.2. 你不能猜测的（不知道的不知道）

• 3.4.7. 数据是客户价值建议的要害部分

  • 3.4.7.1. 每个使用程序都将很快成为一个数据使用程序

  • 3.4.7.2. 当没有优先考虑数据质量时，数据团队和你的客户就会遭受丢失

3.5. 数据质量源于信赖

• 3.5.1. 安排需求信赖他们的数据来为利益相关方供给洁净牢靠的数据

• 3.5.2. 名贵的工程时刻就会被糟蹋在救火数据宕机上，你为成为数据驱动型公司所做出的尽力也会跟着时刻的推移而受阻，事务用户也将失掉对数据的信赖