数智技术

无论在 OLAP 还是 OLTP 领域，Join 都是业务常会涉及到且优化规则比较复杂的 SQL 语句。对于离线计算而言，经过数据库领域多年的积累 Join 的语义以及实现已经十分成熟，然而对于近年来刚兴起的 Streaming SQL 来说 Join 却处于刚起步的状态。其中最为关键的问题在于 Join 的实现依赖于缓存整个数据集，而 Streaming SQL Join 的对象却是无限的数据流，内存压力和计算效率在长期运行来说都是不可避免的问题。下文将结合 SQL 的发展解析 Flink SQL 是如何

对于大多数 Flink 应用开发者而言，无论使用高级的 Table API 或者是底层的 DataStream/DataSet API，Source 都是首先接触到且使用最多的 Operator 之一。然而其实从 2018 年 10 月开始，Flink 社区就开始计划重构这个稳定了多年的 Source 接口[1]，以满足更大规模数据以及对接更丰富的 connector 的要求，另外还有更重要的一个目的: 统一流批两种计算模式。重构后的 Source 接口在概念和使用方式上都会有较大不同，无论对 Flink

作为计算引擎 Flink 应用的计算结果总要以某种方式输出，比如调试阶段的打印到控制台或者生产阶段的写到数据库。而对于本来就需要在 Flink 内存保存中间及最终计算结果的应用来说，比如进行聚合统计的应用，输出结果便是将内存中的结果同步到外部。就 Flink Table/SQL API 而言，这里的同步会有三种模式，分别是 Append、Upsert 和 Retract。实际上这些输出计算结果的模式并不限于某个计算框架，比如 Storm、Spark 或者 Flink DataStream 都可以应用这些模式

如果不打算用 SQL 或者想自己实现底层操作，那么如何基于 DataStream API 来关联维表呢？实际上由于 Flink DataStream API 的灵活性，实现这个需求的方式是非常多样的，但是大部分用户很难在设计架构时就考虑得很全面，可能会走不少弯路。针对于此，笔者根据工作经验以及社区资源整理了用 DataStream 实现 Join 维表的常见方式，并给每种的方式优劣和适用场景给出一点可作为参考的个人观点。总体来讲，关联...

简介： 本篇文章从流计算的本质出发，重点分析流计算领域中数据处理的一致性问题，同时对一致性问题进行简单的形式化定义，提供一个一窥当下流计算引擎发展脉络的视角，让大家对流计算引擎的认识更为深入，为可能的流计算技术选型提供一些参考。流计算的应用与实践在大数据领域越来越常见，其重要性不言而喻，常见的流计算引擎有 Google DataFlow、Apache Flink，Apache Kafka Streams，Apache Spark Streaming 等。流计算系统中的数据一致性一般是用消息处理语义来定义的，

已经了解到流计算是如何解决了传统批处理的局限以及如何支持了新的应用和架构，并且熟悉了开源流计算技术的演进，接下来介绍流计算的基础。数据流图（Dataflow graphs）字面上理解，一个数据流程序描述了数据在各种操作之间的流动。数据流程序通常用一个有向图来表示，其中节点是运算符代表了计算，边表示数据的依赖关系。算子是一个数据流程序的基本函数单元，从输入中消费数据、执行计算，以及输出结果用于进一步的处理。没有输入端的算子称为data source，而没有输出端的算子称为data sink。一个数据流图至

1 debezium概述Debezium是一个开源项目，为捕获数据更改(change data capture,CDC)提供了一个低延迟的流式处理平台。你可以安装并且配置Debezium去监控你的数据库，然后你的应用就可以消费对数据库的每一个行级别(row-level)的更改。只有已提交的更改才是可见的，所以你的应用不用担心事务(transaction)或者更改被回滚(roll back)。Debezium为所有的数据库更改事件提供了一个统一的模型，所以你的应用不用担心每一种数据库管理系统的错综复杂性。

Kafka Connect介绍

上一篇文章介绍了流式处理的基本概念，并提出了窗口的概念的由来——即为了将无限数据切分为有限来处理。这篇文章主要通过以下四个问题逐渐勾勒出流式处理的计算框架：What: 要计算什么结果？——转换（transform）Where: 在哪个位置计算结果？——窗口（window）When: 在处理时间的哪个时刻计算窗口的结果？——水位线（watermark） + 触发器（trigger）How: 如何修正之前计算出的结果？——丢弃、累积、累积&撤回其中水位线和触发器的概念的产生最让我觉得很自

上一篇文章介绍了流式处理的基本概念，并提出了窗口的概念的由来——即为了将无限数据切分为有限来处理。这篇文章主要通过以下四个问题逐渐勾勒出流式处理的计算框架：What: 要计算什么结果？——转换（transform）Where: 在哪个位置计算结果？——窗口（window）When: 在处理时间的哪个时刻计算窗口的结果？——水位线（watermark） + 触发器（trigger）How: 如何修正之前计算出的结果？——丢弃、累积、累积&撤回其中水位线和触发器的概念的产生最让我觉得很自

传统的数据架构公司一般会采用不同的应用来满足商业的需要，例如企业资源规划系统（ERP）、客户关系管理软件（CRM），以及Web应用等。所有这些系统都是典型将数据处理（程序本身）和数据存储（事务型数据库系统）分成独立的层次，如下图所示。这些程序经常需要连接到外部的服务或者面向用户，并且需要持续地处理事件，如订单、邮件、网站的点击。当一个事件被处理，程序会读取其状态，或通过远程的数据库系统来运行一个事务完成状态的更新。一般来说，一个数据库系统会服务于多个应用，这些应用有时候甚至会访问相同的数据库或者表。