读数据质量管理：数据可靠性与数据质量问题解决之道15数据信托
https://img2024.cnblogs.com/blog/3076680/202411/3076680-20241125205544135-797310514.png1. 在数据平台中建立信托
1.1. 确保产品目标与业务目标保持同等
[*]1.1.1. 几十年来，数据平台被视为实现目标的手段，而不是“终极目标”
[*]1.1.1.1. 数据不被看成核心产品来构建
1.2. 寻求得当的利益相关方的反馈与认可
[*]1.2.1. 在整个产品开发过程中获得前期认可并得到迭代反馈是构建数据平台的过程中必不可少的构成部分
[*]1.2.2. 步调
[*]1.2.2.1. 向领导层倾销你的愿景
[*]1.2.2.2. 向实际用户倾销基本操作和一样平常用例
[*]1.2.2.3. 无论和谁交谈，都要以客户为中央
[*]1.2.3. 一个优秀的数据平台可以帮助技术型用户轻松高效地完成他们的工作，同时答应非技术型用户利用数据来获得丰富的洞察或制作可视化图表，而无须太多工程师和分析师的帮助
[*]1.2.4. 能够培养一个数据爱好者社区，他们一起构建、分享和学习
[*]1.2.5. 平台有潜力服务于整个公司，因此每个人都应当愿意为数据平台的成功做出贡献，即使这意味着人们在此过程中要做出一些妥协
1.3. 优先考虑长期增长和可连续性，而非短期收益
[*]1.3.1. 数据平台几乎完全是内部工具，我们发现最好的数据平台是以可连续性为前提构建的，而不是以特定功能来取胜
[*]1.3.2. 你的客户就是你的公司，而公司的成功就是你的成功
[*]1.3.3. 以短期可用性为前提的数据解决方案每每更容易启动，但随着时间的推移，这些平台的成本比以可连续性为前提构建的平台要高
[*]1.3.4. 作为更大的产品开发战略的一部分，获取一些快速成功可以帮助你获得内部认可，但是这不意味着你的计划可以是短视的
[*]1.3.5. 罗马城不是一天建成的，你的数据平台也不是
1.4. 为数据及其评估尺度设定基准指标
[*]1.4.1. 假如你无法信托数据，那么你的数据平台再好也没有用
[*]1.4.2. 组织有能力在整个数据生命周期中保障数据的高可用性和数据健康
1.5. 了解何时构建、何时购买
[*]1.5.1. 重新开始构建平台
[*]1.5.1.1. 基于开源解决方案来进行平台建立的，但如许的做法未必符合你的需求
[*]1.5.1.2. 产品需要使用敏感或机密的信息（例如财务或医疗记载），这些信息由于监管不能与外部供应商共享
[*]1.5.1.3. 数据平台需要特别的定制化才气与其他内部工具或系统配合使用，而且这些定制化设置充足特别，以至于供应商不会优先提供这些设置功能
[*]1.5.1.4. 构建与购买相比具有其他的战略价值（如业务上的竞争优势或对雇用人才有益）
[*]1.5.1.5. 当涉及解决那些对于业务来说非常特别但很关键的问题时（例如，汇总高速公路上的GPS数据），你可能需要构建自己所需的工具
[*]1.5.2. 从供应商那里购买技术（或多个支持技术）
[*]1.5.2.1. 购买通常是更有价值的选择
[*]1.5.2.2. 对于更大的、更广泛的技术挑战（如数据仓库、数据湖或数据可视化工具），购买技术通常更有意义
[*]1.5.3. 为解决更复杂、更高精度的问题，人们更加致力于研发并投资相关的工具
[*]1.5.4. 反向ETL、数据科学工作簿、行为分析，乃至是机器学习特征存储库都曾经是独特而小众的技术，现在却被广泛应用
1.6. 构建数据平台看起来可能是个艰巨的使命，但是只要采取精确的方法保障数据质量并将其规模化，你的解决方案就可能让整个组织事半功倍
2. 数据平台产品化的好处
2.1. 指导销售工作（根据潜伏客户的反馈为你提供需要关注的方向）
2.2. 推动应用程序产品门路图
2.3. 改善客户体验（帮助团队了解服务痛点，哪些方案有效，哪些无效）
2.4. 在公司范围内对数据治理与合规措施进行尺度化
3. 分配数据质量所有权
3.1. 在数据范畴，数据事故造成的不断扩大的影响范围通常被称为爆炸半径
[*]3.1.1. 爆炸半径指的是，当数据故障发生时，下游的利益相关方所经历的宕机程度
[*]3.1.2. 当数据发生故障时，从首席数据官到值班数据工程师在内的很多利益相关方都会被波及
[*]3.1.3. 数据宕时机影响到公司内部依赖数据和数据分析的所有人，而随着数据在管道中向下游传递，低质量数据造成的影响只会不断升级
3.2. 首席数据官
[*]3.2.1. 确保她的团队提供的数据能够保证同等性、准确性、相关性、可解释性和可靠性
[*]3.2.2. 假如不良数据出现在CEO面前，乃至流向了公众或其他数据消耗者，她就要担责了
3.3. 商业智能分析师
[*]3.3.1. 需要一个简便明了的数据仪表板，往返答市场、销售和运营等部门的各种问题，以帮助这些部门了解其业绩表现
[*]3.3.2. 空值和重复行是商业智能分析师的死对头，而数据宕时机让她心烦意乱，以是她很愿意采用任何可以避免数据宕机的方法
[*]3.3.3. 追溯数据上游并验证数据值的准确性是一个极其漫长的过程
3.4. 分析工程师
[*]3.4.1. 主要负责确保利益相关方能够访问和使用数据来满意他们的需求
[*]3.4.2. 精通数据构建工具dbt，并为自己能够通过建模解决几乎所有问题而感到自豪
[*]3.4.3. 要负责解释数据为何以及怎样被损坏，她通常要与数据工程和数据平台团队相助来找到根本缘故原由
[*]3.4.4. 数据可观测性是她最好的朋友
3.5. 数据科学家
[*]3.5.1. 要花费大约80%的时间清洗、整理和明白数据的方方面面
[*]3.5.2. 需要相关的工具和解决方案来简化他们的工作
3.6. 数据治理主管
[*]3.6.1. 在数据可靠性方面，主要关心整个公司的数据和指标的统一界说，并了解谁可以访问并查看哪些数据
3.7. 数据工程师
[*]3.7.1. 超出了构建数据产品，还要负责整合数据源，帮助团队做出业务决策
[*]3.7.2. 公司数据生态系统的黏合剂
[*]3.7.3. 计划可规模化的数据平台解决方案
[*]3.7.4. 确保数据摄取是可靠的
[*]3.7.5. 保障其他团队对数据平台的访问权
[*]3.7.6. 在发生数据宕机时能够快速进行修复
[*]3.7.7. 保证数据分析在整个数据组织的层面上是可连续的
3.8. 数据产品经理
[*]3.8.1. 从分析师到社交媒体经理，所有其他的数据利益相关方都要仰仗他来构建数据平台，而该平台要从多个泉源摄取数据，对数据进行统一化管理，并向各类业务用户提供可访问的数据
4. 谁来负责数据可靠性
4.1. RACI（责任人、最终责任人、被咨询人和知情人）矩阵指南
4.2. 对你的数据组织中全部的数据责任进行映射，从可访问性到可靠性都能如许操作
4.3. 责任每每落在了数据工程师和产品经理的头上
[*]4.3.1. 必须在公司对数据的需求和数据可靠性之间找到均衡
4.4. 在早期的数据组织中，这类职责每每由某个数据多面手或产品经理负担
5. 为数据质量创建责任制
5.1. 数据工程师不是数据目录
5.2. 数据团队不得不更快地做出行动，到场到数据网格的方方面面，并为更加自助式的数据平台提供助力
5.3. 每个人都试图做精确的事情，但每个人的行动也都非常快
[*]5.3.1. 在下游产生真正的运营问题
[*]5.3.1.1. 冗余的“交通管制”带来的低效循环
[*]5.3.1.2. 更糟糕的数据质量
[*]5.3.1.3. 浪费时间去解决由于分析师使用了不合适或有问题的数据而产生的问题
[*]5.3.1.4. 降低了组织内部对数据的信托度
[*]5.3.1.5. 增加了数据宕机时间
5.4. 当你不信托数据，或者数据可靠性较低时，数据组织每每会在猜测中人为增加误差范围
6. 均衡数据可访问性与数据信托
6.1. 数据发现是一种及时了解分布式数据资产健康状况的重要新方法，它也是现代数据栈的基本构成部分
6.2. 数据发现根据一组特定消耗者怎样摄取、存储、聚合和使用数据，提供了对数据在特定范畴的动态解读
6.3. 可以取代现代数据目录，转而提供分布式、及时的跨范畴数据洞察，并同时满意会合式的数据治理尺度
6.4. 数据治理的尺度和工具同样是跨范畴联合的，以支持更高的数据可访问性和互操作性
6.5. 数据发现可以及时了解数据的当前状态，而不是其理想或“编目”状态
6.6. 当数据团队采取分布式数据治理的方法，要求不同的数据所有者将数据看成产品并对其负责时，数据发现会非常有用
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]