大数据开发（牛客）面试被问频率最高的几道面试题_数据开发(牛客)面试被问频率最高的几道面试题

最新推荐文章于 2024-09-19 00:34:04 发布

2401_84573531

最新推荐文章于 2024-09-19 00:34:04 发布

阅读量407

点赞数 4

分类专栏：程序员文章标签：大数据面试学习

本文链接：https://blog.csdn.net/2401_84573531/article/details/138900969

版权

程序员专栏收录该内容

58 篇文章 0 订阅

订阅专栏

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

可灵活回答：

1）Kafka为什么低延迟高吞吐？

2）Kafka高吞吐的原因

3）Kafka为什么高可用、高吞吐？

4）Kafka如何保证高吞吐量？

问过的一些公司：

蘑菇街x2，腾讯，美团x2，猿辅导，转转，小鹏汽车，京东，字节，网易

Kafka是分布式消息系统，需要处理海量的消息，Kafka的设计是把所有的消息都写入速度低容量大的硬盘，以此来换取更强的存储能力，但实际上，使用硬盘并没有带来过多的性能损失。

kafka主要使用了以下几个方式实现了超高的吞吐率。

1）顺序读写

kafka的消息是不断追加到文件中的，这个特性使kafka可以充分利用磁盘的顺序读写性能，顺序读写不需要硬盘磁头的寻道时间，只需很少的扇区旋转时间，所以速度远快于随机读写。

Kafka官方给出了测试数据(Raid-5，7200rpm)：

顺序 I/O: 600MB/s

随机 I/O: 100KB/s

2）零拷贝

先简单了解下文件系统的操作流程，例如一个程序要把文件内容发送到网络。

这个程序是工作在用户空间，文件和网络socket属于硬件资源，两者之间有一个内核空间。

在操作系统内部，整个过程为：

图片
在 Linux kernel2.2 之后出现了一种叫做"零拷贝(zero-copy)"系统调用机制，就是跳过“用户缓冲区”的拷贝，建立一个磁盘空间和内存的直接映射，数据不再复制到“用户态缓冲区” 。

系统上下文切换减少为 2 次，可以提升一倍的性能。

图片
3）文件分段

kafka的队列topic被分为了多个区partition，每个partition又分为多个段segment，所以一个队列中的消息实际上是保存在N多个片段文件中

图片
通过分段的方式，每次文件操作都是对一个小文件的操作，非常轻便，同时也增加了并行处理能力

4）批量发送

Kafka允许进行批量发送消息，先将消息缓存在内存中，然后一次请求批量发送出去，比如可以指定缓存的消息达到某个量的时候就发出去，或者缓存了固定的时间后就发送出去，如100 条消息就发送，或者每5秒发送一次，这种策略将大大减少服务端的I/O次数

5）数据压缩

Kafka 还支持对消息集合进行压缩，Producer可以通过GZIP或Snappy格式对消息集合进行压缩，压缩的好处就是减少传输的数据量，减轻对网络传输的压力，Producer压缩之后，在 Consumer需进行解压，虽然增加了CPU的工作，但在对大数据处理上，瓶颈在网络上而不是 CPU，所以这个成本很值得。

HBase

HBase的rowkey设计原则

可灵活回答：

1）HBase如何设计rowkey？

2）你HBase的rowkey为什么这么设计？有什么优缺点？

3）Hbase rowKey设置讲究

问过的一些公司：

阿里x3，腾讯x2，美团x3，顺丰，360，小米x4，富途，蘑菇街，陌陌x2，美团，冠群驰骋，携程x2，vivo

HBase中，表会被划分为1…n个Region，被托管在RegionServer中。Region二个重要的属性：StartKey与EndKey表示这个Region维护的rowKey范围，当我们要读/写数据时，如果rowKey落在某个start-end key范围内，那么就会定位到目标region并且读/写到相关的数据。

那怎么快速精准的定位到我们想要操作的数据，就在于我们的rowkey的设计了。

设计原则如下：

1、rowkey长度原则

Rowkey是一个二进制码流，Rowkey的长度被很多开发者建议说设计在10~100个字节，不过建议是越短越好，不要超过16个字节。

原因如下：

