DataOps的兴起

数据变得越来越大，传统的数据管理根本不起作用。DataOps正在崛起，有望驯服当今的混乱和环境挑战。

让我们面对现实-传统的数据管理不起作用。如今，75%的高管不信任自己的数据，只有27%的数据项目成功。在所谓的“数据黄金时代”，这些数字令人沮丧。

随着数据的规模和复杂性不断增长，我们正在努力控制它。更糟糕的是，数据团队及其成员、工具、基础设施和用例同时变得更加多样化。结果是数据出现了前所未有的混乱。

DataOps已经存在了好几年了，但现在它火了，因为它承诺解决这个问题。仅仅相隔一周，Forrester和Gartner最近在认识数据操作的重要性方面做出了重大转变。

今年6月23日，Forrester发布了关于数据目录的最新版本的Wave报告，但与正常的“机器学习数据目录”不同，他们将该类别重新命名为“数据操作的企业数据目录”。一周后，即30日，Gartner发布了2022年的宣传周期，预测数据运营将在2-5年内完全渗透市场，并将其从曲线的最左侧移至“膨胀预期峰值”。

自2015年以来，谷歌对“数据操作”的全球搜索数据进行了趋势分析。y轴表示“兴趣随时间的变化”，或搜索兴趣的标准化版本。100表示在给定时间和区域中该术语的最高流行度。

但数据操作的兴起不仅仅来自分析师。在Atlan，我们与世界各地的现代数据团队合作。我个人看到数据操作从一个未知的领域变成了一个必须的领域，一些公司甚至围绕数据操作构建了完整的战略、功能甚至角色。虽然结果各不相同，但我看到数据团队的敏捷性、速度和结果都有了惊人的改善。

在本博客中，我将详细介绍您应该了解的关于DataOps的所有信息-它是什么，为什么您应该关心它，它来自哪里，以及如何实现它。

什么是数据操作？

关于DataOps，首先要知道的，也许也是最重要的一点是，它不是一个产品或者一个工具，事实上，这不是你能买的任何东西，任何人试图告诉你其他事情都是在欺骗你。

相反，DataOps是一种心态或文化—一种帮助数据团队和人员更好地合作的方式。

数据操作可能有点难以理解，所以让我们从一些众所周知的定义开始。

• “DataOps是一种协作数据管理实践，专注于改进整个组织中数据管理者和数据消费者之间的数据流的通信、集成和自动化。”—Gartner

• “DataOps是实现解决方案、开发数据产品和激活数据以实现从基础架构到体验的所有技术层的业务价值的能力。”—Forrester

• “DataOps是一种数据管理方法，强调数据工程师、数据科学家和其他数据专业人员之间的通信、协作、集成、自动化和合作测量。”—Andy Palmer

可以看出，数据操作没有标准定义。然而，您将看到，每个人都在谈论数据操作，而不仅仅是技术或工具。相反，他们专注于交流、协作、集成、体验和合作等术语。

在我们看来，DataOps实际上是将当今日益多样化的数据团队聚集在一起，帮助他们跨同样多样化的工具和流程工作。它的原则和流程有助于团队推动更好的数据管理、节省时间和减少浪费的工作。

为什么要关心数据操作？

简短的回答是：它帮助您驯服每个数据人都非常熟悉的数据混乱。

现在，为了更长远、更个人化的回答…

在Atlan，我们自己开始作为一个数据团队，解决大规模数据项目的社会公益问题。这些项目真的很酷-我们与联合国和盖茨基金会等组织合作，开展影响数百万人的大型项目。

但在内部，生活是混乱的。我们处理了可能存在的每一次消防演习，导致了一连串令人沮丧的电话和花了数小时试图找出哪里出了问题。作为一个数据领导者，这是一个个人脆弱的时期，我知道这不能继续下去。

我们下定决心解决这个问题，做了大量研究，偶然发现了“数据治理”的概念。我们是一个敏捷、快节奏的团队，传统的数据治理似乎不适合我们。因此，我们走到一起，将我们的问题重新定义为“我们如何可能”问题，并启动了一个内部项目，用新的工具和实践解决这些问题。通过将来自不同行业的灵感带回数据世界，我们偶然发现了我们现在所知的数据操作。

