关注 iteblog_hadoop 公众号并在本文末评论区留言（认真写评论，增加上榜的机会）。留言点赞数排名前5名的粉丝，各免费赠送一本《数据驱动：从方法到实践》，活动截止至05月02日18:00。

下面文章节选自《数据驱动：从方法到实践》一书。

如何计算热门榜单

用户行为数据在产品功能中的应用多种多样，一个典型且容易理解的例子是各类榜单的计算。几乎所有的小说、视频、音乐等内容网站都有不止一处的榜单，这些榜单主要的数据依据就是用户的行为数据，下面我们来简单看看这一过程是如何进行的。

首先，我们需要采集到用户在产品上的各类行为，例如搜索、浏览、播放等行为，这些行为需要通过 APP 或者浏览器发送，然后到达数据接收服务。

紧接着，我们需要对这些数据进行清洗。行为数据中会存在大量的非法数据，包括机器访问（例如搜索引擎爬虫）、非正常用户访问（例如靠刷量产生的用户），或者干脆直接就是程序模拟的行为数据。这些数据会导致榜单数据不准确，因此需要在这个阶段进行清洗。

由于要兼顾榜单的时效性，实时的数据清洗一般只能利用一个较短窗口期内的数据来做策，并且无法回溯数据。例如对于一个特定 IP 的访问，可能处理了 500 条之后才能判断来自该 IP 的访问是非法的，但是这个 IP 的行为可能已经被用于之前榜单的计算了。

在经过这一阶段之后，我们就可以拿行为数据来计算实时的热门榜单并将其更新到产品上。根据产品需求的不同，可能是秒级的实时更新，也可能是 5 分钟甚至半小时级别更新。

实时的行为数据不能在计算完成之后就丢掉，而需要被持久地存储。因为除了实时的热门榜单，一般的内容网站往往还会提供周榜、月榜等周期的榜单。这些榜单需要更长周期的数据以及更复杂的策略，例如综合考虑播放量、播放时长、评分等信息。并且，在这一阶段我们有了更丰富的信息，可以对数据进行进一步的清洗，例如可以找出那些长期进行刷量的黑名单，以进一步提高数据的可靠性。由于更新周期足够长，在最终的结果被使用之前还可以加上人工的编辑审核，以确保榜单结果符合产品运营的需求。

客服系统中的行为数据

用户行为数据和客服系统的结合也是一个非常实用的例子。例如对于一个在线订票网站的客服来说，如果他接到用户电话的那一刻，就知道这个用户近期做了什么操作，显然会给他的客服工作提供很大的帮助。

类似于第一个例子，我们同样也需要进行行为数据的采集、传输、存储等。不过，这时复杂的数据清洗工作不是必要的，因为绝大多数情况下的非法数据都不会针对某一个具体的人，而少量的脏数据并不会对应用造成干扰。这时我们更希望尽快让数据能够被客服系统查询到，因为客户有可能会在他打电话的同时也进行一系列的操作，这个时候，如果客服能同步看到用户的操作，显然会更有帮助。相反，如果因为不必要的数据清洗导致数据延迟了几分钟，则完全是对资源的浪费。

另外，在这个应用场景中，我们并不是产出一份固定的数据，而是需要实时地根据当前客户的 ID 来查询客户近期行为，这一需求对于数据存储系统也会有一定的要求，即存储系统需要具备根据客户 ID 来进行高并发查询的能力。

值得注意的是，用户在客服系统中也可能会产生一系列的行为，例如客服协助用户进行了退款操作，实际上即是用户发生了一次退款行为。显然，这些行为也会和其他用户行为一样被真实地采集、传输、存储下来，当下一次用户打客服电话时，客服能参考这些行为。

为什么需要数据平台

除了上面提到的两个例子，还有无数个或简单或复杂的数据应用，例如个性化推荐、风控、精准营销等。即使是热门榜单这个看起来很简单的功能，也会随着产品的迭代不断产生新的需求，例如某一个版本可能需要不同打分依据的榜单，或者是产品经理在某一天希望针对不同板块来设计不同榜单的策略。很显然，在功能实现上，我们不可能对于每一个数据应用都单独进行数据的采集、传输或者存储。

虽然产品功能是易变且难以预测的，但是所有这些基于数据的功能依然会有很多的共同点，尤其是它们对于底层基础数据的处理和访问的需求，基本上是稳定不变的。针对这一部分的需求，我们可以抽象出一个比较通用的数据平台，以减少不同数据应用中的重复数据处理过程，让不同的数据应用更专注于业务相关需求的实现，不用纠结于数据从哪来、数据如何访问等重复枯燥的问题。

相对于上层数据应用的易变性，数据平台更要做到以不变应万变，用一个比较通用的架构适应众多的数据需求。需要注意的是，不同的数据应用对于数据的需求并不是完全一致的。例如，我们上文提到的两个例子虽然都是行为数据的应用，但是很显然它们在数据的时效性、准确性、访问能力上都有着完全不同的需求。因此，设计一个灵活而通用的数据平台架构是相当不容易的，需要平台的设计人员对技术架构、产品业务都有非常深入的理解能力以及抽象能力。

数据平台提供的能力

为了支撑多种多样的数据应用，一个数据平台需要具备对数据的灵活处理能力，包括接收、清洗、存储、计算、查询等，整个过程中既要足够高效，又要考虑通用性。

数据接收

典型的数据平台架构如图5-6所示。用户行为数据是一个天然的实时数据流，因此在数据接收层面，必须要提供可靠、实时接收的能力。无论采集端以什么方式进行，最终都应当使用统一的接口将数据发送到数据接收层。

