http://spark.apache.org/docs/2.4.5/structured-streaming-kafka-integration.html
在大数据时代中我们迫切需要实时应用解决源源不断涌入的数据，然而建立这么一个应用需要解决多个问题：
随着实时数据的日渐普及，企业需要流式计算系统满足可扩展、易用以及易整合进业务系统。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的数据。
目前Spark中Structured Streaming只支持实时向Iceberg中写入数据，不支持实时从Iceberg中读取数据，下面案例我们将使用Structured Streaming从Kafka中实时读取数据，然后将结果实时写入到Iceberg中。
读取的时候，可以读取某个topic，也可以读取多个topic，还可以指定topic的通配符形式：
这篇博客将会记录Structured Streaming + Kafka的一些基本使用(Java 版)
浪院长，最近忙死了，写文章的时间都没了。但是，都说时间就像海绵里的水，挤挤就有了。所以，今晚十点半开始整理这篇Structured streaming 相关的文章。
此检查点位置必须是HDFS兼容文件系统中的路径，两种方式设置Checkpoint Location位置：
第一，MapReduce模型的抽象层次低，大量的底层逻辑都需要开发者手工完成。 第二，只提供Map和Reduce两个操作。 举个例子，两个数据集的Join是很基本而且常用的功能，但是在MapReduce的世界中，需要对这两个数据集 做一次Map和Reduce才能得到结果。 第三，在Hadoop中，每一个Job的计算结果都会存储在HDFS文件存储系统中，所以每一步计算都要进行硬 盘的读取和写入，大大增加了系统的延迟。 第四，只支持批数据处理，欠缺对流数据处理的支持。
写了快两个月Structured Streaming的代码，最近刚把数据迁移代码写完。
最近很多球友都说在准备面试，不知道准备点啥，尤其是spark，实际上星球里浪尖分享的内容真的都掌握了，应对一般面试绝对没问题，但是遗憾的事情是很多人都是处于不会主动搜集资料，主动梳理知识，主动记忆整理知识，而是伸手要粮的境地。浪尖觉得这个是阻止你成长的罪魁祸手。前天跟朋友聚餐就说道这种情况，不努力，不加班给自己喂粮的，没有足够量和时间积累的人很难在一个领域里有所建树。
一，概述 Structured Streaming是一个可扩展和容错的流处理引擎，并且是构建于sparksql引擎之上。你可以用处理静态数据的方式去处理你的流计算。随着流数据的不断流入，Sparksql引擎会增量的连续不断的处理并且更新结果。可以使用DataSet/DataFrame的API进行 streaming aggregations, event-time windows, stream-to-batch joins等等。计算的执行也是基于优化后的sparksql引擎。通过checkpointing
本文介绍了 Structured Streaming 是如何逐步从 Apache Spark 生态系统中发展起来的，以及其设计理念和实现方式。本文还介绍了 Structured Streaming 在实际应用中的优势，包括与批处理计算的关系、与 Apache Kafka 的集成、以及在高吞吐和低延迟场景下的性能表现。此外，本文还提供了若干实例，以展示 Structured Streaming 在各种应用场景中的实际效果。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6wtQxLP6-1626354186973)(/img/image-20210506154426999.png)]
分布式，是程序员必备技能之一，在面试过程中属于必备类的，在工作中更是会经常用到。而Kafka是一个分布式的基于发布订阅的消息队列，目前它的魅力是无穷的，对于Kafka的奥秘，还需要我们细细去探寻。
Hello，大家好，这里是857技术社区，我是社区创始人之一，以后会持续给大家更新大数据各组件的合集内容，路过给个关注吧!!!
在这个数据驱动的时代，信息的处理和分析变得越来越重要。而在众多的大数据处理框架中，「Apache Spark」以其独特的优势脱颖而出。
我们知道，当下流行的MQ非常多，不过很多公司在技术选型上还是选择使用Kafka。与其他主流MQ进行对比，我们会发现Kafka最大的优点就是吞吐量高。实际上Kafka是高吞吐低延迟的高并发、高性能的消息中间件，配置良好的Kafka集群甚至可以做到每秒几十万、上百万的超高并发写入。
本篇博客，博主为大家带来的是关于Structured Streaming从入门到实战的一个攻略，希望感兴趣的朋友多多点赞支持!!
接着上一篇《Spark Streaming快速入门系列（7）》，这算是Spark的终结篇了，从Spark的入门到现在的Structured Streaming，相信很多人学完之后，应该对Spark摸索的差不多了，Spark是一个很重要的技术点，希望我的文章能给大家带来帮助。
又是一个超长的标题（摊手┓( ´∀` )┏）。Spark Streaming 历史比较悠久，也确实非常好用，更重要的是，大家已经用熟了，有的还做了不少工具了，所以觉得这东西特别好了，不会像一开始各种吐槽了。反倒是Structured Streaming， 吐槽点比较多，但是到目前，我们经过一番实践，觉得是时候丢掉Spark Streaming 升级到Structured Streaming了。
Structured Streaming 非常显式地提出了输入(Source)、执行(StreamExecution)、输出(Sink)的3个组件，并且在每个组件显式地做到fault-tolerant（容错），由此得到整个streaming程序的 end-to-end exactly-once guarantees。
场景描述：Flink是标准的实时处理引擎，而且Spark的两个模块Spark Streaming和Structured Streaming都是基于微批处理的，不过现在Spark Streaming已经非常稳定基本都没有更新了，然后重点移到spark sql和structured Streaming了。
本系列主题是大数据开发面试指南，旨在为大家提供一个大数据学习的基本路线，完善数据开发的技术栈，以及我们面试一个大数据开发岗位的时候，哪些东西是重点考察的，这些公司更希望面试者具备哪些技能。
在这里我们解释如何配置 Spark Streaming 以接收来自 Kafka 的数据。有两种方法，一种为使用 Receivers 和 Kafka 高级API的旧方法，以及不使用 Receivers 的新方法（在 Spark 1.3 中引入）。它们具有不同的编程模型，性能特征和语义保证。就目前的 Spark 版本而言，这两种方法都被为稳定的API。
Spark 针对 Kafka 的不同版本，提供了两套整合方案：spark-streaming-kafka-0-8 和 spark-streaming-kafka-0-10，其主要区别如下：
Delta 原本是在 Databricks Runtime 里面的一个增值功能，在 spark + AI Summit 2019 大会上，官方以 Apache License 2.0 协议开源。
在Spark框架当中，早期的设计由Spark Streaming来负责实现流计算，但是随着现实需求的发展变化，Spark streaming的局限也显露了出来，于是Spark团队又设计了Spark Structured Streaming。今天的大数据开发学习分享，我们就主要来讲讲，Spark Structured Streaming特性。
上一篇博客博主已经为大家从发展史到基本实战为大家详细介绍了StructedStreaming(具体请见:《看了这篇博客，你还敢说不会Structured Streaming？》)。本篇博客，博主将紧随前沿，为大家带来关于StructuredStreaming整合Kafka和MySQL的教程。
连续处理（Continuous Processing）是“真正”的流处理，通过运行一个long-running的operator用来处理数据。
从Spark 2.0至Spark 2.4版本，目前支持数据源有4种，其中Kafka 数据源使用作为广泛，其他数据源主要用于开发测试程序。
一个Kafka的Message由一个固定长度的header和一个变长的消息体body组成。
Spark 2.0 将流式计算也统一到DataFrame里去了，提出了Structured Streaming的概念，将数据源映射为一张无线长度的表，同时将流式计算的结果映射为另外一张表，完全以结构化的方式去操作流式数据，复用了其对象的Catalyst引擎。
当前无论是传统企业还是互联网公司对大数据实时分析和处理的要求越来越高，数据越实时价值越大，面向毫秒~ 秒级的实时大数据计算场景，Spark 和 Flink 各有所长。CarbonData 是一种高性能大数据存储方案，已在 20+ 企业生产环境上部署应用，其中最大的单一集群数据规模达到几万亿。
我们可以通过交易数据接口以非常低的延迟获得全球各个比特币交易市场的每一笔比特币的成交价，成交额，交易时间。
作者Michael G. Noll是瑞士的一位工程师和研究员，效力于Verisign，是Verisign实验室的大规模数据分析基础设施（基础Hadoop）的技术主管。本文，Michael详细的演示了如何将Kafka整合到Spark Streaming中。期间，Michael还提到了将Kafka整合到Spark Streaming中的一些现状，非常值得阅读，虽然有一些信息在Spark 1.2版本中已发生了一些变化，比如HA策略：通过Spark Contributor、Spark布道者陈超我们了解到，在Spar
Apache Spark在2016年的时候启动了Structured Streaming项目，一个基于Spark SQL的全新流计算引擎Structured Streaming，让用户像编写批处理程序一样简单地编写高性能的流处理程序。
大数据入门学习框架 前言 利用框架的力量，看懂游戏规则，才是入行的前提 大多数人不懂，不会，不做，才是你的机会，你得行动，不能畏首畏尾 选择才是拉差距关键，风向，比你流的汗水重要一万倍，逆风划船要累
当前公司的大数据实时链路如下图，数据源是MySQL数据库，然后通过Binlog Query的方式消费或者直接客户端采集到Kafka，最终通过基于Spark/Flink实现的批流一体计算引擎处理，最后输出到下游对应的存储。
1. 概要 Hadoop的MapReduce及Spark SQL等只能进行离线计算，无法满足实时性要求较高的业务需求，例如实时推荐，实时网站性能分析等，流式计算可以解决这些问题，spark Streaming就是现在常用的流式计算框架。作为spark的五大核心组件之一，spark Streaming原生地支持多种数据源的接入，而且可以与Spark MLLib、Graphx结合起来使用，具有高吞吐量，容错机制，
一般的大型集群和平台, 都需要对其进行监控的需求。 要针对各种数据库, 包括 MySQL, HBase 等进行监控 要针对应用进行监控, 例如 Tomcat, Nginx, Node.js 等 要针对硬件的一些指标进行监控, 例如 CPU, 内存, 磁盘 等
spark读取kafka数据流提供了两种方式createDstream和createDirectStream。 两者区别如下： 1、KafkaUtils.createDstream 构造函数为KafkaUtils.createDstream(ssc, [zk], [consumer group id], [per-topic,partitions] ) 使用了receivers来接收数据，利用的是Kafka高层次的消费者api，对于所有的receivers接收到的数据将会保存在Spark executors中，然后通过Spark Streaming启动job来处理这些数据，默认会丢失，可启用WAL日志，该日志存储在HDFS上 A、创建一个receiver来对kafka进行定时拉取数据，ssc的rdd分区和kafka的topic分区不是一个概念，故如果增加特定主体分区数仅仅是增加一个receiver中消费topic的线程数，并不增加spark的并行处理数据数量 B、对于不同的group和topic可以使用多个receivers创建不同的DStream C、如果启用了WAL，需要设置存储级别，即KafkaUtils.createStream(….,StorageLevel.MEMORY_AND_DISK_SER) 2.KafkaUtils.createDirectStream 区别Receiver接收数据，这种方式定期地从kafka的topic+partition中查询最新的偏移量，再根据偏移量范围在每个batch里面处理数据，使用的是kafka的简单消费者api 优点: A、 简化并行，不需要多个kafka输入流，该方法将会创建和kafka分区一样的rdd个数，而且会从kafka并行读取。 B、高效，这种方式并不需要WAL，WAL模式需要对数据复制两次，第一次是被kafka复制，另一次是写到wal中
## Spark Streaming(DStreaming) VS Spark Structured 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
Spark是Scala语言实现的核心数据结构是RDD的基于内存迭代计算的分布式框架。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
