DataOps 是现代数据堆栈的未来吗？
发布时间：2022-08-25 12:33:24 所属栏目：大数据 来源：互联网
导读：在DevOps掀起软件工程风暴之前，一旦他们的应用程序开始运行，开发人员就被蒙在鼓里。工程师们不是在第一时间知道故障发生，而是在客户或利益相关者抱怨 网站滞后 或503页面太多时才会发现。 不幸的是，这会导致了同样的错误反复发生，因为开发人员缺乏对应
|
在DevOps掀起软件工程风暴之前，一旦他们的应用程序开始运行，开发人员就被蒙在鼓里。工程师们不是在第一时间知道故障发生，而是在客户或利益相关者抱怨 "网站滞后 "或503页面太多时才会发现。 不幸的是，这会导致了同样的错误反复发生，因为开发人员缺乏对应用程序性能的洞察力，不知道在发生故障时从哪里开始调试他们的代码。 所以现在广泛采用DevOps概念，要求在软件部署和开发过程中，开发人员（Dev）和运营（Ops）团队之间进行协作和持续迭代来解决上述问题。 到2010年中期，大型的数据优先公司，如Netflix、Uber和Airbnb已经采用了持续集成/持续部署（CI/CD）原则，甚至建立了开源工具来促进其数据团队的发展，DataOps也就诞生了。 事实上，如果你是一个数据工程师，你可能已经在你的堆栈中应用了DataOps流程和技术，无论你是否意识到这一点。 在过去的几年里，DataOps在各种规模的数据团队中越来越受欢迎，它是一个能够快速部署数据管道的框架，同时还能提供可靠和值得信赖的数据，并且随时可用。 什么是数据运维？ DataOps 是一门融合数据工程和数据科学团队以支持组织的数据需求的学科，其方式类似于 DevOps 帮助扩展软件工程的方式。 与 DevOps 如何将 CI/CD 应用于软件开发和运营类似，DataOps 需要一种类似于 CI/CD、自动化优先的方法来构建和扩展数据产品。同时，DataOps 使数据工程团队更容易为分析师和其他下游利益相关者提供可靠的数据来推动决策。 DataOps 与 DevOps 虽然 DataOps 与 DevOps 有许多相似之处，但两者之间存在重要区别。 关键区别在于 DevOps 是一种将开发和运营团队聚集在一起以提高软件开发和交付效率的方法，而 DataOps 专注于打破数据生产者和数据消费者之间的孤岛，使数据更加可靠和有价值。 多年来，DevOps 团队已成为大多数工程组织不可或缺的一部分，消除了软件开发人员和 IT 之间的孤岛，因为他们促进了软件无缝且可靠地发布到生产中。随着 DevOps 的发展以及为它们提供动力的技术堆栈的复杂性开始增加，DevOps 在组织中越来越受欢迎。 为了保持系统整体健康状况的持续变化，DevOps 工程师利用可观察性来监控、跟踪和分类事件，以防止应用程序停机。 软件可观察性包括三个支柱： 日志：在给定时间戳发生的事件的记录。日志还为发生的特定事件提供上下文。 指标：在一段时间内测量的数据的数字表示。 Traces：表示分布式环境中相互关联的事件。 总之，可观察性的三个支柱使 DevOps 团队能够预测未来的行为并信任他们的应用程序。 同样，DataOps 的纪律可帮助团队消除孤岛并更有效地工作以在整个组织内交付高质量的数据产品。 随着公司开始从各种来源摄取大量数据，DataOps 专业人员还利用可观察性来减少停机时间。 数据可观察性是组织充分了解其系统中数据健康状况的能力。它通过监控和提醒团队可能在数天、数周甚至数月内未被发现的事件，减少数据停机的频率和影响（数据不完整、错误、丢失或其他不准确的时间段）。 与软件可观察性一样，数据可观察性包括自己的一组支柱： 新鲜度：数据是最新的吗？最后一次更新是什么时候？ 分布：数据是否在可接受的范围内？它是预期的格式吗？ 卷：所有数据都到了吗？是否有任何数据重复或从表中删除？ 架构：架构是什么，它有变化吗？对架构的更改是故意的吗？ 沿袭：哪些上游和下游依赖项连接到给定的数据资产？谁依赖这些数据进行决策，这些数据在哪些表中？ 通过深入了解这些支柱的数据状态，DataOps 团队可以了解并主动解决数据生命周期每个阶段的质量和可靠性问题。 数据运维框架 为了更快、更可靠地从数据中获得洞察力，DataOps 团队应用了一个持续的反馈循环，也称为 DataOps 生命周期。DataOps 生命周期从 DevOps 生命周期中汲取灵感，但考虑到数据不断变化的性质，它结合了不同的技术和流程。DataOps 生命周期允许数据团队和业务利益相关者协同工作，为组织提供更可靠的数据和分析。 以下是 DataOps 生命周期在实践中的样子： 计划：与产品、工程和业务团队合作，为数据的质量和可用性设置 KPI、SLA 和 SLI（下一节将详细介绍）。 开发：构建将为你的数据应用程序提供动力的数据产品和机器学习模型。 集成：将代码和/或数据产品集成到你现有的技术和/或数据堆栈中。（例如，你可以将 DBT 模型与 Airflow 集成，以便 DBT 模块可以自动运行。） 测试：测试你的数据以确保它符合业务逻辑并满足基本操作阈值（例如数据的唯一性或无空值）。 发布：将你的数据发布到测试环境中。 部署：将你的数据合并到生产中。 操作：将你的数据运行到应用程序中，例如为机器学习模型提供数据的 Looker 或 Tableau 仪表板和数据加载器。 监控：持续监控数据中的任何异常并发出警报。 这个循环会一遍又一遍地重复。然而，通过将 DevOps 的类似原则应用于数据管道，数据团队可以更好地协作，从一开始就识别、解决甚至防止数据质量问题的发生。 DataOps 的五个最佳实践 与我们在软件开发领域的朋友类似，数据团队也开始效仿，将数据视为产品。 数据是组织决策过程的关键部分，数据团队也开始将数据视为产品，并将产品管理思维应用于构建、监控和测量数据产品的方式有助于确保这些决策基于准确、可靠的洞察力。 在过去几年与数百个数据团队交谈后，我们总结了五个关键的 DataOps 最佳实践，可以帮助你更好地适应这种“数据就像产品”的方法。 1. 尽早让利益相关者在 KPI 上达成一致，并定期重新审视它们。 由于你将数据视为产品，因此内部利益相关者就是你的客户。因此，尽早与关键数据利益相关者保持一致并就谁使用数据、他们如何使用数据以及用于什么目的达成一致至关重要。为关键数据集制定服务水平协议 (SLA) 也很重要。与利益相关者就良好的数据质量达成一致有助于你避免在 KPI 或无关紧要的测量上出现旋转周期。 在你和你的利益相关者达成一致后，你应该定期与他们核对以确保优先级仍然相同。Red Ventures 的高级数据科学家 Brandon Beidel 每周与公司的每个业务团队会面，讨论他的团队在 SLA 方面的进展。 “我总是用简单的商业术语来构建对话，并专注于'谁、什么、何时、何地以及为什么，”布兰登告诉我们。“我特别会问一些关于数据新鲜度限制的问题，我发现这对业务利益相关者特别重要。” 2.自动化尽可能多的任务 DataOps 的主要关注点之一是数据工程自动化。数据团队可以自动执行通常需要数小时才能完成的死记硬背任务，例如单元测试、硬编码摄取管道和工作流编排。 通过使用自动化解决方案，你的团队可以减少人为错误进入数据管道的可能性并提高可靠性，同时帮助组织做出更好、更快的数据驱动决策。 3. 拥抱“运送和迭代”文化 对于大多数数据驱动的组织而言，速度至关重要。而且，你的数据产品可能不需要 100% 完美才能增加价值。我的建议？构建一个基本的 MVP，对其进行测试，评估你的学习成果，并根据需要进行修改。 我的第一手经验表明，通过使用实时数据在生产中进行测试和迭代，可以更快地构建成功的数据产品。团队可以与相关利益相关者合作，监控、测试和分析模式，以解决任何问题并改善结果。如果你定期执行此操作，你将减少错误并降低错误进入数据管道的可能性。 4. 投资自助服务工具 DataOps 的一个关键好处是消除了数据在业务利益相关者和数据工程师之间的孤岛。为了做到这一点，业务用户需要能够自助满足自己的数据需求。 业务利益相关者可以在需要时访问他们需要的数据，而不是满足业务用户的临时请求（这最终会减慢决策制定）的数据团队。Intuit 的前工程副总裁 Mammad Zadeh 认为，自助服务工具在整个组织中启用 DataOps 方面发挥着至关重要的作用。 （编辑：柳州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
