DataOps课程：使用DataOps，如何实现快速部署？ | 内附视频

LinkTime_Cloud

于 2023-09-12 09:01:03 发布

阅读量158

点赞数

CC 4.0 BY-SA版权

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

《DataOps开发管道》课程内容包括《开发生命周期复杂性》《数据和分析开发》《如何实现快速部署》《DataOps部署：超越DevOps》。本文汲取课程精华要点，如需完整版可观看视频讲解，关注公众号回复关键字【第三课】，获取课程完整版文字内容。

课程完整版（31分钟）

开发生命周期复杂性

从一个非常具体的案例开始，一家欧洲大型电信公司有四个环境：开发、系统测试、EDW预生产和EDW环境。将SQL从一个环境移动到另一个环境需要四个月的时间，这是一个手动过程，他们有很多会议和检查点，还有很多文件要做，有很多审查委员会。这支球队并非刚刚拿到EDW，他们有很多工具，但仅仅将EDW代码转移到生产中太慢了。所以你可以想象商业客户会说，“我想在我的数据仓库里有新的数据集。”所以有了一个源表，必须能够将其可视化。

进入数据仓库需要四个月的时间，再过一两个月才能实现可视化。六个月过去了，你可能会想为什么客户会对数据和分析团队翻白眼并不停地说：“他们太慢了”或“我要雇一个咨询机构来做这项工作。”这是因为他们有期望，如果第二天能从加州运来一个盒子，出现在他们家门口，为什么他们明天不能把一个新的数据集放进仪表板？

与Eckerson Group就“将变更部署到生产中需要多长时间”进行了调查，大约76%的人行动太慢，很多人需要数周或数月的时间才能将开发中的东西部署到生产中。

组织环境的复杂性、部署的缓慢性，以及在不同地点工作的不同人员的组织，这些特征促成了挑战。

数据和分析开发

那我们该如何应对呢？这里有一句格言：这不是对做出改变的恐惧，而是从做出改变中消除恐惧，这是你如何改变注意力的另一个想法。

让我们用一种非常简单的方式来思考这个问题，把你所做的所有数据和分析，Python代码的工厂，ETL代码和VS代码等等想象成一个大管道。数据从一边进入，从另一边进入仪表板。想象上面有红绿灯，写着绿色是好的，红色是有问题的，黄色是警告。因此，在这些管道中有许多管道，每个正在开发或执行的人都在管道中工作，还有大量的工具和生产数据，我们只是想让一盏灯说：“生产中的东西正在发挥作用。”

考虑在部署和DataOps方面所做的工作，非常简单的方法是：“一条生产管道，在开发环境中与开发团队一起反映的点，想要的不是生产数据，而是测试数据，希望能够在开发环境下运行它。在管道中添加的更改并没有破坏任何东西。然后有安全可控的过程，用测试数据和开发人员从开发环境中获取这些数据，并将其投入生产。”想确保当你有东西在生产时，你可以改变它，并以安全、可控和无风险的方式部署它。

这个想法是什么？首先，恐惧是一件好事，不要冒太多风险，但你还要真正的倾听恐惧。DataOps宣言的前三个原则是如何专注于快速部署和无畏部署的理念基础，第一是不断满足你的客户，这意味着不要花三、四、五、六个月的时间来建造一些东西，更快地把东西摆在客户面前，这样你就可以得到反馈，因为他们可能会说不需要它，这样你就省下了几个月的工作。或者他们可能会给你另一个方向，商业人士或消费者需要看到、感受和接触分析。

让一些东西发挥作用，也许不是最好的模型，不是准确的数据，但让一些东西起作用，然后从那里改变。拥抱变革，很多人花了很多时间专注于新功能，他们在生产中得到了一些东西，但他们害怕碰它，他们没有接受改变，而是推迟了改变。

因此，这些关于关注客户、让事情发挥作用和拥抱变革的原则，实际上意味着你的团队最终会最大限度地学习。这就是它的意义所在，如果你能快速迭代，得到足够有效的反馈，并且能在不杀死自己或制造大量技术债务的情况下改变它，那么你就处于一个很好的位置。

如何实现快速部署

假设有一位营销副总裁，一位数据工程师和一位数据分析师，他们的数据工作是在Pentaho中完成的（Pentaho是一个开源ETL工具），可视化是在Tableau中完成的。并没有特别局限于任何ETL工具或ELT工具，它可以是Pentaho、Informatica或Talend，也可以是你喜欢使用的任何工具。同样，不受特定BI工具的约束，许多大公司都有这些工具的多个版本。

