当前位置:首页 > 知识库 > 正文

netflix技术架构 刷访客网站

客服   dy抖音ks快手 自助商城点击进入

在Netflix,我们投入了大量的努力,将Notebooks作为一个综合开发平台超越互动:看Netflix是如何将Jupyter Notebook使用到极致的。这个想法开始于对未来开发和协作接口的讨论。它发展成为一个战略赌注在Notebooks上,既作为一个互动的用户界面,也作为统一的基础,我们的工作流调度程序。在过去的一年里,我们在这方面取得了重大进展,目前我们正在迁移Netflix数据平台上运行的所有10,000个计划作业,以使用基于Notebooks的执行。当我们完成后,每天将有超过15万个Genie jobs运行在我们的平台上的Notebooks上。

故事的起源

在考虑分析工具的未来时,我们最初问了自己几个基本问题:

· 数据科学家将使用什么接口将统计分析的结果与业务通信?

· 数据工程师如何编写代码以确保每小时运行一次?

· 机器学习工程师如何封装他们的同事可以重用的模型迭代?

我们还想知道:是否有一个工具可以支持所有这些场景?

一个有希望的工具是Jupyter notebook。在Netflix,Notebooks已经被用于数据科学,但也越来越多地用于其他类型的工作负载。由于其灵活性和高扩展性,加上其庞大而充满活力的开源社区,Notebooks是一个引人注目的选择。因此,我们深入研究了如何将其用作用户的公共接口。

Notebooks本质上是托管的JSON文档,具有一个简单的接口来执行其中的代码。他们擅长通过单元来表达迭代的工作单元,这使得报告和执行隔离更加容易。此外,使用不同的内核,Notebooks可以支持多种语言和执行模式。这些属性意味着我们可以为高级用户公开任意级别的复杂性,同时为消费者呈现更容易遵循的叙述——所有这些都在一个文档中。

我们知道,我们选择的任何工具都需要能够调度工作负载。随着Jupyter notebook的潜力越来越明显,我们开始考虑如何安排一个Notebooks。Notebooks的特性虽然非常适合交互式工作,但却不适合按计划执行。如果您已经熟悉Notebooks—包括它们的优点和缺点—您甚至可能认为我们将所有etl工作负载都转移到Notebooks上有点疯狂。

战胜苦难

从表面上看,Notebook带来了很多挑战:它们经常被更改,它们的单元输出不需要匹配代码,它们很难测试,而且没有简单的方法来动态配置它们的执行。此外,您需要一个Notebook服务器来运行它们,这将创建体系结构依赖项来促进执行。这些问题引起了一些内部对这个想法的反对。但随着我们为Notebook生态系统引入新的工具,这种情况已经发生了变化。

对我们来说,最大的游戏规则改变者是Papermill()。Papermill是一个nteract库,它考虑到生产生态系统,为Notebook的可配置和可靠执行而构建。Papermill的工作相当简单。它采用一个Papermill路径和一些参数输入,然后使用呈现的输入执行请求的Papermill。当每个单元执行时,它将生成的工件保存到一个单独的输出Papermill中。

Papermill使我们在处理Notebook文档时实现范例更改。由于Papermill不修改源Notebook,所以我们在工作定义中添加了一个函数属性——这通常是Notebook空间中缺少的。我们的输入(一个notebook JSON文档和输入参数)被视为不可变记录,用于生成不可变输出文档的执行。该单个输出文档提供了执行的代码、每个代码单元的输出和日志,以及一个可重复的模板netflix技术架构,可以在将来的任何时候轻松地重新运行该模板。

Papermill的另一个特点是它可以从很多地方读写。这使我们能够存储我们的输出Notebook与高耐用性和方便的访问,以提供一个可靠的管道。今天,我们默认将输出Notebook存储到一个s3 bucket中,这个bucket由commuter()管理,这是nteract的另一个项目,它提供笔记本的只读显示。