1）数据的持久化文件HFile中是按照Key Value 存储的，如果Rowkey过长比如100个字节，1000万列数据光Rowkey就要占用100*1000 万=10亿个字节，将近1G数据，这会极大影响 HFile的存储效率；

2）MemStore将缓存部分数据到内存，如果 Rowkey字段过长内存的有效利用率会降低，系统将无法缓存更多的数据，这会降低检索效率。因此Rowkey的字节长度越短越好；

3）目前操作系统是都是64位系统，内存8字节对齐。控制在16个字节，8字节的整数倍利用操作系统的最佳特性。

2、rowkey散列原则

如果Rowkey是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散列字段，由程序循环生成，低位放时间字段，将会提高数据均衡分布在每个Regionserver实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个 RegionServer上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别 RegionServer，降低查询效率。

3、rowkey唯一原则

必须在设计上保证其唯一性。rowkey是按照字典顺序排序存储的，因此，设计rowkey的时候，要充分利用这个排序的特点，将经常读取的数据存储到一块，将最近可能会被访问的数据放到一块。

Spark

Spark数据倾斜问题+解决方案

问过的一些公司：

字节跳动x8，安恒信息，顺丰，腾讯，网易云音乐x2，小米，祖龙娱乐，商汤科技，阿里，米哈游，快手，百度社招，触宝，多益，贝壳，ebayx2，京东，嘉云数据

1、数据倾斜

数据倾斜指的是，并行处理的数据集中，某一部分（如Spark或Kafka的一个Partition）的数据显著多于其它部分，从而使得该部分的处理速度成为整个数据集处理的瓶颈

数据倾斜俩大直接致命后果

1）数据倾斜直接会导致一种情况：Out Of Memory

2）运行速度慢

主要是发生在Shuffle阶段。同样Key的数据条数太多了。导致了某个key(下图中的80亿条)所在的Task数据量太大了。远远超过其他Task所处理的数据量

图片
一个经验结论是：一般情况下，OOM的原因都是数据倾斜

2、如何定位数据倾斜

数据倾斜一般会发生在shuffle过程中。很大程度是使用可能会触发shuffle操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。

查看任务->查看Stage->查看代码

图片
也可从以下几种情况考虑：

1）是不是有OOM情况出现，一般是少数内存溢出的问题

2）是不是应用运行时间差异很大，总体时间很长

3）需要了解你所处理的数据Key的分布情况，如果有些Key有大量的条数，那么就要小心数据倾斜的问题

4）一般需要通过Spark Web UI和其他一些监控方式出现的异常来综合判断

5）看看代码里面是否有一些导致Shuffle的算子出现

3、数据倾斜的几种典型情况

3.1 数据源中的数据分布不均匀，Spark需要频繁交互

3.2 数据集中的不同Key由于分区方式，导致数据倾斜

3.3 JOIN操作中，一个数据集中的数据分布不均匀，另一个数据集较小（主要）

3.4 聚合操作中，数据集中的数据分布不均匀（主要）

3.5 JOIN操作中，两个数据集都比较大，其中只有几个Key的数据分布不均匀

3.6 JOIN操作中，两个数据集都比较大，有很多Key的数据分布不均匀

3.7 数据集中少数几个key数据量很大，不重要，其他数据均匀

4、数据倾斜的处理方法

4.1 数据源中的数据分布不均匀，Spark需要频繁交互

解决方案：避免数据源的数据倾斜

实现原理：通过在Hive中对倾斜的数据进行预处理，以及在进行kafka数据分发时尽量进行平均分配。这种方案从根源上解决了数据倾斜，彻底避免了在Spark中执行shuffle类算子，那么肯定就不会有数据倾斜的问题了。

方案优点：实现起来简单便捷，效果还非常好，完全规避掉了数据倾斜，Spark作业的性能会大幅度提升。

方案缺点：治标不治本，Hive或者Kafka中还是会发生数据倾斜。

适用情况：在一些Java系统与Spark结合使用的项目中，会出现Java代码频繁调用Spark作业的场景，而且对Spark作业的执行性能要求很高，就比较适合使用这种方案。将数据倾斜提前到上游的Hive ETL，每天仅执行一次，只有那一次是比较慢的，而之后每次Java调用Spark作业时，执行速度都会很快，能够提供更好的用户体验。

总结：前台的Java系统和Spark有很频繁的交互，这个时候如果Spark能够在最短的时间内处理数据，往往会给前端有非常好的体验。这个时候可以将数据倾斜的问题抛给数据源端，在数据源端进行数据倾斜的处理。但是这种方案没有真正的处理数据倾斜问题

4.2 数据集中的不同Key由于分区方式，导致数据倾斜

解决方案1：调整并行度

实现原理：增加shuffle read task的数量，可以让原本分配给一个task的多个key分配给多个task，从而让每个task处理比原来更少的数据。

方案优点：实现起来比较简单，可以有效缓解和减轻数据倾斜的影响。

方案缺点：只是缓解了数据倾斜而已，没有彻底根除问题，根据实践经验来看，其效果有限。

实践经验：该方案通常无法彻底解决数据倾斜，因为如果出现一些极端情况，比如某个key对应的数据量有100万，那么无论你的task数量增加到多少，都无法处理。

图片
解决方案2：

自定义Partitioner（缓解数据倾斜）

适用场景：大量不同的Key被分配到了相同的Task造成该Task数据量过大。

解决方案：使用自定义的Partitioner实现类代替默认的HashPartitioner，尽量将所有不同的Key均匀分配到不同的Task中。

优势：不影响原有的并行度设计。如果改变并行度，后续Stage的并行度也会默认改变，可能会影响后续Stage。

劣势：适用场景有限，只能将不同Key分散开，对于同一Key对应数据集非常大的场景不适用。效果与调整并行度类似，只能缓解数据倾斜而不能完全消除数据倾斜。而且需要根据数据特点自定义专用的Partitioner，不够灵活。

4.3 JOIN操作中，一个数据集中的数据分布不均匀，另一个数据集较小（主要）

解决方案：

Reduce side Join转变为Map side Join

适用场景：在对RDD使用join类操作，或者是在Spark SQL中使用join语句时，而且join操作中的一个RDD或表的数据量比较小（比如几百M），比较适用此方案。

实现原理：普通的join是会走shuffle过程的，而一旦shuffle，就相当于会将相同key的数据拉取到一个shuffle read task中再进行join，此时就是reduce join。但是如果一个RDD是比较小的，则可以采用广播小RDD全量数据+map算子来实现与join同样的效果，也就是map join，此时就不会发生shuffle操作，也就不会发生数据倾斜。

优点：对join操作导致的数据倾斜，效果非常好，因为根本就不会发生shuffle，也就根本不会发生数据倾斜。

缺点：适用场景较少，因为这个方案只适用于一个大表和一个小表的情况。

4.4 聚合操作中，数据集中的数据分布不均匀（主要）

解决方案：两阶段聚合（局部聚合+全局聚合）

适用场景：对RDD执行reduceByKey等聚合类shuffle算子或者在Spark SQL中使用group by语句进行分组聚合时，比较适用这种方案

实现原理：将原本相同的key通过附加随机前缀的方式，变成多个不同的key，就可以让原本被一个task处理的数据分散到多个task上去做局部聚合，进而解决单个task处理数据量过多的问题。接着去除掉随机前缀，再次进行全局聚合，就可以得到最终的结果。具体原理见下图。

优点：对于聚合类的shuffle操作导致的数据倾斜，效果是非常不错的。通常都可以解决掉数据倾斜，或者至少是大幅度缓解数据倾斜，将Spark作业的性能提升数倍以上。

缺点：仅仅适用于聚合类的shuffle操作，适用范围相对较窄。如果是join类的shuffle操作，还得用其他的解决方案

将相同key的数据分拆处理

图片
4.5 JOIN操作中，两个数据集都比较大，其中只有几个Key的数据分布不均匀

解决方案：为倾斜key增加随机前/后缀

适用场景：两张表都比较大，无法使用Map侧Join。其中一个RDD有少数几个Key的数据量过大，另外一个RDD的Key分布较为均匀。

解决方案：将有数据倾斜的RDD中倾斜Key对应的数据集单独抽取出来加上随机前缀，另外一个RDD每条数据分别与随机前缀结合形成新的RDD（笛卡尔积，相当于将其数据增到到原来的N倍，N即为随机前缀的总个数），然后将二者Join后去掉前缀。然后将不包含倾斜Key的剩余数据进行Join。最后将两次Join的结果集通过union合并，即可得到全部Join结果。

