1 当歌单只需要每天更新的时候可以用map reduce，在用map reduce的high level architecture里面为啥slow path有两个地方用到了distributed messaging system？data partitoner是干什么用的，为啥不直接跑一个map reduce来aggregate不就好了么？
2. 能重复一下精度要求不高的时候可以用什么算法来着可以替代hashmap？
3. 没听懂trending怎么用hashmap做realtime，比如trending定义是7天内counter比上再之前7天的counter，相当于有两个长度为7天的sliding window。
- mapReduce 的输入是一天所有人听的歌。因为用户听歌的时间可能在这一天的任何时候，而 MapReduce 只是一天跑一次，所以没法直接用 MapReduce 来 aggregate。需要一个额外的分布式系统 (Data partitioner + Message Queue + Partition Processor)来把原始数据先写到一个 Hive Table 里。
- Count-min Sketch
- Trending 没办法做到像 TopK 那么 realtime，需要把两个 sliding window 除一下再排个序。
Trending 为什么没办法做到real-time？ 是因为trending是要找delta， 而不是简单的counter么？
Trending 要看趋势算斜率，没有容易的方法实时 Scalable 做计算。
如果歌单每天更新，可以用map reduce。
课件中歌单每天更新是什么意思，是指给用户展示的TopK歌单每天更新么？
需要一个额外的分布式系统 (Data partitioner + Message Queue + Partition Processor)来把原始数据先写到一个 Hive Table 里。
为什么不能直接用partition processor 去处理第一个messageQ里的东西直接写进distributed file system? Aka 去掉 Data partitioner + Message Queue 这个模块
课件里的slow path:
API Geteway → Message Q → Data partitioner + Message Queue + Partition Processor-> distributed file system → map reduce job → TopK
为什么不能
API Geteway → Message Q → Partition Processor → distributed file system → map reduce job → TopK
是的
这里的 Data partitioner 会把前面的 Message Queue 里的数据做一些简单处理，比如把 batch data 分成一条一条的，再分发到一个 Message Queue Cluster 里面去，之后的 partition processor 会做一些进一步处理，把一定时段内（比如10分钟内）的同一个歌曲计数做好。
之后的 partition processor 会做一些进一步处理，把一定时段内（比如10分钟内）的同一个歌曲计数做好。
怎么感觉像做了Map Reduce 中Reduce的工作？我以为count歌曲的逻辑会放到map reduce.所以这里reduce 的unit是10分钟的同一歌曲？
是的。你可以认为 Partition Processor 在 MapReduce 之前做了一步预处理，减轻一些 network 上的负担。
如果想要更简化一点，直接把每首歌的播放时间直接做 MapReduce 的输入也是可以。