希望你能够在第二天就可以给客户细分，这样做不会让你的团队感到压力，不会造成很多技术债务，也不会造成风险或无人管理的噩梦。

这意味着什么？在实践中，有时当你想做某事时，你必须引进一个新人。在这个演示中，称之为数据科学家，这位数据科学家有自己的工具，一个Jupyter笔记本，他们必须做好自己的工作。在很多情况下，数据分析师可以在Tableau中作为计算字段进行分割，也许这已经足够好了。但很多时候，你必须让每个人都参与进来，必须更改数据库，添加模型，更改可视化，所以整个团队都需要一个工作的地方。

数据工程师在Pentaho中构建了一些东西，并开始运行。事实上，他们用了自己最喜欢的工具来做这件事，台式机或服务器上都有Pentaho，Pentaho本身创建了这些名为KTR文件的文件，这些只是Pentaho应用程序创建的XML文件。数据分析中几乎每一个工具都有一个编辑器、一个引擎和一个实际存储工作的文件，把它们放在Docker容器里。但最重要的是，当运行它们时会对其进行测试，从ETL过程中获取数据，并与之进行简单的测试比较，以确保正确性，当系统运行时创建了一个叫做订单运行的东西。

所以它成功地完成了在生产中运行，这意味着我们的分析是在客户面前进行的，此时五个灯都是绿色的。数据和分析方面的挑战之一是当事情在系统中进行时是很难发现的，如果背后发生了变化或破坏，它会如何影响前端，通过用一堆测试来装饰整个系统。这是在Pentaho上运行的一个测试，以确保它运行正确，将进入Tableau并从中提取数据，以确保它是正确的，因为如果你的数据提供商给了你糟糕的数据，那么怎么知道这不是问题的焦点？这是系统中每个节点中的逻辑或if-then-else或代码，这就是测试的原因。

DataOps部署：超越DevOps

这就是数据厨房中的目标，使其快速自动化，这样部署就不需要几个月，可能需要几个小时或几分钟，部署时失败风险非常低，成功率很高。

每个人都认为，应该很快将开发人员的工作投入生产，身边的软件人员都在谈论CI和CD、持续集成和部署。他们在谈论能以多快的速度将JavaScript代码从盒子中投入生产。在一些组织中有这种模式，这些组织实现了部署和单元测试的自动化，但在将开发箱中的东西部署到生产中时仍然存在很多问题。因此，本节实际上是关于为什么CI、CD和单元测试还不够，或者如何超越对软件开发人员的思考，将这些想法应用到数据分析的世界中。

关于DevOps和DataOps之间差异的文章不少，在DevOps过程中，你正在开发软件，正在经历构建过程，在这个过程中要组装所有的工件并编译它们，你正在测试它们，然后将它们部署到web服务器上。这个循环持续的整合，就是在开发过程中发生的事情。签入一些代码，运行一系列测试，确保系统仍然处于良好状态。在一些组织中会超越这一点，按下按钮就会自动部署到生产中。

但这是CI和CD，在DataOps中有些复杂，因为你在管理沙盒方面有很大的困难，仍然有相同的开发，但有更多的工具需要协调。类似的测试和部署，也有协调和监控。因此，DataOps流程与DevOps流程不同也更复杂。在很多方面，DataOps与DevOps的不同之处在于创建沙盒的复杂性，所有这些不同工具、数据和分析的协调，测试和监控最终进行合作，因为很多组织都没有一个数据和分析管道，而是有多个。

接下来谈谈测试，有一种观点认为，测试具有双重性质。如果你还记得一开始，说过在生产中你的代码是固定的，但数据是可变的。因此，当你编写测试时要监控数据的变化，以确保你的客户没有问题。在开发过程中代码是可变的，但数据是固定的，因为使用的是生产数据或测试数据集的副本。在开发中创建的这些测试的目的是不同的，不是试图监控以确保客户不会对你发火，而是试图进行回归或功能或性能测试。事实证明，这些测试实际上可以在很多地方重复使用，也许不是100%，但在生产中运行的测试可以在开发中重复使用，并且它们的用途会发生变化。

测试必须更多地处理历史平衡任务、位置平衡任务、统计过程控制测试，这些测试更多地应用于数据世界，但这些概念适用。关键是，测试单个单元本身并不足以证明当你做出改变时，一切都是可行的，必须测试整个系统。

最后一句格言是：“多个镜头会导致突出显示卷轴。”这就是你为什么要这样做的想法，你想继续尝试，如果你继续努力，你会做对的。当你应用DataOps原则时，你从开发到生产的速度的部署延迟，可以从几周或几个月到几小时或几分钟。