优势：相对于Map侧Join，更能适应大数据集的Join。如果资源充足，倾斜部分数据集与非倾斜部分数据集可并行进行，效率提升明显。且只针对倾斜部分的数据做数据扩展，增加的资源消耗有限。

劣势：如果倾斜Key非常多，则另一侧数据膨胀非常大，此方案不适用。而且此时对倾斜Key与非倾斜Key分开处理，需要扫描数据集两遍，增加了开销。

注意：具有倾斜Key的RDD数据集中，key的数量比较少

图片
4.6 JOIN操作中，两个数据集都比较大，有很多Key的数据分布不均匀

解决方案：随机前缀和扩容RDD进行join

适用场景：如果在进行join操作时，RDD中有大量的key导致数据倾斜，那么进行分拆key也没什么意义。

实现思路：将该RDD的每条数据都打上一个n以内的随机前缀。同时对另外一个正常的RDD进行扩容，将每条数据都扩容成n条数据，扩容出来的每条数据都依次打上一个0~n的前缀。最后将两个处理后的RDD进行join即可。和上一种方案是尽量只对少数倾斜key对应的数据进行特殊处理，由于处理过程需要扩容RDD，因此上一种方案扩容RDD后对内存的占用并不大；而这一种方案是针对有大量倾斜key的情况，没法将部分key拆分出来进行单独处理，因此只能对整个RDD进行数据扩容，对内存资源要求很高。

优点：对join类型的数据倾斜基本都可以处理，而且效果也相对比较显著，性能提升效果非常不错。

缺点：该方案更多的是缓解数据倾斜，而不是彻底避免数据倾斜。而且需要对整个RDD进行扩容，对内存资源要求很高。

实践经验：曾经开发一个数据需求的时候，发现一个join导致了数据倾斜。优化之前，作业的执行时间大约是60分钟左右；使用该方案优化之后，执行时间缩短到10分钟左右，性能提升了6倍。

注意：将倾斜Key添加1-N的随机前缀，并将被Join的数据集相应的扩大N倍（需要将1-N数字添加到每一条数据上作为前缀）

图片
4.7 数据集中少数几个key数据量很大，不重要，其他数据均匀

解决方案：过滤少数倾斜Key

适用场景：如果发现导致倾斜的key就少数几个，而且对计算本身的影响并不大的话，那么很适合使用这种方案。比如99%的key就对应10条数据，但是只有一个key对应了100万数据，从而导致了数据倾斜。

优点：实现简单，而且效果也很好，可以完全规避掉数据倾斜。

缺点：适用场景不多，大多数情况下，导致倾斜的key还是很多的，并不是只有少数几个。

实践经验：在项目中我们也采用过这种方案解决数据倾斜。有一次发现某一天Spark作业在运行的时候突然OOM了，追查之后发现，是Hive表中的某一个key在那天数据异常，导致数据量暴增。因此就采取每次执行前先进行采样，计算出样本中数据量最大的几个key之后，直接在程序中将那些key给过滤掉。

说下RDD的宽依赖和窄依赖

可灵活回答：

1）Spark的宽依赖和窄依赖，为什么要这么划分？

问过的一些公司：

字节x7，小米x5，阿里x4，快手x3，美团x2，妙盈科技，头条x2，网易云，蘑菇街，京东x3，海康，抖音，米哈游，顺丰x2，360，拼多多，腾讯x2，作业帮社招，猿辅导，ebay

RDD和它依赖的parent RDD(s)的关系有两种不同的类型，窄依赖（narrow dependency）和宽依赖（wide dependency）

1）窄依赖指的是每一个parent RDD的Partition最多被子RDD的一个Partition使用

图片

2）宽依赖指的是多个子RDD的Partition会依赖同一个parent RDD的Partition

图片
Flink

Flink的Exactly Once语义怎么保证

可灵活回答：

1）Flink怎么保证精准一次消费？

2）Flink如何实现Exactly Once？

3）Flink如何保证仅一次语义？

4）Flink的端到端Exactly Once？

问过的一些公司：（社招问的也多）

头条x3，一点咨询，字节，微众，陌陌，触宝，网易，贝壳

