Spark3大数据实时处理-Streaming+Structured Streaming 实战
作者：互联网
download：Spark3大数据实时处理-Streaming+Structured Streaming 实战
随着云计算和大数据的快速发展，在企业中大数据实时处理场景的需求越来越多。本课针对企业级实时处理方案进行全方位的讲解，基于Spark3，在同一个项目中，学习两套实时处理的解决方案：Spark Streaming和Structured Streaming。在框架学习的基础上，不仅带你体验完整实时处理方案的全流程，真正所学即所用，还会为你梳理大数据的常见面试题、大厂的实时解决方案，带你跨过面试最后一公里。
适合人群
想转型或者从事大数据开发的同学
对Spark有浓厚兴趣的同学
想掌握大数据实时处理技术的同学
技术储备要求
Linux命令基本操作
Hadoop命令基本操作
Scala基本语法的使用
struct bs{
unsigned m;
unsigned n: 4;
unsigned char ch: 6;
};
:后面的数字用来限定成员变量占用的位数。成员 m 没有限制，依据数据类型即可推算出它占用 4 个字节（Byte）的内存。成员 n、ch 被:后面的数字限制，不能再依据数据类型计算长度，它们分别占用 4、6 位（Bit）的内存。
n、ch 的取值范围十分有限，数据略微大些就会发作溢出，请看下面的例子：
#include <stdio.h>
int main(){
struct bs{
unsigned m;
unsigned n: 4;
unsigned char ch: 6;
} a = { 0xad, 0xE, '$'};
//第一次输出
printf("%#x, %#x, %c\n", a.m, a.n, a.ch);
//更改值后再次输出
a.m = 0xb8901c;
a.n = 0x2d;
a.ch = 'z';
printf("%#x, %#x, %c\n", a.m, a.n, a.ch);
return 0;
}
运转结果：
0xad, 0xe, $
0xb8901c, 0xd, :
关于 n 和 ch，第一次输出的数据是完好的，第二次输出的数据是残缺的。
第一次输出时，n、ch 的值分别是 0xE、0x24（'$' 对应的 ASCII 码为 0x24），换算成二进制是 1110、10 0100，都没有超出限定的位数，可以正常输出。
第二次输出时，n、ch 的值变为 0x2d、0x7a（'z' 对应的 ASCII 码为 0x7a），换算成二进制分别是 10 1101、111 1010，都超出了限定的位数。超出局部被直接截去，剩下 1101、11 1010，换算成十六进制为 0xd、0x3a（0x3a 对应的字符是 :）。
C言语规范规则，位域的宽度不能超越它所依附的数据类型的长度。浅显地讲，成员变量都是有类型的，这个类型限制了成员变量的最大长度，:后面的数字不能超越这个长度。
例如上面的 bs，n 的类型是 unsigned int，长度为 4 个字节，共计 32 位，那么 n 后面的数字就不能超越 32；ch 的类型是 unsigned char，长度为 1 个字节，共计 8 位，那么 ch 后面的数字就不能超越 8。
我们能够这样以为，位域技术就是在成员变量所占用的内存当选出一局部位宽来存储数据。
C言语规范还规则，只要有限的几种数据类型能够用于位域。在 ANSI C 中，这几种数据类型是 int、signed int 和 unsigned int（int 默许就是 signed int）；到了 C99，_Bool 也被支持了。
关于C言语规范以及 ANSI C 和 C99 的区别，我们已在付费教程《C言语的三套规范：C89、C99和C11》中停止了解说。
但编译器在详细完成时都停止了扩展，额外支持了 char、signed char、unsigned char 以及 enum 类型，所以上面的代码固然不契合C言语规范，但它仍然可以被编译器支持。
位域的存储
C言语规范并没有规则位域的详细存储方式，不同的编译器有不同的完成，但它们都尽量紧缩存储空间。
位域的详细存储规则如下：
1) 当相邻成员的类型相同时，假如它们的位宽之和小于类型的 sizeof 大小，那么后面的成员紧邻前一个成员存储，直到不能包容为止；假如它们的位宽之和大于类型的 sizeof 大小，那么后面的成员将重新的存储单元开端，其偏移量为类型大小的整数倍。
以下面的位域 bs 为例：
#include <stdio.h>
int main(){
struct bs{
unsigned m: 6;
unsigned n: 12;
unsigned p: 4;
};
printf("%d\n", sizeof(struct bs));
return 0;
}
运转结果：
4
m、n、p 的类型都是 unsigned int，sizeof 的结果为 4 个字节（Byte），也即 32 个位（Bit）。m、n、p 的位宽之和为 6+12+4 = 22，小于 32，所以它们会挨着存储，中间没有缝隙。
sizeof(struct bs) 的大小之所以为 4，而不是 3，是由于要将内存对齐到 4 个字节，以便进步存取效率，这将在《C言语内存精讲》专题的《C言语内存对齐，进步寻址效率》一节中细致解说。
假如将成员 m 的位宽改为 22，那么输出结果将会是 8，由于 22+12 = 34，大于 32，n 会重新的位置开端存储，相对 m 的偏移量是 sizeof(unsigned int)，也即 4 个字节。
假如再将成员 p 的位宽也改为 22，那么输出结果将会是 12，三个成员都不会挨着存储。
2) 当相邻成员的类型不同时，不同的编译器有不同的完成计划，GCC 会紧缩存储，而 VC/VS 不会。
请看下面的位域 bs：
#include <stdio.h>
int main(){
struct bs{
unsigned m: 12;
unsigned char ch: 4;
unsigned p: 4;
};
printf("%d\n", sizeof(struct bs));
return 0;
}
在 GCC 下的运转结果为 4，三个成员挨着存储；在 VC/VS 下的运转结果为 12，三个成员依照各自的类型存储（与不指定位宽时的存储方式相同）。
m 、ch、p 的长度分别是 4、1、4 个字节，共计占用 9 个字节内存，为什么在 VC/VS 下的输出结果却是 12 呢？这个疑问将在《C言语和内存》专题的《C言语内存对齐，进步寻址效率》一节中为您解开。
3) 假如成员之间交叉着非位域成员，那么不会停止紧缩。例如关于下面的 bs：
struct bs{
unsigned m: 12;
unsigned ch;
unsigned p: 4;
};
在各个编译器下 sizeof 的结果都是 12。
经过上面的剖析，我们发现位域成员常常不占用完好的字节，有时分也不处于字节的开头位置，因而运用&获取位域成员的地址是没有意义的，C言语也制止这样做。地址是字节（Byte）的编号，而不是位（Bit）的编号。
无名位域
位域成员能够没有称号，只给出数据类型和位宽，如下所示：
struct bs{
int m: 12;
int : 20; //该位域成员不能运用
int n: 4;
};
标签：ch,Spark3,成员,Structured,unsigned,Streaming,int,bs,位域 来源： https://blog.51cto.com/15110735/2661272