当前位置: 首页 > 工具软件 > Scala > 使用案例 >

Flink开发语言使用Java还是scala合适?

萧德庸
2023-12-01

最近碰到一个很有意思的问题,Flink到底用什么语言开发?Scala还是Java?国内部分程序员对scala开发flink好像存在着偏见或者是迷茫,一般是因为你能找到的flink项目大多是java写的。

想要弄明白这个问题,首先要知道这个问题为什么会发生,作者在网上查看了相关的词条,并且根据开发经验,大致总结了一下对这个事情的个人看法。

首先这个问题牵扯了一部分spark,2009年的时候spark作为第一个弥补MR无法基于内存计算缺陷的第二代大数据计算框架,诞生于伯克利大学,从诞生之初开始spark的内核开发语言以及使用者的开发手段就全是scala。而第二年开始,也是2010年到2014年,在这四年中欧洲的一些大学联合起来,开发出了flink。

flink它的内核用的是JAVA语言编写,而且一个更要命的事情是flink于2014年四月份才捐献给了Apache基金会,并且由原先flink的部分开发者离开大学并寻找着它的商业化道路。说白了,就是在2014年的时候才开始走商业化,开始像成熟的商业模式摸索。

可问题就是先它一步的spark,已经早在2010年对外开源发布得到了很多的代码贡献,更是在2012年的时候就发布了0.6的第一个正式版,我们都知道一个道理,一步快步步快,所以spark在第一个正式版本发出以后,进入了更快的发展,2013年的时候成为了Apache基金会下的项目,并在同年研发出了机器学习、流处理,以及spark sql的前身shark,再到2014年的时候,正式发布了1.0版本,不只有了图计算,而且还开发出了spark sql,更是成为了Apache顶级项目。

与之相比,当时的flink就显得太弱小了,所以大数据计算市场,就分成了两股,一股是主流的scala开发spark,另外一股市场占比较小的Java开发flink,两边的开发人员都不愿意丰富自己的开发语言。但是慢慢的flink劣势就出来了,首先是对于scala的开发者,其开发的程序运行本身就使用了Java的运行库,而且Scala的环境不可或缺的就是Java虚拟机,对于开发者来说Scala的开发需要依托于Java-JDK,可以说scala的开发者在技术储备上对Java就不陌生,再加上scala天生就能调用JAVA实现混编,再一个当时Spark能力本身就比flink要丰富的太多太多。所以当时的flink官方为了推广自己就想了一个妙招,对外宣称并坚持至今,希望更多的开发者在不舍弃自己熟练的开发语言情况下,依然可以使用flink,而且还为此付出了实践,在原先的JAVA底层代码上封装了一层scala,且随着发展现在不止可以用scala,还可以用python开发。你可以理解为原先的flink代码作为底层在外面包了一层scala-service的服务,就好像现在国内的安卓系统手机厂商一样。

事情的大致情况就是这样子,但据这样来看,两边的开发其实都是互不影响的,而且更利于flink的推广,但为什么事态变成了现如今的国内市场上很多Flink的项目都是用JAVA开发,并且对scala开发的推广如此之难,是因为flink再提供了scala的API后,Java和scala之间发生了混乱。

如果你用scala开发你常常就会发现调用一个类,会有存在两个同名类被加载到,一个是包名有明确的scala的资源,另外一个无法明确的分清是哪的资源。而如果你用JAVA开发会发现Flink的包已经是用JAVA开发了,但莫名其妙还需要考虑scala的版本。最后就是前面说的scala的开发者熟悉Java,但是Java开发者一般不去接触scala,并且java自己来说无法和scala混编,即使可以调用scala的代码,不过存在着会将scala类识别成java类的问题,很容易混淆。

这就导致JAVA和scala两面都不讨好,两面都认为是对方的问题,Scala的开发者由于语言本身的优势,所以开发起来还不算太困难,但java开发者就很难受了,简直就是属于用自身的短处碰到了别人的长处,比如可以看下面这个论坛里面说的问题

https://lists.apache.org/thread.html/rd7bf0dabe2d75adb9f97a1879638711d04cfce0774d31b033acae0b8%40%3Cdev.flink.apache.org%3E

这个论坛里大致说的问题就是某个flink的java使用者,他所开发的项目里,因为flink-streaming-java依赖了flink-runtime_2.11,发现是个有scala版本后缀的包,一样的困惑,为啥纯java写的flink runtime要携带scala的版本号,并且产生了混淆,接着排查问题的时候,发现flink-runtime依赖了akka-actor/stream/protobuf_2.11,这是flink依赖的三方库,虽然是纯java的,但是同样携带了scala版本。最后发现akka-stream这个第三方库 50+的代码都是用scala写的,而且还是2.11版本就没有更新,导致他的项目也没有办法更新,但好在目前没有对项目产生不好的因素,且还因为有scala依赖而存在一些优势,然后以此为核心引发的一系列由于JAVA开发需要考虑scala依赖的问题,总体上表达了希望该JAVA开发人员剔除scala的相关依赖。

所以我们回到最开始的问题,首先是flink-Java开发上的混淆,后是java是flink的主人翁,导致养成了一种市场习惯,再加上Spark本身满足了绝大多数市场的需求,最致命的还是程序员没有太多个人时间去充实自己,想扩展scala方式开发的程序员很少有时间去学习,导致flink的scala推广很难。

再来总结一下flink到底用什么语言开发,首先你要知道,在国内市场上使用flink的场景本身就很少,少到你基本不会用到,一个spark就够了,如果你的时间很充裕,那你就两种开发方式均掌握,毕竟如果真的遇到了,那一个项目的开发手段也不是由你自己可以决定的,说的玄一点,就是看命,如果你在找工作期间遇到了这个问题,那么你完全可以结合自身考虑这份工作你是否要去胜任?而当然无论什么时候,如果遇到了在使用哪种语言编写上存在严重偏见的人,你完全可以不理他,因为技术是无罪的,有问题的只是人心而已。

最后跟大家说一点最实际的,flink它主要是一个专注于流计算的计算引擎,但是国内为什么使用它的相当少呢?就算有流处理,一般也是用spark的,这个原因大家搭建一遍flink跑一个测试的word count任务就明白了,在我主页大数据原生测试集群搭建文档五中有搭建方法,你搭建完之后,你就会发现其他的计算框架跑任务的资源把控讲究的是逻辑单元container容器,一个节点上根据不同资源分配方式可以有多个容器,但是flink不一样,它将集群中的每一个跑任务的节点注册为task节点,每个test节点在配置文件里就写好了有几个并行度,每个并行度占这台节点的多少资源,从物理上直接限制死了资源,而且如果你不开启窗口的话,是真正的用钱用服务器去砸效率,所以很少有资本家用的起,不过也有经济的用法,就是跑在yarn上,但是这样的话除了特别需要flink的非窗口计算模式,就和spark没差别了,对于资本家来言,既然没差别那我为什么非要用flink?这就把问题又上升了一个台阶,从推广scala开发flink变成了推广flink本身了。不过随着flink的发展,在未来一定会占有一定的市场份额的,时间问题罢了。

 类似资料: