连城：大数据场景下的“搔到痒处”和“戳到痛处”

非商业转载请注明做译者、出处，并保留本文的原始连接：http://www.ituring.com.cn/article/179495

连城，Databricks工程师，Apache Spark committer。《Erlang/OTP并发编程实战》与《Erlang并发编程（第一篇）》译者。目前从事Apache Spark中结构化数据分析组件Spark SQL的开发。

在作Spark以前，连城历来没有作过大数据分析方向的工做。为了理解函数式编程，他作了两年和Scheme相关的side project；为了学习分布式存储，他把1974年之后的分布式文献都过了一遍；为了参与Spark相关的项目，他在Coursera上自学了Scala。现在做为Spark committer的他，对大数据分析逐渐造成了本身的理解，他认为“对工具的选择，既能够解放咱们的思想，也能够禁锢咱们的思想”。而他本身曾经并不感冒的函数式编程，才是更加契合大数据场景的编程方式。

爱上函数式编程

“由于从小到大走的都是C/C++/Java这类命令式语言的路线，函数式语言对于当时的我来讲实在是很不合胃口。”

问：你是从何时开始编程的？

初一的时候由于我爸爸工做须要，家里买了台电脑，我就拿着电脑画画、玩扫雷。我爸大概是以为我扫雷太上瘾了，就不知从哪儿拣了一本少年儿童BASIC编程之类的书。如今惟一有印象的是那本书插图特别地粗糙，讲的基本概念也很是模糊。就i=i+1这么一个概念，花了我好几个礼拜才搞明白。由于那本书根本没有讲到赋值跟相等判断的区别，而BASIC里面赋值跟相等判断都是一个等号。无论怎么样，正是这本书让我知道了计算机编程这个事物的存在。

问：大学学的是什么？

大学学的计算机。这是从初中开始就打定了主意的。初二时班级重组，刚好发现坐我前面的男生下课时间在草稿纸上涂写BASIC程序，一问才知道他从小学就开始写程序，因而拜师学艺。后来成了莫逆之交。如今他也在湾区工做。那时候其实也写不出什么有技术含量的东西。可是无知无畏啊，以为写程序的时候有造物主的感受，因而就下定决心走这条路了。

问：为何对函数式编程和分布式系统感兴趣？

两者都是从工做须要出发，逐渐探索出来的兴趣。虽然从初中就开始写程序，可是其实在本科以前历来没有接受过正规的计算机教育。毕业的时候各类基础都通常，也没有肯定到底要作哪一个细分方向。本科毕业后第一份工做是在网易杭州研究院作即时通信，也就是老一辈网民熟悉的网易泡泡。当时我也不知道本身对什么感兴趣，因而采起了一个简单粗暴的策略：来者不拒，能干的我都干，再把不爱干的筛掉。

在网易泡泡，我前后作过新旧版本的Windows客户端、FreeBSD/Linux服务端以及旧版线上集群运维等等。后来这个项目中须要用到一些分布式存储的东西，我以为颇有意思。坦白说在此以前除了本科毕业的时候写毕设翻过一些文献材料，我尚未看过什么论文。因而我从Google Bigtable开始，顺着参考文献列表一路往下遍历，而后就一发不可收拾，包括后来去了百度也还在接着看。就这样看了两三年，大概1974年之后的分布式文献都过了一遍。

函数式编程其实也是在网易作即时通信的时候接触到的。即时通信有一个开放的协议叫XMPP，当时我想找一个开源的分布式XMPP服务器实现。找来找去，惟一一个比较靠谱的就是ejabberd。ejabberd是用Erlang写的，而Erlang是一个函数式特性很强的语言。可是当时并无啃下去，由于从小到大走的都是C/C++/Java这类命令式语言的路线，函数式语言对于当时的我来讲实在是很不合胃口。

后来到了百度，2009年我发现Facebook Chat的服务端就是一套定制版的ejabberd。大概也就是从那时候开始，Erlang开始进入互联网行业，我想Facebook的这一动做应该算是个标志。Erlang诞生于80年代，早就已经成熟应用在电信行业里，最擅长处理的就是高并发、高可靠、分布式的场景。而早年互联网行业内这样的场景还并不普遍，因而直到如今大众才开始关注Erlang。那时候我正好也还在研究分布式系统，而且须要一套可以快速完成原型验证的工具。用C/C++的话，光是底层网络通信等基础设施就已经够复杂了。因而我又把Erlang捡起来了。此后，从Erlang出发，业余又开始对函数式语言作了些研究。因此说，函数式编程和分布式的学习背景其实都是由于工做须要。

