这是一个创建于 2114 天前的主题，其中的信息可能已经有所发展或是发生改变。
广告系统会跟踪一些数据（类似 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 F281M6Dh8DXpD1g2 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