在大数据时代中我们迫切需要实时应用解决源源不断涌入的数据，然而建立这么一个应用需要解决多个问题：
随着实时数据的日渐普及，企业需要流式计算系统满足可扩展、易用以及易整合进业务系统。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的数据。
本篇博客，博主为大家带来的是关于Structured Streaming从入门到实战的一个攻略，希望感兴趣的朋友多多点赞支持!!
Apache Spark在2016年的时候启动了Structured Streaming项目，一个基于Spark SQL的全新流计算引擎Structured Streaming，让用户像编写批处理程序一样简单地编写高性能的流处理程序。
接着上一篇《Spark Streaming快速入门系列（7）》，这算是Spark的终结篇了，从Spark的入门到现在的Structured Streaming，相信很多人学完之后，应该对Spark摸索的差不多了，Spark是一个很重要的技术点，希望我的文章能给大家带来帮助。
http://spark.apache.org/docs/2.4.5/structured-streaming-kafka-integration.html
一个Kafka的Message由一个固定长度的header和一个变长的消息体body组成 header部分由一个字节的magic(文件格式)和四个字节的CRC32(用于判断body消息体是否正常)构成。当magic的值为1的时候，会在magic和crc32之间多一个字节的数据：attributes(保存一些相关属性，比如是否压缩、压缩格式等等)；如果magic的值为0，那么不存在attributes属性 body是由N个字节构成的一个消息体，包含了具体的key/value消息
在Spark框架当中，早期的设计由Spark Streaming来负责实现流计算，但是随着现实需求的发展变化，Spark streaming的局限也显露了出来，于是Spark团队又设计了Spark Structured Streaming。今天的大数据开发学习分享，我们就主要来讲讲，Spark Structured Streaming特性。
欢迎阅读美图数据技术团队的「Spark，从入门到精通」系列文章，本系列文章将由浅入深为大家介绍 Spark，从框架入门到底层架构的实现，相信总有一种姿势适合你，欢迎大家持续关注：）
此检查点位置必须是HDFS兼容文件系统中的路径，两种方式设置Checkpoint Location位置：
这篇博客将会记录Structured Streaming + Kafka的一些基本使用(Java 版)
写了快两个月Structured Streaming的代码，最近刚把数据迁移代码写完。
大数据入门学习框架 前言 利用框架的力量，看懂游戏规则，才是入行的前提 大多数人不懂，不会，不做，才是你的机会，你得行动，不能畏首畏尾 选择才是拉差距关键，风向，比你流的汗水重要一万倍，逆风划船要累
如今，越来越多的业务场景要求 OLTP 系统能及时得到业务数据计算、分析后的结果，这就需要实时的流式计算如Flink等来保障。例如，在 TB 级别数据量的数据库中，通过 SQL 语句或相关 API直接对原始数据进行大规模关联、聚合操作，是无法做到在极短的时间内通过接口反馈到前端进行展示的。若想实现大规模数据的“即席查询”，就须用实时计算框架构建实时数仓来实现。
读取的时候，可以读取某个topic，也可以读取多个topic，还可以指定topic的通配符形式：
当前无论是传统企业还是互联网公司对大数据实时分析和处理的要求越来越高，数据越实时价值越大，面向毫秒~ 秒级的实时大数据计算场景，Spark 和 Flink 各有所长。CarbonData 是一种高性能大数据存储方案，已在 20+ 企业生产环境上部署应用，其中最大的单一集群数据规模达到几万亿。
本系列主题是大数据开发面试指南，旨在为大家提供一个大数据学习的基本路线，完善数据开发的技术栈，以及我们面试一个大数据开发岗位的时候，哪些东西是重点考察的，这些公司更希望面试者具备哪些技能。
干线运输指的是运输的主干线, 在主干线上有最大的运力,一般快件的运行都是由支线去向主干线去汇集, 由主干线运输过去
浪院长，最近忙死了，写文章的时间都没了。但是，都说时间就像海绵里的水，挤挤就有了。所以，今晚十点半开始整理这篇Structured streaming 相关的文章。
The Spark Streaming integration for Kafka 0.10 is similar in design to the 0.8 Direct Stream approach；
正如在之前的那篇文章中 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
上一篇博客博主已经为大家从发展史到基本实战为大家详细介绍了StructedStreaming(具体请见:《看了这篇博客，你还敢说不会Structured Streaming？》)。本篇博客，博主将紧随前沿，为大家带来关于StructuredStreaming整合Kafka和MySQL的教程。
Hopsworks特征存储库统一了在线和批处理应用程序的特征访问而屏蔽了双数据库系统的复杂性。我们构建了一个可靠且高性能的服务，以将特征物化到在线特征存储库，不仅仅保证低延迟访问，而且还保证在服务时间可以访问最新鲜的特征值。
Structured Streaming 非常显式地提出了输入(Source)、执行(StreamExecution)、输出(Sink)的3个组件，并且在每个组件显式地做到fault-tolerant（容错），由此得到整个streaming程序的 end-to-end exactly-once guarantees。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6wtQxLP6-1626354186973)(/img/image-20210506154426999.png)]
二、从 Structured Data 到 Structured Streaming
Kafka是分布式发布-订阅消息系统，它最初是由LinkedIn公司开发的，之后成为Apache项目的一部分，Kafka是一个分布式，可划分的，冗余备份的持久性的日志服务，它主要用于处理流式数据。
一个Kafka的Message由一个固定长度的header和一个变长的消息体body组成。
分布式，是程序员必备技能之一，在面试过程中属于必备类的，在工作中更是会经常用到。而Kafka是一个分布式的基于发布订阅的消息队列，目前它的魅力是无穷的，对于Kafka的奥秘，还需要我们细细去探寻。
场景描述：Flink是标准的实时处理引擎，而且Spark的两个模块Spark Streaming和Structured Streaming都是基于微批处理的，不过现在Spark Streaming已经非常稳定基本都没有更新了，然后重点移到spark sql和structured Streaming了。
我们知道，当下流行的MQ非常多，不过很多公司在技术选型上还是选择使用Kafka。与其他主流MQ进行对比，我们会发现Kafka最大的优点就是吞吐量高。实际上Kafka是高吞吐低延迟的高并发、高性能的消息中间件，配置良好的Kafka集群甚至可以做到每秒几十万、上百万的超高并发写入。
市场上的许多玩家已经建立了成功的MapReduce工作流程来每天处理以TB计的历史数据。但是谁愿意等待24小时才能获得最新的分析结果？这篇博文将向您介绍旨在利用批处理和流处理方法的Lambda架构。我们将利用Apache Spark（Core，SQL，Streaming），Apache Parquet，Twitter Stream等实时流数据快速访问历史数据。还包括清晰的代码和直观的演示！
Hello，大家好，这里是857技术社区，我是社区创始人之一，以后会持续给大家更新大数据各组件的合集内容，路过给个关注吧!!!
Spark Streaming（下称streaming）是Spark core的拓展，一个易扩展、高吞吐、高容错的流式数据处理系统。
Real-Time End-to-End Integration with Apache Kafka in Apache Spark’s Structured Streaming
一，概述 Structured Streaming是一个可扩展和容错的流处理引擎，并且是构建于sparksql引擎之上。你可以用处理静态数据的方式去处理你的流计算。随着流数据的不断流入，Sparksql引擎会增量的连续不断的处理并且更新结果。可以使用DataSet/DataFrame的API进行 streaming aggregations, event-time windows, stream-to-batch joins等等。计算的执行也是基于优化后的sparksql引擎。通过checkpointing
我们可以通过交易数据接口以非常低的延迟获得全球各个比特币交易市场的每一笔比特币的成交价，成交额，交易时间。
1. 概要 Hadoop的MapReduce及Spark SQL等只能进行离线计算，无法满足实时性要求较高的业务需求，例如实时推荐，实时网站性能分析等，流式计算可以解决这些问题，spark Streaming就是现在常用的流式计算框架。作为spark的五大核心组件之一，spark Streaming原生地支持多种数据源的接入，而且可以与Spark MLLib、Graphx结合起来使用，具有高吞吐量，容错机制，
Flink是一个开源流处理框架，注意它是一个处理计算框架，类似Spark框架，Flink在数据摄取方面非常准确，在保持状态的同时能轻松地从故障中恢复。
在这个数据驱动的时代，信息的处理和分析变得越来越重要。而在众多的大数据处理框架中，「Apache Spark」以其独特的优势脱颖而出。
大数据时代来临，如果你还不知道Kafka那你就真的out了(快速掌握Kafka请参考文章：如何全方位掌握Kafka核心技术)！据统计，有三分之一的世界财富500强企业正在使用Kafka，包括所有TOP10旅游公司，7家TOP10银行，8家TOP10保险公司，9家TOP10电信公司等等。
Structured Streaming将实时数据视为一张正在不断添加数据的表。
CDC(Change Data Capture)从广义上讲所有能够捕获变更数据的技术都可以称为CDC，但本篇文章中对CDC的定义限定为以非侵入的方式实时捕获数据库的变更数据。例如：通过解析MySQL数据库的Binlog日志捕获变更数据，而不是通过SQL Query源表捕获变更数据。Hudi 作为最热的数据湖技术框架之一, 用于构建具有增量数据处理管道的流式数据湖。其核心的能力包括对象存储上数据行级别的快速更新和删除，增量查询(Incremental queries,Time Travel)，小文件管理和查询优化(Clustering,Compactions,Built-in metadata)，ACID和并发写支持。Hudi不是一个Server，它本身不存储数据，也不是计算引擎，不提供计算能力。其数据存储在S3(也支持其它对象存储和HDFS)，Hudi来决定数据以什么格式存储在S3(Parquet,Avro,…), 什么方式组织数据能让实时摄入的同时支持更新，删除，ACID等特性。Hudi通过Spark，Flink计算引擎提供数据写入, 计算能力，同时也提供与OLAP引擎集成的能力，使OLAP引擎能够查询Hudi表。从使用上看Hudi就是一个JAR包，启动Spark, Flink作业的时候带上这个JAR包即可。Amazon EMR 上的Spark，Flink，Presto ，Trino原生集成Hudi, 且EMR的Runtime在Spark，Presto引擎上相比开源有2倍以上的性能提升。在多库多表的场景下(比如：百级别库表)，当我们需要将数据库(mysql,postgres,sqlserver,oracle,mongodb等)中的数据通过CDC的方式以分钟级别(1minute+)延迟写入Hudi，并以增量查询的方式构建数仓层次，对数据进行实时高效的查询分析时。我们要解决三个问题，第一，如何使用统一的代码完成百级别库表CDC数据并行写入Hudi，降低开发维护成本。第二，源端Schema变更如何同步到Hudi表。第三，使用Hudi增量查询构建数仓层次比如ODS->DWD->DWS(各层均是Hudi表)，DWS层的增量聚合如何实现。本篇文章推荐的方案是: 使用Flink CDC DataStream API(非SQL)先将CDC数据写入Kafka，而不是直接通过Flink SQL写入到Hudi表，主要原因如下，第一，在多库表且Schema不同的场景下，使用SQL的方式会在源端建立多个CDC同步线程，对源端造成压力，影响同步性能。第二，没有MSK做CDC数据上下游的解耦和数据缓冲层，下游的多端消费和数据回溯比较困难。CDC数据写入到MSK后，推荐使用Spark Structured Streaming DataFrame API或者Flink StatementSet 封装多库表的写入逻辑，但如果需要源端Schema变更自动同步到Hudi表，使用Spark Structured Streaming DataFrame API实现更为简单，使用Flink则需要基于HoodieFlinkStreamer做额外的开发。Hudi增量ETL在DWS层需要数据聚合的场景的下，可以通过Flink Streaming Read将Hudi作为一个无界流，通过Flink计算引擎完成数据实时聚合计算写入到Hudi表。
在很多实时数据处理的场景中，都需要用到流式处理（Stream Process）框架，Spark也包含了两个完整的流式处理框架Spark Streaming和Structured Streaming（Spark 2.0出现），先阐述流式处理框架，之后介绍Spark Streaming框架使用。
数据时代，从数据中获取业务需要的信息才能创造价值，这类工作就需要计算框架来完成。传统的数据处理流程中，总是先收集数据，然后将数据放到DB中。当人们需要的时候通过DB对数据做query，得到答案或进行相关的处理。这样看起来虽然非常合理，但是结果却非常紧凑，尤其是在一些实时搜索应用环境中的某些具体问题，类似于MapReduce方式的离线处理并不能很好地解决。 基于此，一种新的数据计算结构---流计算方式出现了，它可以很好地对大规模流动数据在不断变化的运动过程中实时地进行分析，捕捉到可能有用的信息，并把结果发送
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
