weixin_45417821的博客

CDC有两种方式，一种是离线的，一种是实时的，也就是一种是基于查询的，一种是Binlog的这种方式。CDC 是Change Data Capture（变更数据获取）的简称。核心思想是，监测并捕获数据库的变动（包括数据或数据表的插入、更新以及删除等），将这些变更按发生的顺序完整记录下来，写入到消息中间件中以供其他服务进行订阅及消费。

文章目录我们分析过 CEP 检测处理的流程，可以认为检测匹配事件的过程中会有“初始（没有任何匹配）”“检测中（部分匹配成功）”“匹配成功”“匹配失败”等不同的“状态”。随着每个事件的到来，都会改变当前检测的“状态”；而这种改变跟当前事件的特性有关、也跟当前所处的状态有关。这样的系统，其实就是一个 “状态机”（state machine） 。这也正是正则表达式底层引擎的实现原理。所以 Flink CEP 的底层工作原理其实与正则表达式是一致的，是一个“非确定有限状态自动机”（Nondeterminist

文章目录处理超时事件使用 PatternProcessFunction 的侧输出流使用 PatternTimeoutFunction应用案例处理迟到数据处理超时事件复杂事件的检测结果一般只有两种：要么匹配，要么不匹配。检测处理的过程具体如下：（1）如果当前事件符合模式匹配的条件，就接受该事件，保存到对应的 Map 中；（2）如果在模式序列定义中，当前事件后面还应该有其他事件，就继续读取事件流进行检测；如果模式序列的定义已经全部满足，那么就成功检测到了一组匹配的复杂事件，调用PatternProces

文章目录将模式应用到流上处理匹配事件匹配事件的选择提取（select）匹配事件的通用处理（process）将模式应用到流上将模式应用到事件流上的代码非常简单，只要调用 CEP 类的静态方法.pattern()，将数据流（DataStream）和模式（Pattern）作为两个参数传入就可以了。最终得到的是一个 PatternStream：DataStream<Event> inputStream = ...Pattern<Event, ?> pattern = ...Patt

文章目录前提：由于有循环模式和非确定性宽松近邻的存在，同一个事件有可能会重复利用，被分配到不同的匹配结果中。这样会导致匹配结果规模增大，有时会显得非常冗余。当然，非确定性宽松近邻条件，本来就是为了放宽限制、扩充匹配结果而设计的；我们主要是针对循环模式来考虑匹配结果的精简。在 Flink CEP 中，提供了模式的“匹配后跳过策略”（After Match Skip Strategy），专门用来精准控制循环模式的匹配结果。这个策略可以在 Pattern 的初始模式定义中，作为 begin()的第二个参数传入

文章目录之前在模式序列中，我们用 begin()、next()、followedBy()、followedByAny()这样的“连接词”来组合个体模式，这些方法的参数就是一个个体模式的名称；而现在它们可以直接以一个模式序列作为参数，就将模式序列又一次连接组合起来了。这样得到的就是一个“模式组”（Groups of Patterns）。在模式组中，每一个模式序列就被当作了某一阶段的匹配条件，返回的类型是一个GroupPattern。而 GroupPattern 本身是 Pattern 的子类；所以个体模式

文章目录初始模式（Initial Pattern）近邻条件（Contiguity Conditions）严格近邻（Strict Contiguity）宽松近邻（Relaxed Contiguity）非确定性宽松近邻（Non-Deterministic Relaxed Contiguity）其他限制条件循环模式中的近邻条件定义好的个体模式，就可以尝试按一定的顺序把它们连接起来，定义一个完整的复杂事件匹配规则了。这种将多个个体模式组合起来的完整模式，就叫作“组合模式”（Combining Pattern），为

