你在电视棒上打开 Netflix，同一个功能能不能用，答案未必只取决于电视棒。它还可能受外接屏幕、内存、处理器、平台和软件版本影响。今天支持，不代表升级前也支持。Netflix要解决的，正是如何把这团不断变化的条件整理成可查询、可统计的数据。
据 Netflix Technology Blog，Netflix为此建立了一套综合设备能力数据模型，并接入内部系统的 feature flags——用于控制某项功能是否向特定设备开放的开关。本文的全部实践与示例均来自这一篇官方博客，尚无独立信源交叉验证。
设备能力不是一张勾选表
Netflix覆盖的内容和功能从4K、沉浸式音频，一直延伸到直播和云游戏。但设备并不具备相同条件：可用 RAM（运行内存）、CPU 核心数、显示能力和平台支持，都可能限制某项功能。
问题在于，这些条件彼此关联。设备能力并非简单的“支持／不支持”。某款设备或许只有在特定软件版本、连接特定显示器时，才能使用某项功能。分析人员若只看到一个布尔值——也就是只有真或假的字段——就很难判断限制究竟来自哪里。
数据建模的作用，就是规定现实中的设备、版本和能力怎样变成表与字段，以及它们如何关联。Netflix的思路是把设备能力拆成可分析的状态，再把这些状态同功能开关结合起来，支持更细粒度的功能管理。
一张表看现在，一张表看分布
Netflix使用 cumulative table（累积表）处理设备能力信息。它保存每种设备及相关能力的最新状态，字段包括屏幕分辨率、支持的视频 profile、环绕声和 RAM 大小等。这里的 profile 可以理解为一组播放能力标记；博客给出的示例包含 720×1280 的屏幕尺寸，以及 playready、hevc 等条目。
这张表回答的是：“这类设备现在具备什么条件？”它适合报表和日常查询，但只看单台或单类设备还不够。产品团队还需要知道一种能力覆盖了多少活跃设备，以及缺口集中在哪些型号和版本。
为此，Netflix又使用 histogram table（直方图表）。它不是画图本身，而是一张预先整理好的聚合统计表：按照设备型号和软件版本，记录过去28天内的活跃设备数，同时统计其中有多少设备支持特定能力。
两张表分工明确。累积表保留最新状态，直方图表把大量设备压缩成可比较的分布。前者像设备档案，后者像人口普查汇总。
外接屏幕让问题更真实
Netflix给出的一个用途，是分析连接到 streaming sticks（电视棒等流媒体棒状设备）的外接显示设备能力。电视棒本身相同，接上的电视或显示器却可能不同。若只按电视棒型号判断，分析就会漏掉真正决定播放能力的那块屏幕。
博客还展示了一组未披露规模的直方图示例：其中全部设备支持原文所称的“HD profile（playready）”，另有一项能力只覆盖20%的设备。但原文在此处截断，没有说明20%对应哪项能力、分母口径和样本量，因此这组数字不能推广到Netflix的全部设备。
为什么值得关注
这套实践有意思的地方，不在于多建了两张表，而在于它把复杂产品能力变成了可以分层追问的问题：某功能覆盖不足，是设备硬件不行、软件版本没跟上，还是外接显示设备不支持？团队可以沿着型号、版本和具体能力逐步缩小范围。
它也提醒我们，功能管理不能脱离分析语境。feature flags负责决定功能向谁开放，设备模型则提供判断条件及覆盖分布。两者接上以后，产品团队才有机会看见能力渗透的瓶颈，而不是只看到一个总开关。
局限与未知
- 博客没有披露表结构、更新频率、数据规模，以及如何处理能力随软件升级变化的历史版本。分析系统通常需要保留这类变化，才能还原某次播放发生时的设备状态，但材料不足以判断Netflix如何实现。
- 材料也没有说明数据血缘——即字段来自哪些原始系统、经过哪些转换——如何记录，因此无法判断能力定义出错后怎样追溯。
- Netflix称该方法能促进更智能、更细粒度的功能管理并加快创新，但未给出量化指标或外部证据，实际提升幅度仍未知。