Apache Flink 漫谈系列 - 流表对偶(duality)性

现实题目

许多大数据计较产物，都对用户提供了SQL API，好比Hive, Spark, Flink等，那么SQL作为传统相关数据库的查询说话，是应用在批查询场景的。Hive和Spark本质上都是Batch的计较模式(在《Apache Flink 漫谈系列 - 概述》我们先容过Spark是Micro Batching模式)，提供SQL API很轻易被人领略，可是Flink是纯流(Native Streaming)的计较模式, 流与批在数据集和计较进程上有很大的区别，如下：

• 批查询场景的特点 - 有限数据集，一次查询返回一个计较功效就竣事查询
• 流查询场景的特点 - 无穷数据集，一次查询不绝批改计较功效，查询永久不竣事

我们发明批与流的查询场景在数据荟萃和计较进程上都有很大的差异，那么基于Native Streaming模式的Apache Flink为啥也能为用户提供SQL API呢?

流与批的语义相关

我们知道SQL都是浸染于副黄?的，在传统数据库中举办查询时辰，SQL所要查询的表在触发查询时辰数据是不会变革的，也就是说在查询那一刻，表是一张静态表，相等于是一个有限的批数据，这样也声名SQL是源于对批计较的查询的，那么要答复Apache Flink为啥也能为用户提供SQL API，我们起主要领略流与批在语义层面的相关。我们以一个详细示例声名，如下图：

上图揭示的是一个携带时刻戳和用户名的点击变乱流，我们先对这些变乱流举办流式统计，同时在最后的流变乱上触发批计较。流计较中每吸取一个数据城市触发一次计较，我们以2018/4/30 22:37:45 Mary到来那一时刻切片看，无论是在流照旧批上计较功效都是6。也就是说在沟通的数据源，沟通的查询逻辑下，流和批的计较功效是沟通的。沟通的SQL在流和批这两种模式下，最终功效是同等的，那么流与批在语义上是完全沟通的。

流与表的相关

流与批在语义上是同等的，SQL是浸染于表的，那么要答复Apache Flink为啥也能为用户提供SQL API的题目，就酿成了流与表是否具有等价性，也就是本篇要重点先容的为什么流表具有对偶(duality)性?如下图所示，一张表可以看做为流吗?同样流可以看做是一张表吗?假如可以必要奈何的前提和变通?

MySQL主备复制

在先容流与表的相关之前我们先聊聊MySQL的主备复制，binlog是MySQL实现主备复制的焦点本领，简朴来说MySQL主备复制实现分成三个步调：

• Master将改变(change logs)以二进制日记变乱(binary log events)情势记录到二进制日记(binlog)中;
• Slave将Master的binary log events拷贝到它的中继日记(relay log);
• Slave重做中继日记中的变乱，将改变反应到数据;

详细如下图所示:

binlog

接下来我们从binlog模式，binlog名目以及通过查察binlog的详细内容来细致先容binlog与表的相关。

1. binlog模式

上面先容的MySQL主备复制的焦点本领是操作binlog实现的，何处binlog会记录那些内容呢?binlog记录了数据库全部的增、删、更新等操纵。MySQL支持三种方法记录binlog:

(1) statement-based logging - Events contain SQL statements that produce data changes (inserts, updates, deletes);

(2) row-based logging - Events describe changes to individual rows;

(3) mixed-base logging - 该模式默认是statement-based，当碰着如下环境会自动切换到row-based:

• NDB存储引擎，DML操纵以row名目记录;
• 行使UUID()、USER()、CURRENT_USER()、FOUND_ROWS()等不确定函数;
• 行使Insert Delay语句;
• 行使用户自界说函数(UDF);
• 行使姑且表;

2. binlog名目

我们以row-based 模式为例先容一下binlog的存储名目 ，全部的 binary log events都是字节序列，由两部门构成：

• event header
• event data

关于event header和event data 的名目在数据库的差异版本略有差异，但配合的处所如下：

+=====================================+ 
| event  | timestamp         0 : 4    | 
| header +----------------------------+ 
|        | type_code         4 : 1    | 
|        +----------------------------+ 
|        | server_id         5 : 4    | 
|        +----------------------------+ 
|        | event_length      9 : 4    | 
|        +----------------------------+ 
|        |差异版本纷歧样(省略)          | 
+=====================================+ 
| event  | fixed part                 | 
| data   +----------------------------+ 
|        | variable part              | 
+=====================================+ 

这里有个值得我们留意的处所就是在binlog的header中有一个属性是timestamp，这个属性是标识了change产生的先后次序，在备库举办复制时辰会严酷凭证时刻次序举办log的重放。

3. binlog的天生

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!