因此,无论哪个系统最支持我们的用户,输出Notebook都可以成为独立的记录。这使得分析作业或相关工作就像链接到服务或S3前缀一样简单。用户可以使用这些链接来调试问题、检查结果和创建新模板,而不会影响原始工作流。

此外netflix技术架构,由于Papermill控制自己的运行时进程,我们不需要任何notebook服务器或其他基础设施来针对notebook内核执行。这消除了托管Notebook服务带来的一些复杂性,因为我们是在更简单的上下文中执行的。

为了进一步提高notebook的可靠性,我们将notebook推入git,并在对使用Papermill的notebook进行测试后才将其推广到生产服务中。如果一个notebook变得太复杂而不容易测试,我们有一个本地存储库,我们可以将代码合并到一个更传统的包中。这使我们能够在将notebook作为传统代码推广方面获得常规CI工具的好处,但仍然允许我们使用notebook作为集成工具进行探索和迭代。

因此,我们的notebook被版本化,在执行之前和之后作为不可变的记录推送到可靠的数据存储中,在它们可用之前进行测试,并在运行时使专门化参数化。用户友好但不可靠的notebook格式现在对于我们的数据管道来说是可靠的,而且相对于非notebook执行模式,我们获得了一个关键的改进:我们的输入和输出是完整的文档,完全可执行,并且可以在同一个界面中共享。

Notebook Scheduling

即使有一个支持测试、版本控制和Notebook显示的平台,我们仍然缺少一个关键组件,以使用户能够定期运行带有触发执行的工作——或者更简单地说,我们需要一个调度层。通过web界面执行一个Notebook对于用户的视觉反馈和反应性反馈非常好,但是一旦你有了工作,你就需要一个工具来代替你执行。

这个方程的执行面用Papermill是容易的。我们可以计算运行时参数并将它们注入到Notebook中,运行Papermill,并将结果存储到数据仓库中。该体系结构将参数化的Papermill与调度解耦,在选择调度程序时提供了灵活性。因此,几乎任何cron字符串和/或事件消费工具都可以运行我们到目前为止设置的工作。

这意味着只要有一些基本功能,就可以轻松地调度Notebook。相反,您将在这里花费精力选择您最关心的调度程序的次要属性。您可能希望重用团队已经熟悉的工具,或者选择满足其他操作需求。如果您没有首选的调度器,或者以前没有使用过调度器,那么Airflow()是一个开源工具,可以很好地发挥这个作用。

在我们的例子中,我们关心的次要属性是:

· 为外部事件触发或等待功能

· 能够在受控执行环境中启动(例如Docker)

· 捕获并公开关于执行和失败的度量

· 并发控制

· 动态重试的可配置性

· 可靠性团队代表用户进行调解的能力

这些需求给我们留下了一些可以考虑的潜在选项,包括开源和闭源解决方案。在彻底研究了我们的选项之后,我们选择了Netflix开发的一个名为Meson()的调度程序。Meson是一个通用工作流编排和调度框架,用于跨异构系统执行ML管道。我们选择Meson的主要原因之一是它对Netflix现有基于云的基础设施(包括我们的数据平台)的深度支持。

用户工作流程

有了适当的调度程序,开发人员将如何看待这一点?让我们研究一个假设的数据工作流。假设我们希望按设备类型聚合视频播放,以了解我们的成员使用哪些设备来观看内容。因为我们是全球性的,所以我们需要按地区划分聚合,这样我们就可以了解世界各地最流行的设备。而且,一旦每天的结果准备好了,我们想把更新后的报告推送给我们的分析师。

首先,我们需要一个工作流程的时间表。假设每天凌晨2点。大多数调度程序接受crontab作为调度触发器,因此一个0 2 * * *就满足了这个要求。

接下来,我们需要将工作分解为逻辑工作单元。我们希望收集数据,聚合数据,并向用户报告结果。为了表示这项工作,我们将定义一个DAG(),其中每个作业都表示为图中的一个节点,每条边表示成功运行后的下一个作业。

在这种情况下,我们需要四个Notebook。一个是收集我们的输入数据。一是用地理信息增强我们的原始数据。每个区域参数化一个。一个是把我们的研究结果写进报告。例如,我们的聚合Notebook可能有一个参数化的执行,比如:

