DataOps课程：如何做到先于客户发现问题？ | 内附视频

LinkTime_Cloud

于 2023-08-29 09:30:39 发布

阅读量170

点赞数

CC 4.0 BY-SA版权

本文链接：https://blog.youkuaiyun.com/LinkTime_Cloud/article/details/132573796

文章探讨了DataOps课程的核心内容，包括数据旅程的五个支柱：观察步骤、错误监测、数据组合、用户体验和期望管理。强调了在数据处理过程中降低错误、提高效率的重要性，以及围绕数据建立系统的必要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

《数据之旅DataOps》课程内容包括《数据旅程宣言》《数据之旅简介》《数据之旅的五大支柱》。本文汲取课程精华要点，如需完整版可观看视频讲解，关注公众号回复关键字【第一模块】，获取课程完整版文字内容。

课程完整版（21分钟）

数据旅程宣言

当你因还没有出现的问题而感到羞愧和指责时，是因为你不理解现有的数据流程。绝大多数人都抱着希望运行他们的数据和分析系统，或者他们等着你的客户发现问题。显然，让客户早于自己发现问题是很糟糕的。

这里有非常复杂的数据体系结构，几十个小盒子分布在各处，里面有服务器、软件、工具和链接，这些盒子几乎是你的冷却器。因此，当有很多小盒子在一起工作时，你需要一个任务控制来看看这些盒子里的东西是否在工作。

和所有做过数据和分析的人一样：不要相信你的数据提供商，因为他们会给你坏数据，让你习惯并防范它。

不要以为上周有效的东西今天也有效。如果上周一切都很好，那么，数据可能已经改变，一些代码可能也变了，一些服务器可能出现了问题。然后，当你发现问题时，希望你能在客户找到来源之前，先找到这个小盒子的实例，以及运行它的工作簿、模型和作业。

很多人都关注完美的数据质量，即我们获得的原始数据，这很重要但并不是万能的。即使有了完美的数据质量，你仍然可能会遇到问题，可能会出现错误，因为数据正在被连接、组合和可视化……很多人试图进行测试，即以手动方式检查事情是否正确。

关于DataOps理论已经谈到了很多，但实际在经营一家工厂时，丰田、利恩和德明的经验就是：一路上的每一个工具，摄入工具、转换工具、数据库、模型、可视化数据准备工具、数据治理工具都是装配线上的工作站。因此，你不会想买那辆在有着很多错误的装配线上生产出来的汽车，也不想在糟糕的装配线上生产洞察力。

数据之旅简介

你需要在已经运行的基础上有一个期望层，它会告诉你数据从哪里进入你的组织，在哪里到达你客户所经过的路径。信任来自于在数据旅程中监控和检查每个工具中的数据，并在每一步测试和查找异常。

这种分析方法以及能够深入研究和学习的想法都是好主意。原因在于它减少了错误，提高了团队的生产力。第二，它实际上也可以通过进行某种测试的数据旅程，在开发中使用它。还有一种想法是，通过数据之旅来帮助回归测试或进行影响分析，这是一种对数据系统的静态分析，但它无法回答你事情是否晚了或数据是否错误。

那么，旅行背后的原则是什么呢？数据之旅像是跨越了小盒子，在你获取原始数据的地方，它是批量的或流式的。把它放在数据库中，然后进行ETL或ELT，转换或清理，然后在可视化或数据科学中正确使用它，或者把它发送到其他地方。其特点是：有多个工具、多个数据集、通过这些数据集的多条路径、多个作业、多个体系结构、多个客户和多个人，所以除了盒子之外到处都是倍数。

还有一个小问题：盒子很深。所以问题可能一直到底部，在FTP运行的右下角得到一些东西。这可能是完美的，也许你的服务器正在失控旋转，又或者协调器上运行的东西掉了。如果你有一些任务，也许你的测试会返回错误。在寻找事物的位置时，你会遇到这种交叉和向下的问题，这就是挑战，因为事情总是会出错。

所以，你的组织中已经有很多这样的人了，也许你称之为工作、管道或工作流，它们可以嵌入不同的团队以及他们的批处理、流媒体和手册中而无处不在。如果你看看更大的组织，可能有数百人，甚至是一个3到5人的团队，他们可能会有20到50人在运行这些东西，重点是你只想知道他们在正确运行。

人们有不同的工具链，每个类别都有很多工具。第二个问题是，事情有很多部分在运行。这是一个横向和向下的问题，数据传输实际上适合组织环境。因此，你可能有一个中央枢纽团队，他们接收数据，有自己的旅程，然后让每个团队都在一个单独运行的业务线中。这可以映射到数据混搭上下文中，或者每个都是域间关系中的域，但这里有很多轮辐式的依赖关系。

