原文：
www.kdnuggets.com/2020/02/observability-data-engineering.html
评论
由 Evgeny Shulman，Databand.ai 联合创始人。
Observability 是一个在 Ops 社区快速增长的概念，近年来受到主要监控/日志公司和 Datadog、Splunk、New Relic、Sumo Logic 等思想领袖的推动。它被描述为监控 2.0，但实际上远不止于此。Observability 使工程师能够基于对系统内部状态和操作环境的深刻理解，了解系统是否按照预期工作。
1. Google 网络安全证书 - 快速进入网络安全职业道路。
2. Google 数据分析专业证书 - 提升你的数据分析技能
3. Google IT 支持专业证书 - 支持你的组织在 IT 领域
Sumo Logic 将 Observability 描述为以下内容：
这是一种监控和分析事件日志、关键绩效指标（KPI）及其他数据的能力，从而获得可操作的见解。一个 Observability 平台将数据以三种主要格式（日志、指标和跟踪）进行汇总，将其处理成事件和 KPI 测量，并利用这些数据提供有关系统安全性和性能的可操作见解。
Observability 比监控更深入，通过为系统指标提供更多上下文，提供系统操作的更深层次视图，并指出工程师是否需要介入进行修复。换句话说，虽然监控告诉你某个微服务消耗了特定量的资源，但 Observability 会告诉你其当前状态与关键故障相关，你需要进行干预。
直到现在，Observability 一直存在于 DevOps 或 DevSecOps 的领域，专注于应用程序、微服务、网络和基础设施健康。但负责管理数据管道的团队（数据工程师和 DataOps）往往被迫自己摸索。这可能适用于那些对数据能力投资不大的组织，但对于拥有严肃数据基础设施的公司来说，缺乏专业管理工具会导致重大低效和生产力差距。
当前数据工程师的典型做法是使用最初为应用程序或基础设施构建的标准监控工具来监控他们的数据流程。使用这些通用工具，数据工程团队可以获得高层次的作业（或 DAG）状态和数据库性能摘要，但会缺乏管理管道所需的详细信息。这种差距导致许多团队花费大量时间追踪问题或处于持续的焦虑状态。
标准工具无效的原因是数据管道的行为与软件应用程序和基础设施非常不同。
Zabbix 和 Airflow，我们如何将所有正确的数据集中在一个地方？
这里是数据管道，特别是批处理过程与其他基础设施类型之间的一些主要区别。
周期性
大多数监控工具是为了监督系统的持续运行而构建的，24/7\运行。任何停机时间都是不好的，这意味着访问者无法访问网站或用户无法访问应用程序。另一方面，批处理数据过程设计上是按离散时间段运行的。因此，它们需要不同类型的监控，因为你提出的大多数问题没有像“开/关”，“上/下”，“绿/红”那样简单的二元答案。需要理解更多维度——计划开始时间、实际开始时间、结束时间和可接受的范围。
与其他系统不同，数据管道定期在成功之前失败是完全正常的。一个 DAG 可能在成功运行之前失败 6 或 7 次。这可能是由于某种类型的可取的作业节流，如数据库池。
要点是，DAG 的典型行为与其他基础设施服务非常不同。使用标准警报，数据团队会收到大量无意义的警报，数百封未读的通知邮件，无法从噪音中筛选出有用信息。
长期运行的过程
数据管道通常是长期运行的过程，完成需要许多小时。我们的客户反馈回来的平均时间约为 6 小时。监控长期运行的过程具有挑战性，因为错误可能在作业后期出现，你需要等待并观察很长时间才能知道是否成功或失败。这导致了更高的失败成本，因为如果下游出现问题，需要从头开始重新启动作业。团队需要能够收集早期警告的方式和更智能的历史分析方法，以预测失败。
复杂的依赖关系
DAG 本质上是复杂的。它们有内部依赖关系，如任务序列，以及外部依赖关系，如数据何时可用以及前一个作业的输出。这个相互依赖的网络创建了独特的监控需求，你需要了解过程的更广泛背景，以便了解问题如何级联或追溯。
数据流
当然，我们不能忘记数据管道依赖于数据。这是另一个需要监控和理解的复杂维度，包括模式、分布和数据完整性。例如，大多数批处理作业操作于某个数据窗口，即过去 60 天。你需要知道在这 60 天里是否存在问题，例如数据未生成。
尽管有大量的数据跟踪解决方案，今天的团队真正不同的是，专业化和开源的使用大大增加，很难找到与现代工具栈（即 Airflow、Spark、Kubernetes、Snowflake）易于集成、通用并提供适当扩展性的框架。
成本归属
最后但同样重要的是，管道监控中的成本归属更为困难，因为团队需要从多个角度查看流程以理解其投资回报率。示例包括按以下方式查看成本：
-
环境（我生产 Spark 集群上的管道成本 X）
-
数据源提供商（从 Salesforce 读取数据的管道成本 Y）
-
数据消费者（将数据传递给数据科学团队的管道成本 Z）
将这些因素结合在一起，监控数据管道与其他基础设施的差异归结为管道需要监控更多的维度，并且需要非常详细的状态报告。这些问题在使用更复杂系统如 Kubernetes 和 Spark 的团队中更加严重。如果没有可观测性，数据工程团队将盲目操作，大部分时间都在追踪问题和调试。
在我们之前管理数据工程团队的经历中，我们总是难以保持对项目和基础设施的良好可见性。我们建议你更多地考虑数据栈的可观测性，并考虑使其独特的因素。这将帮助你通过更容易对齐团队状态、更快识别问题和更快调试来建立更强大的数据操作。以下是我们建议的最佳实践：
（1）在你的 DAG 中逐步投资数据/元数据收集。首先跟踪管道输入和输出的基本指标，以便立即发现是否有显著的数据变化，以及这些变化是否是管道内部问题还是由外部事件引起的。示例包括报告输入/输出文件的数量和大小。
下一步是提取有关管道内部的信息——即任务之间的中间结果。这些是管道中任务之间的输入和输出。拥有内部可见性将帮助你准确地深入到 DAG 中查看问题或变化发生的地方。
对数据监控来说，下一个重要的补充将是跟踪模式、分布以及输入和输出文件的其他统计指标。
逐步进行这些改进将帮助你在不进行大规模项目的情况下更好地了解你的管道，并使你能够尝试适合每个可见性层级的正确工具和方法。
（2）定义管道回归测试并跟踪你的测试指标。 就像软件工程师在应用程序代码投入生产之前进行测试一样，数据工程师也必须测试管道代码。
对于有测试或 CI/CD 流程的团队，我们看到两个常见的问题。首先，要确保在数据回归测试中使用的数据是最新的，并且代表真实的生产数据。我们建议使用最新成功的生产管道运行的数据。其次，需要一些基本的自动化工具，这些工具可以在这些数据上运行新的 DAG 代码，并在推送到生产环境之前警报问题。
自动化测试管道将帮助你更好地理解数据流中的细微差别，并在数据消费者遇到问题之前发现问题。你可以发现管道中的错误，识别数据质量的变化，以免数据分析师和科学家感到意外，并在更新/重新训练机器学习模型时做出决策。
（3）定义并监控标准的 KPI，以便所有角色——数据工程师、分析师和科学家——都可以对齐。 对于一个从事机器学习的团队，这可能意味着数据工程师需要了解由数据科学家构建的模型性能指标（如 R2），而数据科学家需要关注数据工程师管理的数据摄取过程的指标（如过滤事件的数量）。在这些共享指标上创建团队之间的对齐是非常强大的，因为每一方都会理解问题，而不需要反复沟通。
这里有一个例子——假设一个数据工程师添加了一个额外的数据源。这个源包含了大量的噪声，因此工程师添加了过滤器，以确保只有有用的数据能够通过。数据科学家开始使用这些数据并训练一个模型。了解数据如何被准备好能让数据科学家更好地管理他们的模型。他们可以预测如果模型在没有类似过滤数据的环境中投入使用会出现的问题，并能提供建议，说明当他们的模型需要在未来重新训练时数据应该如何处理。
除了入门外，随着数据工程团队的扩展，观察能力将变得更加重要，使用正确的工具来完成工作是至关重要的。
不要假设你用来运行流程的工具可以自行监控。大多数团队用来运行数据堆栈的工具在可观测性方面存在显著差距——例如，依赖 Airflow 监控 Airflow 可能会迅速演变成过度复杂和不稳定的局面。此外，也不要假设你可以仅用标准的时间序列监控工具来监控计划任务，因为数据流程的复杂性非常不同。
要真正实现可观测性，你需要将执行指标（CPU、运行时间、I/O、数据读取和写入）、管道指标（管道中的任务数量、每个任务的 SLA）、数据指标和 ML 指标（R2、MAE、RMSE）集中在一个地方，并建立一个专门的系统来确保日志的准确性和状态的一致性。
原文。经许可转载。
相关链接：