返回

Netflix 如何用 DataJunction 构建指标语义层

RSS Netflix Technology Blog AI 逐段翻译 发布 2026-10-15 03:59
DataHot 速览

Netflix 实验平台在指标定义、发现和信任方面遇到困难,指标、数据集和管道分散且重复。原有系统要求大量业务知识、实验约定和复杂工程实践,新增指标往往需要数周。Netflix 评估了内部 Mando、Airbnb 的 Minerva 和开源 DataJunction,并用 DataJunction 改善数据工作流和洞察获取。

为什么值得关注:该文是 Netflix 第一方实践,讨论指标语义层的选型与落地,对数据平台、实验分析和指标治理从业者有直接参考价值。

本文目录 9 节
  1. 引言
  2. 最初的问题
  3. DataJunction登场
  4. 架构决策
  5. API优先,UI和其他界面稍后
  6. 一致图优先,其他功能稍后
  7. Cube作为完美的消费协议
  8. Netflix的实验
  9. 结论

译文

AI 逐段翻译

引言

我们在Netflix从数据到仪表盘的旅程,尤其是在实验平台领域,始终呈现出一系列独特的挑战。本篇博文旨在阐明这些障碍,并解释一个创新的开源指标平台如何帮助我们克服其中的一些挑战。我们将展示DataJunction在简化我们的数据工作流以及增强我们从海量数据集中获取有意义洞察的能力方面所发挥的关键作用。

指标是数据驱动决策的基础,但在许多组织中,它们分散各处、定义不一致,且难以发现或信任。在Netflix,这一挑战最初在我们的实验平台中显现出来,因为可靠的指标对于解读测试结果至关重要。但原始工具的复杂性使得在指标定义和取值两方面都很难理解和内省这些指标。

最初的问题

分散的指标定义、冗余的数据集和流水线,往往是一家拥有庞大而强大的分析团队的快速发展公司的自然产物。这是大型数据驱动型企业中的普遍问题,而且很难跨多个部门解决,因为这些部门通常受制于略有不同的规则和条例。一个易用、治理良好且集中化的语义层可以帮助解决这些问题。我们最初的问题在实验平台团队中最为明显,那里的先前系统要求:

  • 广泛的业务知识
  • 熟悉实验惯例
  • 以及复杂的工程实践

这导致指标编写流程需要数周时间,对于希望向实验平台引入新指标的数据科学家和分析工程师来说,这是一个令人望而却步的要求。

DataJunction登场

为了解决这个问题,并为未来走上成功的语义层解决方案之路,我们考察了几个候选方案。在我们评估的其他方案中,有Mando(一个内部框架)、Minerva(来自AirBnB的开源语义层)和DataJunction(另一个开源解决方案,简称“DJ”)。它们都有各自的优势,但DJ提供了当时其他方案所没有的一样东西:一个可靠的SQL解析和SQL生成引擎。在POC时,DJ也是唯一一个将其所有定义存储在连通图中的开源解决方案,类似于关系数据库在其视图和查询上存储元数据的方式。轻松的“SQL处理”加上丰富的元数据,是说服我们将其用于当前用例的主要特性。

DataJunction起源于一个类似的内部Facebook项目,由数据科学与基础设施(DSI)团队在(大约2015年)创建,主要是为了满足指标可移植性的需求。在Deltoid项目——当时Facebook的主要实验平台——的多次迭代中,用户想要迁移到下一个版本的Deltoid时,必须重建并重新填充他们的指标。但在实现了DJ并抽象出所有指标定义之后,团队通过将指标与统计计算平台之间的关注点分离,实现了无缝迁移。该项目随后更名为MDF(指标与维度工厂),并被推广为一个被各部门广泛使用的通用语义层。2021年,Facebook的一位工程师(Beto Dealmeida)启动了DJ Github项目并构建了一些基本功能。随后,他们与Netflix的一些人一起进一步扩大了范围,不久之后该项目被引入Netflix。在该项目被引入后,三位Netflix工程师(本博文的作者)与几位外部贡献者,尤其是Nick Ouellet,一直在构建该平台的其余功能。

架构决策

在Netflix构建DJ时,一个关键的设计约束是资源稀缺。我们拒绝在产品品质上妥协,而是选择限制功能集。尽管DJ显然能够同时解决各种用例中的许多问题,但缺乏足够的资源和官方支持意味着我们在两年多的时间里将其作为一个副项目来开发。我们希望展示其价值最终能够赢得管理层的关注。

API优先,UI和其他界面稍后