问：你是如何学习函数式编程的？

玩Erlang的时候，我开始对Erlang的不少特性感到好奇，包括匿名函数、GC、尾递归调用等等，这些特性在Python、Ruby等一些动态语言中也一样存在，可是我只知其然，而不知其因此然。我以为好奇的是，第1、函数式语言跟普通的命令式语言的本质相比有什么优点；第2、这些特性背后的运行时机制究竟是什么。那个时候我在百度已经开始作管理，基本脱离了一线开发，说实话少了挺多乐趣。我就决定用业余时间把函数式编程搞清楚。

我本身的习惯是每一年都会作一个side project，我以为要把函数式搞明白，最简单的办法就是本身作一个实验性的函数式语言实现，好比一个最简单的解释器什么的，也不求它可以多么高效、实用，只求把个中原理搞明白。既然是实验，目标语言固然越简单越好，因而选中了Scheme。Scheme的整个R5RS标准连目录带附录总共才50页，特别精简。

由于都是业余时间作，这个小项目断断续续地作了两年，期间用不一样方法重写了若干遍。项目整个作完了以后，确实把动态类型函数式语言最基本的东西，从运行时模型到理论上的一些概念和原理都弄明白了。实际上就跟我以前研究的分布式系统同样，也是把主要文献都粗略扫了一遍。

问：据说你在百度有一段时间在作管理工做，为何？

这个说来有趣，最先入行的时候，对管理有误解，原本是下定决心坚定不走管理路线的，由于当时以为作经理这个事情特别无趣。百度内部各个部门有各自的TC（技术委员会），由部门内高级工程师组成，负责本部门的技术方向把控、技术评审、职称评定等工做。我当时在客户端软件部，起初部门很小，高级工程师也很少。因为当时处在扩张期，招了不少新人，TC的工做重点之一即是培训和技术氛围建设。我当时对这些事情比较活跃一些，发现新的、好玩的东西我比较喜欢拿出来跟你们讲，由于我以为若是好东西光我本身会用是用不起来的，必须你们一块儿用，这个东西才能推得动。大概由于这个缘由，我入职不到一年的时候，TC主席破格把我调到TC。因为TC站在一个相对全局的视角，而且常常须要跟其余经理打交道，相对于其余工程师，我得以更早地接触到一些管理相关的工做，逐渐体会到了这些工做的重要性和难度。

后来，客户端软件部内部整合，须要创建一个后端团队统一负责各产品的后端服务。因为一时没有合适的经理人选，TC主席对我说：“要不你先把这个队伍建起来，过个半年咱们招到经理了就换你下来。”我心说，试试管理岗位也不错，就答应了。结果这一干就干了两年没换下来。这支队伍我从零建起来，到离职时已经有25人，而且保持了部门内最低的离职率。这两年里，我从个人团队和合做伙伴们那里学到了大量的非技术知识和技能，并彻底改变了我之前对管理的幼稚见解。但尽管如此，我我的仍然对管理工做提不起兴趣。所以直到离职为止，也一直没有正式转到管理线上去。

问：后来找工做好像有些趣事？

是的，2012年下半年从百度离职，打算出国。准备了半年后来去Google、Amazon和Facebook面试，没有成功，因此写了那篇《加州求职记》。那篇文章两三天被刷上万，大概是由于不多有人写面试失败的面经，因此你们以为特别亲切吧……由于面试过程不顺，刷题又很无聊，因而跟着Coursera上Martin Odersky开设的Functional Programming Principles in Scala课程学了Scala。巧的是，13年六月份意外得知Intel中国研究院在招会Scala的实习生作Spark。那时候Scala还在国内尚未多少动静，不要说会，据说过Scala的学生都很少。当时我对Spark还一无所知，简单看了一下，发现这个项目很好地结合了分布式系统和函数式语言这两个我最为感兴趣的技术方向。耐不住在家赋闲刷题的无聊，我最终以contractor身份加入了Intel，并和Intel中国研究院吴甘沙和杨栋带领的团队一块儿作了大半年Hadoop和Spark相关的研究。

