关于 PV 和 UV 变化与数字的解读

1.概念1.1UV和PV是互联网产品中两个非常常见的指标，通常是分析的最基本指标。一般来说，UV是指使用产品(或产品某一功能)的独立用户数量。PV来自网站时代，一般指网站(或网站某个页面)的页面浏览量。在移动互联网时代，用户行为或用户操作数量通常会延伸到使用产品(或产品某个功能)。一般来说，PV和UV是相互影响和共同变化的，这也是对PV和UV变化和数字解读的深刻理解。由于本文主要介绍了UV和PV在多维分析中的计算规则，因此不讨论PV和UV的具体解释和分析。1.2多维分析和多维分析（BusinessIntelligence）一种广泛应用于该领域的分析技术和方法，可以从不同的角度灵活动态地进行分析。多维分析有两个基本概念：“指标”和“维度”。在这里，我们用一个实际的例子来描述它。一个典型的网站，可能需要从区域、终端、App版本三个角度来考察自己的PV和UV。然后，在这种情况下，有三个维度，即区域、终端和应用程序版本；有两个指标，即PV和UV。所谓多维分析，就是在维度的任何组合下，都可以看到相应指标的值:可以看到北京、iOS、7.1版App的PV和UV。；你也可以看到湖北安卓PV和UV；也可以看到7.2版App的PV和UV。在具体设置查询条件时，维度可以是三个，两个，一个。从这个例子中可以看出，多维分析非常灵活，分析能力强，能够充分满足分析人员对产品各种细粒度的分析需求。为了使多维分析发挥更大的价值，一般希望多维分析的查询结果能在一分钟内获得，使用户能够不断调整查询条件，快速验证自己的猜测。2.正如上面提到的，多维分析对查询速度非常敏感，行业内有很多专门的存储和查询方案。在具体实现中，最常见的实现方法之一是提前计算和存储各维度所有值组合下的指标，一般称为事实表。然后，在进行具体的多维查询时，根据维度的选择扫描相应的数据，并聚合最终的查询条件。这时候会发现一个有趣的问题，就是PV这样的指标是“可加”的，而UV这样的指标是“不可加”的。例如，我们计算并存储了昨天三个维度可能组合下的所有PV和UV，如下表所示，区域终端App版PVUV北京安卓7.19762743北京安卓7.27263531北京iOS7.16549623北京iOS7.25386423湖北安卓7.1297671437湖北安卓7.273681315湖北iOS7.125941236湖北iOS7.2253681432。对于PV指标，最终结果可以通过扫描相应的记录来累积。例如，如果我们想分析湖北的PV，我们可以在湖北的四个相关记录中累积PV，即湖北的PV值。例如，如果我们想分析整个湖北的PV，我们可以在湖北的四个相关记录中累积PV，即整个湖北的PV值。然而，对于紫外线等指标，它不能简单地累积，因为这个指标并不是在每个维度上都是积极的。例如，同一用户可能已经使用了不同的应用程序版本，甚至有一定的机会使用不同的终端。因此，UV不能简单地累积。通常，真正的UV比加起来的值更小。因此，其他计算方案需要用于UV等不可累加的指标。3.UV类型的UV计算指标有三种，我们在这里分别介绍。3.1估算方案所谓估算方案，就是在上表的基础上，不再记录更多细节，而是通过估算给出接近真实值的UV结果。常用的算法有很多，比如Hyperloglog。因为毕竟是估算，最终估算的结果可能和真实值有很大的不同，所以只有一些统计平台可能会采用，而以精细分析为核心的分析系统，比如我们的Sensorsanalytics，这里就不多描述了。3.2扩展事实表，所谓存代算，就是在预先计算事实表时，计算所有需要聚合的结果。以上例子仍然表明，如果我们想用存代算提前完成聚合，类似于Hive提供的groupbywithcube操作。扩展完成后，此表的结果应该是：地域终端App版PV北京289195湖北1051570安卓74026iOS597.168723217.2657.2687.2657.2657.2657.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.26267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.267.27.27.267.267.267.267.267.267.267.27.27.假设每个维度有三个维度和两个值，以前的事实表共有2*2*2=8个记录，但现在已经扩展到3*3*3-1=26个记录，整个规模扩大了很多，会带来更多的存储和预期计算成本。3.3从最细粒度数据上扫描之前提出的扩展事实表的方法，确实可以解决多维分析中指标聚合的问题。此外，还有一种方案，即在事实表上，用户ID也被用作保存UV的维度，如下表所示：北京iOS7.1232312北京iOS7.1462973的区域终端App版本用户IDPV……………………………………………………………………………………………下表:北京iOS7.1232312015-01-01212012:区域终端App版用户ID时间事件:03:北京iOS7.1232312015-01-0124浏览商品:04:08.934提交订单....尽管如此，需要保存的数据规模已经扩大到数量级，所有的聚合计算都需要在多维分析和查询中扫描数据并聚合，存储和计算成本大大提高，这似乎是一个非常冷漠的措施。然而，与之前的计划相比，它有一个最大的好处，即由于用户行为数据的最细粒度，有可能计算漏斗、保留、回访等事件级别，有可能在这些数据的基础上进一步做用户肖像、个性化推荐等。这就是Sensorsanalytics目前采用的数据存储方案。正是因为这个存储方案，我们才能把自己变成一个精细的用户行为分析系统，满足用户对最细粒度数据分析和获取的需求。在这样一个数据存储方案的基础上，为了提高数据查询的效率，一般的优化理念是使用列存储压缩来减少磁盘扫描的数据量，使用分布式方案来提高并发扫描的性能，使用应用层缓存来减少不同查询的公共扫描数据量等，我们将在以下文章中进一步讨论，请期待。