大数据那些事:从Spark到Spark

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
简介:

Spark,当前大数据领域最活跃的开源项目。好几个人想让我写写Spark了,说实话我觉得对Spark来说有点难写。Spark的论文我倒多半读过,但是Spark的系统就没怎么用过了。所以以一个没有实际使用经验的人去写这样一个当红的系统, 我也不知道楼会歪到哪里去。

大家可能觉得这个标题很奇怪,确实,当我们开始谈论Spark的时候,我们需要区分一下最初Matei Zaharia论文里写的Spark,还是今天开源社区广泛使用的Spark。Spark和其他的开源项目有一个最大的不同,一开始是作为研究项目从学校里面出来的,现在则更多的是一个工业界使用的项目。研究和工业界的产品之间的差距,对于我这种读过PhD做过那样的系统和今天在写商用系统的人来说,之间的区别还是大概可以说的。

举个例子来说,关系数据库里面最成功的研究系统,同样是伯克利出品的Ingres显然少不了。Ingres后来也商用了,被Oracle打败了。现在最成功的商用系统则应该是Oracle。所以此Spark非彼Spark。

2016年在印度开VLDB,晚上吃饭的时候旁边坐着的是从OS领域来客串DB会议的一个知名教授。喝了酒之后是相当的出言不逊。大致的意思说,database这几年是越混越不行了,你看所谓的BigData主要都是我们OS的人在做,从早年的MapReduce,BigTable,到现在当红的Spark,哪个不是我们OS的人做出来的。这些人把论文投到了DB的会议,一个一个被拒了。周围一群正统做DB的人都不知道怎么接这个话。

当时就让我想起了可能是2011年的事情了,时间不太记得。但是我一个开始做DB转做OS的PhD朋友,后来成了著名教授,给我转了Spark的论文,问我有什么感受。我算得上初生牛犊吧,和对方的回复很简单啊,这篇论文投到database的会议来,肯定被拒啊。这是大名鼎鼎的Spark,如今业界无数公司在用的Spark。那么现在是2017年了,我回头问我自己,倘若那篇文章今天投稿到一个DB的会议,有假设才刚做出来,没多大名气,而我是审稿人之一,结果会是什么样。这个问题我问自己好几回,最后的答案是,倘若投了industry track,多半是发了,要是投到research track,基本上还是据。

各位看官看不明白了。数据库领域的会议,对于创新性的要求很高,对系统的可用性要求没那么高。说白了如果说思想是先进的,那么这个系统只是能跑几个查询,也就发了,至于有多少个bug,是不是能在实际中很好的用,就不好说了。而Spark如果作为一个研究项目,从创新性的角度去看,至少最初的那个版本,不管是RDD也好,还是作为一个通用的DAG execution engine也好,不是新鲜东西。举几个例子,Dryad, DryadLinq,FlumeJava这些发表更早或者同期的论文里面,都有着相似的思想,而我每次听Spark早年的体系架构讲座,感觉就是我在微软开组会看内部文档经常看到的东西。只是在那个时候open-source圈子里并无这样的东西存在。

有个大八卦是我有次和UT Austin一教授聊天的时候听说的,Spark的作者Matei当年毕业去面试UT Austin,作为有图灵奖的计算机系,Austin的老教授们听完他做的这个东西,颇不以为然,觉得这东西没啥新意,然后就把大神给据了。我讲这个八卦绝非鄙视大神,一个能进MIT去stanford的人,能把Spark从无到有带那么大的人,毫无疑问是大神。但是数据库这个圈子里的人非常的强调创新性,而并不是那样的强调可用性。这到底是好事还是坏事,我时常在想这个问题,也想不清楚。相反而言OS的圈子对于系统实用性的在意程度,明显比DB这个圈子更接地气,而不是过度去追求那些虚无缥缈的创新性。我想过度的追求原创性,而不重视可用性,也是一种病。

但是毫无疑问,Spark是迄今为止由学校主导的最为成功的开源大数据项目,几乎很难再有之二了。那么撇开这一个所谓的创新性我们来看看Spark为什么会那么成功。天时地利人和,其实我觉得Spark都做得很好。