在作Spark以前，我历来没有作过大数据分析相关的方向。之前研究分布式系统，主要集中在分布式存储方面，和大数据分析差异仍是蛮大的。在Intel期间，能在大数据分析方面快速入门，要特别感谢甘沙。他技术嗅觉极其敏锐，精力极其充沛，并且善于表达。在短期内就将这一领域的历史、现状、机遇高屋建瓴地描绘给了整个团队。更妙的是，咱们团队成员的能力很是互补，既有作操做系统的，又有作机器学习的，也有我这样工做多年有实际系统经验的。这半年多，算是我近几年学习速度最快，长进最大的一段时间。

问：你是如何加入Databricks的？

刚开始作Spark相关的工做时，Databricks尚未成立。当时一方面是对Spark感兴趣，一方面也是为14年初在湾区找工做再打些基础。（我在加入Intel之初就明确说过打算出国，也正所以一直是contractor。）

在Intel期间，我前后向Spark贡献了一些补丁，对总体系统比较熟悉以后，就挑了一件相对完整的工做。我基于两年多前Ankur Dave（后来GraphX的做者）的Arthur项目开发了用于分析和调试分布式Spark做业的Spark Replay Debugger（惋惜后来并无被合并到主线）。这个时候，Databricks成立的消息公布，对我产生了巨大的吸引力。正好公司创始人之一辛湜博士回国参加China Hadoop Summit。以Spark Replay Debugger为契机，在甘沙的引荐下，辛湜为我安排了面试。面试过程种种略去不表，最终总算幸运经过。

问：如今你在Databricks工做，可是尚未去美国那边，你如今是怎么和团队合做的？

由于Apache Spark自己是个开源项目，你们直接经过GitHub和邮件列表就能够比较好地交互。同时咱们每周有一到两次远程会议。还好时差不算太严重，北京早上8点的时候是加州那边下午4点。通常事务主要经过邮件，急事则经过Google Hangout或Skype联系。因为开源项目的公开透明性质，沟通问题并不太严重。

大数据处理的因此然

“JVM的设计使得在JVM之上实现函数式变成一种戴着枷锁跳舞的艺术，Clojure、Scala都由于JVM的限制而不得不在语言层面做出了一些丑陋的妥协。”

问：Databricks上面有一个对Spark的介绍，其中提到大数据时代的计算平台必需要开源，你能稍微解释一下吗？

我本身的理解是这样的，大数据分析复杂性相对来讲是很高的，从用户的角度来看，复杂性突出体如今两个方面：

第1、不少状况下，采用大数据系统的组织内部本来就存在一些重要的遗留系统，不免面临对内外系统进行扩展和/或改造，这时也会产生不少复杂的技术性和非技术性问题。采用开源系统时，咱们能够有效地对系统进行定制。

第2、大数据系统通常来讲代码量比较大，动辄十数万、数十万行代码，不免会存在各式各样的缺陷；分析、调试、修复这些系统中的缺陷一样是一个复杂的工做。大数据场景下，不少问题必须在足够的体量下才可以重现，难以构造最小的问题重现场景，这使得现场调试定位显得尤其重要。而开源软件大大下降了现场调试定位的难度。

问：有人说MapReduce是一个巨大的倒退，说它倒退回了现代数据管理系统发明之前的时代，你怎么看？

这个说法是数据库大师David DeWitt和Michael Stonebraker在2008年在发表的MapReduce: A major step backwards一文中提出的。这里的“现代数据管理系统”指的主要是关系数据库。文章将MapReduce与关系数据库作了一个详细的比较，得出了MapReduce在功能、性能、易用性等方面相对于关系数据库都是巨大倒退的结论，而且抨击MapReduce背后的想法“毫无创新可言”，甚至还质疑了MapReduce的可伸缩性（scalability）。这篇文章自己发表以后饱受争议。评论中有大量针锋相对的辩论。我最为赞同的两点相反意见包括：

1. MapReduce和数据库面临的场景是很不同的。传统数据库处理的是规整的结构化数据集，全部数据都符合预先设定的规则（schema）；而Google最初MapReduce处理的是不规则的半结构化数据——整个互联网。
2. MapReduce的可伸缩性是铁板钉钉的不争事实。MapReduce论文中提到，Google利用MapReduce天天处理20PB的数据，在当时这是任何传统关系型数据库也作不到的记录。

