我一直对过滤器在HBase中的工作方式感到困惑（或者，在很大程度上等同于HappyBase - 我用它与HBase交互）。我混淆的原因是我似乎无法处理过滤器的作用。
某些过滤器（如SingleColumnValueFilter）会导致不根据其中一列的值发出行。这是有道理的 - 在我看来，这就是过滤器的用途。但是，其他过滤器（如FirstKeyOnlyFilter）似乎不会按行方式进行过滤，而是过滤显示给请求者的数据 - 即，它们按列列式过滤columns参数。不仅如此，它们似乎也会影响其他过滤器是否可以访问数据。
也许我只是错误地使用它们。但是，对我来说，“过滤器”应根据对其属性进行操作的输出删除项目，例如“找到所有超过7英尺高的人！”但FirstKeyOnlyFilter的行为，至少在HBase中，似乎更像是“把我的每个人留给耳朵而不是别的！”此外，如果我有一个像：
SingleColumnValueFilter('body', 'height', =, 'regexstring:^over7ft$') AND FirstKeyOnlyFilter，FirstKeyOnlyFilter似乎限制第一个过滤器访问列族：列“body：height”。
这个设计选择是什么？上面的过滤器看起来像是在说，“让我明白7英尺高的每个人的名字！”但更确切地说，如果名字是7英尺高，那就更像是“给我一个名字！”一行中的第一个键没有列，只能说名称具有“高度”。
我做错了什么？这是HappyBase的特点还是在HBase中是相同的？
答案 0 :(得分：2)
在每行的可用列上对两者进行过滤匹配。
正如您所注意到的，某些HBase过滤器会限制返回给客户端的列。这是一种有意的设计选择，可减少客户端调用期间使用的内存和网络资源量。
回想一下，HBase实际上是一系列键值对的rowkey映射（键值中的键被称为列限定符）。它们不是严格的集合，因为底层数据抽象实际上是一个rowkey + columnQualifier to value（一个Cell）。过滤器在单元级别工作。这也是为什么建议列限定符很短的原因，因为它们实际上存储了每一行/每个值。
Timing-Allow-Origin旨在尽可能少地返回数据，同时保持知道rowkey确实存在并带有一些键值映射。它可以是返回的任何键值映射。
或者，您可以使用FirstKeyOnlyFilter代替KeyOnlyFilter，这将使与返回的每列关联的值无效。这应该使您能够根据需要进行匹配，同时最小化返回的数据。