有没有人知道 cnzz 这种统计的 后端计算架构是怎么样实现的 那么海量的数据实时(雾= =.相对实时的)处理

好奇＋ 1

HyperLogLog

@YouXia 这样用来做统计会不会准确性不佳 能细讲些么

@0x5010 正好最近给公司项目做了一个这个,前端只管上传数据,服务端的接口收到数据后只管保存本次的访问数据,不进行任何计算,然后由一个或者多个队列程序专门来跑这些数据,及时性要看数据量的大小,大了肯定都会有一点延迟的

这种各站点的统计数据互相独立的，只要堆机器和内存缓存就好了，哪里需要什么架构。

@lincanbin 主要 cnzz 免费用户那么多, 那些硬件成本非常高的 不可能无脑堆

@penjianfeng 模型肯定是这样 主要 后端的存储结构应该如何做才能满足那么多人的查询的及是返回 而且要考虑空间成本和计算成本 所以对他们的设计比较好奇

曾经在 cnzz 现在合并的公司做过几年研发，大概知道一些。

@0x5010 数据库直接存储的是统计结果,前端直接取数据,不涉及任何计算

你的零点的时候刷 cnzz 会发现数据不见了。
做类似服务的时候是先入内存再入库，然后进程定时统计数据。

@penjianfeng 后端需要呀 不可能那么大的数据都入库肯定是经过计算聚合然后在入到存储的结构里去的

@audi 大大能否讲解一二?

kafka 前端收集，中间上 spark 、 storm 等分布式流处理，后面处理结果放到 hbase 或 phoenix 甚至 redis 供查询
总计算延迟基本 15 分钟内
然后，性能不够就加机器扩容....

这种其实跟群租户概念差不多，所有免费用户都是相对独立的，那么主服务器只要根据用户 ID 做一个负载均衡式的分流就好，化整为零，做实时存储都没问题。理论上可以毫无技术含量的支撑无线大的流量。

我倒想知道百度是怎么做的，搜了增高，广告立马全都变成增高

@stabc 可是有的但个的量一天就好几十亿了,比如嵌入在广告里面的统计代码 而好几层基本一层一个
而且这样的情况很多,一天单单聚合这么大数据的计算量是非常大的

@des 百度用户量多呀而且有帐号.每个用户相当于永久的 cookie.百度自己的广告识别你的 cookie 然后就知道你的搜索记录了 有符合你的广告优先返回 没有就返回关键字广告咯

曹政在公众号写过文章介绍了一点，可以去找找

楼主， CNZZ 和 51LA ，这俩统计，都是从个人网站起家的。
SO ，先听听站长本人怎么说：
http://www.1982y.com/index.php/archives/176
http://www.ajiang.net/article/artview.asp?id=1109

@0x5010 我其实是相问百度那么多用户，他们是怎么做到这么多数据的实时

有时候他位的统计也有问题。明细里面有。概览没数据

每一次点击 /事件等都入数据库，经 hadoop 定时聚合计算后放到数据仓库 ( Data Warehouse ) 里，再从数据仓库生成报表。 No-SQL 兴起后这个流程应该有所改进。有技术含量的是 Google Analytics 的 ad-hoc 报表，就是用户可以添加包括手工输入正则表达式在内的各种条件细分后实时生成报表的功能，这不是光靠堆设备就能解决的。至今国内大部分统计系统都模仿不了，大家都是加几个预设写死的条件做个细分的样子。

@0x5010 我跟公司写过这种统计大概每天统计请求一百万吧，这个并没那么难，如果只是存储访客信息， nginx+tornado*4 然后用 mysql 存储就行，为了让 mysql 压力小一点 100 次请求才提交一次事务，机器配置也不高 2core+4g 内存。
如果是做广告 dsp-trace ，有几种方案可以做
1.给用户设置 cookie ，请求接口将广告显示出来，然后后台数据库用 redis 设置一个 kv 就行（某个用户 某个时间访问了某个广告的 ID ），聚合的时候根据 cookie 去找，很容易通过这种方式去进行各种维度的聚合，其实去了根据维度去重复后数据量还好（其实产生的时候基本上到 redis 的时候就已经是个完整字典结构了）
2.还有将数据分布存储，隔一段时间 hadoop 或者 spark 进行离线计算，把相关数据库存储到 monogodb 里面去，前端展示结构从 mongodb 里面查询

