1.1. 机器学习正在变得普遍

1.1.1. 机器学习、数据科学、数据工程以及机器学习工程的界限正在变得模糊，并且在各个组织内部都形态各异

1.2. 现状

1.2.1. 某些组织中，机器学习工程师负责处理为机器学习应用程序处理收集到的数据，有时甚至会形成独立且平行工作的数据组织来处理整个机器学习应用程序生命周期的数据

1.2.2. 在另一些组织中，数据工程师负责全部的数据处理流程，然后向机器学习工程师交付模型训练用的数据

1.3. 了解典型的机器学习原理和深度学习基础是很有帮助的

1.3.1. 了解基础知识可以很大程度地帮助数据工程师来和数据科学家共同构建数据产品

1.4. 了解的机器学习领域

1.4.1. ①监督学习、非监督学习、半监督学习的差别

1.4.2. ②分类和回归技术的差别

1.4.3. ③处理时间序列数据的不同手段

1.4.3.1. 时间序列分析

1.4.3.2. 时间序列预测

1.4.4. ④基础的机器学习知识可以帮助发现机器学习技术是否合适，以及界定所需数据的边界

1.4.4.1. 当在“典型的”方法（逻辑回归、基于树的学习、支持向量机）和深度学习之间进行选择时，尽管可能是杀鸡用牛刀，但数据科学家还是常常立马选择深度学习

1.4.5. ⑤什么时候用自动机器学习(AutoML)

1.4.6. ⑥用于结构化和非结构化数据的数据整理技术有哪些？

1.4.7. ⑦如何编码分类数据和各种类型数据的嵌入？

1.4.8. ⑧批量学习和在线学习的差别

1.4.9. ⑨数据工程生命周期和机器学习生命周期在公司内怎样产生交集？

1.4.10. ⑩什么时候用GPU比用CPU更好？

1.4.10.1. 硬件选型取决于需要解决的机器学习问题的种类、使用的技术以及数据集大小

1.4.11. ⑾批处理和流数据在机器学习模型训练中的不同应用

1.4.11.1. 批处理数据更适合离线模型训练

1.4.11.2. 流数据更适合在线学习

1.4.12. ⑿数据级联是什么

1.4.13. ⒀机器学习的结果是实时返回的还是批量返回的

1.4.13.1. 一个批处理的讲话字幕生成模型会处理语音样本并且通过API调用的方式批量返回文本

1.4.13.2. 一个产品推荐模型可能需要实时运作来支持客户和在线零售网站的互动

1.4.14. ⒁对于结构化和非结构化数据的运用

1.4.14.1. 用神经网络聚类表格（结构化）客户数据

1.4.14.2. 识别图像（非结构化）

1.4.15. ⒂本地训练、集群训练或者边缘训练的适用场景

2.1. 为机器学习提供数据服务和为分析提供数据服务并列讨论的原因是它们的管道和流程非常相似

2.2. 文件交换

2.2.1. 文件交换在数据服务的过程中无所不在

2.2.1.1. 数据被处理并生成文件传送给数据消费者

2.2.2. 文件可以有各种用途

2.2.2.1. 数据科学家可能加载客户消息的文本文档（非结构化数据）来分析客户投诉的情绪

2.2.3. 因素

2.2.3.1. 用例

2.2.3.1.1. 业务分析

2.2.3.1.2. 运营分析

2.2.3.1.3. 嵌入式分析

2.2.3.2. 数据消费者的数据处理流程

2.2.3.2.1. 需要通过文件而不是数据共享提供数据服务，因为数据消费者无法使用数据共享平台

2.2.3.3. 储存中单个文件的大小和数量

2.2.3.4. 谁在访问这个文件

2.2.3.5. 数据类型

2.2.3.5.1. 结构化

2.2.3.5.2. 半结构化

2.2.3.5.3. 非结构化

2.2.4. 提供文件的最简单办法是用邮件发送单个Excel文件

2.2.4.1. 文件偏差不可避免

2.2.4.2. 如果文件已经通过邮件发送出来了，那么收回的手段就很有限了