Flink跟其他的流计算引擎相比，最突出或者做的最好的就是状态的管理。什么是状态呢？比如我们在平时的开发中，需要对数据进行count，sum，max等操作，这些中间的结果(即是状态)是需要保存的，因为要不断的更新，这些值或者变量就可以理解为是一种状态，拿读取kafka为例，我们需要记录数据读取的位置(即是偏移量),并保存offest，这时offest也可以理解为是一种状态。

Flink是怎么保证容错恢复的时候保证数据没有丢失也没有数据的冗余呢？checkpoint是使Flink 能从故障恢复的一种内部机制。检查点是 Flink 应用状态的一个一致性副本，包括了输入的读取位点。在发生故障时，Flink 通过从检查点加载应用程序状态来恢复，并从恢复的读取位点继续处理，就好像什么事情都没发生一样。Flink的状态存储在Flink的内部，这样做的好处就是不再依赖外部系统，降低了对外部系统的依赖。在Flink的内部。通过自身的进程去访问状态变量。同时会定期的做checkpoint持久化。把checkpoint存储在一个分布式的持久化系统中。如果发生故障。就会从最近的一次checkpoint中将整个流的状态进行恢复。

下面通过Flink从Kafka中获取数据，来说下怎么管理offest实现exactly-once的。

Apache Flink中实现的Kafka消费者是一个有状态的算子（operator），它集成了Flink的检查点机制，它的状态是所有Kafka分区的读取偏移量。当一个检查点被触发时，每一个分区的偏移量都被存到了这个检查点中。Flink的检查点机制保证了所有operator task的存储状态都是一致的。这里的“一致的”是什么意思呢？意思是它们存储的状态都是基于相同的输入数据。当所有的operator task成功存储了它们的状态，一个检查点才算完成。因此，当从潜在的系统故障中恢复时，系统提供了excatly-once的状态更新语义。

下面我们将一步步地介绍Apache Flink中的 Kafka消费位点是如何做检查点的。在本文的例子中，数据被存在了Flink的JobMaster中。值得注意的是，在POC或生产用例下，这些数据最好是能存到一个外部文件系统（如HDFS或S3）中。

第一步：
如下所示，一个Kafka topic，有两个partition，每个partition都含有 “A”，“B”，“C”，”D”，“E”5条消息。我们将两个partition的偏移量（offset）都设置为0。

图片
第二步：
Kafka comsumer（消费者）开始从 partition 0 读取消息。消息“A”正在被处理，第一个 consumer 的 offset 变成了1。

图片
第三步：
消息“A”到达了Flink Map Task。两个 consumer都开始读取他们下一条消息（partition0读取“B”，partition1读取“A”）。各自将offset更新成2和1。同时，Flink的 JobMaster开始在source触发了一个检查点。

图片
第四步：
接下来，由于source触发了检查点，Kafka consumer创建了它们状态的第一个快照（”offset = 2, 1”），并将快照存到了Flink的 JobMaster 中。Source 在消息“B”和“A”从partition 0 和 1 发出后，发了一个 checkpoint barrier。Checkopint barrier 用于各个 operator task 之间对齐检查点，保证了整个检查点的一致性。消息“A”到达了 Flink Map Task，而上面的 consumer 继续读取下一条消息（消息“C”）。

图片
第五步：

Flink Map Task收齐了同一版本的全部 checkpoint barrier后，那么就会将它自己的状态也存储到JobMaster。同时，consumer会继续从Kafka读取消息。

图片
第六步：
Flink Map Task完成了它自己状态的快照流程后，会向Flink JobMaster汇报它已经完成了这个checkpoint。当所有的task都报告完成了它们的状态checkpoint后，JobMaster就会将这个checkpoint标记为成功。从此刻开始，这个 checkpoint就可以用于故障恢复了。值得一提的是，Flink并不依赖Kafka offset从系统故障中恢复。

图片
故障恢复
在发生故障时（比如，某个worker挂了），所有的operator task会被重启，而他们的状态会被重置到最近一次成功的checkpoint。Kafka source分别从offset 2和1重新开始读取消息（因为这是完成的checkpoint中存的offset）。当作业重启后，我们可以期待正常的系统操作，就好像之前没有发生故障一样。如下图所示：

