1.1.         数据收集和清洗是生产管道中的第一步

1.1.1.           数据转换和测试则在生产管道中解决数据质量问题

1.2.         在收集数据时，管道的任何地方可能都没有入口点重要，因为入口点是任何数据管道中最上游的位置

1.3.         入口点定义为来自外部世界的数据进入数据管道的初始接触点

1.4.         在入口点的数据是最原始的

1.4.1.           包含了其所建模的外部世界的所有典型噪声和不规则性

1.4.2.           数据可能来自应用程序或服务日志、点击流源或实时传感器

1.4.3.           数据可能是高度异构的

1.4.3.1.            结构化的

1.4.3.2.            非结构化的

1.4.3.3.            会导致数据未来在管道中出现问题

2.1.         应用程序日志是指对某些软件应用程序进行操作时所产生的数据

2.1.1.           带有时间戳的事件描述

2.1.2.           可能会发现应用软件产生的错误或警告消息

2.1.3.           应用程序日志中的内容包括什么是由该应用程序的开发人员来决定的

2.2.         应用程序可以是面向客户的或内部的，而操作可以是用户发起的，也可以是编程式自动产生的

2.3.         要素

2.3.1.           结构

2.3.1.1.            美国信息交换标准码(American

Standard Code for Information Interchange，ASCII)

2.3.1.2.            二进制格式

2.3.1.3.            简单的可序列化文本

2.3.2.           时间戳

2.3.2.1.            大多数应用程序日志文本是离散事件，带有描述，由\n字符分隔

2.3.2.2.            时间戳应该是高度标准化的，通常采用ISO标准格式(yyyy-mm-ddThh:mm:ss[.mmm])或其他类似的格式

2.3.3.           日志级别

2.3.3.1.            会使用级别来大致编码每个事件的日志类型

2.3.3.2.            常用的日志级别

2.3.3.2.1.             INFO（信息）：该日志包含的是纯粹的描述性信息

2.3.3.2.2.             WARN（警告）：该日志是应用程序警告，但不是失败错误

2.3.3.2.3.             ERROR（错误）：该日志代表应用程序中的编程故障

2.3.4.           目的

2.3.4.1.            应用程序日志并不会被随意收集

2.3.4.2.            应当确定日志在某些情况下是有用的才会进行推送

2.3.5.           诊断

2.3.5.1.            出于诊断目的而收集日志数据，那么问题的答案或许能在非常具体的WARN或ERROR级别的日志中找到

2.3.5.1.1.             涉及诊断标准，并通过智能收集和解析日志来回答

2.3.5.2.            收集的绝大多数内容可能与你现在遇到的特定问题无关

2.3.6.           审计

2.3.6.1.            审计日志记录就是记录应用程序中的事件历史

2.3.6.2.            许多INFO级别的日志对于审计来说很有用

2.3.6.3.            审计的力量通常来自应用程序会话的大量聚合

3.1.         你自己的应用程序不可能完成所有事情

3.1.1.           这就是为什么我们要将某些功能分发给不同的应用程序

3.2.         执行此操作的标准方法是使用应用程序编程接口(Application Programming Interface，API)

3.3.         API是两个程序之间的中介，它们需要特定格式的请求才会提供响应

3.3.1.           这些响应只是半结构化数据

3.4.         除了应用程序日志之外，你还可以存储从API端点提取的数据

3.5.         要素

3.5.1.           结构

3.5.1.1.            API响应对象是可以序列化的对象

3.5.1.1.1.             经常看到的一种对象格式（尤其是在Web API中）是JSON

3.5.1.1.2.             JSON对象非常灵活，但它们会在一些重要方面受到结构的约束

3.5.1.1.3.             其他API响应类型具有类似的格式

3.5.1.1.4.             HTTP响应规范，如HTTP/1.1，它也可能在HTTP请求或响应正文中包含JSON或XML

3.5.2.           响应代码

3.5.2.1.            最常接触到的是HTTP状态码(200 OK、404 Not Found、500Internal Server Error)

3.5.2.2.            HTTP 500响应的比率是服务器是否出现中断的关键指标

3.5.2.3.            其他传输协议的SOAP

API

3.5.3.           目的

3.5.3.1.            API用例的数量是非常庞大的，因此我们无法预测一个人可能遇到的所有用例

3.5.3.2.            如果我们对服务器错误率感兴趣的话，应该从根本上关心响应码

3.5.3.3.            如果我们只是通过API从外部服务器提取数据，则响应码可能无关紧要，因为我们只想要数据本身

3.5.3.4.            用例会影响API响应对象中的哪些信息是有用的，而传输的某些信息在特定环境中可能是无用的

4.1.         数据来自传感器

4.1.1.           物联网设备

4.1.2.           研究设备

4.2.         传感器不一定是应用程序，因为它们的内部逻辑可能非常简单

4.2.1.           温度传感器只是通过一些硬件来记录温度并将其发送出去用于收集

4.3.         重要事项

4.3.1.           噪声

4.3.1.1.            从现实世界传感器中收集到的数据可能非常嘈杂，这不一定是收集阶段需要关注的事情