Hadoop流行起来的时候,MapReduce很大程度上是被绑在了Hadoop上。MapReduce的弊病当然也很快被大家发现,尤其做机器学习的开源软件Mahout早年在MapReduce上写,那叫一个坑爹。业界有需求,那是非常明确的。

UCBerkeley作为一个传统上非常有名的系统学校,它曾经出过的系统都有一个非常明确的特点,可用性非常高。大凡高校做研究,学生做的东西,bug那基本上是满天飞,很难真正在产品里面能用。行百里者半九十。这最后的十里,毫无疑问,绝大部分学校放弃了。譬如说华盛顿大学的某知名系统,很多查询号称都比Spark快很多,但是架不住bug多没有人敢用啊。UCBerkeley这方面和别的学校很不一样,大概是早年Michael Stonebraker留下来的传统吧。系统做得都是非常的可用,最初的版本的系统的稳定性,虽然也会遇到很多头疼的问题,但是一般来说作为一个通用系统,可用性是非常的高。这在Spark上也是毫无疑问的体现出来了。

加上湾区是一个很特殊的地方,新东西出来,summit开起来,就会有很多公司去尝试,尝试着,好东西大浪淘沙,就很快被淘出来了。所以Spark能够流行起来也是不奇怪的。

而且Spark的团队显然非常的知道在什么时候应该做什么。Spark最初建立的生态圈的重点主要放在了图算法和机器学习上。虽然说也做一点累世SQL on Hadoop的东西。但是当时HIVE作为敌人太强大,而Mahout什么的还有各类图算法的库,相对来说就弱多了,也有需求,所以最初的生态圈建立的非常的成功。

成功的站稳了根据地以后又很早的和工业界进行了各种合作,Spark在非常早的时候就和Intel的人合作了,那个时候有工业界的人进来我想肯定是很大的助力。现在自然更不用说,自从大数据以来就做百变金刚天天换技术的IBM最后终于把自己的未来绑在了Spark的战车上,算得上是一个很好的例子。

Spark团队在商业上布局很少犯错误。我过去几年里注意到比较明显的错误是Shark这个东西。在Spark上面再搭一个东西做SQL on Hadoop还是说要把SQL做进Spark里面去,这个选择,我一直以来都认为SQL应该做进其他东西里面去做为一个component,这才是BigData Analytics未来的正确道路。那种SQL on Hadoop的产品有其生存空间,但也就这样了。Shark明显是一个没有发挥Spark威力而把Spark引向错误道路的项目。但是很快的这个项目就停了,Spark SQL出来了,DataFrame也出来了。不得不说,这是Spark团队在关键时候做了一次非常重要而正确的历史选择。如果当初继续做Shark,我想可能是另外一个局面了。 另外一个需要提一句的是BlinkDB这个项目,也是这个团队里面少数在我看来犯了错误的项目,但是这个项目应该也停止多年了。

我在2014年决定离开微软的时候,投过很多企业,也包括databricks。简历在对方系统里面出了点问题,过了若干个月以后,我在Tableau工作大概已经一个月了,接到对方的回复说我简历给遗漏了,问我是不是愿意再去面试。大家都知道,找工作是个辛苦事,一鼓作气,再而衰,三而竭。在新公司一个月就去面试然后离职,确实说不过去,而且当时我的状态已经是面试完彻底出了一口气的懒散状态,真去面试估计应该也会面挂掉,所以我也就这样和Databricks错失了一次面试的机会。

我想Spark这个作为从UCBerkeley出来的项目,从最初的高可用性,到开始建立的生态圈,到后来的发展,乃至自身的纠错,方方面面毫无疑问都证明了现在Spark无疑是大数据开源项目里面最具影响力的项目之一,而且其影响力应该会是越来越大。

【本文为51CTO专栏作者“徐飞”的原创稿件,转载请通过作者微信公众号“飞总的IT世界面面观”获取联系和授权】

本文转自d1net(转载)

