让我们先说，每小时25000k个条目的数据量相当低（甚至不到1/s）。除非您想大规模扩展，否则您的项目将很容易通过单个sql server实现。
无论如何，您有两个选择：

1. 非实时

记录每个visitorid+源并运行作业（如mapreduce），以便每小时或每天根据需要分析数据。在这种情况下，您甚至可以完全避免使用hbase，而只使用hadoop。您可以每小时将数据记录到不同的文件中，然后对其进行处理，并将结果存储在sql中（如果您愿意，也可以存储在hbase中）。就性能而言，这将是最好的方法。

2. 实时

通过使用hbase计数器实时跟踪数据，在本例中，我将考虑使用两个表：
表unique\u users：跟踪visitorid上次访问站点的时间（rowkey将是visitorid+source或just visitorid，具体取决于visitorid可以有不同的源还是只有一个源）。这个表可以有一个3600秒的ttl，如果你想自动丢弃旧数据尽快可以，但我会让几天的数据。
表date\u source\u stats：跟踪每小时每个源的唯一visitorid。根据您的保留要求，此表的ttl可以是几周甚至几年。
当访问者进入您的站点时，您阅读unique\u users表以检查上次访问日期，如果该日期早于1小时，则将其视为新的访问，并在date\u source\u stats表中增加date+hour+sourceid组合的计数器。然后，更新唯一的用户，将上次访问时间设置为当前时间。
这样，您可以通过扫描轻松检索特定日期+小时的所有独特访问，并获取所有来源。您还可以考虑一个source\u date\u stats表，以防您要对某个特定的源执行查询，也就是说，x源的最近7天的每小时报告(您甚至可以使用不同的行键将所有统计信息存储在同一个表中。
请注意这种方法的几点：
我没有太详细的模式，让我知道如果你需要我。
我还会将总访问量存储在另一个计数器中（不管它是否唯一，它总是递增），这是一个有用的值。
这个提议可以很容易地扩展，因为你想跟踪每日、每周甚至每月的独立访客，你只需要更多的计数器和行键：date+sourceid，month+sourceid。。。在这种情况下，可以使用具有不同ttl属性的多个列族来调整每组的保留策略。
这个提议可能会面临热插拔问题，因为行键是连续的。如果每秒有数千个请求，您可以在这里阅读更多。
date\u source\u stats的另一种方法可以是选择一种广泛的设计，其中只有一个sourceid作为rowkey，date\u hour作为列。