DataOps课程：DataOps环境管道，如何实现一键自动化？ | 内附视频

LinkTime_Cloud

于 2023-09-19 09:00:10 发布

阅读量98

点赞数

文章标签：自动化运维

本文链接：https://blog.csdn.net/LinkTime_Cloud/article/details/133054095

版权

《DataOps环境管道》课程内容包括《DataOps环境挑战》《环境管理：组件和用例》《数据操作环境原理》。本文汲取课程精华要点，如需完整版可观看视频讲解，关注公众号回复关键字【第四课】，获取课程完整版文字内容。

课程完整版（27分钟）

DataOps环境挑战

我们将重点关注环境管道。首先，与Eckerson进行了一项调查，“你花了多长时间来创建新的开发环境？”对大多数人来说都花费了很长时间：几个月，几个星期，几天。打个比方，如果你看看一个软件团队，当一个新的软件工程师加入软件团队时，高功能团队希望为他们建立一个开发环境，或者让他们在一天内建立自己的开发环境，并且希望他们能够在本周将一些小代码修复部署到生产中。有多少分析团队有同样的情况，一个人可以在工作的第一周获得开发环境，成功地进行更改，并将其部署到生产中？这可能与DataOps的原则有关，它有商业价值，但人们并没有这么做。

环境的提供和创建是一个缓慢、手动且高度接触的过程。这是分析型组织面临的主要挑战，因为当开发环境和生产环境之间存在差异时，云环境和另一个云环境之间的差异最终不适合使用，能够调和这些差异的是一种手动的、缓慢的、会导致停机和不稳定的操作。这会导致开支、硬件和软件、基础设施和许可证的数量超过你的需要。环境中的数据（测试数据和生产数据）之间的差异可能会导致部署错误，转化对质量数据和分析组织的影响，项目超支延迟，以及向客户交付变更的速度缓慢。

这里有一个单独的开发环境，一个团队开发环境、一个测试环境，最后是一个生产环境。在你的个人开发环境中，尝试在Tableau中开发Python模型或其他东西；在团队开发环境中，试图看看这与团队中其他人的做法如何契合；然后在UAT环境中试图运行它，以确保它在生产之前不会崩溃。硬件是不同的：你可能有开发服务器、测试服务器、生产服务器和数据库；可能有不同的数据：一个测试数据集，一个非常小的个人开发环境，团队环境可能是一个干净的、90%的版本，也可能是100%的版本；最后是生产环境，在每台不同的服务器上都运行着不同的库和工具，然后每一个都有不同的数据。

任何时候，如果在单个开发环境和测试环境之间存在不同版本的Python库，测试数据和模式存在差异，都是一个突破的机会，这些问题很棘手且复杂。

我们所说的环境是一个更大的术语，这不仅仅是你用来运行分析的硬件和软件，这是测试数据。它是正确的硬件和软件库，可能是与之配套的网络配置。此外，你正在处理的代码分支，以及正在使用的所有工具甚至是人员。因此，环境很复杂，在某些方面比软件工程师更复杂，因为数据的大小、工具的数量、工具链、这些工具在整个组织中的分布以及安全问题。所以，很难把所有这些东西放在一起，为你的工作建立一个分析环境。

环境管理：组件和用例

构建环境的挑战是能够通过创建代码来实例化它们，当然创建测试数据也是一个挑战，因为测试数据本身就非常重要。在某些组织中，你可以只复制生产数据，也许它足够小，或者没有安全问题。然而，对于许多组织来说，在数据分发方面都面临着这一挑战，从生产中获取测试数据的速度有多快？在和那些测试数据已经过期六个月的组织谈论过，这意味着数据中存在模式差异和分布差异，所有这些都会导致错误。

我们如何管理环境的最基本区别不是多云或多组织，而是开发环境和生产环境。举一个简单的例子，在每个组织中都有像Eric这样的人，他是你的生产完美主义者，他们管理着生产环境，在每件事上都有一点技巧，他们的目标是保护和完善提供数据和分析的日常工作，希望尽量减少错误。他们往往是任务主管，他们希望事情完美，当事情出错时他们也会被骂。在使用软件时，有一个叫DataOps工程师的人，他们的目标是试图优化从开发到生产的操作，他们在软件中拥有DevOps技能、云技术。然后是一组完全不同的数据执行者，也许是数据科学家、数据工程师或者是做BI的人，但他们的目标是为客户创造新功能，他们需要灵活性，这可能有一大堆不同的工具，在这里只展示了一个叫NoProd的女人，因为她没有生产渠道，但组织中往往有几十个这样的人，而且他们有不同的环境。

所以生产是由Eric管理的，这是单独的软件，这种情况下是一个安全的环境。因此，开发人员无法访问，但情况并非总是如此，在一些金融服务公司，他们不希望开发者能够访问生产数据。在某些情况下，他们甚至不希望开发人员访问正在进行生产的网络，所以这是一个完全封装的环境，也许在亚马逊有自己的专有网络，或者有自己的Kubernetes集群。

我们需要能够在开发中构建一些东西，并轻松地将其推向生产。在系统中，必须有一种不同的称之为代理的方式，一种在开发中运行与在生产中运行不同的方式，因为它们有单独的硬件和软件。它们是安全的，有不同的访问级别，他们有不同的管理团队，不同的资质，所有这些都要谈论，以及人与技术的互动是如何运作的。

如果看一下本例中的生产环境，就会发现有一个VPC在运行代理，有一些SFTP服务器、Redshift数据库、S3数据库、一条用于警报的Slack通道、不同的Docker和Python放置位置，以及不同的开发环境。一个非常简单的例子，只是试图在数据库表中加载一些东西，已经拥有了所有这些你必须能够组织的组件、人员和他们的技术，这样你就可以快速地将事情从开发转移到生产中。

