定制开发小程序最近碰到一个很有意思的问题，Flink定制开发小程序到底用什么语言开发？还是Java？定制开发小程序国内部分程序员对scala开发flink定制开发小程序好像存在着偏见或者是迷茫，定制开发小程序一般是因为你能找到的flink定制开发小程序项目大多是java写的。
定制开发小程序想要弄明白这个问题，定制开发小程序首先要知道这个问题为定制开发小程序什么会发生，定制开发小程序作者在网上查看了相关的词条，定制开发小程序并且根据开发经验，定制开发小程序大致总结了一下对这个定制开发小程序事情的个人看法。
定制开发小程序首先这个问题牵扯了一部分，2009年的时候spark定制开发小程序作为第一个弥补MR无法基于内存计算缺陷的第二代大数据计算框架，诞生于伯克利大学，从诞生之初开始spark的内核开发语言以及使用者的开发手段就全是scala。而第二年开始，也是2010年到2014年，在这四年中欧洲的一些大学联合起来，开发出了flink。
flink它的内核用的是JAVA语言编写，而且一个更要命的事情是flink于2014年四月份才捐献给了基金会，并且由原先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-JDK依托于Java-JDK，因此天生就能调用JAVA实现混编，而且当时Spark能力本身就比flink要丰富的太多太多，所以当时的flink官方就想了一个妙招，对外宣称并坚持至今，希望更多的开发者在不舍弃自己熟练的开发语言情况下，依然可以使用flink，而且还为此付出了实践，在原先的JAVA底层代码上封装了一层scala，且随着发展现在不止可以用scala，还可以用python开发。你可以理解为原先的flink代码作为底层在外面包了一层scala-service的服务，就好像现在国内的安卓系统手机厂商一样。
事情的大致情况就是这样子，但据这样来看，两边的开发其实都是互不影响的，而且更利于flink的推广，但为什么事态变成了现如今的国内市场上很多Flink的项目都是用JAVA开发，并且对scala开发的推广如此之难，是因为flink的官方，给它的使用者出了一个难题。
这个难题就是flink在使用上，出现了Java和scala的混乱，如果你用scala开发你常常就会发现调用一个类，会有存在两个同名类被加载到，一个是包名有明确的scala的资源，另外一个无法明确的分清是哪的资源，而如果你用JAVA开发会发现Flink的包已经是用JAVA开发了，但莫名其妙还需要考虑scala的版本。
这就导致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本身了。