4.3.1.2.            强调了处理传感器时吞吐量的重要性

4.3.1.3.            下游处理将对传感器数据进行大量异常值去除、平滑和其他转换，因此稳定一致的数据流几乎总是必不可少的

4.3.2.           故障模式

4.3.2.1.            传感器不像应用程序那样智能

4.3.2.1.1.             可能不会在出现问题时通知你

4.3.2.1.2.             损坏的温度传感器不会发送“错误：设备离线”这样的信息

4.3.2.1.2.1.              可能会开始发送疯狂的温度值

4.3.2.1.2.2.              根本什么也不发送

4.3.2.2.            处理传感器数据比处理应用程序数据更具挑战性

4.3.2.2.1.             不能像依赖应用程序一样依赖传感器

4.3.2.2.2.             可能需要用更聪明的方式检查接收到的数据数量或批数据之间的时间差

4.3.3.           目的

4.3.3.1.            传感器数据被用于许多下游任务

4.3.3.1.1.             被用于机器学习系统

4.3.3.1.1.1.              收集的数据量可能会是一个重要的影响因素

4.3.3.1.1.2.              最好的机器学习系统通常会消耗最大的数据集并与其拟合

4.3.3.1.1.3.              用于机器学习的传感器数据的吞吐量非常重要

5.1.         实现高数据质量的最大障碍之一就是数据清洗

5.1.1.           从其他可用的数据集中删除不准确或不具代表性的数据

5.1.2.           根据数据类型和数据处理状态以及数据产品开发的不同，数据清洗也有多种形式

5.2.         从传感器可知，入口点的数据不太可能是干净的

5.2.1.           你的数据只是从混乱的外部世界中获得的

5.2.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.3.1.6.            更新潮的算法技术

5.3.1.6.1.             孤立森林

5.3.2.           评估数据集特征

5.3.2.1.            有时数据的整个部分都与下游任务无关，那么你应该把它们清洗出去

5.3.2.2.            云存储的成本正在下降，但存储无意义的数据不仅是一个存储问题，其他工程师也可能对为什么会存在某个字段而感到困惑

5.3.2.3.            更多的特征意味着需要更多的文档或更多的领域知识来理解你的系统

5.3.2.3.1.             这两者都会让你的分析复杂化，并影响数据质量

5.3.2.4.            要认真思考数据集的哪些特征才是解决问题所必需的

5.3.3.           数据归一化

5.3.3.1.            有些数据点可以单独检查，这没有问题

5.3.3.2.            其他数据在与相同类型的数据进行比较时才是最有意义的

5.3.3.3.            在清洗或转换步骤期间对数据进行归一化通常可以帮助到你和你的机器学习系统

5.3.3.4.            归一化常用的选择

5.3.3.4.1.             L1范数（曼哈顿距离）

5.3.3.4.2.             L2范数

5.3.3.4.3.             去均值化

5.3.3.4.4.             单位方差

5.3.3.4.5.             最佳选择将取决于数据的用例

5.3.4.           数据重建/数据重构

5.3.4.1.            你收集到的数据中的某些字段会丢失

5.3.4.1.1.             遗漏是可以的，但有时你可能需要所有字段都具有与它们相关联的值

5.3.4.1.2.             会发生在容易出错的API调用或传感器可能离线等情况下

5.3.4.2.            插值法

5.3.4.3.            外推法

5.3.4.4.            对相似数据进行分类/标记

5.3.4.5.            来填补缺失值，即便数据伴随一点噪声也无妨

5.3.5.           时区转换

5.3.5.1.            将时区转换视为一种归一化

5.3.5.2.            这一步对于许多数据清洗任务来说都非常重要，所以时区转换值得单独一提

5.3.5.3.            应用程序用户或传感器可能遍布全球，这意味着它们将记录不同的本地时间戳

5.3.5.4.            只有在某些相同的标准下，才能将时间戳相互比较

5.3.5.5.            协调世界时(Coordinated

Universal Time，UTC)

>  5.3.5.5.1.             UTC不是时区，而是时间标准>  5.3.5.5.2.             使用格林尼治标准时间(Greenwich

Mean Time，GMT)的国家碰巧总是与UTC一致，但这些国家并不使用UTC

5.3.5.6.            如果你不进行时区转换，并且疯狂到在收集时不捕获时区信息，那么你将永远无法知道两个国际事件相对彼此发生的先后顺序

5.3.5.7.            千年虫

5.3.5.8.            按照UTC标准来转换或捕获时间

5.3.6.           类型强制转换

5.3.6.1.            大多数结构化数据都是类型化的，这意味着它必须遵循某种格式

5.3.6.2.            如果下游应用程序需要某种类型的数据，你需要考虑强制对其进行转换

5.3.6.3.            作为数据清洗过程的一部分，你需要将值从一种数据类型自动或隐式转换为另一种数据类型

5.3.6.4.            如果要组合来自不同格式的数据，类型强制转换也是不可或缺的

5.3.6.5.            许多库和应用程序对不同的事物都有自己的数据类型，并且通常需要将它们显式转换为新的、更容易接受的格式