2.2.5. 如果想要维护的文件版本连续和一致，那么最好采用Microsoft 365或者Google Docs这样的协作平台

2.2.6. 仅靠传文件是很难扩展功能的，而且需求最终会膨胀到超出简单的云文件存储

2.2.6.1. 如果文件又大又多，就需要考虑对象存储了

2.2.6.2. 对象存储可以存储任何类型的二进制大文件，特别适合半结构化或者非结构化文件

2.2.6.3. 如果需要稳定的文件供应，就要用数据湖

2.2.7. 通过选择对象存储（数据湖）进行的、以数据共享为基础的数据传输，明显要比单纯的点对点文件传输更有扩展性和效率

2.3. 数据库

2.3.1. 数据库是为分析和机器学习提供数据服务的关键层

2.3.1.1. 管理数据服务层的任务一般会安排给数据工程师，包括性能和成本的管理

2.3.1.2. 存算分离的数据库与那些固定本地部署的基础设施相比可以说是做了些许的优化

2.3.2. 数据库通过模式来维护数据的顺序和结构

2.3.3. 数据库也能针对表、列、行提供细粒度的权限控制，允许数据库管理员为不同角色创建复杂的访问控制规则

2.3.4. 数据库可以为大型、计算密集型查询和高查询并发性提供高服务性能

2.3.5. BI系统通常会利用源数据库的数据处理能力，但是这两个系统中处理之间的界限有所不同

2.3.6. 查询下推的计算模型

2.3.7. 数据科学家也会连接数据库、提取数据、执行特征工程和选择

2.3.7.1. 然后将转换后的数据集输入到机器学习模型

2.3.7.2. 这个离线模型训练好后就可以产生预测结果了

2.3.8. 性能的关注点：延迟、查询性能和并发

2.3.8.1. 从流中直接获取数据的系统可以降低数据延迟

2.3.8.2. 多数据库架构使用了SSD或者内存缓存来增强查询性能和并发性，以满足高要求的嵌入式分析用例

2.3.8.3. Snowflake和Databricks这样的数据平台开始允许分析师和数据科学家在单个环境下工作，并在同一套界面下提供了SQL编辑器以及数据科学notebook

2.3.8.3.1. 存算分离，所以分析师和数据科学家可以在互不影响的状态下使用底层数据

2.3.8.3.2. 将允许向利益相关者提供高吞吐量和快速交付的数据产品

2.4. 流式系统

2.4.1. 发散指标(emitted metric)

2.4.2. 运营分析数据库在这个领域变得越来越重要

2.4.2.1. 可以运行大范围历史数据查询，包括查询最新的当前数据

2.4.2.2. 一个必要的设计点是将OLAP数据库的特点和流处理系统相结合

2.5. 联邦查询

2.5.1. 联邦查询越来越受欢迎，人们意识到它的分布式查询虚拟引擎在提供查询服务时不需要解决OLAP系统中集中化的数据带来的问题

2.5.1.1. Trino和Presto这样的OSS选项以及诸如Starburst这样的完全托管服务

2.5.2. 如果联邦查询需要接触生产环境的源系统，则一定要保证联邦查询不会消耗过多的源系统资源

2.5.3. 当需要数据分析具有灵活性或者使用处在严格控制下的源数据时，联邦查询非常适合

2.5.3.1. 联邦查询是访问权限和规章都很严苛的条件下的优秀选项

2.5.4. 联邦查询能够通过点对点的查询进行探索性分析，将不同的系统数据混合的同时又避开了搭建数据管道或者ETL的复杂性

2.5.5. 选型决定

2.5.5.1. 是联邦查询就能满足眼前的需求，还是需要将所有需要的数据都获取到并且通过OLAP数据库或者数据湖将其中心化

2.5.6. 联邦查询同时提供源系统的只读权限，这是非常好的一点，尤其是应对你不想提供文件、数据库访问权限、或者数据转储的场景

2.5.6.1. 终端用户只读取他们需要看到的那版数据

2.6. 数据共享

2.6.1. 任何组织间或者大组织中部门间的数据交换行为都可以看作数据共享

