Young
12/10/2025, 11:53 AM오찬해
12/11/2025, 11:49 AMAnatoliy Samsonov
12/11/2025, 12:43 PMAlexey
12/15/2025, 9:07 AMGeorge Leonard
12/15/2025, 1:10 PMYoung
12/15/2025, 2:58 PMGeorge Leonard
12/17/2025, 4:49 AMGeorge Leonard
12/17/2025, 12:02 PMGeorge Leonard
12/17/2025, 1:47 PMGeorge Leonard
12/18/2025, 4:05 PMGeorge Leonard
12/20/2025, 2:27 PM徐科
12/29/2025, 11:19 AMGeorge Leonard
12/31/2025, 6:10 PMChiara
01/02/2026, 7:40 PMJan Siekierski
02/15/2026, 10:14 AMSlackbot
02/25/2026, 5:56 PMSlackbot
02/27/2026, 7:51 PMSlackbot
03/03/2026, 2:18 PMSlackbot
03/07/2026, 1:58 AMMichael Goodnow
03/17/2026, 1:42 PMShaun Wanford
03/19/2026, 10:24 PMSlackbot
03/21/2026, 12:50 AMSlackbot
03/24/2026, 6:34 PMAle
03/24/2026, 8:11 PMSlackbot
03/25/2026, 6:20 AMSlackbot
03/25/2026, 9:10 AMSlackbot
03/27/2026, 1:15 PMAdam Bell
05/29/2026, 11:55 AMSpark can now process events in milliseconds; up to 92% faster than Flink . Very wishful thinking I think and I'm guessing there is a hint of bias given that the article was written by Databricks.
I've been reading up on their process for comparing the two (I've never used Spark so I don't understand aspects of the code), but on the face of it, it looks like:
• Flink Job (parallelism = 1) | Spark Job (parallelism = 40 - i think this is what spark.sql.shuffle.partitions does)
• Flink Job (runs on AWS Managed Apache Flink 1.18 - limits optimisation) | Spark Job (runs on Databricks cluster - could be optimised)
Doesn't seem like a fair fight to me (although I'm happy to be told otherwise if it is).
Here is the article and Github repo for reference if anyone wants to have a look and share their thoughts. I'd love to hear them
Article: https://www.databricks.com/blog/real-time-mode-ultra-low-latency-streaming-spark-apis-without-second-engine
Github Repo: https://github.com/databricks-solutions/latency-benchmarks/tree/mainKenny Duran
08/20/2026, 7:04 PMKenny Duran
08/25/2026, 5:33 PM