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. 决定是否迁移到数据网格的公司应该长期认真地考虑其能否推动跨组织采用并避免不完善微服务实施的陷阱