MapReduce提供的抽象当然十分简单，缺乏高层抽象和更加易用的接口，但在当时它确实有效地解决了最迫切的问题——可伸缩性。这就比如乘坐火车、汽车、轮船时咱们能够用手机，但坐飞机的时候就不行，咱们能说飞机相对于火车等传统交通工具是倒退吗？当技术发展还不足够成熟时，为了达到某一重要目标，每每不得不舍弃另一些东西。

但从如今来看，MapReduce确实已经落伍了。DeWitt和Stonebraker提出的MapReduce的诸多缺点也逐渐被后来人所弥补。自Hadoop提供了开源的MapReduce以后，整个大数据产业蓬勃发展。缺乏schema、逻辑层和执行层耦合紧密的问题，已经由各类SQL on Hadoop系统解决；作复杂计算时MapReduce涉及的shuffle过多，磁盘IO密集的问题由Tez等DAG计算引擎缓解；MapReduce所不擅长的流式数据处理，也由MillWheel、Storm等系统挑起了大梁。而Spark做为MapReduce的超集，更是能够在单一软件栈上搭建一体化的大数据流水线，同时完成批处理、流处理、关系查询、迭代计算、图计算等多种计算范式而无须维护多套系统。

因此我认为，说MapReduce相对于现代数据管理系统是历史倒退是不公平的，由于它在当时提供了关系数据库没法提供的价值——足以处理整个互联网的超高可伸缩性。但在MapReduce论文发表十多年后的今天，它也确实该退休了。

问：JVM能在大数据领域里面流行，其背后的缘由是什么？

JVM在大数据领域的流行，与Hadoop脱不开干系。Hadoop自己的成功，与Java的低入门门槛、高开发效率（相对于C++而已）应该有至关大的关系。在HDFS、Hadoop MapReduce流行以后，为了能与Hadoop无缝互操做，后续的一些大数据系统天然而然地也选择了Java。近年来，虽然Java在语言层面发展缓慢，愈来愈被诟病，但Clojure、Scala等JVM上的新语言却层出不穷，这又进一步激发了人们继续以JVM为平台搭建新兴大数据系统的热情。Hadoop生态圈越作越大，而试图加入这个生态圈的新系统若想无缝利用现有的遗产，就只能选择JVM。因而雪球越滚越大，进而令JVM几乎垄断了整个大数据行业。

然而我想说的是，除了Hadoop的缘由以外，还有更多人的因素掺合在内。JVM之因此可以流行，另外一个缘由是JVM之上最初的语言Java，对于几十年来被命令式语言和OOP所统治的工业界来讲很是直观和简单。这种直观和简单最直接的体现就是初学者的心智负担很低，让人以为“理所固然”，这使得人们天然而然地更倾向于使用这些这类语言，促使其流行。然而，直观的事物却未必是正确，反之正确的事物也未必就直观——现实世界中客观存在的波粒二象性、量子纠缠、黑洞等事物都是典型的反直觉的存在。

在这个问题上，我禁不住想多说两句题外话。愈来愈多的实践代表，函数式编程更加契合大数据场景。对不变性的强调使得分布式一致性、容错、并行/并发都变得更为简单和高效。函数式语言的各类基本算子天生适合数据并行处理。GFS/HDFS对数据不变性的强调以及MapReduce的成功，自己就是函数式编程范式适合大数据处理的绝佳证据。实际上不只仅是大数据领域，在不少方面函数式语言都有着优异的表现。虽然JVM上Clojure和Scala逐渐壮大，渣打银行也打出了Haskell程序员的招聘帖，但为何函数式语言却仍然如此小众呢？更进一步，我发现历史上以及当前不少流行的工具，其实未必是该领域内最优的选项。这是为何呢？

这两年时不时会思考这个问题，得出了一些结论：

1. 对于大部分人来讲，甚至包括不少很是聪明的人，他们并不乐于去改变本身的思惟方式——对本身的大脑从新“编程”实在太难了。
2. 流行的工具大体能够分为两类。第一类能够帮助人们以熟悉、直观、符合大众思惟的方式便捷地解决眼前的问题，搔到痒处。第二类要么可以将不可能变为可能，要么在应用效果上远远超越同类竞争者，戳到痛处。

然而长远来看，第一类解决方案却未必正确，甚至每每牺牲了其余更为重要的系统属性——例如一些动态语言中的monkey patching，看似方便，却打破了对象运行时布局不变的假设，结果既牺牲了运行时性能，又破坏了系统的静态分析潜力，使得大型项目重构困难重重。第二类技术和工具，因为效果绝佳、暂时无可替代，即使会带来必定的心智负担，要求大众转变思惟方式，你们也心甘情愿。例如当年横空出世时的MapReduce，以及如今的Spark。这类技术和工具，更有益于健康的思惟方式和方法论的推广。正如Dijkstra在1975年时所说：

