Introduction to Stateful Stream Processing
Traditional Data Infrastructures
企业的应用，如enterprise resource planning (ERP) systems, customer relationship management (CRM) software, or web-based applications等都会对DBMS进行操作，有时操作还会公用一个库甚至一个表。为减少应用间的耦合性，最近提出微服务概念。微服务之间通过标准接口，如RESTful HTTP进行连接。在这种情况下，微服务就可以使用自己的技术栈。
各个应用与事务数据库系统交互，这个系统的数据不能直接用于分析（格式、业务单一等问题）。想要对数据进行分析，需要对事务数据库的数据进行extract-transform-load (ETL)，即复制、转换数据到数据仓库。
数据查询通常分为周期报告和热点查询。
Apache Hadoop的出现使得数据仓库的使用（存储、分析）成为可能。
Stateful Stream Processing
几乎所有的数据都是通过连续的事件流来创建的。 Stateful stream processing就是一个用来处理无界事件流的、较为通用的应用设计模式。任何处理事件流（不是简单的记录数据）的应用都需要是stateful的，即有能力存储和访问中间数据。这些状态state可存储在各种地方，如program variables, local files, or embedded or external databases。Flink把state存储到内存或绑定的数据库（不包括远程数据库），并周期性地将state的一致性checkpoint写到remote and durable storage。（state, state 一致性, and Flink’s checkpointing 机制后面介绍）
Stateful stream processing applications 通常处理事件日志，日志是append-only的，所以顺序是不变的。Flink能够保持日志的这一特点，即便是遇到挂机、升级和测试。
Stateful stream processing可以解决很多案例，其中常见的三类如下：
-
Event-driven Applications：接收事件流并对其执行业务逻辑，根据处理结果做出反应。场景：实时推荐、complex event processing (CEP如反作弊）、异常检测
-
Data Pipelines and Real-time ETL
-
Streaming Analytics：Flink可以把过去的数据分析步骤穿起来，包括 event ingestion, continuous computation including state maintenance, and updating the result.
The Evolution of Open Source Stream Processing
第一代分布式开源流处理器focused在millisecond latencies and provided guarantees that events would never be lost in case of a failure，但降低了结果的准确性、且处理一条数据多于一次。
第二代提高了准确性（结果仍取决于计时、事件到达时间）和数据只处理一次，但延迟提高到了秒级。
第三代解决了high throughput和low latency，made the lambda architecture obsolete。
Stream Processing Fundamentals
Introduction to dataflow programming
Dataflow graphs
Dataflow programs：类似Spark的DAG，节点称为operators并表示计算，而边表示数据依赖。没有输入端口的operators称为sources，没有输出端口的operators称为sinks。
physical dataflow graph：包含计算的细节。在这里operators变为tasks
Data parallelism and task parallelism
前者 partition input data and have tasks of the same operation execute on the data subsets in parallel
后者 have tasks from different operators performing computations on the same or different data in parallel.
Data exchange strategies
定义数据在physical dataflow graph中的分配方式。
- forward：两个任务的数据在同一机器上，不跨节点
- broadcast：如果下一级有n个并行任务，那么一个节点的所有数据都被复制n份，分别发到n个节点上。
- key-based：类似于groupbyKey，相同key到相同的任务
- random：为了平均分布数据到n个并行任务
Processing infinite streams in parallel
定义：A data stream is a potentially unbounded sequence of events
events可以是监测数据、传感器的测量、信用卡交易等。
Latency and throughput
Latency：不是平均延迟，而是每次都要低延迟。Throughput：处理速度。两者必须做取舍，除非增加机器来提高并行处理。
背压backpressure ：数据涌入的速度大于处理速度，并挤爆了缓冲区，数据就会丢失。
Operations on data streams
计算可分为无状态和有状态。前者不保留历史，计算更快，失败也可重算。有状态则可以用于更新。
-
Data ingestion and data egress，即source和sink
-
Transformation operations：相当于map操作
-
Rolling aggregation
-
Window：为了得到计算结果，必须收集并存储数据时用（在存储期间可用于查询）。窗口运算不断产生有限数据集buckets。事件会被根据其特征或到达时间分配到buckets。所以这种运算要定义buckets什么时候被使用（触发条件），事件分配规则和产生buckets的频率。
-
Tumbling：不重叠的固定大小（数量或者时间）
-
Sliding：重叠固定大小
-
Session：设定不活跃时间长度，timeout就算session窗口结束
这些窗口也可以并行，比如一个窗口针对同一id的信息
-
Time semantics
Processing time：服务端处理数据的时点，适合低延迟要求高的，准确度稍低的，因为不需要理会延迟和数据产生顺序，数据一旦到达或达到触发数量就可以进行计算。但这样的结果是不一致的（不同顺序、数据），不可reproduce的。
Event time：客户端产生数据的时点，适合场景反之，即便乱序也能保持唯一正确。
Watermarks：设定多久不再接受延迟的信息，这是低延迟和准确性的权衡。stream processing system提供超出watermarks范围的数据的处理方式很重要，比如忽略、记录或者用它来更新数据。
State and consistency models
由于流数据是无界的，所以要限定state的大小，比如聚合成一些指标或保留部分特征等。state的实现要防止并发更新、划分数据流和保证数据的准确。
Task failures：一个任务的顺序：接收事件（存入buffer）、可能要更新state、产生结果。任务失败可以是这里的任何一个步骤。
假设：这里假设网络不会丢失和重复数据。未失败的任务都遵循上述步骤。
Result guarantees
-
AT-MOST-ONCE：do nothing，数据丢失，适合准确度要求不高的。
-
AT-LEAST-ONCE：保证没有数据丢失，即便对数据进行重复处理（即也不一定准确）。
-
EXACTLY-ONCE：没有数据丢失、数据只处理一次。即如果任务失败，在重启计算时会知道上一次更新是否已经反映在state上。
-
END-TO-END EXACTLY-ONCE：包括source和sink的整个pipeline
不一定所有情况都需要最高级别的保证，如计算最值就可以采用AT-LEAST-ONCE
参考：
Stream Processing with Apache Flink by Vasiliki Kalavri; Fabian Hueske