图片
Flink的checkpoint是基于Chandy-Lamport算法的分布式一致性快照，如果想更加深入的了解Flink的checkpoint可以去了解一下这个算法。

数据仓库

数据仓库分层（层级划分），每层做什么

问过的一些公司：

字节，阿里x2，爱奇艺，百度x2，网易x3，美团x5，贝壳，keep，马蜂窝x2，转转，滴滴，小米，米哈游，有赞x2，猿辅导，58x2，作业帮社招，字节社招，腾讯社招x2，京东，触宝

CIF 层次架构（信息工厂）通过分层将不同的建模方案引入到不同的层次中，CIF 将数据仓库分为四层，如图所示：

图片
这里再给一张项目里面的数仓分层架构

图片
分层优点：复杂问题简单化、清晰数据结构(方便管理)、增加数据的复用性、隔离原始数据(解耦)

ODS（Operational Data Store）：

操作数据存储层，往往是业务数据库表格的一对一映射，将业务数据库中的表格在 ODS 重新建立，数据完全一致；

DWD（Data Warehouse Detail）：

数据明细层，在 DWD 进行数据的清洗、脱敏、统一化等操作，DWD 层的数据是干净并且具有良好一致性的数据；

DWS（Data Warehouse Service）：

服务数据层（公共汇总层），在DWS层进行轻度汇总，为DM层中的不同主题提供公用的汇总数据；

DM（Data Market）：

数据集市层，DM层针对不同的主题进行统计报表的生成。

其它类型

Scala实现wordcount

问过的一些公司：

网易云，字节x2，第四范式

先来个复杂版的

object WordCount {
def main(args: Array[String]): Unit = {
//定义一个List
val list = List(“java scala java”,“scala python scala”)
//处理原始数据,获取每个word
val words = list.flatMap(.split(" "))
println(words)//List(java, scala, java, scala, python, scala)
//改变格式，为元组（word，1）
val wordOne = words.map((,1))
println(wordOne)//List((java,1), (scala,1), (java,1), (scala,1), (python,1), (scala,1))
//根据（word，1）中的key值 word 进行分组
val wordG = wordOne.groupBy(.1)
println(wordG)//Map(scala -> List((scala,1), (scala,1), (scala,1)), java -> List((java,1), (java,1)), python -> List((python,1)))
//获取map中的value，对value中的tuple的.2(也就是1)进行统计（也就是叠加）
val wordCount = wordG.mapValues(.foldLeft(0)(+._2))
println(wordCount)//Map(scala -> 3, java -> 2, python -> 1)
}
}
一行代码版

import org.apache.spark.rdd.RDD
import org.apache.spark.{SparkConf, SparkContext}

object WorldCount {
def main(args: Array[String]): Unit = {
new SparkContext(new SparkConf().setAppName(“WC”).setMaster(“local”)).textFile(“./data/words”).flatMap(.split(" ")).map((,1)).reduceByKey(+).foreach(println)
}
}

Saprk Streaming和Flink的区别

可灵活回答：

1）Saprk和Flink的区别

2）Flink和Spark对于批处理的区别？

3）Spark Streaming相比Flink的优劣势

问过的一些公司：

字节x3，阿里x3，爱奇艺x2，嘉云，腾讯，快手，蘑菇街x2，360，中信信用卡，美团社招，贝壳，安恒信息，海康，招银网络，触宝，竞技世界，趋势科技，网易，美团

这个问题是一个非常宏观的问题，因为两个框架的不同点非常之多。但是在面试时有非常重要的一点一定要回答出来：Flink是标准的实时处理引擎，基于事件驱动。而Spark Streaming是微批（Micro-Batch）的模型。

下面我们就分几个方面介绍两个框架的主要区别：

1）从流处理的角度来讲，Spark基于微批量处理，把流数据看成是一个个小的批处理数据块分别处理，所以延迟性只能做到秒级。而Flink基于每个事件处理，每当有新的数据输入都会立刻处理，是真正的流式计算，支持毫秒级计算。由于相同的原因，Spark只支持基于时间的窗口操作（处理时间或者事件时间），而Flink支持的窗口操作则非常灵活，不仅支持时间窗口，还支持基于数据本身的窗口(另外还支持基于time、count、session，以及data-driven的窗口操作)，开发者可以自由定义想要的窗口操作。