读数据工程之道：设计和构建健壮的数据系统29分析

1. 合作角色

1.1. 数据分析师

1.2. 数据科学家

1.3. MLOps/机器学习工程师

1.4. 业务侧

• 1.4.1. 数据或非技术的利益相关者、经理和高管

1.5. 数据工程师更多的是在支持这些利益相关者的工作，不一定对数据的最终使用方式负责

1.6. 数据工程师负责的是产出高质量的数据产品

• 1.6.1. 在数据服务阶段，数据工程师的一项重要任务是将职责和工作内容分离

1.7. 数据工程走到了交付阶段后会产生反馈循环

• 1.7.1. 数据很少以静态存在，外部环境会影响到被获取和提供的数据，以及被二次获取和提供的数据

1.8. 采用数据网格会在很大程度上重新分配团队职责，每个领域的团队都需要承担各种提供数据服务的任务

2. 底层设计

2.1. 数据服务是数据工程生命周期底层设计的最后一部分内容

• 2.1.1. 数据生命周期是一个闭环，在环中的一切都是一脉相承的

• 2.1.2. 数据工程师需要一直寻找底层设计框架下能够帮助数据产品提升的方法

2.2. 数据是一个无声的杀手

• 2.2.1. 提供数据服务是确保交付到终端用户手中的数据质量的最后一道屏障

2.3. 安全

• 2.3.1. 数据服务是最能体现数据安全必要性的一环

• 2.3.2. 对人和系统都要一如既往地推行最小权限的原则，只提供仅供当前工作所需的访问

• 2.3.2.1. 切忌对任何个人或任何服务给予完全开放许可

• 2.3.3. 提供数据服务一般只涉及只读权限，除非人或程序需要更新被查询系统中的数据

• 2.3.3.1. 用户访问权限要限定在对特定数据库和数据集的只读权限，除非他们的工作必须使用更高级的权限，如写入或更新访问

• 2.3.3.2. 权限控制可以通过为用户组分配具有某些IAM角色（即分析师组、数据科学家组）或自定义IAM角色来完成

• 2.3.4. 访问控制应该尽可能地细化，并在不需要时收回

• 2.3.5. 访问控制在多租户环境中提供数据服务时是至关重要的

• 2.3.5.1. 确保用户只能访问他们自己的数据

• 2.3.5.2. 过有过滤条件的视图来调整查询结果，从而减弱公用表的安全风险

• 2.3.5.3. 工作流中使用数据共享，这样就可以对数据使用方有只读粒度控制

• 2.3.6. 要检查数据产品的使用频率，以及考虑停止共享一些无用的数据产品

• 2.3.6.1. 如果数据产品没有在使用，就去问问用户是否还需要它们

• 2.3.6.2. 如果不需要，那就把该数据产品停掉，可以减少一个安全漏洞

• 2.3.7. 访问权限控制和安全不应该是数据服务的障碍，恰恰相反，它们是推动数据服务的关键因素

• 2.3.7.1. 由于安全措施没有得到正确落实，有用的数据可能很少能被访问

• 2.3.7.2. 细致、健壮的访问权限控制意味着可以进行更有价值的数据分析和机器学习，同时对企业及其客户也是一种保护

2.4. 数据管理

• 2.4.1. 关注点是确保人们能够获得高质量和值得信赖的数据

• 2.4.2. 信任是数据服务中最关键的因素

• 2.4.2.1. 如果人们信任他们的数据，就会使用它

• 2.4.2.2. 不受信任的数据会被闲置

• 2.4.2.3. 一定要收集用户的反馈，使数据信任和数据改进走向良性循环

• 2.4.2.4. 当用户与数据交互时，要让他们能够报告问题并提出改进

• 2.4.2.5. 在响应改进需求时，也要积极地与用户进行沟通

• 2.4.3. 使用数据脱敏手段可以向终端用户提供合成、打乱或匿名的数据

• 2.4.3.1. “假”数据集应该足以让分析师或数据科学家从数据中获得必要的有用信息，且可以防止暴露现实世界的实体

• 2.4.3.2. 在一些强力的数据处理方法下，许多数据集可以被实名或者逆向工程，但这些脱敏手段或多或少地降低了数据泄露的风险

• 2.4.4. 将语义层和度量层纳入数据服务层，同时建立可以正确表达业务逻辑和定义的严谨数据模型，能够为分析、机器学习、反向ETL或其他服务用途提供可信单一数据源