在此期间，我们看到了正确的工具和文化可以为数据团队带来什么。混乱减少了，同样的海量数据项目变得更快、更容易，深夜的电话也变得非常罕见。因此，我们能够用更少的资源完成更多的工作。我们最喜欢的例子是：我们建立了印度国家数据平台，由一个8人团队在短短12个月内完成，其中许多人以前从未将一行代码投入生产。

后来，我们在DataOps文化代码中写下了我们的经验教训，这是一套帮助数据团队合作、建立信任和更好协作的原则。

这就是DataOps的最终目的，也是为什么它今天风靡全球的原因—它帮助数据团队停止将时间浪费在无休止的人际关系和技术障碍上，这些障碍阻碍了他们和他们热爱的工作。在今天的经济中，任何节省时间的东西都是无价的。

数据操作背后的四个基本思想

有些人喜欢说数据团队就像软件团队，他们试图将软件原则直接应用于数据工作。但现实是，他们之间的差异太大了。

在软件中，您可以对使用的代码进行某种程度的控制。毕竟，某个地方的人在写它。但在数据团队中，您通常无法控制数据，因为数据来自不同的源系统，格式不断变化。如果有什么区别的话，数据团队更像是一个制造团队，将一堆难以控制的原材料转化为成品。或者，数据团队更像是一个产品团队，将产品带到各种内部和外部终端消费者。

我们喜欢思考数据操作的方式是，我们如何从其他团队获得最佳经验，并将其应用于帮助数据团队更好地合作？DataOps结合了精益、产品思维、敏捷和DevOps的最佳部分，并将其应用于数据管理领域。

关键思想：通过价值流映射减少浪费

尽管精益的根源可以追溯到本杰明·富兰克林（Benjamin Franklin）在1730年代的著作，但精益源自丰田在20世纪50年代的工作。在第二次世界大战的阴影下，汽车工业-以及整个世界-正在恢复元气。对于各地的汽车制造商来说，员工工作过度，订单延迟，成本高昂，客户不满意。

为了解决这个问题，丰田创建了丰田生产系统，这是一个通过消除浪费来节约资源的框架。它试图回答这样一个问题：如何在最短的时间内以最低的成本交付最高质量的产品？其关键思想之一是在不牺牲质量的前提下，尽可能消除制造业中的八种浪费-从生产过剩、等待时间、运输、未充分利用的工人等。

TPS是精益的前身，由商人约翰·克拉夫西克于1988年发明，1996年由研究人员詹姆斯·沃马克和丹尼尔·琼斯推广。精益专注于价值流映射的理念。就像您将生产线映射到TPS一样，您将以极其详细的方式映射业务活动，识别浪费，并优化流程，以在消除浪费的同时保持质量。如果流程的一部分不能为客户增加价值，那就是浪费——所有浪费都应该消除。

价值流映射实际上是什么样子的？让我们从现实世界中的一个例子开始。

假设你拥有一家咖啡馆，你想改善顾客点咖啡的方式。第一步是规划出顾客点咖啡时所发生的一切：接受订单、接受付款、制作咖啡、交给顾客等等。对于这些步骤中的每一步，你都会解释可能出现的问题以及这一步骤可能需要多长时间-例如，顾客在确定他们应该点的位置时遇到困难，然后在他们到达后花7分钟排队等候。

这个想法如何适用于数据团队？数据团队类似于制造团队。它们都使用原材料（即源数据），直到其成为产品（即“数据产品”）并到达客户（即数据消费者或最终用户）。

因此，如果供应链有自己的价值流，数据价值流会是什么样子？我们如何将这些相同的原则应用于数据价值流映射？我们如何优化它们以消除浪费并使数据团队更高效？

产品思维

关键思想：询问您的产品在“待办工作”框架中真正完成了什么工作。

产品思维的核心概念是待办工作（JTBD）框架，由Anthony Ulwick在2005年推广。

