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

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

首先这个问题牵扯了一部分spark，2009年的时候spark作为第一个弥补MR无法基于内存计算缺陷的第二代大数据计算框架诞生于伯克利大学。这里的第一个是值基础架构相对完善，没有很严重的缺陷，单纯的谈论有无来说它前面还有个storm。但是storm它的基础架构存在着让市场没有办法忽视的缺陷，既然说到了storm的缺陷，就在这里提一嘴让大家知道为什么市场上很少有人用它。首先storm处理数据的粒度过小，如果有了解过这个框架的人，就会知道storm处理数据最小的颗粒度是tuple，一个tuple里面只有一条信息，数据不多还可以，但是随着我们需要处理数据的种类越来越繁杂，数据量越来越大，它就导致了过多的网络通信和序列化开销，严重影响了性能。第二storm没有内置的容错机制，需要用户自己实现，增加了开发和维护的难度。第三缺乏批处理的支持，无法满足市场的需求。第四缺乏对数据存储和管理的支持，需要用户自己实现。

言归正传，从诞生之初开始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它主要是一个专注于流计算的计算引擎，当然其本身并没有犯storm的错误，也提供批处理，只不过卖点不是批处理而已，但是国内为什么使用它的相当少呢？就算有流处理，一般也是用spark的批流一体化，这个原因大家搭建一遍flink跑一个测试的word count任务就明白了，在我主页大数据原生测试集群搭建文档五中有搭建方法，你搭建完之后，就会发现其他的计算框架跑任务的资源把控讲究的是任务队列提供虚拟内存能力，把任务运行在逻辑单元容器上，并且一个节点上根据不同资源分配方式可以有多个容器，如果没有现成的资源任务可以在队列里等待，总的来说卖点就是灵活多变，服务器下线低，开发成本低廉。但是flink不一样，它将集群中的每一个跑任务的节点注册为任务节点，每个节点在配置文件里就写好了有几个并行度，在flink里叫task，我之前经历的项目上习惯叫任务槽，有一个taskmanager组件管理并把控这些task资源，任务提交的时候由另一个组件jobmanager去和taskmanager联动使用这些资源，而每个并行度占这台节点多少资源同样明文写在了配置文件里，从物理上直接限制死了资源的多少，提交任务不再是存任务队列中等待，也不再灵活多变，而是有现成资源就用，没有现成的就报错，是真正的用钱用服务器去砸，总之在使用上就会感觉到平常你使用yarn或者spark拥有的那些提交任务时的便利，在flink里基本不要想了，所以很少有资本家用的起。不过也有经济的用法，就是跑在yarn上，但是这样的话除了特别需要flink的非窗口计算能力，就和spark没差别了，虽然不可否认，在实时计算上，flink要甩了spark几条街，不过用flink开发，要注意很多的问题，比如任务是否反压？checkpoint是否失败？任务是否重试？数据倾斜情况是否有分险？一天内JM FullGC次数是否在50以上？一天内最大CheckPoint大小是否突破20G？诸如此类，很多很多要注意的问题，而反之用spark这些问题的就不是那么明显了，因为虽然在实时能力上不如flink，但是它使用的资源可以动态扩列，对于资本家来言，既然没太大差别，同样是忽悠客户就能拿钱，那为什么要用flink，而不是给自己买台车买套房？这就把问题又上升了一个台阶，从推广scala开发flink变成了推广flink本身了。不过随着flink的发展，在未来一定会占有一定的市场份额的时间问题罢了。