2.5. DataOps

• 2.5.1. 数据管理，也就是数据质量、数据治理和数据安全，都应该在DataOps的监控下

• 2.5.2. 监控的内容

• 2.5.2.1. 数据健康程度和数据不可用时间

• 2.5.2.2. 用来提供数据服务的仪表板、数据库等系统的延迟

• 2.5.2.3. 数据质量

• 2.5.2.4. 数据以及系统的安全性和访问权限

• 2.5.2.5. 提供的数据和模型的版本

• 2.5.2.6. 达到SLO标准的可用时间

• 2.5.3. 流行的数据可观测性工具旨在减少数据不可用时间和提高数据质量

• 2.5.4. 可观测性工具可以从数据领域跨越到机器学习领域，支持对模型和模型性能的监控

• 2.5.5. 传统的DevOps监控对DataOps也很重要

• 2.5.6. 数据工程生命周期的每个阶段都要对代码进行版本控制并将代码部署可操作化

• 2.5.7. 使用多阶段的部署（开发、测试、生产）分析报告和模型

2.6. 数据架构

• 2.6.1. 在提供数据服务阶段，用户反馈循环要快速且紧密

• 2.6.2. 应该让用户能够尽快访问所需数据

2.7. 编排

• 2.7.1. 数据服务是数据工程生命周期的最后阶段

• 2.7.2. 编排不仅仅是一种将复杂工作变得有组织和自动化的方式，也是协调跨团队数据流的手段，以便在承诺的时间内将数据提供给消费者

• 2.7.3. 谁来负责数据任务编排是一个关键的组织决策

• 2.7.3.1. 非集中式方法让小型团队能够管理自己的数据流，但增加了跨团队协调的负担

• 2.7.3.2. 团队不能只管理单一系统内的数据流，而需要直接触发属于其他团队的DAG或任务，各团队必须跨系统传递消息或查询

• 2.7.3.3. 集中式方法意味着工作更容易协调，但把关也必须存在，以保护唯一的生产环境

• 2.7.3.4. 集中式的编排需要高标准、自动化的DAG测试和对系统的把关

2.8. 软件工程

• 2.8.1. 许多向终端用户提供数据服务的方法涌现出来，而数据工程师的重点变成了了解这些系统如何工作以及如何交付数据

• 2.8.2. 数据工程师需要负责的另一部分任务是了解代码和查询对存储系统的性能影响

• 2.8.3. 基础设施即代码的兴起意味着之前专注写代码的角色正在转向构建可以支持数据科学家和分析师的系统

• 2.8.3.1. 数据工程师可能会负责建立CI/CD管道并为数据科学家和分析师的数据团队建立数据流程

• 2.8.3.2. 数据工程师也会培训和支持这些数据团队使用数据工程师所建立的Data/MLOps基础设施，以便这些数据团队走向自给自足

• 2.8.4. 对于嵌入式分析，数据工程师需要与应用程序开发人员合作，以确保查询能够快速且经济有效地返回

• 2.8.4.1. 应用程序开发人员负责面向用户的前端代码，数据工程师负责让前端收到准确的数据

• 2.8.5. 优秀的数据工程师总是乐于接受新的反馈，并不断改进

3. 分析

3.1. 最常见的数据服务用例是分析

3.2. 分析指的是发现、探索、识别以及让数据中的关键洞见和模式变得可见

3.3. 分析是通过统计方法、报告和BI工具等进行的

3.4. 作为数据工程师，了解各种工具和分析方法是完成工作的关键

4. 业务分析

4.1. 业务分析是一门科学，也是一门艺术

• 4.1.1. 业务分析会运用历史和新产生的数据来做策略性的且可执行的决策

4.2. 通过统计数据和趋势分析以及领域专家和人为判断的共同配合，来做出会影响长期业务走向的决策

• 4.2.1. 好的分析师往往能够参与到业务当中，并且可以深入数据回答问题，解密隐藏或者反直觉的趋势和洞见

• 4.2.2. 可以和数据工程师一同来为数据质量、可靠性问题以及新的数据集需求提供参考意见

• 4.2.3. 数据工程师则需要负责落地这些参考意见并且为分析师提供新的数据集

• 4.2.3.1. 需要考虑对现有和未来数据的各种潜在应用

• 4.2.3.2. 数据工程师必须使用最合适的后端技术方案来为业务分析提供数据服务

4.3. 仪表板

• 4.3.1. 能简明扼要地将反映组织运行情况的几个核心指标展示给决策层

• 4.3.1.1. 通过可视化（图表或热力图等）​、汇总统计，甚至是单个数字来展示

• 4.3.2. 最高决策层会看顶层仪表板，而他们的直属下级会看带有特定指标、KPI或者OKR（Objective and Key Result，目标和关键成果）的仪表板

• 4.3.3. Tableau、Looker、Sisense、Power BI，以及Apahe Superset/Preset

4.4. 报告

• 4.4.1. 业务利益相关者会要求分析师创建报告

• 4.4.2. 使用报告的目的是利用数据得出洞见和决策

• 4.4.3. 调查结果被汇总在一份报告中，并在仪表板所在的同一BI工具中发布

4.5. 专项分析

• 4.5.1. 深入探究某个潜在的问题并产出洞见，这就是专项分析的一个案例

• 4.5.2. 调查报告通常以专项需求作为起始

• 4.5.3. 如果专项分析的产出有影响力，那么就会演变成一个报告或仪表板

4.6. 报告、专项分析和仪表板用的都是类似的工具，比如Excel、Python、基于R的notebook、SQL查询等

4.7. 业务分析数据常常以批处理模式从数据仓库或者数据湖供应

4.8. 为用例提供数据服务时，不同的更新频率经常混合在一起使用

• 4.8.1. 从上游获取数据的频率是下游所使用数据更新频率的上限

• 4.8.2. 如果数据是由流式应用产生的，那么数据就应该通过流式获取，即使下游使用批处理方式做数据的处理和服务也应如此

4.9. 在数据湖或者数据仓库中运行查询

• 4.9.1. 优点是可以更好发挥OLAP数据库的能力

• 4.9.2. 缺点是成本、权限控制，以及时延方面的问题

5. 运营分析

5.1. 运营分析是用数据来进行即时的操作

• 5.1.1. 在工厂部署实时分析

• 5.1.1.1. 使用现成的云机器视觉工具来自动实时识别次品

5.2. 运营分析与业务分析=即时操作与可供执行的洞见

• 5.2.1. 随着流数据和低延迟数据更加普遍，用运营分析的方法解决业务分析的问题才是正确的思路

• 5.2.2. 数据架构会变成可以让“热到发烫”的低时延流数据和暖数据共存一处

5.3. 差异体现在时间上：业务分析用的数据是从更长远的角度看待所考虑的问题

• 5.3.1. 秒级的数据更新是很好的，但是并不会实质性地影响分析结果

• 5.3.2. 运营分析则恰恰相反，数据更新的实时程度对解决时下发生的问题有很大的影响

5.4. 例子是应用程序的实时监控

• 5.4.1. 如果系统达到某个阈值，监控系统也可以通过短信、群聊通知和邮件发送告警

5.5. 正确的行动才会产生影响力和价值

• 5.5.1. 没有促成行动的实时数据只会变成一团乱麻

5.6. 从长远看，流数据会逐渐取代批处理数据

• 5.6.1. 未来十年的数据产品更有可能是流优先，并且有能力无缝衔接历史数据

• 5.6.2. 实时采集的数据仍然可以按需求以批处理的形式来消费和处理

6. 嵌入式分析

6.1. 业务分析和运营分析更多关注于组织内部，而面向外部的，也就是嵌入式分析成了最新的趋势

6.2. 向终端用户提供更多的分析结果

• 6.2.1. 数据应用程序，多数在应用程序内部嵌入了分析仪表板

• 6.2.2. 面向终端用户仪表板的嵌入式分析可以给用户提供他们和应用相关联的关键指标

6.3. 数据工程师一般不会去开发嵌入式分析的前端

• 6.3.1. 专业的应用程序开发人员来做这项工作

6.4. 数据工程师要维护嵌入式分析使用的数据库，因此需要了解嵌入式分析的速度和时延要求

6.5. 提高嵌入式分析的性能需要解决三个问题

• 6.5.1. 用户都希望获得低延迟的数据

• 6.5.1.1. 应用程序的用户不会像公司内的分析师那样容忍批处理

• 6.5.2. 用户想要更高的查询效率

• 6.5.3. 支持高并发就是非常关键的

• 6.5.3.1. 需要支持发生在多个仪表板和众多用户中非常高的查询率

6.6. 转向新一代拥有快速查询、高并发，以及近实时更新并且易用（例如基于SQL的分析）的高性能数据库