The tools we use have a profound (and devious!) influence on our
thinking habits, and, therefore, on our thinking abilities.

对工具的选择，既能够解放咱们的思想，也能够禁锢咱们的思想。

从这个意义上将，做为一个为命令式OOP语言设计的JVM，在大数据领域已经开始显得格格不入了。JVM的设计使得在JVM之上实现函数式变成一种戴着枷锁跳舞的艺术，Clojure、Scala都由于JVM的限制而不得不在语言层面做出了一些丑陋的妥协。Erlang、Haskell等强调不变性的单次赋值语言所特有的高效GC和并行优点在JVM上也不可能实现。Full GC带来的停顿恐怕是每一个与JVM打交道的工程师都饱尝过的噩梦。

也正是由于这些限制，JVM上目前尚未一个特别令我满意的语言实现，Scala算是JVM上最为接近的一个。脱离JVM，Rust也是我特别感兴趣的一门语言。我的特别期待能出现一门既带有静态强类型纯函数式语言特质，又带有与Erlang相似的运行时级别的软实时、高并发支持，同时还能尽可能接近native执行性能的语言。

问：若是你的想法这么具体的话，是否是能够本身去写了？

确实时不时会有这种想法。可是实际上去作一个语言的话，要作的并不只仅是一个编译器，还有不少和整个生态发展相关的因素须要考虑，其工做量是巨大的，而且我自认如今也远没有相应的能力，耽于空想罢了。固然，我很是指望从此有精力的时候，可以去作这样的研究。哪怕不是作一个实用的语言，仅仅试作一个原型，去作一些探索。

进击的Spark

“他们试用过Spark SQL以后广泛反馈：‘不再想回到Shark了。’”

问：Spark及其相似产品取代MapReduce是否是一个必然？

我以为如今已经有比较明显的趋势了。固然，Spark跟Hadoop生态之间仍是一个补充关系，可是Spark做为一个计算引擎，确实已是在革MapReduce的命了，实际上它也在革不少基于MapReduce搭建的其余计算引擎的命。这也是为何如今Mahout、Hive、Pig等一些原先基于Hadoop MapReduce的系统都正在逐渐迁移到Spark上来。

问：和Spark相似的好像还有一些模型，好比你刚才提到的Tez，还有一个就是在2014 Daytona GraySort大赛中和Spark并列第一的Themis，能不能比较一下？

Themis系统其实是一个特化系统，而不是一个通用的计算引擎。这也是Spark在排序比赛当中获奖特别使人振奋的一点，由于Spark并无专门为这样的一个排序竞赛去作特殊的优化。Spark作的全部的优化实际上都是对总体执行效率以及稳定性的提高，搭建在Spark core之上的Spark Streaming、Spark SQL、MLlib、GraphX等全部组件均可以直接获益。Tez虽然也是DAG计算引擎，从目前来看总体的执行效率还在Spark之下。Hive 0.14集成Tez引擎后，相对于Spark SQL，单从执行效率上讲并未看到明显优点。

问：Databricks提供技术支持的服务吗？

虽然去年公司人数翻了一倍多，但Databricks目前总共也只有不到50人。直接面向终端用户提供Spark技术支持很是消耗人力，这对于Databricks目前的规模来讲是不现实的，咱们目前更但愿将人力投入到研发和Spark的推广上。目前Databricks和包括Coursera、Hortonworks、Pivotal、MapR在内的全部Hadoop发行商都创建和合做关系，终端用户能够从这些厂商处得到专业的技术支持服务。

问：Spark如今在国内和国外的应用状况如何？国内如今有腾讯、百度这样的企业用起来了，TDW应该算是国内Spark比较典型的成功案例，会不会影响大环境？

确定会带来积极的影响。大公司的规模效应能够起到一个定心丸的做用，增强了不少观望中的中小公司的信心。据我所知，国内的不少小公司尤为不少创业公司也都在用Spark。实际上，相对于大公司来说，Spark对于这些创业公司来讲更加有吸引力。缘由很简单，对于大公司来说，它们在引入Spark以前就已经有了本身的专有系统或者其余开源系统。引入Spark以后，还有对接、替换、改造、扩展的成本。

