1. 使用场景
1.1. 为分析和BI，也就是统计分析、报表和仪表板提供数据服务
-
1.1.1. 是数据服务最为常见的目标
-
1.1.2. 这些概念的提出早于IT和数据库，但是它们对于了解业务、组织和财务流程的利益相关者来说仍然至关重要
1.2. 为机器学习应用程序提供数据服务
-
1.2.1. 机器学习完全依赖于高质量的数据
-
1.2.2. 数据科学家和机器学习工程师需要在数据工程师的帮助下来获取、转化以及交付必要的数据，从而训练模型
1.3. 为反向ETL提供数据服务
-
1.3.1. 反向ETL是一种将数据回传给数据源的过程
-
1.3.2. 反向ETL和BI以及机器学习有着深度的共生关系
2. 常见关注点
2.1. 信任
-
2.1.1. 人们需要相信你提供的数据
-
2.1.2. 花20年建立的名誉可能只需要5分钟就可以毁掉。如果你明白这一点，你就会换种方式做事情。
-
2.1.2.1. 沃伦·巴菲特(Warren Buffett)
-
2.1.3. 信任一旦丢失就极难挽回
-
2.1.3.1. 不可避免的结局是业务方不能发挥数据的潜在价值，数据团队也会丢失信誉（甚至被解散）
-
2.1.4. 信任是提供数据服务的根本关注点
-
2.1.4.1. 终端用户需要信任他们接收的数据
-
2.1.4.2. 失去信任通常是数据项目无声的表钟，即使这个项目直到几个月或几年后才正式取消
-
2.1.5. 利用数据验证流程以及数据可观测性流程，同时与利益相关者一起目视检查和确认数据有效性
-
2.1.5.1. 数据验证使用数据分析方法来保证数据可以忠实反映财务信息、客户行为以及销售记录等信息
-
2.1.5.2. 数据可观测性提供了一个观测数据和数据处理的持续视图
-
2.1.6. SLA和SLO也是工程师建立终端用户和上游利益相关者信任的必要手段
-
2.1.6.1. 当用户开始依赖数据来完成业务需求时，会要求使用的数据有持续的可用性以及数据工程师保障的最新状态
-
2.1.6.2. 高质量的数据在没有达到预期内的可用性时很难发挥辅助商业决策的价值
-
2.1.6.3. SLA和SLO也可以采用正式或者非正式的数据契约形式
-
2.1.6.4. SLA都给了用户对于数据产品的预期
-
2.1.6.5. SLO是SLA的关键部分，阐述了用于衡量契约的方法
-
2.1.7. 一定要确保各方的预期是清晰的，并且你有能力验证能否满足约定的SLA和SLO
-
2.1.8. 对SLA达成一致是不够的
-
2.1.8.1. 持续的沟通才能维持一个好的SLA：对可能对SLA和SLO预期有影响的事项进行沟通，并提供补救和改进措施
2.2. 用例是什么，用户又是谁
-
2.2.1. 需要了解你的用例和用户、产出的数据产品以及如何提供数据服务（是否自助服务）、数据定义和逻辑，以及数据网格
-
2.2.2. 数据服务层是为了数据的使用
-
2.2.2.1. 数据在决策中的作用才是核心
-
2.2.3. 数据的用例远远超出了查看报告和仪表板的范围
-
2.2.3.1. 一份数据往往被用于多个用例
-
2.2.4. 高质量、高影响力的数据自然而然地会吸引很多很有趣的用例
-
2.2.5. 尽量挑选有着最高ROI的用例
-
2.2.5.1. 数据工程师喜欢纠结于他们搭建的系统的技术实现细节，而忽略目的
-
2.2.5.2. 当工程师能够以价值和用例为导向时，产出就能更有价值和效率
> 2.2.5.2.1. 很多工程师只想做最擅长的事情：搞工程
-
2.2.6. 当开启一个新的数据项目时，倒排工序是很有必要的
-
2.2.7. 问自己的一些问题
-
2.2.7.1. 谁会使用这些数据？怎么用？
-
2.2.7.2. 利益相关者有什么期望？
-
2.2.7.3. 怎么和数据利益相关者（数据科学家、分析师、业务用户）合作，更好地了解这些数据的用途？
-
2.2.8. 在开展数据工程的时候，一定要从用户及其用例入手
-
2.2.8.1. 在了解他们的期望和目标后，就会更容易产出优秀的数据产品
2.3. 数据产品
-
2.3.1. 数据产品的良好定义是能够通过使用数据促成最终目标的产品。
-
2.3.1.1. D.J.Patil
-
2.3.2. 数据产品不是凭空产生的
-
2.3.2.1. 开发数据产品像是一项需要全身心投入的运动，在技术的框架下混合了产品和业务
-
2.3.2.2. 核心利益相关者参与数据产品的开发是非常重要的
-
2.3.2.3. 一个好的数据产品应该有着正反馈循环
> 2.3.2.3.1. 更多的数据产品使用产生更多的有用数据，产品也因此得以改进
-
2.3.3. 在大多数公司，数据工程师会负责除了终端用户操作外的数据产品全流程
-
2.3.3.1. 优秀的数据工程师会尽力去了解提供给直接用户（比如数据分析师、数据科学家或公司外部客户）的产物
-
2.3.4. 当创造一个数据产品时，应该从“完成任务”的角度思考
-
2.3.4.1. 用户为了“完成任务”才“雇用”数据产品
-
2.3.4.2. 常犯的错误是在不了解终端用户的需求或者没有产品市场调研的情况下盲目开发
-
2.3.5. 做人人都爱用的数据产品是很难的
-
2.3.5.1. 没用的特性和失信的数据会破坏数据产品的采用
-
2.3.5.2. 需要专注在数据产品的采用和利用上，并且愿意做出令用户满意的调整
2.4. 是否用自助服务
-
2.4.1. 让用户可以自己构建数据产品
-
2.4.2. 落地难度高，数据自助服务项目容易虎头蛇尾
-
2.4.3. 如果面向的用户是高管级别的，他们想知道业务运行情况，那么一个清晰且有着可操作指标的预定义仪表板往往就足够了
-
2.4.3.1. 如果报告揭示了更多问题，那么他们可能会找分析师来深挖数据
-
2.4.4. 成功搭建自助服务数据项目从找对受众开始，识别自助服务用户和他们要做的“工作”
-
2.4.5. 具备数据相关技术背景的业务主管，他们就很适合自助服务，他们可能想要自己对数据进行切片，而又不重拾SQL技能
-
2.4.6. 构建好的数据自助服务要确定如何为特定用户提供数据服务
-
2.4.7. 更多的数据带来更多的问题，而这又需要更多的数据来解决
-
2.4.8. 需要理解灵活性和范围之间的微妙平衡，这将有助于你的受众找到价值和洞见，而不会产生错误的结果和混乱
2.5. 数据定义和逻辑
-
2.5.1. 组织中利用数据看重的是它的准确性和可信度
-
2.5.1.1. 数据的准确性不仅仅是对源系统中事件值的忠实再现
-
2.5.1.2. 数据准确性包括了准确的数据定义和逻辑，这两个要素必须融入数据的全生命周期，从源系统到数据管道，再到BI工具等
-
2.5.2. 数据定义指的是数据在一个组织中的共识
-
2.5.3. 数据逻辑规定了指标计算公式
-
2.5.3.1. 合适的逻辑必须融汇数据定义以及完整的统计方法
-
2.5.3.2. 要计算客户流失率指标，就需要定义谁是客户
-
2.5.3.3. 要计算净利润，就需要一系列的规则来规定从收入总额扣除哪些支出
-
2.5.4. 数据定义和逻辑的存在经常被认为是理所当然的，并且在组织内以组织知识(institutional
knowledge)的形式传播
-
2.5.5. 组织知识有着自己的生态，很大程度上会以“奇闻”取代数据推动的洞见、决策和行动
-
2.5.6. 数据定义体现为多种形式，有些是显式的，但是多数是隐式的
-
2.5.6.1. 隐式是指为查询、仪表板或者机器学习提供数据服务时，数据和指标总是可以被持续准确地展示
-
2.5.7. 语义层可以整合业务定义和逻辑，使其可复用
-
2.5.7.1. 一次建设，全局通用
-
2.5.7.2. 范式是建设指标、计算规则和逻辑的面向对象思想的体现
2.6. 数据网格
-
2.6.1. 一种日益流行的数据服务提供方式
-
2.6.2. 数据网格从根本上改变了组织内部的数据服务提供方式
-
2.6.3. 与孤立的数据团队服务于内部成员不同，数据网格需要每个业务领域的团队同时担负起去中心化的、点对点的数据服务的责任
-
2.6.3.1. 团队要对其他团队的数据消费负责
-
2.6.3.2. 数据必须都是开箱即用的
