本文介绍了 Structured Streaming 是如何逐步从 Apache Spark 生态系统中发展起来的，以及其设计理念和实现方式。本文还介绍了 Structured Streaming 在实际应用中的优势，包括与批处理计算的关系、与 Apache Kafka 的集成、以及在高吞吐和低延迟场景下的性能表现。此外，本文还提供了若干实例，以展示 Structured Streaming 在各种应用场景中的实际效果。
Apache Kafka是一个分布式发布-订阅消息传递系统。 它最初由LinkedIn公司开发，LinkedIn于2010年贡献给了Apache基金会并成为顶级开源项目。Kafka用于构建实时数据管道和流式应用程序。它具有水平扩展性、容错性、极快的速度，目前也得到了广泛的应用。
Structured Streaming 是一个基于 Spark SQL 引擎的、可扩展的且支持容错的流处理引擎。你可以像表达静态数据上的批处理计算一样表达流计算。Spark SQL 引擎将随着流式数据的持续到达而持续运行，并不断更新结果。你可以在Scala，Java，Python或R中使用 Dataset/DataFrame API 来表示流聚合，事件时间窗口（event-time windows），流到批处理连接（stream-to-batch joins）等。计算在相同的优化的 Spark SQL 引擎上执行。最后，通过 checkpoint 和 WAL，系统确保端到端的 exactly-once。简而言之，Structured Streaming 提供了快速、可扩展的、容错的、端到端 exactly-once 的流处理。
导读：大家好，很荣幸跟大家分享 Apache Beam 架构原理及应用实践。讲这门课之前大家可以想想，从进入 IT 行业以来，不停的搬运数据，不管职务为前端，还是后台服务器端开发。随着这两年科技的发展，各种数据库，数据源，应运而生，大数据组件，框架也是千变万化，从 Hadoop 到现在的 Spark、Flink，数据库从先前的 oracle、MySQL 到现在的 NOSQL，不断延伸。那么有没有统一的框架，统一的数据源搬砖工具呢？
•Kafka Stream 提供了一个非常简单而轻量的 Library，它可以非常方便地嵌入任意Java应用中，也可以任意方式打包和部署•除了 Kafka 外，无任何外部依赖•充分利用 Kafka 分区机制实现水平扩展和顺序性保证•通过可容错的 state store 实现高效的状态操作（如 windowed join 和aggregation）•支持正好一次处理语义•提供记录级的处理能力，从而实现毫秒级的低延迟•支持基于事件时间的窗口操作，并且可处理晚到的数据（late arrival of records）•同时提供底层的处理原语 Processor（类似于 Storm 的 spout 和 bolt），以及高层抽象的DSL（类似于 Spark 的 map/group/reduce）
本文是关于如何在实时分析中使用云原生应用程序对股票数据进行连续 SQL 操作的教程。
一，概述 Structured Streaming是一个可扩展和容错的流处理引擎，并且是构建于sparksql引擎之上。你可以用处理静态数据的方式去处理你的流计算。随着流数据的不断流入，Sparksql引擎会增量的连续不断的处理并且更新结果。可以使用DataSet/DataFrame的API进行 streaming aggregations, event-time windows, stream-to-batch joins等等。计算的执行也是基于优化后的sparksql引擎。通过checkpointing
本文主要研究一下flink的BoundedOutOfOrdernessTimestampExtractor
分布式系统需要解决：分配和管理在集群的计算资源、处理配合、持久和可访问的数据存储、失败恢复。Fink专注分布式流处理。
在SparkStreaming中窗口统计分析：Window Operation（设置窗口大小WindowInterval和滑动大小SlideInterval），按照Streaming 流式应用接收数据的时间进行窗口设计的，其实是不符合实际应用场景的。
正如在之前的那篇文章中 Spark Streaming 设计原理 中说到 Spark 团队之后对 Spark Streaming 的维护可能越来越少，Spark 2.4 版本的 [Release Note](http://spark.apache.org/releases/spark-release-2-4-0.html) 里面果然一个 Spark Streaming 相关的 ticket 都没有。相比之下，Structured Streaming 有将近十个 ticket 说明。所以各位同学，是时候舍弃 Spark Streaming 转向 Structured Streaming 了，当然理由并不止于此。我们这篇文章就来分析一下 Spark Streaming 的不足，以及Structured Streaming 的设计初衷和思想是怎么样的。文章主要参考今年（2018 年）sigmod 上面的这篇论文：Structured Streaming: A Declarative API for Real-Time
Apache Flink 是一个分布式大数据处理引擎，可对有限数据流和无限数据流进行有状态或无状态的计算，能够部署在各种集群环境，对各种规模大小的数据进行快速计算。
flink 的安装参照：flink 简单入门， 我们来了解下flink的配置文件。
Apache Flink 是一个分布式流计算引擎，用于在无边界和有边界数据流上进行有状态的计算。
在定义数据处理管道时，Table API 和 DataStream API 同样重要。
Spark创始人Matei最近在spark submmit上做了一次演讲，看了内容会发现spark这是要一统江湖的架势，一起来看看都介绍了什么内容。 Spark一直以来想做的一个事情就是统一整个大数据
Apache Spark在2016年的时候启动了Structured Streaming项目，一个基于Spark SQL的全新流计算引擎Structured Streaming，让用户像编写批处理程序一样简单地编写高性能的流处理程序。
Apache Flink（以下简称 Flink） 是一个天然支持无限流数据处理的分布式计算框架，在 Flink 中 Window 可以将无限流切分成有限流，是处理有限流的核心组件，现在 Flink 中 Window 可以是时间驱动的（Time Window），也可以是数据驱动的（Count Window）。
实际业务场景中，会遇到基础数据存在Mysql中，实时写入数据量比较大的情景。迁移至kafka是一种比较好的业务选型方案。
由Apache Flink提供支持的Cloudera Streaming Analytics的1.2.0.0版本提供了广泛的新功能 ，包括通过Apache Atlas 支持血缘和元数据跟踪，支持连接到Apache Kudu 以及期待已久的FlinkSQL API 的第一次迭代。
在Spark框架当中，早期的设计由Spark Streaming来负责实现流计算，但是随着现实需求的发展变化，Spark streaming的局限也显露了出来，于是Spark团队又设计了Spark Structured Streaming。今天的大数据开发学习分享，我们就主要来讲讲，Spark Structured Streaming特性。
Window 可以说是 Flink 中必不可少的 operator 之一，在很多场合都有很非凡的表现。今天呢，我们就一起来看一下 window 是如何实现的。
Apache Beam（原名Google DataFlow）是Google在2016年2月份贡献给Apache基金会的孵化项目，被认为是继MapReduce、GFS和BigQuery等之后，Google在大数据处理领域对开源社区的又一贡献。Apache Beam的主要目标是统一批处理和流处理的编程范式，为无限、乱序，Web-Scale的数据集处理提供简单灵活、功能丰富以及表达能力十分强大的SDK。Apache Beam项目重点在于数据处理的编程范式和接口定义，并不涉及具体执行引擎的实现。本文主要介绍Apac
Spark Streaming是Spark最初的流处理框架，使用了微批的形式来进行流处理。
Benthos 是一个开源的、高性能和弹性的数据流处理器，能够以各种代理模式连接各种源和汇，可以帮助用户在不同的消息流之间进行路由，转换和聚合数据，并对有效载荷执行水合、富集、转换和过滤。
这篇博客将会记录Structured Streaming + Kafka的一些基本使用(Java 版)
随着实时数据的日渐普及，企业需要流式计算系统满足可扩展、易用以及易整合进业务系统。Structured Streaming是一个高度抽象的API基于Spark Streaming的经验。Structured Streaming在两点上不同于其他的Streaming API比如Google DataFlow。 第一，不同于要求用户构造物理执行计划的API，Structured Streaming是一个基于静态关系查询（使用SQL或DataFrames表示）的完全自动递增的声明性API。 第二，Structured Streaming旨在支持端到端实时的应用，将流处理与批处理以及交互式分析结合起来。 我们发现，在实践中这种结合通常是关键的挑战。Structured Streaming的性能是Apache Flink的2倍，是Apacha Kafka 的90倍，这源于它使用的是Spark SQL的代码生成引擎。它也提供了丰富的操作特性，如回滚、代码更新、混合流\批处理执行。 我们通过实际数据库上百个生产部署的案例来描述系统的设计和使用，其中最大的每个月处理超过1PB的数据。
segmentio/kafka-go 是一款开源的golang kafka读写sdk，开源地址为：https://github.com/segmentio/kafka-go 。截止写文章时，这个开源代码库收获了3.3K的star，在很多公司内外部项目广泛使用。与 https://github.com/confluentinc/confluent-kafka-go 和 https://github.com/Shopify/sarama 一起，作为最常用的三个golang kafka sdk。
我们经常需要在一个时间窗口维度上对数据进行聚合，窗口是流处理应用中经常需要解决的问题。Flink的窗口算子为我们提供了方便易用的API，我们可以将数据流切分成一个个窗口，对窗口内的数据进行处理
掌握Flink中三种常用的Time处理方式，掌握Flink中滚动窗口以及滑动窗口的使用，了解Flink中的watermark。
Maxwell是一个能实时读取MySQL二进制日志binlog，并生成 JSON 格式的消息，作为生产者发送给 Kafka，Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平台的应用程序。它的常见应用场景有ETL、维护缓存、收集表级别的dml指标、增量到搜索引擎、数据分区迁移、切库binlog回滚方案等。官网(http://maxwells-daemon.io)、GitHub(https://github.com/zendesk/maxwell)
Flink 可以说已经是流计算领域的事实标准，其开源社区发展迅速，提出了很多改进计划（Flink Improvement Proposals，简称 FLIP）并不断迭代，几乎每个新的版本在功能、性能和使用便捷性上都有所提高。Flink 提供了丰富的数据连接器（connecotr）来连接各种数据源，内置了 kafka、jdbc、hive、hbase、elasticsearch、file system 等常见的 connector，此外 Flink 还提供了灵活的机制方便开发者开发新的 connector。对于 source connector 的开发，有基于传统的 SourceFunction 的方式和基于 Flink 改进计划 FLIP-27 的 Source 新架构的方式。本文首先介绍基于 SourceFunction 方式的不足，接着介绍 Source 新架构以及其设计上的深层思考，然后基于 Flink 1.13 ，以从零开发一个简单的 FileSource connector 为例，介绍开发 source connector 的基本要素，尽量做到理论与实践相结合，加深大家的理解。
在本次实验中，您将在 Cloudera SQL Stream Builder使用 SQL 语言查询和操作数据流。SQL Stream Builder 是一项功能强大的服务，使您无需编写 Java/Scala 代码即可创建 Flink 作业。
以下是我们如何确保我们不断发展的Gojek生态系统对我们的客户、司机伙伴和商户伙伴是安全的。 在Gojek，我们不断寻求创新的解决方案，以解决我们不断变化的挑战，为我们的客户、司机伙伴、商户伙伴和我们的整个生态系统保持平台安全。 ClickHouse正是用于这一目的。 它是我们最近部署的技术之一，以打击我们平台上的欺诈者。在这篇文章中，我们旨在描述我们采用ClickHouse的方法，涵盖以下主题。 使用ClickHouse的一个简化用例 为ClickHouse建立一个数据管道 我们的生产设置 ◆ 我们正
flink-table_2.11-1.7.0-sources.jar!/org/apache/flink/table/api/table.scala
• Table API 是一套内嵌在 Java 和 Scala 语言中的查询API，它允许以非常直观的方式组合来自一些关系运算符的查询
Apache Hudi 是一个流式数据湖平台，将核心仓库和数据库功能直接引入数据湖。Hudi 不满足于将自己称为 Delta 或 Apache Iceberg 之类的开放文件格式，它提供表、事务、更新/删除、高级索引、流式摄取服务、数据聚簇/压缩优化和并发性。Hudi 于 2016 年推出，牢牢扎根于 Hadoop 生态系统，解释了名称背后的含义：Hadoop Upserts Deletes and Incrementals。它是为管理 HDFS 上大型分析数据集的存储而开发的。Hudi 的主要目的是减少流数据摄取过程中的延迟。
当人们讨论使用apache kafka构建数据管道时，他们通常会应用如下几个示例，第一个就是构建一个数据管道，Apache Kafka是其中的终点。丽日，从kafka获取数据到s3或者从Mongodb获取数据到kafka。第二个用例涉及在两个不同的系统之间构建管道。但是使用kafka做为中介。一个例子就是先从twitter使用kafka发送数据到Elasticsearch，从twitter获取数据到kafka。然后从kafka写入到Elasticsearch。 我们在0.9版本之后在Apache kafka 中增加了kafka connect。是我们看到之后再linkerdin和其他大型公司都使用了kafka。我们注意到，在将kafka集成到数据管道中的时候，每个公司都必须解决的一些特定的挑战，因此我们决定向kafka 添加AP来解决其中的一些特定的挑战。而不是每个公司都需要从头开发。 kafka为数据管道提供的主要价值是它能够在管道的各个阶段之间充当一个非常大的，可靠的缓冲区，有效地解耦管道内数据的生产者和消费者。这种解耦，结合可靠性、安全性和效率，使kafka很适合大多数数据管道。
将数据从外部源如事件日志、数据库提取到Hadoop数据湖中是一个很常见的问题。在大多数Hadoop部署中，一般使用混合提取工具并以零散的方式解决该问题，尽管这些数据对组织是非常有价值的。
上一篇幅中对processing Time的整个注册流程与调用流程做了整体分析，并且分析了Flink中时间系统管理涉及的核心类，此篇幅将会介绍Event Time如何注册定时、定时如何触发。
librdkafka提供的异步的生产接口，异步的消费接口和同步的消息接口，没有同步的生产接口。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