我们有几行代码来执行一个简单的SQL语句。您可以看到,在单元格[4]中,我们从Papermill注入的参数覆盖了默认的region_code。run_date已经是我们想要的,所以我们将保留默认值,而不是覆盖它。

然后调度程序执行一个简单的命令来运行Notebook。

papermill s3://etlbucket/jobs/templates/vid_agg.ipynb s3://etlbucket/jobs/outputs/${timestamp}_vid_agg_fr.ipynb -p region_code fr

Done!很简单,不是吗?现在,这是一个人为设计的例子,可能并不能反映我们的数据工程师实际是如何进行这项工作的,但它确实有助于演示在工作流中如何将所有东西组合在一起。

服务自愈

在将新技术引入平台时,需要考虑的另一个重要方面是调试和支持用户的能力。对于Notebook,这可能是我们的调度器系统中最有益的方面。

让我们深入探讨一下如何应对失败。假设我们前面的例子Notebook出了问题。我们如何调试和修复这个问题?我们首先要查看的是Notebook的输出。它将具有堆栈跟踪,并最终具有与错误相关的任何输出信息。

在这里,我们看到我们的工作找不到主机名。错误的主机名。这可能不是用户输入错误,因此我们可能需要更改模板以获得正确的主机名。在传统的调度程序情况下,您需要创建作业执行环境的模拟,或者尝试进行更改并重新提交类似的作业。在这里,我们只是简单地使用输出Notebook和我们失败的运行时参数,并将其加载到一个Notebook服务器。

通过几次迭代并查看我们的作业库方法,我们可以快速找到故障的修复方法。

现在已经修复了这个模板,可以将其推到源Notebook路径。以后的任何执行,包括重试失败的作业,都将获取并运行更新后的模板。

Notebooks 整合

在Netflix,我们采用Notebook作为集成工具,而不是library的替代品。这意味着我们需要采用良好的集成测试,以确保我们的Notebook能够顺利执行,并且不会经常遇到bug。因为我们已经有了参数化执行模板的模式,所以我们重复这些与虚拟输入的交互,作为对线性代码路径的测试。

papermill s3://etlbucket/jobs/templates/vid_agg.ipynb s3://etlbucket/jobs/tests/.ipynb -p region_code luna -p run_date 2017_01_01

这意味着我们没有使用Notebook作为代码库,因此也没有迫切要求在Notebook上进行单元级测试,因为这些测试应该由底层库封装。相反,我们提倡Notebook开发的指导原则:

· 低分支因素:保持你的Notebook相当线性。如果您有许多条件或潜在的执行路径,就很难确保端到端测试能够很好地覆盖所需的用例。

· 库中的库函数:如果您最终得到了可以独立重用或重构的复杂函数,那么这些函数很适合作为编码库而不是Notebook。在git中提供您的Notebook意味着您可以将共享的单元测试代码放置在与您的 Notebook相同的git中,而不是试图对复杂的Notebook进行单元测试。

· 短小精悍更好:一本用几个简单的单元格生成大量有用输出和视觉效果的Notebook胜过一本十页的手册。这使您的Notebook更易于共享、理解和维护。

当遵循这些指导原则时,我们可以很容易地指导和支持我们的用户跨越广泛的用例和底层技术。

未来展望

通过到目前为止概述的选择和技术,我们已经能够开始构建我们在本文开头描述的共享体验。Netflix的内部用户今年增长迅速,我们提前完成了完全替换之前的ETL和报告模式的计划。

但我们还远远没有完成。我们仍然有工作要做,以改善开发经验和易于采用。也就是说,我们希望为使用nbdime()等工具的Notebook提供更好的代码审查模式,将CI和平台工具更多地集成到Notebook上,以及更容易地安排和共享Notebook。这些,以及更多有用的改进,将有助于使Notebook成为Netflix跨功能开发的一个共同而简单的入门点。

ref:

发表评论

最新文章

推荐文章