数据处理
- 背景
最经典的一个数据处理MODEL
问题：每次处理一个请求，大量请求来的时候不是很高效。
解决方案，批处理。
批处理的时候，可以批量并发，经典模型就是MAP/REDUCE
带来的问题是， 你知道所有的数据，你知道如何处理
但是很多新的应用是新流进来的数据，不是历史数据。不能看到数据的全貌。这时就要引入一个概念STREAM COMPUTING。
BATCH VS STREAMING
BATCH 的角度是数据集是已知的。 STREAM 的角度 是INPUT 是动态变化的，源源不断的。
BATCH角度理解STREAM，某一个时间范围内，那么STREAM的数据也是确定的。所以可以理解为streaming = a series of batch
stream 可以被拆解为一个个小BATCH，用BATCH 去处理。(micro batch)
最经典的是spark streaming
从STREAM 角度看BATCH。BATCH 就是一个STREAMING JOB 在一个特定条件下终止。
如FLINK, HERON。
所有的计算引擎都会自由的在BATCH 和 STREAM 做转换，没有很严格的界定。
这2个都是数据计算的实现。而本质就是输入是BOUNDED 还是 UNBOUNDED的区别。
Batch
Batch天生就是用来处理BOUNED 数据。
如何用BATCH 去处理UNBOUNDED 数据集？
把无限的数据，去切分成一个个小窗口，然后再这个窗口里用BATCH计算去计算。
如何定义batches?
静态时间窗口（Fixed Size），
动态时间窗口（session）
活动的时长，连到网站，做了一系列操作，然后就不再动了。这样就可以动态分片，针对用户的活跃时间产生的数据做计算。
Streaming
时间在STREAMING系统中很重要。数据是流动的方式进来，那么会有2个时间，事件到达的时间，事件产生的时间。
事件时间（event time）：比如你点击网页的一个事件的时间点。
消化时间(ingestion time)：消息被收集丢到计算任务的时间点。
处理时间(process time)：被计算任务处理完的时间点。
一般对用户有意义的时间是第一个和第三个。
比如一个电子温度计，发温度，我们需要考虑事件时间。
有些业务和事件产生的时间没关系，可以用处理时间。
Streaming 处理bounded
unboudned + termination( 只跑2小时，比如处理EVENT 一直到11点)
处理unbounded
跟时间无关的
filtering :如源源不断的数据，浏览这个网页的来自中国的IP是多少
projection : 把EVENT 抽取固定信息
transformation: 把时间的数据，用数学函数转换。近似计算
top N窗口计算（看使用处理时间还是事件时间）
每个小时的点击量
which time to use for windowing?
how to window?
用哪种WINDOW，看用户的需求。
固定窗口：
Process Time : 没有DELAY， 不需要保存状态
Event Time: event -> {seq-mp, event-time, val}
[1, 11:00, 10]
[2, 11: 01, 50]
[3, 11:02, 30]
[4, 10:55, 30]
时间可能乱序
Sum : emit result by processing time
11:00 :10
11:01 : 60
11:02 :90
11:05 : 120
Sum : emit result by event time
11:00 :10
11:01 : 60
11:02 :90
10:55 : 10:54+30
需要有10:54的状态，需要保存状态