接收层通常不需要复杂的处理逻辑，更重要的是保证接收服务的可靠性以及可扩展性，在面对突发性的流量增长时不会造成数据丢失。

图 5-6　一个典型的数据平台架构

实时订阅

数据到达接收层之后，会被立即写入一个消息队列中，以对下游提供订阅服务。这里基本上没有任何额外的处理逻辑，因此延时是非常低的，通常都在 1 秒以内，甚至只有几十毫秒。

举个例子，一个用户在产品首页搜索了一个关键词“鲜花”，立即会有一条代表此行为的数据被发送到接收层。而后续的一个针对用户近期搜索行为提供推荐服务的模块则可以在 1 秒钟内拿到这个行为的数据，并且在用户访问下一个页面的时候及时提供“鲜花”相关的内容推荐。

需要注意的是，这个阶段的数据是没有经过任何数据清洗的，因此可能会存在大量的非法数据。使用这些数据的下游应用应当具备处理非法数据的能力，或者能容忍非法数据导致的干扰。在上面的例子中，推荐模块主要关注的是一个人的近期搜索行为，而大部分非法数据并不是针对某个具体的个人，因此这里受到非法数据的影响较小。

数据清洗

在榜单计算的例子中我们介绍过，行为数据会存在大量各种行为的非法数据，因此数据清洗对于很多数据应用都是一个必要的步骤。不过，通常来说，除非是能 100% 确定的非法数据，例如没有通过基本的格式校验，否则数据清洗并不会真的完全过滤数据，而是通过对数据附加一系列的标签来标注数据是否非法，例如是否搜索引擎、是否是黑名单 IP 等。其中，部分标签甚至是一个概率值，例如数据清洗模块会标注某条行为数据有 80% 的概率是非人类访问。这些标签从不同的角度描述了一条行为数据的可靠性，下游的应用可以根据各种业务需要，利用这些标签的值来灵活决定是否需要信任某一条行为数据。

由于实时数据清洗的局限性，多数场景下我们还需要定期进行离线的数据清洗，以便进一步标记出非法数据，提高数据准确性。和实时清洗类似，离线数据清洗依然采用标签的方式进行，这些标签可以复用。

数据存储

所有的行为数据最终都需要落到一个持久化的、高效访问的存储系统中。一般来说，像 HDFS 这样的分布式文件系统是一个很好的选择。

但是，正如我们在客服系统中的例子里提到的，不同的数据应用可能需要不同的数据查询访问，HDFS 虽然是一个可靠的存储，但是显然对于根据 ID 进行随机查询这件事情非常不擅长。因此，通常一个数据平台的存储体系都是多个组件相结合，例如以 HDFS 来提供高吞吐的基础存储，以 HBase 来提供随机更新和查询的能力。

数据计算

数据计算是一个更复杂的话题，类似于数据存储，不同的数据应用对数据计算的需求也是各不相同的。前文提到的榜单计算中，就同时需要实时计算和批量计算两种不同的模式。因此，一个数据平台通常应该具备多种计算能力，例如提供以 MapReduce、Spark 为代表的批量计算框架，以及以 Storm、Spark Streaming 为代表的流式计算框架。

API 查询

虽然数据存储层已经提供了完全的数据访问能力，但是底层的接口往往是复杂而难以使用的，并且使用不当可能会导致资源的浪费。因此，对于常见的查询场景，数据平台通常还需要提供一套查询 API，把底层的查询能力进行封装。

上文我们提到客服系统中需要根据用户 ID 进行用户行为序列的查询，这是一个典型的 API 查询的使用场景。同样的 API 还可以被直接用在浏览轨迹、用户行为调研等其他数据应用中。

SQL 查询

SQL 提供了高效、灵活的数据处理能力，在数据调研、数据预处理等阶段都是非常便利的手段。因此，数据平台必须要提供针对用户行为数据的 SQL 访问
接口。

由于用户行为数据的数据量通常是非常大的，我们不建议专门针对 SQL 访问的需求单独进行数据存储，以免导致不必要的计算和存储成本。更合适的方式是基于已有的数据存储，配合合适的 SQL 查询引擎，直接进行数据查询。

具体来说，常见的 SQL 需求可以分为两大类。第一类是统计分析类，例如 PV、UV 等汇总类查询。这类查询的特点是会产生一个较小的结果集，但是对响应时间的要求比较高，例如秒级或者分钟级。第二类是数据处理类，例如格式转换、条件抽取等常见的数据预处理操作。这类查询的特点是产生结果的大小和原始数据集相当，甚至有可能会更大（例如 JOIN）。

在超大规模数据量的平台体系下，针对上述两类需求有可能需要采用不同的 SQL 引擎来提供支持。因此，数据平台中通常也需要支持多个 SQL 查询引擎，以便在合适的应用上选择合适的查询引擎来使用。

总结

用户行为数据可以被应用在产品、服务的各个层面，而底层的数据平台则是这一切的基础。只有构建了一个灵活、易用的数据平台，才能实现高效的数据应用迭代，让数据更快地对产品和服务产生价值，最终实现真正意义上的数据驱动业务。

活动规则

• 关注 iteblog_hadoop 公众号，并在评论区留言获点赞数最高前5名将赠送；《数据驱动：从方法到实践》1本，共送出5本；

• 活动时间：即日起至05月02日18:00点；

• 活动结束后，收到中奖通知的用户请在公众号私信：微信号 + 姓名 + 地址+ 电话 + 邮编；最终快递信息请到本页获取；

• 本活动解释权归Hadoop技术博文所有。