理解这个想法最简单的方法是通过奶昔理论，一个来自克莱顿·克里斯滕森的故事。一家快餐店想增加奶昔的销量，所以他们尝试了很多不同的改变，比如让奶昔比竞争对手更巧克力、更耐嚼、更便宜。然而，一切都不起作用，销售保持不变。

接下来，他们让人们在餐厅里站上几个小时，收集购买奶昔的顾客的数据。这让他们意识到，将近一半的奶昔是在早上8点之前卖给单身顾客的。但是为什么呢？当他们第二天早上回来与这些人交谈时，他们了解到，这些人开车去上班的时间很长，很无聊，需要一份早餐，开车时可以在车里吃。百吉饼太干了，甜甜圈太乱了，香蕉吃起来太快了……但奶昔正好，因为它们需要一段时间才能喝，让人整个上午都吃饱。

一旦他们意识到，对于这些客户来说，奶昔的目的或“工作”是在通勤途中提供令人满意、方便的早餐，他们就知道他们需要让奶昔更方便、销量也随之增加。

JTBD框架帮助您构建人们喜爱的产品，无论是奶昔还是仪表板。例如，产品经理的JTBD可能会优先考虑不同的产品功能，以实现业务成果。

这个想法如何适用于数据团队？在数据世界中，有两种主要类型的客户：“内部”数据团队成员需要更有效地处理数据，以及来自更大组织的“外部”数据消费者，他们使用数据团队创建的产品。

我们可以使用JTBD框架来理解这些客户的工作。例如，分析师的JTBD可能会为这些产品优先级决策提供分析和见解。然后，一旦您创建了JTBD，您就可以创建实现它所需的任务列表-每个任务都是数据价值流，可以使用上面的价值流映射过程进行映射和优化。

关键思想：使用Scrum提高速度，将MVP优先于成品。

如果你曾在科技公司或任何“现代”公司工作过，你可能使用过敏捷。2001年，随着《敏捷软件开发宣言》的诞生，敏捷是软件团队计划和跟踪其工作的框架。

敏捷的核心思想是Scrum，这是一个基于创建MVP或最小可行产品的思想的迭代产品管理框架。

举个例子：如果你想造一辆车，你应该从哪里开始？你可以从采访、寻找供应商、建立和测试原型等开始……但这需要很长时间，在这期间，市场和世界将发生变化，你可能最终创造出人们实际上不喜欢的东西。

MVP是关于缩短开发过程。要创建一个MVP，你要问JTBD是什么-它真的是关于创建一辆汽车，还是关于提供交通？解决这项工作的第一个、最快的产品可能是自行车，而不是汽车。

Scrum的目标是尽可能快地创建一些可以投放市场并用于收集用户反馈的东西。如果你专注于寻找最小的解决方案，而不是创建理想或梦想的解决方案的话，你可以在测试你的MVP时了解用户的实际需求-因为他们通常无法在面试中表达他们的实际需求。

这个想法如何适用于数据团队？许多数据团队在组织其他部分的竖井中工作。当他们被分配到一个项目时，他们通常会花几个月的时间研究一个解决方案，并将其推广到公司，结果却发现他们的解决方案是错误的。也许他们给出的问题陈述不正确，或者他们没有设计正确解决方案所需的上下文，或者在他们构建解决方案时组织的需求发生了变化。

数据团队如何使用MVP方法来缩短时间并更快地找到答案？他们如何建立航运思维模式，并尽早、频繁地从利益相关者那里获得反馈？

敏捷可以用来开放孤立的数据团队，并改进他们与终端数据消费者的合作方式。它可以帮助数据团队找到正确的数据，将数据模型投入生产并更快地发布数据产品，使他们能够从业务用户那里获得反馈，并随着业务需求的变化不断改进和调整他们的工作。

关键思想：改进与发布管理、CI/CD和监控的协作。

DevOps于2009年在Velocity会议运动中诞生，工程师John Allspaw和Paul Hammond在会上介绍了如何改进“开发与运营合作”。

当时的传统思维是，软件以线性流程移动-开发团队的工作是添加新功能，然后运营团队的工作就是保持功能和软件的稳定。然而，这次演讲引入了一个新的想法：开发人员和运营人员的工作都是实现业务。

