读数据质量管理：数据可靠性与数据质量问题解决之道03数据目录 ...

1. 同步数据

1.1. 不同的数据堆栈和数据湖通过数据集成层来进行桥接
1.2. AWS Glue、Fivetran和Matillion等数据集成工具从不同来源收集数据，同一这些数据，并将其转换为上游来源
1.3. 数据集成的一个典型用例是收集数据湖的数据并以结构化格式将其加载到数据堆栈中
1.4. ETL是数据集成中一个众所周知的过程

• 1.4.1. ETL通常描述集成的步骤，此中首先从一个或多个数据存储库中提取数据，转换为新的结构或格式，最后加载到目标数据存储库中
  

2. 收集数据质量指标

2.1. 你无法修复你无法测量的东西

• 2.1.1. 如果没有数据质量指标，你就无法得到数据质量
  

2.2. 数据宕机的时间（也就是你的数据不完备、有错误、出现缺失或者其他禁绝确的时间段）来度量数据质量

• 2.2.1. 公司会仔细度量宕机时间，并投入大量资源来制止发生服务中断的环境
  

2.3. 问题列表

• 2.3.1. 数据是最新的吗？
  
• 2.3.2. 数据是完备的吗？
  
• 2.3.3. 字段是否在预期的范围内？
  
• 2.3.4. 空值率是否高于或低于应有的程度？
  
• 2.3.5. 模式是否已经更改？
  

2.4. 可扩展性

• 2.4.1. 跟踪大量的表和大数据集可能会非常棘手
  

2.5. 监控栈的其他部分

• 2.5.1. 构建真正可靠的数据管道并实现数据可观测性必要的远不但是收集指标这么简朴
  

2.6. Snowflake

• 2.6.1. Snowflake是最流行的云数据堆栈工具之一，其设计从一开始就优先思量了数据质量和数据完备性
  
• 2.6.2. 映射清单
  
• 2.6.3. 监控数据的奇怪度和容量
  
  
  
  • 2.6.3.1. 度量视图的奇怪度和容量并不简朴，由于这是底层查询指令中包含的表的函数
    
  
  
• 2.6.4. 建立你的查询汗青纪录
  
  
  
  • 2.6.4.1. 拥有在Snowflake环境中运行的所有查询的可靠汗青纪录是解决问题时非常有用的工具，它可以让你准确了解最近一次写入表的方式和时间
    
  
  
• 2.6.5. 健康检查
  

2.7. 数据堆栈最重要的功能之一就是能够直接从此中提取数据质量指标并将其可视化以便进行简朴的分析
2.8. 为跟踪数据质量指标而提取的信息必要随时能够提供给团队中的其他成员利用，特别是当事变发生变革或你正处于对数据管道进行根因分析的痛楚之中时
3. 查询日志

3.1. 问题

• 3.1.1. 谁在访问这些数据？
  
• 3.1.2. 来自上游的哪里？
  
• 3.1.3. 来自上游的哪里？
  
• 3.1.4. 均匀多久实行一次特定的转换？
  
• 3.1.5. 有多少行会受到影响？
  

3.2. 查询日志表通常仅存储某些天数的查询汗青纪录，且此中所包含的信息比数据质量计划所必要的多得多
3.3. 一个处理数据质量指标查询日志的健壮的解决方案必要具有前瞻性，并将所需的指标和聚合存储在一个更为永久的位置
4. 数据目录

4.1. 数据栈中的另一个关键元素是数据目录，它在理解数据质量方面起着重要的作用

• 4.1.1. 数据目录作为元数据清单，为投资者提供了评估数据可访问性、健康状况和位置所需的信息
  
• 4.1.2. 不仅可以监测数据，还可以与机器学习和自动化相集成，让数据更易于被发现、更具协作性，而且更符合当前构造、行业甚至当局的相干规则
  

4.2. 由于数据目录提供了有关公司数据源的单一真相来源，因此你可以很容易地利用数据目录来管理管道中的数据

• 4.2.1. 数据目录可以用来存储元数据，让利益相干方更好地了解特定来源的沿袭，从而增强对数据本身的信任
  
• 4.2.2. 数据目录可以方便地纪录个人身份信息的存放位置和下游蔓延位置，以及构造中谁有权通过管道来访问这些信息
  

4.3. 问题

• 4.3.1. 应该在哪里查找数据？
  
• 4.3.2. 这些数据重要吗？
  
• 4.3.3. 这些数据代表了什么？
  
• 4.3.4. 这些数据的相干性和重要性如何？
  
• 4.3.5. 该如何利用这些数据？
  

4.4. 传统上利用Excel来解决数据编目问题的方式

