读数据质量管理：数据可靠性与数据质量问题解决之道19数据未来 ...

1. 开创可靠数据系统的未来

1.1. 数据作为一个行业很可能正在经历一场巨大且不可逆转的巨变
1.2. 分析型数据正变成现代企业最关键和最具竞争力的核心资产

• 1.2.1. 不再是公司是否依靠数据的问题
  
• 1.2.2. 是使用多少数据以及将数据用于什么场景的问题
  

1.3. 仅仅网络更多数据还是不够的，你必须学会相信它

• 1.3.1. 让数据可靠性变得越发紧张
  
• 1.3.2. 数据信任对于任何成功的数据工程或分析计划来说都至关紧张，但实现起来往往充满挑衅，而维护起来就更难了
  

1.4. dbt和Great Expectations等开源工具让从业者能够快速地对更关键的数据集举行单元测试
1.5. 数据质量终极还是要靠精良的文化、结实的流程和利益干系方的认同来维系
1.6. 数据质量计划通常应优先于数据目录和数据发现等项目
1.7. 除非你可以对数据质量举行评估，否则提出把资金投入到数据质量上的论点往往提及来容易而做起来难
1.8. 对数据宕机的计算取决于数据变乱的数量乘以均匀检测时间息争决它们所需的时间

• 1.8.1. DDT=N(TTD+TTR)
  
• 1.8.2. DDT是数据宕机的时间
  
• 1.8.3. N是变乱的数量
  
• 1.8.4. TTD是检测所需时间
  
• 1.8.5. TTR是解决所需时间
  

2. 积极主动

2.1. 只有当钱因不良数据而“溜走”时，我们才会清晰地了解到优质数据的价值

• 2.1.1. 计算你公司每年处理数据质量问题的小时数
  
• 2.1.2. 许多数据问题可能必要几天甚至几周的时间才气被检测出来
  
• 2.1.3. 数据团队会启动一个耗时的根因分析过程，此中涉及几个步调，包括检查相沿（如有）​、代码、数据、操作环境以及与同事交流
  
• 2.1.4. 计算甚至没有考虑时机成本（换句话说就是：你为使用不准确的数据而做堕落误决策所付出的代价）​
  
• 2.1.5. 随着行业的成熟，我们预计会出现比我们这个方程聪明得多的算法来得出这些问题为企业所带来的成本预测
  

2.2. 证明数据质量价值的第一步是评估数据可靠性对你公司的财务影响
3. 对数据质量和数据可靠性未来的预测

3.1. 在公司中建立全面的数据实践远不只是在数据宕机时才主动出击
3.2. 了解该领域的发展方向并主动管理公司的目标和战略也非常紧张
3.3. 分析成为各个职能部分的关键部分，解决数据质量的要求和方法自然会发生变化也就不言而喻了
3.4. 数据仓库和数据湖将融为一体

• 3.4.1. 越来越多的企业同时接纳数据仓库和数据湖
  
• 3.4.1.1. 无论是作为一个整体的解决方案或是多个解决方案中的一部分
  
• 3.4.2. 数据质量在数据仓库中更容易维护，由于在这里更容易自然地跟踪数据的模式、容量和新鲜度
  
• 3.4.3. 数据湖由多个入口组成，这意味着会有更多的层来对数据举行排序和对齐以供操作使用
  
• 3.4.4. 一种使用更少工具来更好处理数据的方法意味着理论上数据在生产过程中被破坏的时机要更少
  
• 3.4.5. 湖仓一体要求数据平台的工作方式更加标准化，而这也因此为接纳更集中的数据质量和数据可观测性方法打开了大门
  
• 3.4.6. 预测这种融合将在财务和资源管理这两方面都有利于消费者，但这也有可能会给你的数据管道带来额外的复杂度
  
• 3.4.7. 更广泛的应用场景意味着更多的数据用户，而这通常会导致更多的数据重复、错误和下游警报
  

3.5. 数据团队中的新脚色

• 3.5.1. 孤立的数据库管理员或分析师的日子早已一去不复返了
  
• 3.5.2. 数据正在以其自身的力量通过数据科学家、分析师和工程师等定制脚色的出现席卷整个公司
  
• 3.5.3. 专业化海潮并非数据所独有
  
• 3.5.3.1. 专业化几乎对每个行业都很广泛，它标志着市场的成熟，表明白对规模化、进步速度和提拔性能的必要
  