DevOps将线性开发流程转变为循环的、相互关联的流程，打破了这两个团队之间的孤岛。它有助于团队通过一套流程跨两个不同的职能部门合作。发布管理（实施一套“运输标准”以确保质量）、运营和监控（创建监控系统以在出现故障时发出警报）和CI/CD（持续集成和持续交付）等理念使这成为可能。

这个想法如何适用于数据团队？在数据世界中，数据工程师和分析师很容易独立工作-例如，工程师管理数据管道，而分析师构建模型-并在不可避免地出现故障时相互指责。这只会导致争吵和怨恨，而不是解决方案。相反，重要的是将它们结合在一个共同的目标下-使业务更加数据驱动。

例如，您的数据科学家可能依赖工程或IT来部署他们的模型，从探索性数据分析到部署机器学习算法。使用DataOps，他们可以自己部署模型并快速执行分析-不再依赖。

注意：这一点我怎么强调都不过分-数据操作不仅仅是具有数据管道的DevOps。DevOps解决的问题是两个高技术团队之间的问题，软件开发和IT。DataOps解决了复杂的问题，帮助日益多样化的技术和业务团队创建复杂的数据产品，从管道到仪表板或文档。了解更多。

您实际上如何实现数据操作？

今天，每个其他领域都有一个集中的启用功能。例如，SalesOps和Sales Enablement专注于提高销售团队的生产效率、提升时间和成功率。DevOps和开发人员生产力工程团队专注于改善软件团队之间的协作和开发人员的生产力。

为什么我们不为数据团队提供类似的功能？数据操作是答案。

确定最终消费者

DataOps团队或职能部门不是执行数据项目，而是帮助组织的其他部门从数据中实现价值。它专注于创建正确的工具、流程和文化，以帮助其他人在工作中取得成功。

创建专用数据操作功能

当有一个专门的团队或职能支持时，数据操作策略最有效。该功能中有两个关键人物角色：

数据操作支持主管：他们了解数据和用户，擅长跨团队协作和将人员聚集在一起。DataOps支持领导通常来自信息架构师、数据治理经理、图书馆学、数据战略家、数据传播者，甚至外向的数据分析师和工程师。

数据操作支持工程师：他们是数据操作团队中的自动化大脑。他们的主要优势是对数据以及数据如何在系统/团队之间流动的良好知识，同时担任自动化的顾问和执行者。他们通常是前开发人员、数据架构师、数据工程师和分析工程师。

规划价值流，减少浪费，改善协作

在公司的数据运营之旅开始时，数据运营领导者可以使用JBTD框架来识别常见的数据“作业”或任务，也称为数据价值流。然后，通过精益，他们可以进行价值流映射，以确定并消除这些过程中浪费的时间和精力。

同时，来自敏捷的Scrum思想帮助数据团队了解如何更高效地构建数据产品，而来自DevOps的思想则表明他们如何在这些数据产品上与组织的其他部门更好地协作。

规划价值流，减少浪费，改善协作

在公司的数据运营之旅开始时，数据运营领导者可以使用JBTD框架来识别常见的数据“作业”或任务，也称为数据价值流。然后，通过精益，他们可以进行价值流映射，以确定并消除这些过程中浪费的时间和精力。

同时，来自敏捷的Scrum思想帮助数据团队了解如何更高效地构建数据产品，而来自DevOps的思想则表明他们如何在这些数据产品上与组织的其他部门更好地协作。

创建专用的数据操作策略和功能绝非易事。但如果您做得正确，DataOps有潜力解决当今最大的数据挑战，节省整个组织的时间和资源，并增加您从数据中获得的价值。

在我们的下一篇博客中，我们将深入探讨如何根据我们从团队中看到的最佳实践实施数据运营战略-如何识别数据价值流、如何构建运输思维、如何创建更好的数据文化等等。请继续关注，如果您有任何亟待解决的问题，请告诉我！

要在收件箱中获取未来的DataOps博客，请注册我的新闻稿：元数据周刊

原文标题：The Rise of DataOps
原文作者：Prukalpa Sankar
原文链接：https://humansofdata.atlan.com/2022/08/the-rise-of-dataops/