• 4.4.1. 自动化能够让数据工程师和分析师腾出时间来专注于真正能取得进展的项目
  

4.5. 当前存储的大部分数据都黑白结构化且高度活动的

• 4.5.1. 人们越来越必要根据数据的意图和目的来理解数据，而不是简朴地描述斲丧者访问和利用的数据
  
• 4.5.2. 数据编目可以发现并构造恰当的元数据来表明你的数据管道
  

4.6. 构建数据目录

• 4.6.1. 在构建或投资数据目录之前，你必要与运营和分析团队的下游利益相干方一起合作，了解哪些数据对业务最为重要，从而必要进行纪录和编目
  
• 4.6.2. 最基本的，数据目录是元数据聚集，可提供对数据位置、所有权和潜在用例的背景信息和洞察
  
• 4.6.3. Sqlparse、ANTLR、Apache Calcite和MySQL的SQL Parser都是流行的开源SQL解析解决方案
  
• 4.6.4. GraphQL、REST和Cube.js等开源查询语言工具将允许你在数据库中查询SQL并将其呈现在编目可视化服务中
  
• 4.6.5. Amundsen、Apache Atlas、DataHub或CKAN
  
• 4.6.6. 当你拥有严格的模型时，数据目录的效果很好，但随着数据管道变得越来越复杂，非结构化数据开始成为黄金标准，我们对数据的理解（数据做什么、谁在利用它、如何利用它）并不能反映现实环境
  
• 4.6.7. 下一代数据目录将具有学习、理解和推断数据的本领，让用户能够以自助式服务的方式利用其洞察力
  
  
  
  • 4.6.7.1. 数据目录将支持自动数据发现和主动元数据
    
  
  
• 4.6.8. 数据管理策略还必须包含数据发现，这是一种及时了解分布式数据资产健康状况的新方法
  
  
  
  • 4.6.8.1. 数据发现借鉴了Zhamak Dehghani和Thoughtworks的数据网格模型提出的面向范畴的分布式架构，认为不同的数据所有者都应对其数据产品负责，并推动不同位置的分布式数据之间的通讯
    
  • 4.6.8.2. 一旦数据被提供给某一特定范畴并在该范畴转换后，该范畴数据的所有者就可以利用这些数据来满足其自身的运营或分析需求
    
  
  
• 4.6.9. 数据发现取代了对数据目录的必要，它根据一组特定斲丧者如何摄取、存储、聚合和利用数据，提供了对特定范畴数据的动态解读
  
  
  
  • 4.6.9.1. 数据治理的标准和工具同样是跨范畴联合的，以支持更高的可访问性和互操作性
    
  • 4.6.9.2. 数据发现可以及时了解数据的当前状态，而不是其理想状态或“编目”状态
    
  
  

4.7. 以数据质量为优先的数据目录

• 4.7.1. 自助式服务的数据发现与自动化
  
  
  
  • 4.7.1.1. 即使没有专门的支持团队，数据团队也应该能轻松利用其数据目录
    
  • 4.7.1.2. 自助式服务、自动化和工作流编排等数据工具消除了数据管道各阶段之间及其过程中产生的孤岛，让数据变得更容易理解和访问
    
  • 4.7.1.3. 更高的可访问性自然会提高数据的接纳率，从而减轻数据工程团队的负担
    
  
  
• 4.7.2. 随数据演变的可扩展性
  
  
  
  • 4.7.2.1. 随着公司接收越来越多的数据且非结构化数据开始成为常态，通过扩展来满足这些需求的本领对于数据计划的成功将变得至关重要
    
  
  
• 4.7.3. 用于分布式数据发现的数据沿袭
  
  
  
  • 4.7.3.1. 数据发现严峻依靠自动化表格和字段级的沿袭来映射数据资产之间的上下游依靠关系
    
  • 4.7.3.2. 数据发现让数据团队能够相信团队对数据的假设与现实符合，从而在不思量范畴的前提下，在数据基础办法中实现动态发现和高度的可靠性
    
  • 4.7.3.3. 你的团队可能已经以某种方式在数据发现方面进行了投资，无论是通过团队为验证数据而正在进行的手动工作，照旧通过工程师编写的自定义验证规则，或者仅仅是基于损坏的数据或未被察觉的隐性错误所做出的决议成本
    
  
  

4.8. 要得到真正可发现的数据，很重要的一点在于数据不仅要“编目”​，而且从摄取到利用这一过程要准确、干净且完全可观测

• 4.8.1. 要可靠
  
• 4.8.2. 只有了解你的数据及其状态，以及在其生命周期的所有阶段和跨范畴的利用方式，我们才能开始信任它
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。