这是一个创建于 1730 天前的主题，其中的信息可能已经有所发展或是发生改变。
广告系统会跟踪一些数据（类似 log ），这些数据专门用来做统计的。
但是由于以后可能量比较大，不想着存数据库（ MySQL ）。
现在一般是怎么好做法？
比如，现在想到的比较笨的方法：
系统会有频繁跟踪数据传过来， 那么我就在 DB 里 [跟踪日志表] 里新建一条记录。
然后定时每 10 分钟汇总一些。记录在 [分小时统计表] 里。 然后再定时从 [分小时统计表] 算出总量，存放 [总量表] 的。
现在是 3 张表。
A - 跟踪记录表
B - 分小时统计表
C - 每个广告的统计总量表
感觉这种方法不好， A 表应该算是非主业务的，不应该与业务表们放在一起。 A 表也会越来越庞大。（大表做统计的话，可能会把 MySQL 搞崩溃掉） 其余两个表是由于 A 来算出来的。
应该会有更好的解决方法，求教
第 1 条附言 · 2020-02-22 08:39:04 +08:00
有人说用 ELK 来做，这种方式是否合适？
（ track 数据发送到 ELK 里，结果再回写到 MySQL ）
（ track 数据发送到 ELK 里，结果再回写到 MySQL ）
 |
1
liprais 2020-02-21 16:42:54 +08:00
日志隔一段时间汇总之后存 s3,统计用 hive 或者 spark
或者日志直接写 kafka,后面跑个 spark streaming 写成 parquet 或者 orc,然后用 spark 或者 hive 做统计 统计结果写 mysql 完事 |
 |
2
cabing 2020-02-21 16:47:55 +08:00
广告数据分很多种。
比如结算日志，访问记录。 楼上说的包括历史数据 hive，实时 spark 或者 flink，mysql 只存结果 |
 |
3
zealinux OP 有人说，可以 ELK 来做？不知是否合适？
|
 |
4
awanganddong 2020-07-11 15:56:46 +08:00
现在也在做该相关场景的业务，隐约感觉这种日志流，其实最需要的数据，不超过 7 天，也就是对底层数据进行抽取，然后汇总到上层表，然后底层数据进行定期归档就可以。
这里边一个点，就是对热点数据的不停机归档。 还有一个点，就是对数据的聚合。 |
 |
5
fucUup 2021-02-28 21:52:52 +08:00
clickhouse 我兄弟开发的
|
Select Language