@gluttony 同意同意同意，超级牛！

这个很难吗？ 无非是堆机器加简单分析 。 感兴趣的可以研究 ga

不了解 cnzz 的，不过做法大同小异。

有两个假设条件：

1. 首先，“实时处理”这个假设，实际应该是批量处理，只不过时间周期较短，甚至级别，达到实时的效果。
2. 然后从数据的纬度来看，是很自然可以按照站点级别进行拆分的。

满足 1 & 2 这两个条件，那么方案就很多了。

数据提交部分，主要面临的问题单个节点支撑不了，所以解决方案：“拆”
1. N 个数据接入节点，将用户上传的数据，按照站点 id 取模（假设模是 M ），写入对应的队列（假设 kafka ）。
2. kafka 后面，挂 M 个消费者，独立处理一条数据流就 Ok ，然后写入 hdfs 或者 mysql

数据存储 & 处理：
就看存不存在在线的实时查询需求了；如果没有相对简单，直接把原始数据存入 hdfs ，然后用 hadoop/spark 直接离线分析就 ok 了，扩展性不是问题

实时分析就看数据规模, mysql, Greenplum 各种方案都有，甚至大厂甚至会定义自己的 olap 引擎。

@gluttony Google Analytics ad-hoc 某种程度上也是靠堆机器，只是 G 家机器资源池子够大，底层任务调度机制各方面做的都很好了，所以不怕这种复杂统计所带来的计算量冲击。

对于那些规模就百来台机器的厂子，要是瞬间来个几百个用户提交几百个复杂的统计，估计直接歇菜了。

每次数据都入数据库的 你们太天真了 08 年奥运的时候，我们给 sohu 做全站流量统计，每天上亿的 pv ，你们就用数据库存吧。。。。这还只是一个站，国内几大门户，中型门户都是我们在做，每天总计几十亿级别的 pv 也直接存库吗？

@audi 求分享

@JiShuTui 手机码字不方便，等上 pc 后简单介绍下。

@audi 期待

@audi 期待兄弟分析学习，如果方便的话

@0x5010 免费用户不给钱，但他们的数据可以卖啊

@audi 关注

penjianfeng 说得很有道理的样子。

我们用的 CNZZ ，加载他们的 js 会随机跳转到别的网站，不知道这个是不是他们盈利的方法？

大家可以研究一下 Piwik 这个开源的基于 PHP+MySQL 的统计，实时统计极为强大，能显示的内容也很多。

类似 @penjianfeng 和 @gluttony 所说， Piwik 也是一样，会定时处理才（比如一小时一次）报表，然后再将访客的日志写入本月、本日、当前小时的表中，算出页面浏览什么的。用户访问时只存储基本的日志，几乎没别的计算量（似乎此过程中都不连接数据库，只写入几个文件）。

Piwik 默认是 150 秒处理一次，但是建议大流量网站设置为一小时一次。

但是查看实时访客，只是读取最新的日志，然后立刻生成，返回结果，完全是实时。

我的 Piwik 就在自己的服务器上，运行的很不错。

https://media.landcement.com/sites/2/20160423145643/image.png

https://media.landcement.com/sites/2/20160423145638/image6.jpeg

@ZE3kr piwik 访问人数少还可以，人多了就要崩了吧

@zeinipiyan Piwik 可以部署集群的，也适合超大流量的。比如开好多个 AWS EC2 负载均衡， auto-scaling ，配合 AWS RDS 使用应该没有问题。但是估计实时访客系统就不准了。

@ZE3kr piwik 非常棒，但是太吃资源了，每次操作 piwik CPU 飙 100..我感觉 CPU 和内存都要爆了

@ZE3kr 你是怎么部署的呢？服务器啥配置呢，还有那个 IP 地位表示也不准确 -.-

@SlipStupig 大站一个站日 pv 好几亿，然后里面广告十多个，基本很多都有统计代码，而且广告位流量经了好几手 好几层 基本也都有统计代码的 这些还只是一个站的量而以， 和百万级别完全不一样，总不能几百倍的你们硬件数量去支撑一个站的统计吧。

@0x5010 硬件只是一部分，而且大厂拿 IDC 机器的价格比你低多了，最大消耗的还是带宽，又不是单点计算，广告代码和静态图片并不在统计方这边，不然不得亏死