所以数据之旅本身就有一个发展过程，你改变它们，希望将新代码、新数据或配置的新更改投入生产，而开发过程往往因组织而异。所以，因为有这些组织设计，有定制的数据匹配，你的数据旅程最终会遵循康威定律。人们拥有的数据旅程是基于组织结构，而不是基于最好的技术方式，这种情况发生在软件中，也发生在制造业中，康威定律是一个非常普遍的东西。

它们需要相关性，如果出了问题，你想知道是原始数据的问题吗？当将原始数据与其他数据或可视化数据放在一起时，发生了什么事情？这有意义吗？还是太晚了，服务器被固定住了，然后会发生什么？与此相关的事情会破坏它。因此，由于这些系统的复杂性和耦合性，这种跨旅程、跨旅程和跨旅程的相关性实际上是非常基本的。

因此，常见的情况是数据旅程如何与另一个相关？其中包括因果关系，它完成了然后某个配器或信号导致了其他事情的发生。有时这是暂时的，就像你的ETL过程必须在早上5点前完成，早上7点仪表板构建工作正常，它们是不耦合的，但它们显然是相互关联的。还有一些手动案例，气流时间表凌晨1点结束，然后你的印度团队必须在凌晨3点按下按钮做一些事情。还有一些案例更受事件驱动，因此在更新的仪表板中添加了一些新的数据删除功能。所以这些关系在旅程之间变得很复杂。

数据之旅的五大支柱

接下来谈一谈数据之旅的五大支柱（以往文章中我们介绍过《一文读懂：数据之旅的五大支柱》）。数据之旅的第一个支柱是观察步骤，看看顺序是否正确，有时一个集合它们是无序的，或者表是无序的。但数据之旅一般都是有秩序的，在做模型工作或业务工作之前，必须先做数据工作，确保订单发生、SLA得到满足、时间得到满足、没有延迟，真正获得流程谱系和流程可靠性是第一支柱。

第二个支柱是，当事情出错时，它们在不同的地方都会出错。它可能是你的服务器、基础设施、坏代码或网络、CPU，可能是磁盘空间，以一种非常IT的方式监控这些事情也很重要。你的技术堆栈能工作吗？数据正确吗？这种模式新鲜吗，体积大吗？从商业角度来看是正确的吗？比如你的销售额是上升还是下降？他们的百分比是上升还是下降？这就是很多人所说的数据质量。

拥有更多的扩展，这不仅仅关于原始数据，还涉及如何将数据组合在一起。因此，我们将讨论静态数据或数据质量验证。另一部分是不在数据库中的数据，但它正在使用中，实际上是在预测模型或可视化。以及如何测试这一点，因为这些软件工具是由可能存在错误的代码驱动的。

那么，如何确保这些工具的用户体验是正确的呢？如何确保他们信任数据，即使数据库中的数据可能是完美的。模型或可视化中的某个人可能使用了它，你的客户可能会发现它是错误的。

最后，类似期望层，要知道你的数据旅程应该用一定的CPU运行——数据、原始数据和集成数据应该是完美的，模型应该有这样的预测水平，以及所有这些事情怎样能够按顺序发生。然后，如何收集所有期望，告诉人们并通知他们，这实际上是关于提醒和共享信息。

如何在数据库中测试静止的数据？举个例子，真正的问题是“为什么？”很多时候项目失败了，或者当在生产中得到一些东西时，没有人信任数据，没有人相信团队，他们有太多错误。调查显示大部分团队都会感到压力巨大，数据和分析团队正在运行数据，都是一种非常不愉快的状态，项目正在失败，人们不信任数据，团队压力很大。

因此，看待世界的方式与很多人相反。问题不是你的数据库不太快，或者ETL工具不够容易使用。而是你需要围绕数据和分析产业建立一个系统，该系统的目的是推动这三个价值观——降低生产中的错误，增加以低风险将新事物投入生产的周期时间。

然后试着自动化工作中的各个部分，因此像数据库、数据源、ETL工具、可视化工具、治理工具、数据科学工具、人工智能工具等等这些工具都出现了，它们正在被数据工作者所使用。

所以，关注数据之旅，首先要关注降低生产中的错误数量。使用“错误”一词很重要，因为重要的不仅仅是数据质量，也不是你的原始数据有多好。但这也是从原始数据到集成数据，再到在工具中使用的其他步骤，所有这些东西都需要放在一起。