定义数据字段后，您可以在定义群体中使用它。这里有一个例子，它要么匹配 Gmail 和 Yahoo 用户并且显式排出两个特定的用户，要么匹配[email protected]这个用户：

　　因为可以运行任意逻辑计算，所以数据字段十分强大。在 Dropbox 内部定义了很多数据字段，来支持我们所有的用例，不通的团队如果需要他们可以不断得添加新的数据字段。

　　基于 Hive 的群体分类：连接我们的分析数据仓库

　　即使具有创建任意数据字段的能力，我们也面临一个限制：我们只能依赖我们服务器代码可访问的信息（来定义群体），也就是已经加载的模型或数据库中。但是 Dropbox 还有另一个大数据源：我们基于 Hive 的分析数据仓库。有时候 Dropboxer 想要通过写一个 HiveQL 来查询一组任意的用户，这就可以利用各种历史日志和分析数据。

　　为了使 Stormcrow 可以利用通过 Hive 查询获得的群体，我们需要将其从分析仓库移到可扩展的，同时可被生产代码检索的数据存储中。为此我们构建了一个每天运行的数据管道，它将当天的所有基于 Hive 查询的群体导出到生产环境中。

　　这种方法的主要缺点是数据滞后。与数据字段不同（数据字段总是生成最新的数据），基于 Hive 导出的数据库仅仅每天更新一次。虽然这对于某些类型的开关是不可接受的，但它对于群体变化缓慢的场景来说很有用。

　　基于 Hive 的群体分类体现了表达力和数据新鲜度之间的权衡：对复杂分析数据执行特征开关比对常用数据进行开关具有更多的滞后和数据工程工作。

　　派生群体：从简单的群体定义中构建复杂群体

　　Stormcrow 最强大的功能之一是定义群体的能力。比如派生群体，下面示例是一个群体，它匹配 a）“Android设备”用户和 b）功能 recents_web_comments值为 OFF。

　　这个功能帮我们避免了有些复杂匹配规则不断得被复制和粘贴。相反，Dropbox 的功能开关旨在构建一组核心的基本群体，可以混合和匹配以满足任意复杂的匹配需求。我们在实践中发现，设计派生群体层次结构与重构代码非常相似。

　　实际上，可以将派生群体视为替换代码中的 “if” 语句，以便在实验之间进行选择。而不是写形如“如果用户匹配在实验 A 中就显示东西 A，否则如果匹配在实验 B 中就显示东西 B”这样的逻辑。

　　选择器推断：通过推断附加信息使得 API 更易于使用

　　像其他复杂的软件系统一样，我们的代码中使用了很多 Dropbox 内部模型。例如，user模型表示单个用户帐户，team模型表示 Dropbox 业务团队。identity模型代表配对的帐户：它将个人和商业用户模型绑定到单个对象中。我们所有的模型都通过各种一对多和多对一的关系连接。

　　在 Dropbox 产品代码中，我们通常可以访问一个或多个这类模型。为了开发人员的方便，如果 Stormcrow 理解我们的模型关系就可以自动推断额外的选择器。例如，开发者可以访问用户对象 u并且希望查询针对团队而开关的功能。 他们可以这样写：

　　Stormcrow 自动推断来获取更多的信息，所以开发人员只需要写：

　　在 Stormcrow 中，我们将 Dropbox 的模型关系表示成一个图，我们称之为选择器推断图。在这个图中，每个节点都是模型类型，直播，从节点 A 到节点 B 的边意味着我们可以从模型 A 推断除模型 B。当 Stormcrow 调用时，我们做的第一件事是获取指定的选择器，接着在图中计算其传递闭包（transitive closure）。

　　当然，推断可能因为额外的计算或网络调用而造成性能损耗。为了使它更高效，推断会产生 thunk，它们会被延迟求解（evaluate），这样我们只有在实际需要选择器来作出开关决策时才计算它们。 请参阅下面的“性能风险”