此外，Spark相对于其余大数据系统的一个巨大优点在于可让开发者在一个系统内实现多种计算范式，从而无缝地在一套系统上搭建一个完整的一体化流水线。对于创业公司来讲，无需部署多套系统，只须要一个stack，就能够完成各类类型的大数据分析需求，这样就节省了大量的学习成本、开发成本、部署成本和运维成本。对于大公司来说，因为现有遗留系统的存在，Spark一体化流水线的优点反而不太容易发挥出来，他们只会用Spark来作现有系统作不到或作很差的事情。好比腾讯和阿里更多地是用Spark去作机器学习，而不太可能将从数据清洗开始的一整条数据流水线都迁移到Spark上来。百度之因此前两年在Spark社区里声音很少，也是由于他们在作内部系统的整合和消化。如今百度本身的BMR服务已经出来了，说明内部的整合和消化已经基本完毕了。

问：你如今的工做重点仍是在Spark SQL上？你说过但愿外部数据源API设计能有更多进展，如今怎么样了？

个人工做重点目前的确还在Spark SQL上。在Spark1.2中，外部数据源API最重要的一部分已经发布出来了。目前开发者已经能够基于这个API去开发各类各样的connector，而后把外部的数据源对接到Spark上。可是当前的API中咱们只提供了查询入口，尚未办法把咱们处理完毕的数据写回到外部系统当中去。在1.3和1.4中会提供相应的支持。

另外在外部数据源的集成上，咱们目前的重点主要集中在高度可扩展的API上，同时也会实现一些最为经常使用的数据源，例如JSON、Parquet、JDBC。此外社区中也已经出现了一些第三方数据源的实现。

问：Shark如今已经没有在开发了，把Shark用户迁移到Spark SQL上，这个过程有没有困难？

我曾和国内的一些用户聊过这个问题，包括一些曾经在Shark上用了蛮久的用户。他们试用过Spark SQL以后广泛反馈：“不再想回到Shark了。”

这里边有好几个缘由。

第1、Shark是直接从Hive改造过来的，因此很大程度上受到了Hive的钳制。Shark中从查询语句解析成抽象语法树，到抽象语法树翻译成逻辑执行计划，再到逻辑执行计划优化，都是利用Hive完成的，而Hive的查询优化器是针对MapReduce设计的，这使咱们受到很大的限制。而在Spark SQL中，咱们拿到抽象语法树以后，除了经过Hive的Metastore获取表的元信息之外，后续的执行路径跟Hive就没有什么关系了，查询计划的生成和优化所有都由咱们本身接管，这样就能够更加充分地发挥Spark的优点，进一步提高执行效率。

第2、Spark SQL不只仅提供了关系查询，并且还能够借助SchemaRDD（1.3之后升级为DataFrame）这一统一抽象实现与其余Spark组件的无缝集成，并能够融合多种数据源完成更为丰富的计算。

第3、抛开上述的各类相对于Shark的优点，Spark SQL自己就是一个十分使人兴奋的项目。Spark SQL的核心，其实是一个用一种函数式语言（Scala）实现的另外一种函数式语言（SQL）的编译器。Spark SQL中原创的Catalyst框架大量应用了Scala的函数式特性，令开发者得以以极为简洁明了的声明式代码实现各类查询优化策略，从而大大下降了查询优化器这一数据库中的硬骨头的开发难度和维护成本。

全部这些因素加在一块儿，使得Spark SQL成为一个显著优于Shark的方案，所以你们仍是相对愉快地和Shark告别了。

如今整个Spark SQL社区里面有很是多中国的用户，也有很是多中国开发者。我曾经作过一个统计，发现Spark SQL的贡献者中有一半左右是华人。

问：你以为有这么多中国开发者的缘由是什么？

据我了解到的状况，国内的不少企业，尤为是电信行业的企业，过往大量依赖Oracle和DB2，业务紧密依赖SQL。而在近几年的去IOE潮流中，又恰恰缺少高效的可以处理大数据的SQL执行引擎。这个时候，Shark和Spark SQL的出现给你们带来了较好的选择。以此为契机，大量的开发者被吸引到了Spark SQL社区。此外，Shark的做者辛湜博士本人就是中国人，这点不知道是否是也有关系 :-)

---

更多精彩，加入图灵访谈微信！