指标平台不需要花哨的前端就能带来价值——其核心是语义层,它存储一组一致的维度和指标,并通过丰富的API服务提供这些信息。你可以在下面看到我们在Netflix实现中如何组织DataJunction的主要组件。我们的DJ服务(位于中间)与底层数据(位于左侧)交互,并根据客户端请求,以带有元数据的SQL形式或直接以数据形式向我们的访问层提供业务定义。

一致图优先,其他功能稍后

一个完整的语义层系统可能看起来像一只章鱼,它的触手伸向许多功能领域,并且可以从为某些数据集存储的基本语义元数据扩展到完整的仪表盘功能。让我们列举其中的一些:

  • 语义元数据的编写、管理和监控
  • 指标和维度的查询/定义生成
  • 指标和维度数据生成(需要查询引擎)
  • 数据可视化和数据追踪
  • 性能优化(即缓存或物化)
  • 与其他工具的集成层,以及
  • 上述任何/所有功能以以下形式提供:UI、API、客户端库、MCP服务器等等。

当然,要在所有这些层面提供同类最佳的功能是极其困难的,因此我们这个小型的“非官方”团队决定专注于最重要的一块:坚实的语义层引擎(以及API),能够解析SQL作为图的输入,并生成SQL作为服务层。这是系统的核心,其他一切都可以稍后以较少的投入添加,而无需重建核心。

Cube作为完美的消费协议

分析型多维Cube几十年来一直是一个基本概念,其表示形式已集成到各种数据处理和分析平台中。虽然不同工具之间的定义和功能可能有所不同,但它们都服务于封装或抽象语义对象子集的共同目的。

在DataJunction中,我们将Cube作为一等特性采纳,主要有两个原因:用户对它们熟悉,以及它们适合作为服务接口。它们高效地同时提供语义定义(指标和维度)和快速数据访问。请参见下方数据“流”图(虚线)和维度关系图(实线)的示例。

我们简化了基本Cube的创建,使它们能够轻松聚合共享指标和维度的任意集合。此外,对于任何与DJ集成的客户端来说,访问、管理和可视化这些Cube都很直接。定制集成,例如Netflix内部快速Druid数据分析工具(Data Explorer → 见下文),变得易于构建,我们还让直接在我们的Druid集群中物化这些Cube变得容易。

DJ最强大的客户端集成之一,是能够将任何源自DJ的指标定义链接回DJ生态系统。这创建了一个有价值的反馈循环:如果业务仪表盘显示包含指向定义来源链接的DJ定义指标,那么对它们进行故障排查和内省就变得简单。这个链接随后使得通过修改现有指标来检查和运行临时分析成为一个微不足道的过程。这种集成不仅在我们内部工具中可行,在其他知名的开源产品中也可行,例如Superset。

Netflix的实验

指标是实验的支柱。它们将数据转化为信号,告诉我们某个变更是否有意义、是否安全、是否值得扩展。没有可信的指标和维度,实验就有变得无结论或误导的风险,因此一个稳健的指标层对于数据驱动的决策至关重要。

在Netflix,集成到实验平台中的原始指标层过于复杂。创建新指标不仅需要关于实验数据产物的部落知识,还需要熟悉复杂的工程工作流。这种不必要的摩擦意味着上手一个新指标可能需要数周时间,从而减缓了新指标的采用并阻碍了实验。

这就是DataJunction发挥作用的地方:它提供了一个中心枢纽,用于定义指标和维度,可以通过语义图轻松共享和探索。它还提供灵活、用户友好的界面(包括UI、API和各种客户端),使用户轻松编写和管理他们的指标及其他语义模型。

结论

在DataJunction很好地支持了实验领域之后,我们希望采取下一步,统一Netflix的一般分析,并使Netflix用户更容易做到以下两点:

  • 跨垂直领域查找和使用指标定义(在DJ中定义)
  • 轻松访问、修改和试验Netflix数据栈中的新指标

这将需要在DJ和其他工具之间构建强大的集成,但这已经在进行中,而且是这个项目中最令人愉快的部分之一,其中大多数功能已经存在,我们只是让现有系统以结构化且可靠的方式交换信息。有了像DataJunction这样的系统,我们的内部LLM可以提供关于业务指标的可靠信息,以及解释它们如何在Netflix中定义和使用。

相关资源:

  • 2023:Netflix的DataJunction(幻灯片)
  • 2025:DataJunction在Data Engineering Open Forum 2025的演讲(视频)
  • 2025:DataJunction:统一实验与分析(博客)

DataJunction作为Netflix对现代数据栈缺失部分的回答最初发表于Netflix TechBlog在Medium上,人们通过突出和回应这个故事来继续对话。

这篇内容对你有用吗?

反馈只用于改善内容筛选,不等同于收藏

分享这条资讯
分享海报
保存图片
iOS 也可以长按图片保存