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. 当数据团队采取分布式数据治理的方法，要求不同的数据所有者将数据当作产品并对其负责时，数据发现会非常有用