在自助服务方面，有一家排名前五的银行，他们想降低自助服务的风险，他们有大约1000名非IT用户，希望使用数据来深入了解数据，但需要数据的供应以及对法规遵从性和风险的监控，这对他们来说是一个巨大的问题。因此，他们希望“有一些短期用途，有一些可以使用的数据，几个工具。然后在正确的时间内拥有它，以便能够知道你在用它做什么，我可以正确地处理这些请求。”

因为你向这些人提供了关于客户或供应商的数据，你怎么知道他们没有做违反政策的事情？因此，能够为这些人创建一个数据沙箱或自助沙箱，是一种管理风险和应用法规遵从性的方法。有一家大银行，他们有集中的IT和数据资源，也许在布鲁克林，有人在纽约地区做小企业贷款；也许在得克萨斯州，有人在做高净值财富管理，并试图做分析或获取数据；最后可能会有一些西北分公司的区域营销。因此，你有三个不同的人或三个不同群体来对抗一家大型金融服务公司，他们有不同的需求。例如，布鲁克林的那个人可能需要过去24个月的商业数据。因此你需要在SQL数据库中加载一些DMB文件，并且需要Tableau访问权限；德克萨斯州的人需要德克萨斯州的客户数据，它必须加载到数据库中，但他更想要Python和SQL访问；最后西雅图客户银行需要DDA数据，但他们希望匿名，并通过Power BI访问它，以便拥有某种数据字典来了解发生了什么。

所以有三个不同的团队，三种不同的数据使用方式，三种不一样的循环时间。但他们都面临着一系列共同的挑战，即向人们提供数据和工具的后勤保障是什么？能做多快，循环时间是多少？他们可以使用多长时间？什么用例？他们可以使用它吗？能监控吗？能保住工作吗？IT团队是否可以撤销访问权限？如果这些人离开了公司，他们能重复使用已经做过的事情吗？

因此，从IT角度来看，自助服务意味着快速、低成本的支持和风险管理。实际上，帮助他们建立了一个流程，使得他们可以在这个流程中完成提出请求和批准这个分析开发环境的状态。有时准备这些东西需要时间，它们是否处于错误状态？用户完成了吗？使用了一个表单前端，让人们以一种简单的方式提出请求。然后，实际上用一堆DataKitchen食谱启用它，做退役、供应、调度、监控、故障检测，所有这些不同的部件都需要在不同的循环时间和基于DataKitchen的不同工作中运行。

这里的好处是，不用花三到四周的时间手动检查一个庞大的IT检查表来构建这些东西，可以在不同的时间和人员中实现自动化。这种自动化使他们能够监控发生的事情，自动撤销访问权限，重用他们的工作，只需花费更少的时间，并且能够管理这项任务的支持和风险。

这就是用例：一个要生产的开发，不同的云或云环境，多组织环境，然后是自助开发环境。

数据操作环境原理

DataOps宣言中关于让环境具有可复制性，“我想快速地将一个环境从开发环境复制到生产环境，或者从生产环境复制到开发环境，并使其成为一次性的可以重新创建。”这种环境的可再现性和可处置性的想法很关键。

按下一个按钮：“给我一个环境，让所有都自动化。”人们可以在那个环境中完成工作，然后可以运行任务并帮助部署到生产中，相信这些原则并在你的团队中实现它并不牵强。

以下是每个人都应该寻找的一些核心原则，首先要知道你的环境是什么样子的，了解什么是开发环境，什么是生产环境，并能够在这些环境中协调和交流活动。然后，所有这些进入构建和抽象环境的任务进行自动化。如果构建这些环境需要时间，那么就重新进行，并将痛苦向前推进。

为什么会这样？因为在技术工作中总是有一个挑战，完成意味着它正在生产中，它已经经历了你所拥有的任何数量的环境，开发、QA、预生产、生产。

接下来，让我们谈一谈体系结构方面的考虑，每个人都有一个生产环境，他们使用一大堆工具进行工作。因此，当我们将DataOps视为一种架构时，会想到自动化部署、协调和监控，尤其是在环境创建和管理，你需要在一个地方来说：“我想在Dev中运行它，想在测试中运行它，想在prod中运行它”。

这是在这些多团队或多云案例中展示的架构版本，你必须能够说，“我想在谷歌云开发中运行它，或者在亚马逊测试中运行它”，并且能够运行它的哪一部分，然后进行每个系统调用。

因此，你需要这些环境的协调，对于很多公司来说，他们可能有一些东西在prem上，可能正在转移到云，无法判断什么在运行，什么坏了，能够在整个系统中看到它是获得效率和时间的重要方式。

另一点是从过程分析的角度来看待它，你有多少种环境？用了多少？有多少人在创造和毁灭？在这些环境之间的部署速度有多快？这些都是非常基本的方法。当然，还有更高级的方法，比如如果你在云中，每个环境的运行成本是多少？有没有一种方法可以让你更快地打开和关闭它们，这样它们就不必在周末运行，而且你要为它们支付亚马逊的所有费用？这是你可以创建的另一种度量。

最后，讨论了为什么环境很有价值，为什么抽象你的开发版本，集中化与本地环境，可以真正为你的组织增加价值。这里有四个使用案例讨论了管理环境、体系结构和测量案例的一些原则。最后，谈谈为什么这很重要，希望当你应用DataOps原则时，你的部署延迟——从开发到生产的速度——可以从几周或几个月到几小时或几分钟，而且你可以有低错误，并且你的数据和分析团队会更快乐、更有效率。

因此，如果你对DataOps感兴趣，要关注DataOps的这四件事——减少周期时间、降低错误率、改进协作和衡量流程。