• 3.5.4. 数据产品司理
  
• 3.5.4.1. 负责管理给定命据产品的生命周期，并通常负责管理跨职能的干系职员、产品路线图和其他战略任务
  
• 3.5.5. 分析工程师
  
• 3.5.5.1. 一个被dbt实验室带火的术语，这个脚色介于数据工程师和分析师之间，负责对数据举行转换和建模，以便让干系职员能够信任并使用该数据
  
• 3.5.5.2. 是专家和通才，通常拥有数据栈中的多个工具并分身许多技术性和非技术性任务
  
• 3.5.6. 数据可靠性工程师
  
• 3.5.6.1. 致力于主要通过数据可观测性、测试和其他常用方法来构建更具弹性的数据栈
  
• 3.5.6.2. 通常拥有可以直接应用于这一新脚色的DevOps技能和经验
  
• 3.5.7. 数据设计师
  
• 3.5.7.1. 与分析师密切互助，帮助他们通过商业智能可视化或其他框架来讲述有关数据的故事
  
• 3.5.7.2. 在大型组织中更为常见，并且通常来自产品设计背景
  
• 3.5.7.3. 数据设计师不应与数据库设计师相混淆，后者是一个更为精专的脚色，为存储和生产的数据举行建模和构建
  
• 3.5.8. 随着数据团队脚色的多样化和用例的增加，涉及的利益干系方也会增加
  
• 3.5.9. 聘请数据可靠性工程师，人们也无法“解决”数据质量的问题
  

3.6. 主动化的鼓起

• 3.6.1. 更多应用主动化通常都会是一件积极的事
  
• 3.6.1.1. 主动化减少了手工劳动，扩展了重复过程，并使大型系统更具容错能力
  
• 3.6.1.2. 在进步数据质量方面，主动化有许多时机来填补测试、编目和其他更多手动流程失败的空白
  
• 3.6.2. 硬编码数据管道
  
• 3.6.2.1. 主动摄取解决方案可以轻松快速地摄取数据并将其发送到你的数据仓库或数据湖中举行存储和处理
  
• 3.6.3. 单元测试和编排检查
  
• 3.6.3.1. 单元测试是一个典型的规模问题，由于大多数公司不可能端到端地覆盖他们所有的管道，甚至无法为数据可能变坏的每种方式都准备测试
  
• 3.6.3.2. 接纳更加主动化的机制来测试他们的数据并在损坏的管道上编排断路器
  
• 3.6.4. 将数据从暂存环境转移到生产环境
  
• 3.6.4.1. 积极主动的方法将防止下游架构中断并更可靠地推动生
  
• 3.6.5. 根因分析
  
• 3.6.5.1. 可以利用这些元数据来拼凑出变乱发生时的全景，并从中解决问题
  
• 3.6.6. 数据记录、编目和发现
  
• 3.6.6.1. 无论是通过使用数据目录、数据发现还是其他工具，都必要某种主动化流程来对数据集举行记录
  

3.7. 数据工程技术的创新和进步意味着更高的主动化程度，并进一步提拔了我们做好全面准备防止数据宕机方面的能力

• 3.7.1. 无论怎样举行分别，即使对最新的数据团队来说，寻求肯定程度的数据可靠性也将成为一种标配
  
• 3.7.2. 将数据质量作为数据成熟度的一个向量举行评估
  

4. 更多的分布式环境与数据领域的鼓起

4.1. 分布式数据范式，如数据网格，让整个企业的职能部分都能更容易地利用数据来处理特定用例
4.2. 面向领域的所有权应用于数据管理的潜力非常之大（更快的数据访问、更强的数据民主化、更知情的干系方等）​，但潜在的复杂度也是如此
4.3. 数据团队只必要看看微服务架构，就可以先睹为快在数据网格高潮平息下来并且团队开始认真实施后会发生什么
4.4. 剥离技术组件会增加数据质量的问题
4.5. 如果不积极主动熟悉到问题并创建有关怎样使用数据的来龙去脉，对数据网格方法举行扩展可能会非常具有挑衅性

• 4.5.1. 固然数据网格宣扬了跨领域的通用团结层（换句话说，不受限制的治理）​，但团队必须遵守特定合约并使用专用的API，而这可能会带来复杂性并导致混乱
  
• 4.5.2. 决定是否迁移到数据网格的公司应该长期认真地考虑其可否推动跨组织接纳并避免不完善微服务实施的陷阱
  

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