文章目录基本形式量词条件模式（Pattern）其实就是将一组简单事件组合成复杂事件的“匹配规则”。由于流中事件的匹配是有先后顺序的，因此一个匹配规则就可以表达成先后发生的一个个简单事件，按顺序串联组合在一起。这里的每一个简单事件并不是任意选取的，也需要有一定的条件规则；所以我们就把每个简单事件的匹配规则，叫作“个体模式”（Individual Pattern）。基本形式每一个登录失败事件的选取规则，就都是一个个体模式。比如：Pattern.<LoginEvent>begin("firs

文章目录依赖一个简单实例依赖想要在代码中使用 Flink CEP，需要在项目的 pom 文件中添加相关依赖：<dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-cep_${scala.binary.version}</artifactId> <version>${flink.version}</version></de

文章目录CEP 是什么模式（Pattern）应用场景风险控制用户画像运维监控在实际应用中，还有一类需求是要检测以特定顺序先后发生的一组事件，进行统计或做报警提示，这就比较麻烦了。例如，网站做用户管理，可能需要检测“连续登录失败”事件的发生，这是个组合事件，其实就是“登录失败”和“登录失败”的组合；电商网站可能需要检测用户“下单支付”行为，这也是组合事件，“下单”事件之后一段时间内又会有“支付”事件到来，还包括了时间上的限制。类似的多个事件的组合，我们把它叫作“复杂事件”。对于复杂时间的处理，由于涉及到事

文章目录引入依赖连接到 Hive设置 SQL 方言读写 Hive 表Hive的主要缺点在于查询的延迟很高，几乎成了离线分析的代言人。而 Flink 的特点就是实时性强，所以 Flink SQL 与 Hive 的结合势在必行。Flink 与 Hive 的集成比较特别。Flink 提供了“Hive 目录”（HiveCatalog）功能，允许使用Hive 的“元存储”（Metastore）来管理 Flink 的元数据。这带来的好处体现在两个方面：1）Metastore 可以作为一个持久化的目录，因此使用 H

文章目录控制台Kafka （重点）文件系统JDBCElasticsearchHBase控制台CREATE TABLE ResultTable ( user STRING, cnt BIGINTWITH ( 'connector' = 'print');Kafka （重点）Kafka 的 SQL 连接器可以从 Kafka 的主题（topic）读取数据转换成表，也可以将表数据写入 Kafka 的主题。创建表的时候指定连接器为 Kafka，则这个表既可以作为输入表，也可以作为输出表。想要在

文章目录有了 Table API 和 SQL，我们就可以使用熟悉的 SQL 来编写查询语句进行流处理了。不过，这种方式还是将 SQL 语句嵌入到 Java/Scala 代码中进行的；另外，写完的代码后想要提交作业还需要使用工具进行打包。这都给 Flink 的使用设置了门槛，如果不是 Java/Scala 程序员，即使是非常熟悉 SQL 的工程师恐怕也会望而生畏了。基于这样的考虑，Flink 为我们提供了一个工具来进行 Flink 程序的编写、测试和提交，这工具叫作“SQL 客户端”。SQL 客户端提供了一

文章目录用户自定义表聚合函数（UDTAGG）可以把一行或多行数据（也就是一个表）聚合成另一张表，结果表中可以有多行多列。很明显，这就像表函数和聚合函数的结合体，是一个“多对多”的转换。自定义表聚合函数需要继承抽象类 TableAggregateFunction。TableAggregateFunction 的结构和原理与 AggregateFunction 非常类似，同样有两个泛型参数<T, ACC>，用一个 ACC 类型的累加器（accumulator）来存储聚合的中间结果。聚合函数中必须

文章目录用户自定义聚合函数（User Defined AGGregate function，UDAGG）会把一行或多行数据（也就是一个表）聚合成一个标量值。这是一个标准的“多对一”的转换。聚合函数的概念我们之前已经接触过多次，如 SUM()、MAX()、MIN()、AVG()、COUNT()都是常见的系统内置聚合函数。而如果有些需求无法直接调用系统函数解决，我们就必须自定义聚合函数来实现功能了。自定义聚合函数需要继承抽象类 AggregateFunction。AggregateFunction 有两个

文章目录跟标量函数一样，表函数的输入参数也可以是 0 个、1 个或多个标量值；不同的是，它可以返回任意多行数据。“多行数据”事实上就构成了一个表，所以“表函数”可以认为就是返回一个表的函数，这是一个“一对多”的转换关系。之前我们介绍过的窗口 TVF，本质上就是表函数。类似地，要实现自定义的表函数，需要自定义类来继承抽象类 TableFunction，内部必须要实现的也是一个名为 eval 的求值方法。与标量函数不同的是，TableFunction 类本身是有一个泛型参数T 的，这就是表函数返回数据的类型

文章目录标量函数（Scalar Functions）标量函数（Scalar Functions）自定义标量函数可以把 0 个、 1 个或多个标量值转换成一个标量值，它对应的输入是一行数据中的字段，输出则是唯一的值。所以从输入和输出表中行数据的对应关系看，标量函数是“一对一”的转换。想要实现自定义的标量函数，我们需要自定义一个类来继承抽象类 ScalarFunction，并实现叫作 eval() 的求值方法。标量函数的行为就取决于求值方法的定义，它必须是公有的（public），而且名字必须是 eval。求

文章目录系统函数尽管庞大，也不可能涵盖所有的功能；如果有系统函数不支持的需求，我们就需要用自定义函数（User Defined Functions，UDF）来实现了。事实上，系统内置函数仍然在不断扩充，如果我们认为自己实现的自定义函数足够通用、应用非常广泛，也可以在项目跟踪工具 JIRA 上向 Flink 开发团队提出“议题”（issue），请求将新的函数添加到系统函数中。Flink 的 Table API 和 SQL 提供了多种自定义函数的接口，以抽象类的形式定义。当前 UDF主要有以下几类：标量

文章目录系统函数标量函数（Scalar Functions）比较函数（Comparison Functions）逻辑函数（Logical Functions）算术函数（Arithmetic Functions）字符串函数（String Functions）时间函数（Temporal Functions）聚合函数（Aggregate Functions）在 SQL 中，我们可以把一些数据的转换操作包装起来，嵌入到 SQL 查询中统一调用，这就是“函数”（functions）。Flink 的 Table A

文章目录常规联结查询间隔联结查询两表的联结联结条件时间间隔限制按照数据库理论，关系型表的设计往往至少需要满足第三范式（3NF），表中的列都直接依赖于主键，这样就可以避免数据冗余和更新异常。例如商品的订单信息，我们会保存在一个“订单表”中，而这个表中只有商品 ID，详情则需要到“商品表”按照 ID 去查询；这样的好处是当商品信息发生变化时，只要更新商品表即可，而不需要在订单表中对所有这个商品的所有订单进行修改。不过这样一来，我们就无法从一个单独的表中提取所有想要的数据了。在标准 SQL 中，可以将多个表连

文章目录普通 Top NWHEREPARTITION BYORDER BY窗口 Top N灵活使用各种类型的窗口以及聚合函数，可以实现不同的需求。一般的聚合函数，比如SUM()、MAX()、MIN()、COUNT()等，往往只是针对一组数据聚合得到一个唯一的值；所谓OVER 聚合的“多对多”模式，也是针对每行数据都进行一次聚合才得到了多行的结果，对于每次聚合计算实际上得到的还是唯一的值。而有时我们可能不仅仅需要统计数据中的最大/最小值，还希望得到前 N 个最大/最小值；这时每次聚合的结果就不是一行，而是

文章目录PARTITION BY（可选）ORDER BY开窗范围范围间隔行间隔在标准 SQL 中还有另外一类比较特殊的聚合方式，可以针对每一行计算一个聚合值。比如说，我们可以以每一行数据为基准，计算它之前 1 小时内所有数据的平均值；也可以计算它之前 10 个数的平均值。就好像是在每一行上打开了一扇窗户、收集数据进行统计一样，这就是所谓的“开窗函数”。开窗函数的聚合与之前两种聚合有本质的不同：分组聚合、窗口 TVF聚合都是“多对一”的关系，将数据分组之后每组只会得到一个聚合结果；而开窗函数是对每行都要做一

文章目录滚动窗口滑动窗口累计窗口在流处理中，往往需要将无限数据流划分成有界数据集，这就是所谓的“窗口”。相当于 DataStream API 中的窗口分配器（window assigner），只是明确了窗口的形式以及数据如何分配；而窗口具体的计算处理操作，在DataStream API 中还需要窗口函数（window function）来进行定义。在 Flink 的 Table API 和 SQL 中，窗口的计算是通过“窗口聚合”（window aggregation）来实现的。与分组聚合类似，窗口聚

文章目录SQL 中一般所说的聚合我们都很熟悉，主要是通过内置的一些聚合函数来实现的，比如SUM()、MAX()、MIN()、AVG()以及 COUNT()。它们的特点是对多条输入数据进行计算，得到一个唯一的值，属于“多对一”的转换。比如我们可以通过下面的代码计算输入数据的个数：Table eventCountTable = tableEnv.sqlQuery("select COUNT(*) from EventTable");而更多的情况下，我们可以通过 GROUP BY 子句来指定分组的键（ke

文章目录窗口表值函数（Windowing TVFs，新版本）滚动窗口（TUMBLE）滑动窗口（HOP）累积窗口（CUMULATE）有了时间属性，接下来就可以定义窗口进行计算了。我们知道，窗口可以将无界流切割成大小有限的“桶”（bucket）来做计算，通过截取有限数据集来处理无限的流数据。在 DataStream API 中提供了对不同类型的窗口进行定义和处理的接口，而在 Table API 和 SQL 中，类似的功能也都可以实现。窗口表值函数（Windowing TVFs，新版本）从 1.13 版本开

文章目录事件时间（event time）处理时间（processing time）所以所谓的时间属性（time attributes），其实就是每个表模式结构（schema）的一部分。它可以在创建表的 DDL 里直接定义为一个字段，也可以在 DataStream 转换成表时定义。一旦定义了时间属性，它就可以作为一个普通字段引用，并且可以在基于时间的操作中使用。时间属性的数据类型为 TIMESTAMP，它的行为类似于常规时间戳，可以直接访问并且进行计算。按照时间语义的不同，我们可以把时间属性的定义分成事

文章目录仅追加（Append-only）流撤回（Retract）流更新插入（Upsert）流与关系型数据库中的表一样，动态表也可以通过插入（Insert）、更新（Update）和删除（Delete）操作，进行持续的更改。将动态表转换为流或将其写入外部系统时，就需要对这些更改操作进行编码，通过发送编码消息的方式告诉外部系统要执行的操作。在 Flink 中，Table API 和 SQL支持三种编码方式：仅追加（Append-only）流仅通过插入（Insert）更改来修改的动态表，可以直接转换为“仅追加

文章目录将流转换成动态表用 SQL 持续查询更新（Update）查询追加（Append）查询查询限制将流转换成动态表如果把流看作一张表，那么流中每个数据的到来，都应该看作是对表的一次插入（Insert）操作，会在表的末尾添加一行数据。因为流是连续不断的，而且之前的输出结果无法改变、只能在后面追加；所以我们其实是通过一个只有插入操作（insert-only）的更新日志（changelog）流，来构建一个表。当用户点击事件到来时，就对应着动态表中的一次插入（Insert）操作，每条数据就是表中的一行；随着

文章目录动态表和持续查询持续查询（Continuous Query）当我们将一个 Table 转换成 DataStream 时，有“仅插入流”（Insert-Only Streams）和“更新日志流”（Changelog Streams）两种不同的方式，具体使用哪种方式取决于表中是否存在更新（update）操作。将关系型表/SQL 与流处理做一个对比关系型表/SQL流处理处理的数据对象字段元组的有界集合字段元组的无限序列查询（Query）可以访问到完整的数据输入无

文章目录将表（Table）转换成流（DataStream）将流（DataStream）转换成表（Table）支持的数据类型全代码展示：在 Flink 中我们可以将 Table 再转换成 DataStream，然后进行打印输出。这就涉及了表和流的转换。将表（Table）转换成流（DataStream）（1）调用 toDataStream()方法将一个 Table 对象转换成 DataStream 非常简单，只要直接调用表环境的方法 toDataStream()就可以了。tableEnv.toData

文章目录创建表表的查询输出表全部展示创建表为了方便地查询表，表环境中会维护一个目录（Catalog）和表的对应关系。所以表都是通过 Catalog 来进行注册创建的。表在环境中有一个唯一的 ID，由三部分组成：目录（catalog）名，数据库（database）名，以及表名。在默认情况下，目录名为 default_catalog，数据库名为default_database。所以如果我们直接创建一个叫作 MyTable 的表，它的 ID 就是：default_catalog.default_databa

文章目录对于 Flink 这样的流处理框架来说，数据流和表在结构上还是有所区别的。所以使用 Table API 和 SQL 需要一个特别的运行时环境，这就是所谓的“表环境”（TableEnvironment）。它主要负责：（1）注册 Catalog 和表；（2）执行 SQL 查询；（3）注册用户自定义函数（UDF）；（4）DataStream 和表之间的转换。这里的 Catalog 就是“目录”，与标准 SQL 中的概念是一致的，主要用来管理所有数据库（database）和表（table）的元数

文章目录在 Flink 中，Table API 和 SQL 可以看作联结在一起的一套 API，这套 API 的核心概念就是“表”（Table）。在我们的程序中，输入数据可以定义成一张表；然后对这张表进行查询，就可以得到新的表，这相当于就是流数据的转换操作；最后还可以定义一张用于输出的表，负责将处理结果写入到外部系统。可以看到，程序的整体处理流程与 DataStream API 非常相似，也可以分为读取数据源（Source）、转换（Transform）、输出数据（Sink）三部分；只不过这里的输入输出操作

文章目录快速上手一个简单示例快速上手如果我们对关系型数据库和 SQL 非常熟悉，那么 Table API 和 SQL 的使用其实非常简单：只要得到一个“表”（Table），然后对它调用 Table API，或者直接写 SQL 就可以了。接下来我们就以一个非常简单的例子上手，初步了解一下这种高层级 API 的使用方法。Flink1.13版本不算稳定，依然在不停的调整和更新，关注 原理和基本用法。需要引入的依赖<dependency> <groupId>org.apache

文章目录检查点（Checkpoint）状态后端（State Backends）分类如何选择状态后端的配置Flink管理机制中，很重要的一个功能就是对状态进行持久化保存，这样就可以在发生故障进行重启恢复，持久化方式为当前状态，拍一个快照，并写入检查点，存储在外部存储系统中，存储介质一般为分步式文件系统（例如HDFS）。检查点（Checkpoint）检查点是任务的状态在某个时间点的一个快照，简单来说，就是一次存盘，让之前的数据不会丢掉，Flink会定期保存检查点，记录状态，如果发生故障，就会用最近一次成功

关于两条流的连接，还有一种比较特殊的用法：DataStream 调用.connect()方法时，传入的参数也可以不是一个 DataStream，而是一个“广播流”（BroadcastStream），这时合并两条流得到的就变成了一个“广播连接流”（BroadcastConnectedStream）。这种连接方式往往用在需要动态定义某些规则或配置的场景。因为规则是实时变动的，所以我们可以用一个单独的流来获取规则数据；而这些规则或配置是对整个应用全局有效的，所以不能只把这数据传递给一个下游并行子任务处理，而是.

文章目录基本概念和特点状态类型列表状态（ListState）联合列表状态（UnionListState）代码实现CheckpointedFunction 接口示例代码从某种意义上说，算子状态是更底层的状态类型，因为它只针对当前算子并行任务有效，不需要考虑不同 key 的隔离。基本概念和特点算子状态（Operator State）就是一个算子并行实例上定义的状态，作用范围被限定为当前算子任务，与Key无关，不同Key的数据只要分发到同一个并行子任务，就会访问到同一个算子状态。算子状态一般用在 Sour

文章目录在实际应用中，很多状态会随着时间的推移逐渐增长，如果不加以限制，最终就会导致存储空间的耗尽。一个优化的思路是直接在代码中调用.clear()方法去清除状态，但是有时候我们的逻辑要求不能直接清除。这时就需要配置一个状态的“生存时间”（time-to-live，TTL），当状态在内存中存在的时间超出这个值时，就将它清除。具体实现上，如果用一个进程不停地扫描所有状态看是否过期，显然会占用大量资源做无用功。状态的失效其实不需要立即删除，所以我们可以给状态附加一个属性，也就是状态的“失效时间”。状态创建的

文章目录我们举一个简单的例子，对用户点击事件流每 5 个数据统计一次平均时间戳。这是一个类似计数窗口（CountWindow）求平均值的计算，这里我们可以使用一个有聚合状态的RichFlatMapFunction 来实现。代码展示：public class AverageTimestampExample { public static void main(String[] args) throws Exception { StreamExecutionEnvironment e

文章目录映射状态的用法和 Java 中的 HashMap 很相似。在这里我们可以通过 MapState 的使用来探索一下窗口的底层实现，也就是我们要用映射状态来完整模拟窗口的功能。这里我们模拟一个滚动窗口。我们要计算的是每一个 url 在每一个窗口中的 pv 数据。我们之前使用增量聚合和全窗口聚合结合的方式实现过这个需求。这里我们用 MapState 再来实现一下。需求：定义一个滚动窗口十秒钟，在这个10秒中之内的所有数据，按照url做一个划分，统计出每个url，每一个页面被点击的次数代码如下：pu