2.6.2. 数据共享特指通过云环境中的大规模多租户存储系统进行共享

2.6.3. 数据共享通常会将数据服务转换成安全和访问控制问题

2.6.4. 现实中的查询常常由数据消费方（分析师和数据科学家）而不是由发布数据的工程师处理

2.6.5. 无论是在组织内部的数据网格中提供数据服务、向公众提供数据服务，还是向合作伙伴提供数据服务，数据共享都是一个引人注目的数据服务模式

2.7. 语义和度量层

2.7.1. 当输入低质量的数据或查询时，强大的查询引擎只会快速返回不准确的结果

2.7.2. 好的数据质量依赖数据自身的特征，另外还需要通过各种技术过滤或改进不良数据

2.7.3. 高质量查询是具有适当的逻辑，可以准确回答业务问题的查询

2.7.3.1. 构建高质量的ETL查询和报告是费时费心的

2.7.3.2. 很多工具可以自动化该构建过程，同时又能促进一致性、可维护性和持续改进

2.7.4. 度量层是维护和计算业务逻辑的工具

2.7.4.1. 语义层在概念上和度量层极为相似，而无头BI是另一个密切相关的术语

2.7.5. Looker的LookML工具允许用户定义虚拟的、复杂的业务逻辑

2.7.5.1. Looker更多关注查询和报告

2.7.6. dbt允许用户定义复杂的SQL数据流，其中囊括许多查询和业务指标的标准定义，这项功能很像Looker

2.7.6.1. dbt是为分析工程师而生的功能强大的数据管道编排工具

2.8. 利用notebook提供数据服务

2.8.1. 都可能会使用notebook。在撰写本书时，最流行的notebook是Jupyter Notebook，以及它的下一代JupyterLab

2.8.1.1. Jupyter是开源的，可以托管在笔记本计算机、服务器或各种云托管服务上

2.8.2. 在notebook中，所有的连接都是使用相应的内置库或外部库来创建的，以便从某个路径加载文件、连接到某个API端点，或对某个数据库进行ODBC连接

2.8.3. pandas是一个常用的Python库，用于操作和分析数据，常用于将数据（例如CSV文件）加载到Jupyter Notebook中

2.8.4. 凭证处理

2.8.4.1. 对notebook和数据科学代码中的访问凭证的不当处理是重大的安全风险

2.8.4.2. 数据工程师需要负责审核数据科学代码采用的安全措施，并与数据科学家合作进行改进

2.8.4.3. 数据工程师应该为处理凭证设定标准

2.8.4.4. 凭证不能直接嵌入代码中，数据科学家需要使用凭证管理器或CLI工具来管理访问权限

2.8.5. 当数据集的大小超过本地机器的可用内存时

2.8.5.1. 改用基于云的notebook，可以灵活地扩展底层存储和内存

2.8.5.2. 考虑分布式执行系统，基于Python的常用选项有Dask、Ray和Spark

2.8.5.3. 使用一套开源的端到端机器学习工作流工具，如Kubeflow和MLflow，可以分别在Kubernetes和Spark中轻松扩展机器学习工作负载

2.8.6. 数据工程师和机器学习工程师是促进向可扩展云基础设施转移的重要力量，具体的分工取决于组织的实际情况

2.8.7. notebook用于“小微项目”的上线，完整生产流程用于高价值的项目

3.1. 将数据从OLAP数据库供应回源系统

3.1.1. 数据工程师可能从CRM中拉取客户和订单数据，并存储在数据仓库中

3.1.2. 数据可以训练出一个线索评分模型，模型的产出又返回到数据仓库中

3.2. 好的数据产品需要减少与终端用户的摩擦

3.3. 用反向ETL将评分后的线索加载回CRM中是最简单和最好用的方法

3.3.1. 双向加载和转换(Bidirectional Load and Transform，BLT)

3.4. 反向ETL从数据工程生命周期的输出端获取处理过的数据，并将其反馈回源系统中

3.5. 反向ETL本质上会产生反馈循环

3.5.1. 要小心利用反向ETL，需要密切监控并防止失控