相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
2月前
|
SQL 分布式计算 DataWorks
DataWorks产品使用合集之如何开发ODPS Spark任务
DataWorks作为一站式的数据开发与治理平台,提供了从数据采集、清洗、开发、调度、服务化、质量监控到安全管理的全套解决方案,帮助企业构建高效、规范、安全的大数据处理体系。以下是对DataWorks产品使用合集的概述,涵盖数据处理的各个环节。
|
1月前
|
机器学习/深度学习 分布式计算 大数据
Spark 适合解决多种类型的大数据处理问题
【9月更文挑战第1天】Spark 适合解决多种类型的大数据处理问题
41 3
|
2月前
|
分布式计算 大数据 Apache
跨越界限:当.NET遇上Apache Spark,大数据世界的新篇章如何谱写?
【8月更文挑战第28天】随着信息时代的发展,大数据已成为推动企业决策、科研与技术创新的关键力量。Apache Spark凭借其卓越的分布式计算能力和多功能数据处理特性,在大数据领域占据重要地位。然而,对于.NET开发者而言,如何在Spark生态中发挥自身优势成为一个新课题。为此,微软与Apache Spark社区共同推出了.NET for Apache Spark,使开发者能用C#、F#等语言编写Spark应用,不仅保留了Spark的强大功能,还融合了.NET的强类型系统、丰富库支持及良好跨平台能力,极大地降低了学习门槛并拓展了.NET的应用范围。
57 3
|
2月前
|
分布式计算 大数据 数据处理
Apache Spark的应用与优势:解锁大数据处理的无限潜能
【8月更文挑战第23天】Apache Spark以其卓越的性能、易用性、通用性、弹性与可扩展性以及丰富的生态系统,在大数据处理领域展现出了强大的竞争力和广泛的应用前景。随着大数据技术的不断发展和普及,Spark必将成为企业实现数字化转型和业务创新的重要工具。未来,我们有理由相信,Spark将继续引领大数据处理技术的发展潮流,为企业创造更大的价值。
|
2月前
|
存储 分布式计算 供应链
Spark在供应链核算中应用问题之调整Spark读取ODPS离线表分区大小如何解决
Spark在供应链核算中应用问题之调整Spark读取ODPS离线表分区大小如何解决
|
2月前
|
Java Spring API
Spring框架与GraphQL的史诗级碰撞:颠覆传统,重塑API开发的未来传奇!
【8月更文挑战第31天】《Spring框架与GraphQL:构建现代API》介绍了如何结合Spring框架与GraphQL构建高效、灵活的API。首先通过引入`spring-boot-starter-data-graphql`等依赖支持GraphQL,然后定义查询和类型,利用`@GraphQLQuery`等注解实现具体功能。Spring的依赖注入和事务管理进一步增强了GraphQL服务的能力。示例展示了从查询到突变的具体实现,证明了Spring与GraphQL结合的强大潜力,适合现代API设计与开发。
66 0
|
2月前
|
大数据 RDMA
神龙大数据加速引擎MRACC问题之MRACC-Spark利用eRDMA近网络优化插件来提升性能如何解决
神龙大数据加速引擎MRACC问题之MRACC-Spark利用eRDMA近网络优化插件来提升性能如何解决
35 0
|
2月前
|
分布式计算 Hadoop 大数据
大数据处理框架在零售业的应用:Apache Hadoop与Apache Spark
【8月更文挑战第20天】Apache Hadoop和Apache Spark为处理海量零售户数据提供了强大的支持
46 0
|
1月前
|
存储 大数据 数据挖掘
【数据新纪元】Apache Doris:重塑实时分析性能,解锁大数据处理新速度,引爆数据价值潜能!
【9月更文挑战第5天】Apache Doris以其卓越的性能、灵活的架构和高效的数据处理能力,正在重塑实时分析的性能极限,解锁大数据处理的新速度,引爆数据价值的无限潜能。在未来的发展中,我们有理由相信Apache Doris将继续引领数据处理的潮流,为企业提供更快速、更准确、更智能的数据洞察和决策支持。让我们携手并进,共同探索数据新纪元的无限可能!
88 11
|
2月前
|
存储 分布式计算 大数据
MaxCompute 数据分区与生命周期管理
【8月更文第31天】随着大数据分析需求的增长,如何高效地管理和组织数据变得至关重要。阿里云的 MaxCompute(原名 ODPS)是一个专为海量数据设计的计算服务,它提供了丰富的功能来帮助用户管理和优化数据。本文将重点讨论 MaxCompute 中的数据分区策略和生命周期管理方法,并通过具体的代码示例来展示如何实施这些策略。
110 1