nutch使用，大数据Spark技术是否可以替代Hadoop？
1998年9月4日，Google公司在美国硅谷成立。正如大家所知，它是一家做搜索引擎起家的公司。
无独有偶，一位名叫Doug Cutting的美国工程师，也迷上了搜索引擎。他做了一个用于文本搜索的函数库（姑且理解为软件的功能组件），命名为Lucene。
左为Doug Cutting，右为Lucene的LOGO
Lucene是用JAVA写成的，目标是为各种中小型应用软件加入全文检索功能。因为好用而且开源（代码公开），非常受程序员们的欢迎。
早期的时候，这个项目被发布在Doug Cutting的个人网站和SourceForge（一个开源软件网站）。后来，2001年底，Lucene成为Apache软件基金会jakarta项目的一个子项目。
Apache软件基金会，搞IT的应该都认识
2004年，Doug Cutting再接再励，在Lucene的基础上，和Apache开源伙伴Mike Cafarella合作，开发了一款可以代替当时的主流搜索的开源搜索引擎，命名为Nutch。
Nutch是一个建立在Lucene核心之上的网页搜索应用程序，可以下载下来直接使用。它在Lucene的基础上加了网络爬虫和一些网页相关的功能，目的就是从一个简单的站内检索推广到全球网络的搜索上，就像Google一样。
Nutch在业界的影响力比Lucene更大。
大批网站采用了Nutch平台，大大降低了技术门槛，使低成本的普通计算机取代高价的Web服务器成为可能。甚至有一段时间，在硅谷有了一股用Nutch低成本创业的潮流。
随着时间的推移，无论是Google还是Nutch，都面临搜索对象“体积”不断增大的问题。
尤其是Google，作为互联网搜索引擎，需要存储大量的网页，并不断优化自己的搜索算法，提升搜索效率。
Google搜索栏
在这个过程中，Google确实找到了不少好办法，并且无私地分享了出来。
2003年，Google发表了一篇技术学术论文，公开介绍了自己的谷歌文件系统GFS（Google File System）。这是Google公司为了存储海量搜索数据而设计的专用文件系统。
第二年，也就是2004年，Doug Cutting基于Google的GFS论文，实现了分布式文件存储系统，并将它命名为NDFS（Nutch Distributed File System）。
还是2004年，Google又发表了一篇技术学术论文，介绍自己的MapReduce编程模型。这个编程模型，用于大规模数据集（大于1TB）的并行分析运算。
第二年（2005年），Doug Cutting又基于MapReduce，在Nutch搜索引擎实现了该功能。
2006年，当时依然很厉害的Yahoo（雅虎）公司，招安了Doug Cutting。
这里要补充说明一下雅虎招安Doug的背景：2004年之前，作为互联网开拓者的雅虎，是使用Google搜索引擎作为自家搜索服务的。在2004年开始，雅虎放弃了Google，开始自己研发搜索引擎。所以。。。
加盟Yahoo之后，Doug Cutting将NDFS和MapReduce进行了升级改造，并重新命名为Hadoop（NDFS也改名为HDFS，Hadoop Distributed File System）。
这个，就是后来大名鼎鼎的大数据框架系统——Hadoop的由来。而Doug Cutting，则被人们称为Hadoop之父。
Hadoop这个名字，实际上是Doug Cutting他儿子的黄色玩具大象的名字。所以，Hadoop的Logo，就是一只奔跑的黄色大象。
我们继续往下说。
还是2006年，Google又发论文了。
这次，它们介绍了自己的BigTable。这是一种分布式数据存储系统，一种用来处理海量数据的非关系型数据库。
Doug Cutting当然没有放过，在自己的hadoop系统里面，引入了BigTable，并命名为HBase。
好吧，反正就是紧跟Google时代步伐，你出什么，我学什么。
所以，Hadoop的核心部分，基本上都有Google的影子。
2008年1月，Hadoop成功上位，正式成为Apache基金会的顶级项目。
同年2月，Yahoo宣布建成了一个拥有1万个内核的Hadoop集群，并将自己的搜索引擎产品部署在上面。
7月，Hadoop打破世界纪录，成为最快排序1TB数据的系统，用时209秒。
此后，Hadoop便进入了高速发展期，直至现在。
Hadoop的核心架构
Hadoop的核心，说白了，就是HDFS和MapReduce。HDFS为海量数据提供了存储，而MapReduce为海量数据提供了计算框架。
Hadoop核心架构
让我们来仔细看看，它们分别是怎么工作的。
首先看看HDFS。
整个HDFS有三个重要角色：NameNode（名称节点）、DataNode（数据节点）和Client（客户机）。
典型的主从架构，用TCP/IP通信
NameNode：是Master节点（主节点），可以看作是分布式文件系统中的管理者，主要负责管理文件系统的命名空间、集群配置信息和存储块的复制等。NameNode会将文件系统的Meta-data存储在内存中，这些信息主要包括了文件信息、每一个文件对应的文件块的信息和每一个文件块在DataNode的信息等。
DataNode：是Slave节点（从节点），是文件存储的基本单元，它将Block存储在本地文件系统中，保存了Block的Meta-data，同时周期性地将所有存在的Block信息发送给NameNode。
Client：切分文件；访问HDFS；与NameNode交互，获得文件位置信息；与DataNode交互，读取和写入数据。
还有一个Block（块）的概念：Block是HDFS中的基本读写单元；HDFS中的文件都是被切割为block（块）进行存储的；这些块被复制到多个DataNode中；块的大小（通常为64MB）和复制的块数量在创建文件时由Client决定。
我们来简单看看HDFS的读写流程。
首先是写入流程：
1 用户向Client（客户机）提出请求。例如，需要写入200MB的数据。
2 Client制定计划：将数据按照64MB为块，进行切割；所有的块都保存三份。
3 Client将大文件切分成块（block）。
4 针对第一个块，Client告诉NameNode（主控节点），请帮助我，将64MB的块复制三份。
5 NameNode告诉Client三个DataNode（数据节点）的地址，并且将它们根据到Client的距离，进行了排序。
6 Client把数据和清单发给第一个DataNode。
7 第一个DataNode将数据复制给第二个DataNode。
8 第二个DataNode将数据复制给第三个DataNode。
9 如果某一个块的所有数据都已写入，就会向NameNode反馈已完成。
10 对第二个Block，也进行相同的操作。
11 所有Block都完成后，关闭文件。NameNode会将数据持久化到磁盘上。
读取流程：
1 用户向Client提出读取请求。
2 Client向NameNode请求这个文件的所有信息。
3 NameNode将给Client这个文件的块列表，以及存储各个块的数据节点清单（按照和客户端的距离排序）。
4 Client从距离最近的数据节点下载所需的块。
（注意：以上只是简化的描述，实际过程会更加复杂。）
再来看MapReduce。
MapReduce其实是一种编程模型。这个模型的核心步骤主要分两部分：Map（映射）和Reduce（归约）。
当你向MapReduce框架提交一个计算作业时，它会首先把计算作业拆分成若干个Map任务，然后分配到不同的节点上去执行，每一个Map任务处理输入数据中的一部分，当Map任务完成后，它会生成一些中间文件，这些中间文件将会作为Reduce任务的输入数据。Reduce任务的主要目标就是把前面若干个Map的输出汇总到一起并输出。
是不是有点晕？我们来举个例子。
上图是一个统计词频的任务。
1 Hadoop将输入数据切成若干个分片，并将每个split（分割）交给一个map task（Map任务）处理。
2 Mapping之后，相当于得出这个task里面，每个词以及它出现的次数。
3 shuffle（拖移）将相同的词放在一起，并对它们进行排序，分成若干个分片。
4 根据这些分片，进行reduce（归约）。
5 统计出reduce task的结果，输出到文件。
如果还是没明白的吧，再举一个例子。
一个老师有100份试卷要阅卷。他找来5个帮手，扔给每个帮手20份试卷。帮手各自阅卷。最后，帮手们将成绩汇总给老师。很简单了吧？
MapReduce这个框架模型，极大地方便了编程人员在不会分布式并行编程的情况下，将自己的程序运行在分布式系统上。
哦，差点忘了，在MapReduce里，为了完成上面这些过程，需要两个角色：JobTracker和TaskTracker。
JobTracker用于调度和管理其它的TaskTracker。JobTracker可以运行于集群中任一台计算机上。TaskTracker 负责执行任务，必须运行于 DataNode 上。
1.0版本与2.0版本
2011年11月，Hadoop 1.0.0版本正式发布，意味着可以用于商业化。
但是，1.0版本中，存在一些问题：
1 扩展性差，JobTracker负载较重，成为性能瓶颈。
2 可靠性差，NameNode只有一个，万一挂掉，整个系统就会崩溃。
3 仅适用MapReduce一种计算方式。
4 资源管理的效率比较低。
所以，2012年5月，Hadoop推出了 2.0版本 。
2.0版本中，在HDFS之上，增加了YARN（资源管理框架）层。它是一个资源管理模块，为各类应用程序提供资源管理和调度。
此外，2.0版本还提升了系统的安全稳定性。
所以，后来行业里基本上都是使用2.0版本。目前Hadoop又进一步发展到3.X版本。
Hadoop的生态圈
经过时间的累积，Hadoop已经从最开始的两三个组件，发展成一个拥有20多个部件的生态系统。
在整个Hadoop架构中，计算框架起到承上启下的作用，一方面可以操作HDFS中的数据，另一方面可以被封装，提供Hive、Pig这样的上层组件的调用。
我们简单介绍一下其中几个比较重要的组件。
HBase：来源于Google的BigTable；是一个高可靠性、高性能、面向列、可伸缩的分布式数据库。
Hive：是一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，通过类SQL语句快速实现简单的MapReduce统计，不必开发专门的MapReduce应用，十分适合数据仓库的统计分析。
Pig：是一个基于Hadoop的大规模数据分析工具，它提供的SQL-LIKE语言叫Pig Latin，该语言的编译器会把类SQL的数据分析请求转换为一系列经过优化处理的MapReduce运算。
ZooKeeper：来源于Google的Chubby；它主要是用来解决分布式应用中经常遇到的一些数据管理问题，简化分布式应用协调及其管理的难度。
Ambari：Hadoop管理工具，可以快捷地监控、部署、管理集群。
Sqoop：用于在Hadoop与传统的数据库间进行数据的传递。
Mahout：一个可扩展的机器学习和数据挖掘库。
再上一张图，可能看得更直观一点：
Hadoop的优点和应用
总的来看，Hadoop有以下优点：
高可靠性：这个是由它的基因决定的。它的基因来自Google。Google最擅长的事情，就是“垃圾利用”。Google起家的时候就是穷，买不起高端服务器，所以，特别喜欢在普通电脑上部署这种大型系统。虽然硬件不可靠，但是系统非常可靠。
高扩展性：Hadoop是在可用的计算机集群间分配数据并完成计算任务的，这些集群可以方便地进行扩展。说白了，想变大很容易。
高效性：Hadoop能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快。
高容错性：Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分配。这个其实也算是高可靠性。
低成本：Hadoop是开源的，依赖于社区服务，使用成本比较低。
基于这些优点，Hadoop适合应用于大数据存储和大数据分析的应用，适合于服务器几千台到几万台的集群运行，支持PB级的存储容量。
Hadoop的应用非常广泛，包括：搜索、日志处理、推荐系统、数据分析、视频图像分析、数据保存等，都可以使用它进行部署。
目前，包括Yahoo、IBM、Facebook、亚马逊、阿里巴巴、华为、百度、腾讯等公司，都采用Hadoop构建自己的大数据系统。
除了上述大型企业将Hadoop技术运用在自身的服务中外，一些提供Hadoop解决方案的商业型公司也纷纷跟进，利用自身技术对Hadoop进行优化、改进、二次开发等，然后对外提供商业服务。
比较知名的，是Cloudera公司。
它创办于2008年，专业从事基于Hadoop的数据管理软件销售和服务，还提供Hadoop相关的支持、咨询、培训等服务，有点类似于RedHat在Linux世界中的角色。前面我们提到的Hadoop之父，Doug Cutting，都被这家公司聘请为首席架构师。
Hadoop和Spark
最后，我再介绍一下大家关心的Spark。
Spark同样是Apache软件基金会的顶级项目。它可以理解为在Hadoop基础上的一种改进。
它是加州大学伯克利分校AMP实验室所开源的类Hadoop MapReduce的通用并行框架。相对比Hadoop，它可以说是青出于蓝而胜于蓝。
前面我们说了，MapReduce是面向磁盘的。因此，受限于磁盘读写性能的约束，MapReduce在处理迭代计算、实时计算、交互式数据查询等方面并不高效。但是，这些计算却在图计算、数据挖掘和机器学习等相关应用领域中非常常见。
而Spark是面向内存的。这使得Spark能够为多个不同数据源的数据提供近乎实时的处理性能，适用于需要多次操作特定数据集的应用场景。
在相同的实验环境下处理相同的数据，若在内存中运行，那么Spark要比MapReduce快100倍。其它方面，例如处理迭代运算、计算数据分析类报表、排序等，Spark都比MapReduce快很多。
此外，Spark在易用性、通用性等方面，也比Hadoop更强。
所以，Spark的风头，已经盖过了Hadoop。
结语
以上，就是小枣君关于大数据相关技术的介绍。
小枣君个人觉得，相比于云计算技术来说，大数据的应用范围比较有限，并不是所有的公司都适用，也不是所有的业务场景都适用，没有必要跟风追捧，更不能盲目上马。
対于个人来说，大数据系统的架构非常庞大，内容也非常复杂，入门起来会比较吃力（实践练习倒是门槛很低，几台电脑足矣）。所以，如果不是特别渴望朝这个方向发展，可以不必急于学习它。或者说，可以先进行初步的了解，后续如果真的要从事相关的工作，再进行深入学习也不迟。
编程语言有哪些？
一场编程语言之战
@Author：Runsen
本人懂一点Python，Java，根据自己想法而来，纯属虚构。
现状
进入2020年3月，新的编程语言排行榜新鲜出炉，TIOBE 最新发布了 3 月编程语言排行榜。
从榜单中我们可以看到，前三名分别为Java、C、Python。相较于上个月，Python继续以1.85% 上升至 10.11%，以10.11% 的份额稳居第三。
我们先了解下比较常见的编程语言的，如Java，Python，JavaScript，C/C++，Go，C#各编程语言的用途。
“众口难调”，面对多种多样的编程语言，大家众说纷纭，每种编程语言都有其存在的意义，编程之战从未停止，“战火”一触即发。
家庭内战
最近，编程语言家族开了一场“家庭聚会”，都是在讨论自己的排名。
下面是家庭成员的对话。
老三Py：最近，我可厉害了。从2015年，人工智能的开始，人人学我，基本上我成为最无敌的大佬。
老四C++：可不是嘛，老三，你的爬虫，数据分析，机器学习，深度学习，自然语言处理再加上你的Django，flask等Web开发等，就连你的PyQt也想占领我的QT图形界面市场，都是你这个流氓，害得我从老三变成老四。
老三Py：那都是你太难写了，学我就是几分钟就能入门的，谁叫你这么难懂，什么面向对象，你的一百行代码，我十几行就搞定了，谁还会学你，很快，我就是老大，你就是我的小弟。
老四C++对老大Java说：大哥，有人想谋权篡位。
老大Java：现在，确实是老三的时代，现在个个数据分析师只会Python，都喊出了：人生苦短，我用Python。要怪就怪数据分析人员编程水平太低了，写来写去就是py代码，完全学不会其他语言。
老二C鄙视的说：就算写Python太厉害，也最多就是一个导包侠，没有什么了不起的。老三，话说你有什么本事当老大，我都不敢谋权篡位。
老三Py：不如我们比一比，看看现在开发者需要我多些还是老大多先。
老大Java：好，比就比。谁怕谁，我到底看看你有什么本事。
老三Py：我代码简单，写起来轻松易懂，比如我打印一句Hello World，就是一个，就是这么简单。就问你们服不服？
老大Java：打印一个Hello World，我确实需要好几行代码，还要声明一个HelloWorld对象。
老二C: 我还要定义一个main的主函数，打印一个Hello World确实有点多。
老四C++：我是抄老二的，写个Hello World比老二还要多。
老三Py：看见没有，这就是差距，谁会写那么多代码，直接简单粗暴我就是一个打印Hello World。
老大Java：老三，你这样不行啊，万物都是对象，写一行代码，我觉得都要声明一个对象。
老三Py：什么对象，我能打印出来就Ok了。
其他人：确实老三写的代码太简单了，连小学生基本都能学会，我们自愧不如，老三，你还要什么本事吗？
老三Py：要说我牛逼莫过我的第三方库，超过上万个，安装也简单，一个就轻松搞定，还给人看到安装进度条，你们说我牛不牛逼。
老大Java：这我可不服，你去的maven仓库看看
我的jar包任何一种场景都有，我的生态系早就完善，怎么不如你老三？
老三Py：你在pom.xml安装什么任何信息告诉别人，而且你的dependency鬼死那么长，人家愿意写吗？
老二C和老四C++：我们gcc和cmake添加第三方库还要编译才可以。
老三Py：我的requests，selenium，beautifulsoup，pyquery，lxml，Scrapy，Crawley，Pyspider等一系列爬虫库和爬虫框架厉害到爆，几乎所有爬虫都是我来编写的，你们的爬虫市场早没有你们的份了。
老大Java：我的WebMagic，Nutch，Heritrix，Jsoup， SeimiCrawler，JLiteSpider爬虫编写的代码确实比你多了好几倍，以前爬虫的市场都是基本用我，现在给你占去，悲哀。
老二C老四C++：爬虫，小心爬进监狱，现在首例爬虫禁令，禁止爬取微信公众号，都是老三你的爬虫造成多少假流量，造成多少网站 奔溃，就说12306有尽20%以上都是爬虫访问流量，有多少人抢票，再提价出售，官方发票，又被他们抢了，你以前让多少人抢不票，这背后引发了一系列的肮脏的资产链。
老三Py：这关我毛事，现在的百度蜘蛛爬取，多少网站双手叫好，这都是他们的问题。
其他人：你除了爬虫，还有什么？
老三Py：我的数据分析三剑客numpy，pandas，matplotlib，在加上Seaborn，Scipy，StatModels， Pyecharts，Bokeh，Blaze，Plotly，NetWorkX，Biopython，SymPy和gwpy等数据科学库简直无敌，都喊出了，从excel学Python了。
老大Java：数据分析我虽然也有jar提供，但是我派了我的儿子scala去帮我完善。
老二C老四C++：这东西不是SPSS，stata，tableau，powerbi，excel，Echart，FineReport等强大的数据分析工具就可以解决了，都是用我们和老大开发的，干嘛还要写代码。
老三Py：我一把屠龙剑Pycharm，一把倚天剑anaconda，一个开发，一个数据分析，双剑合并，威力无敌。
老大Java：比IDE开发工具，我可不怕，我有Eclipse，MyEclipse，Intellij IDEA，NetBeans功能厉害到爆。
老二C老四C++：Dev-C++，C-free，CLion， Code::Blocks，CodeLite，C++ Builder，我们觉得同样没问题。
老三Py：我的Web开发Django社区非常庞大，江湖上，Python有两条腿跑，一腿就是我的django，因为两万个包，一万以上都是我的Django，再加上了其他儿子flask，tornado，我开发了国内的豆瓣、知乎，国外：Instagram、Disqus、National Geographic、NASA
老大Java：Web开发，你还敢比，我就拿出一个Spring家族就够了，SpringMVC，SpringBoot,SpringCloud，再说了我还有自己的Tomcat，Jetty应用服务器，微服务的架构早就深化人心。如果以前的网站不是用php开发，那基本就是我以前的Servlet，jsp开发的（虽然落后了，但基本都在维护），现在网站开发首选我的Spring家族。
老二C老四C++：虽然在网站开发我们几乎没有市场，但是软件开发都是采用我们的，比如早期的QQ，微信，支付宝等大部分软件都是我们开发的。
老三Py：有本事比一比现在最火的人工智能，我的机器学习sklearn，深度学习keras，Pytorch，tensorflow，Caffe，PaddlePaddle，哪个不知道，哪个不用？就是因为这个，我才算最近的王者。
老大Java：你是不是想王者荣耀想多了，王者荣耀的客户端应该是C#（Unity3D）开发的，核心后端服务是C++开发，可没有你的份。人工智能，我怎么实现不了，我的深度学习库——DL4J、ND4J以及Deeplearning4j ，深度学习框架就是因为数据分析者只会用Python，才让你火到现在。
老四C++：CPP-Call-Tensorflow，Caffe2 C++ API， PyTorch-CPP，我的性能比你的好不知道多少倍。对了，说说性能，老三，你这不怎么行。
老大Java补刀：连数据都没有，老三你做什么人工智能，看看得我的apache社区的大数据框架Apache Hadoop，Apache Hive，Apache Hbase，Apache Sqoop，Apache Flume，Apache Spark，Apache Beam，Apache Flink ，Apache Storm，Spark Streaming，Apache Oozie还有 Clouders Manager（CDH）都是我开发出来，大数据平台都是我干的，没有了数据，你做什么Ai，你是不是猴子请来的逗逼？
老三Py：游戏方面，我可以有我的Pygame，性能方面，我承认比较低效，大数据不是还有我的pyspark？
老五C#：你的Pygame就是小孩子过家家的，游戏市场我已经占领，老三你可不要来。
老大Java笑道：spark是我的儿子scala开发的，spark就是为了你们这些数据分析的人不会我（Java）和我儿子（scala），你们的压力下，不好意思的开发了pyspark ，对Python提供了APi，再说了我们也给R提供了Rspark。话说，老R从前十掉下到了十一。
老R：就是你老三一直打击我，害得现在数据分析的人员不学习R了，都以为学你，就天下无敌了。
老四C++：就是明明每个人占领一种市场就够了，现在提出了”人生苦短，我学Python“口号。
老三Py：就是要”人生苦短，我学Python“。
老大Java：就是因为你，害得所有人的编程水平只降下来。Java开发人员学习Python，就是分分钟的事情。
老二C：不要说，大学我敢保证所有人都必须学习我开始。
老四C++：有本事你让学Python的来学我或者老大，我不信他能学得了。学我的人基本被我折磨死了，学你py就是分分钟的事情，有本事继续聊性能，我好像记得知乎得推荐系统用go重写了，还不是因为你的效率。
老十go：今天我难得上了前十，什么”人生苦短，我学Python“，明明就是”2020年，我们一起学go“。
老三Py：我去你的，你老十有什么资格说话？再说了我有cpython，Numba提高运行速度不就可以了吗？
老大Java：那你老三有什么资格在我面前说话，你连多线程和并发都处理不好，还不如提出我的口号”OnceWrite，RunAnywhere“，一次编写,到处运行，我的强大的JVM，你老三有吗？
老三Py：我可以用Pyinstall打成exe，到处运行，不就是”一次编写,到处运行“，
老大Java：我的强大，你不知道，你还是在mac和liunx运行你的exe吧。我还有一个儿子Kotlin和我占领APP市场，你有APP市场吗，还想当大佬，这日子是不是有点早了。
老三Py：我有kivy开发APP。
老二C老四C++：老三，你怎么不说用flutter开发APP？
老三Py：那是Google 开源的 UI 工具包，关我毛事。
老二C老四C++：flutter的底层是基于我们的开发的。
老三Py：我不管，反正现在人人学Py，我的市场就是慢慢变大，我就是当老大。
老二C: 我从1972年诞生，可以说我是老三你的长辈。Java可是运行在全球的三十亿设备上的，我都没有把握当老大，你哪里来的勇气？
老三Py：我是从1991年出生，Java可是1995年出生，这样我不就是老大的长辈吗？
老大Java：老三说得没错，老三要当老大，他膨胀了，要先超越老二你了。
老二C: 什么？老三，他连编译器都没有，一个解释器基于我的编译器，竟然敢叫嚣超越我，用我编译器，底层封装我的代码， 没有我，哪里来你，脚本就是脚本，动态语言就是动态语言，老大，老四和我哪个不是静态语言，哪个没有自己的编译器？信不信我不给你用我的编译器，让你从前十消失。
老三Py：卧槽，爸爸，我错了，别让我从前十消失啊。
一声不吭的老八php叫道：php才是最好的语言。
我想说的
Python这语言，只适合作为加分项，不适合作为技术支撑。因为它写不了复杂逻辑。只适合写一个爬虫，计算器，记事本,Qt之类的小程序。Python超越了Java和C，那是不可能的。Python从老四超越了C++，已经是一个很震惊的大事了。
说这个也许有人不服，凭什么Python就写不了复杂逻辑？豆瓣和知乎不是用Python写的吗？
先声明，豆瓣的后端，已经废弃了绝大部分的Python代码，重新写过了。youtube也正在重写中。目前以Python为主的网站，就只有知乎这么个独苗，而且知乎的推荐算法已经用go重写了。
为什么？不是因为Python的性能慢，而是因为Python的语法太悲剧了。也许Python的语法简洁，在初学者看来是优点。因为初学者一般练手，都只写1000行以下的小玩意，Python的语法简直爽翻了，真没任何缺点。
但如果你真的尝试用Python封装几十个类，去写个一万行以上的东西，自然就明白它的语法问题有多严重了。不只是难受，而是根本写不下，去维护成本太大了。没有静态类型检查是主要原因。能解决么？也能，好的模块设计还有code review能回避掉一些，不过这样一来也就抵消掉一些Python能带来的快速开发的优势了。
还是江湖那句话，动态一时爽，重构火葬场。并不适合大项目，Python还是适合原型，前期项目。
搞it要想混得好，如果哪能只会一样东西呢，除非你不想混好，拼得就是综合素质，除非你Python登峰造极的程度，python五分钟都能入门，Python的语法和英语完全一样。学Python的人，去学Java，真的觉得很难。
如果按难度评分0-5的话，Python没有难度指数0，php难度指数1，go难度指数2，Java难度指数3，C++/C难度指数4。静态语言的难度是比动态脚本难的，如果你是编程零基础，建议从学习Python，再深入到Java。一手Python，一手Java基本在市场属于比较靠前的水平。
阿里基本Java的天下，腾讯的前世是靠C/C++出生，华为主要业务是在硬件方面，也需要C/C++的编程基础。百度，字节相反用的Python，go，ruby比较多。
不过如果自己想要有更长远的发展，只学python肯定是不够的，个人觉得Java、Python这二门语言都熟练掌握最好。如果想成为大神，那就补充一个C++，你就是无敌的存在。
@Author：Runsen 公众号：润森笔记
泰国曼谷两个机场的区别是什么？
中国游客抵达曼谷，走素万纳普机场和廊曼机场哪个更方便？
目前泰国曼谷在运营的民用机场有素万纳普机场和廊曼机场。
中国游客前往曼谷，是购买降落曼谷素万纳普机场的正价机票，还是购买降落曼谷廊曼机场的泰国廉价航空机票，一定要把素万纳普机场和曼谷廊曼机场到曼谷市区和曼谷周边的交通因素考虑清楚。
启用于1914年3月27日的曼谷廊曼国际机场（Don Mueang Internatinal Airport），又称为旧曼谷国际机场，代码DMK，是位于泰国曼谷北郊的国际机场，距离曼谷市中心约25公里。
曼谷素万纳普机场（Suvarnabhumi International Airport），又称为新曼谷国际机场，代码BKK，原名叫"眼镜蛇沼泽机场"（Nong-ngu-hao Airport）。2000年9月29日，前泰王普密蓬陛下御赐新国际机场名称为"素万那普"，取自古印度巴利语，意思是"黄金之地"。具体位置为曼谷以东约35公里处。素万纳普机场是世界上建造时间最长的机场，始建于1960年6月，于2006年9月28日才投入使用，历时46年3个月！
曼谷廊曼机场目前是泰国廉价航空公司的基地。经常往来于中国和泰国的泰国亚洲航空航班和泰国飞鸟航空航班起降地在廊曼机场，而往返于泰国国内城际间的廉价航空航班比如泰亚航，泰皇雀（飞鸟航空）、泰国狮航等航班起降地也是廊曼机场。
素万那普国际机场现在是曼谷主要的民用机场，也是东南亚地区乃至亚洲重要的航空枢纽。该机场除了是泰国国际航空的枢纽机场外，香港国泰航空、台湾中华航空、长荣航空等外籍航空公司也将之当作重点机场。目前有免费穿梭巴士来往于两个机场，车程大约1个小时，运行时间是早5:00到24:00，半小时一班车。乘坐免费穿梭巴士时需要出示机票行程单。
素万纳普到市区的交通
2011年6月1日开始，曼谷素万那普国际机场开往曼谷市区的机场大巴已经停止运营。目前，前往曼谷市区的交通有三种方式，机场快轨、长途大巴和出租车。夜间航班抵达的中国游客，也可以在国内网站上提前预订接送机服务。
正常航班到达曼谷素万纳普机场的游客，最方便的莫过于乘坐机场快轨，价格实惠还不担心路上堵车。机场快轨站位于航站楼地下1层，运营时间是早6:00至24:00点。停靠的站点不同，分成三种不同颜色的车。
城市蓝线（SA CityLine)：全程28公里，用时大约30分钟。途径:phayathai站，Ratchaprarop站，makkasan站，ramkhamhaeng站，huamark站，ban tubchang站，lardkrabang站和Suvarnabhumi。票价根据里程，从15泰铢到45泰铢不等。
黄色快线（makkasan Express Line）:全程25公里，约15分钟，makkasan站直接到素万那普国际机场站。单程票价90泰铢，往返票价150泰铢。
红色快线 (Phaya Thai Express):总长28公里，18分钟之内即能从帕亚泰站直达素万那普国际机场，每1小时一班车。单程票价90泰铢，往返票价150泰铢。
夜间抵达的航班，路上畅通，普域度假建议从素万纳普机场乘出租车到市区。素万纳普机场的出租车 24小时营业，航站楼 1 层 4号门口和 7号门口提供出租车服务，加上50泰铢的叫车服务费和高速路费，前往曼谷市区的车费大约在400泰铢。
如果要往返于素万纳普机场和曼谷北部长途站、东部长途站、芭提雅、罗勇府等地之间，可以考虑以下长途大巴车。大巴车的运营时间是早 05:40-21:00。
389 素万那普机场– Leamchabang – 帕提雅
390 素万那普机场 – Chachoengsau – Rongklua市场(跳蚤市场)
825 素万那普机场 – Nakhonratchasima – Khonkhaen – Udonthani – Nongkhai
9904 Jatujak 总车站 (高速公路) –素万那普机场– Motorway – 春武里
9905 Jatujak 总车站l (高速公路) –素万那普机场 – 帕提雅 (Jpmthien)
9906 1. Jatujak总车站l (高速公路) – 素万那普机场 _U-Tapau – Banchang – Maptaphut – Rayong
Jatujak总车站l (高速公路) – 素万那普机场 – Maptaphut – Rayong
Jatujak总车站l (高速公路) – 素万那普机场– Rayong
9907 Jatujak总车站l (高速公路) – 素万那普机场 – Amphur Klaeng –春武里
9908 Jatujak总车站l (高速公路) – 素万那普机场 – Kulpat Tour Center – Amphur Klung - Trad
9909 Jatujak总车站l – 素万那普机场– Sriracha – Leamchabang
9910 Jatujak总车站l – 素万那普机场 – Chachoensau – Banklah
9916 Ekkama总车站l – Sukhumvit (高速公路) – 素万那普机场 - Sakaew
55路 Ekkamai 总车站 – On-nutch路口 – 素万那普机场 – Klongsuan – Klong Prawes– Chachoengsau – Amphur Bang Klah
廊曼机场到曼谷市区的交通
曼谷廊曼机场到市区没有开通轨道交通。前往曼谷市区的交通只能是靠出租车和公交车。公交车价格便宜，当地人用的较多，有的线路不允许上行李。因此，普域度假一般也不建议客人去挤公交车，正常航班抵达的中国游客可以乘出租车或者在国内网上提前预订接送机服务。
显然，从所处的位置来看，虽然曼谷廊曼机场比素万纳普机场距离市区要近，但是从交通方面来考虑，素万纳普机场却占了优势，而且设备更新，功能更齐全。（完）
java和python在爬虫方面的优势和劣势是什么？
做过数年爬虫，Python和Java都用过（主要用Python），亲身感受来回答问题。
做爬虫是一个很有意思的事情，它不是算算数字也不是画图，更像是模拟人类来做重复性的琐碎工作，同时要和反爬虫斗智斗勇。
我们抛开语言，先看看什么是做爬虫开发要注意的或者更重要的：
选择熟悉的语言据说最好的编程语言是你已经熟悉的——网络爬虫也是这样。在学习使用时，可能会加快速度——站在凳子上拿高处东西会容易些。
第三方库可以使事情变得更容易并不需要从头开始，因为有许多第三方库专门用于网络爬虫——憋重头造轮子阿——站在巨人肩膀上更容易摸到月亮——也更容易掉下来。
什么是爬虫的最佳编程语言？从网站爬行和提取数据涉及各种问题——I/O机制、通信、多线程、任务调度和重复数据删除等等。语言框架将对爬网效率产生重大影响。
以下是爬虫的的理想编程语言需要的东西：灵活性提供数据库的操作能力“爬”效率易于编写可扩展性可维护性网络抓取的速度是否依赖于语言？许多初学者都在思考编程语言在速度方面的问题。但是处理速度一般不是这里的瓶颈。实际上，影响速度的主要因素是I / O（输入/输出），因为网络爬虫就是发送请求和接收响应。与互联网的沟通是这里的真正瓶颈。互联网的速度无法与您机器内处理器的速度相匹配。
这并不意味着语言无关紧要；语言的速度主要取决于开发速度，易维护性和代码可读性
Node.js
Node.js特别 适合 抓取使用动态编码的网站。 虽然它支持分布式爬，但通信的稳定性相对较弱，不建议用于大型项目。
C&C++：
虽然C和C++提供了很好的性能，但开发太累了。 因此，建议不要使用C或C++。
PHP：
PHP可能是构建爬虫程序最不利的语言。对多线程和异步的弱支持是一个很大的缺点，这可能会在任务调度和排队方面产生许多问题。
Python：
Python是最流行的Web抓取语言。它更像是一个多面手，可以顺利处理大多数网络爬行相关流程。
Scrapy和Beautiful Soup是基于Python的广泛使用的框架。
Beautiful soup是一个Python库，专为快速高效的Web爬虫而设计。
一些值得注意的功能是用于导航，搜索和修改解析树的Pythonic习语。 Beautiful Soup还可以将传入的文档转换为Unicode，将传出的文档转换为UTF-8。 Beautiful Soup适用于流行的Python解析器，如lxml和html5lib，它们允许您尝试不同的解析方法。这些高度发展的Web库使Python成为Web爬虫的最佳语言。
学习大数据要有哪些预备知识？
计算机的基本工作就是处理数据，包括磁盘文件中的数据，通过网络传输的数据流或数据包，数据库中的结构化数据等。随着互联网、物联网等技术得到越来越广泛的应用，数据规模不断增加，TB、PB量级成为常态，对数据的处理已无法由单台计算机完成，而只能由多台机器共同承担计算任务。而在分布式环境中进行大数据处理，除了与存储系统打交道外，还涉及计算任务的分工，计算负荷的分配，计算机之间的数据迁移等工作，并且要考虑计算机或网络发生故障时的数据安全，情况要复杂得多。
举一个简单的例子，假设我们要从销售记录中统计各种商品销售额。在单机环境中，我们只需把销售记录扫描一遍，对各商品的销售额进行累加即可。如果销售记录存放在关系数据库中，则更省事，执行一个SQL语句就可以了。现在假定销售记录实在太多，需要设计出由多台计算机来统计销售额的方案。为保证计算的正确、可靠、高效及方便，这个方案需要考虑下列问题：
如何为每台机器分配任务，是先按商品种类对销售记录分组，不同机器处理不同商品种类的销售记录，还是随机向各台机器分发一部分销售记录进行统计，最后把各台机器的统计结果按商品种类合并？
上述两种方式都涉及数据的排序问题，应选择哪种排序算法？应该在哪台机器上执行排序过程？
如何定义每台机器处理的数据从哪里来，处理结果到哪里去？数据是主动发送，还是接收方申请时才发送？如果是主动发送，接收方处理不过来怎么办？如果是申请时才发送，那发送方应该保存数据多久？
会不会任务分配不均，有的机器很快就处理完了，有的机器一直忙着？甚至，闲着的机器需要等忙着的机器处理完后才能开始执行？
如果增加一台机器，它能不能减轻其他机器的负荷，从而缩短任务执行时间？
如果一台机器挂了，它没有完成的任务该交给谁？会不会遗漏统计或重复统计？
统计过程中，机器之间如何协调，是否需要专门的一台机器指挥调度其他机器？如果这台机器挂了呢？
（可选）如果销售记录在源源不断地增加，统计还没执行完新记录又来了，如何保证统计结果的准确性？能不能保证结果是实时更新的？再次统计时能不能避免大量重复计算？
（可选）能不能让用户执行一句SQL就可以得到结果？
上述问题中，除了第1个外，其余的都与具体任务无关，在其他分布式计算的场合也会遇到，而且解决起来都相当棘手。即使第1个问题中的分组、统计，在很多数据处理场合也会涉及，只是具体方式不同。如果能把这些问题的解决方案封装到一个计算框架中，则可大大简化这类应用程序的开发。
2004年前后，Google先后发表三篇论文分别介绍分布式文件系统GFS、并行计算模型MapReduce、非关系数据存储系统BigTable，第一次提出了针对大数据分布式处理的可重用方案。在Google论文的启发下，Yahoo的工程师Doug Cutting和Mike Cafarella开发了Hadoop。在借鉴和改进Hadoop的基础上，又先后诞生了数十种应用于分布式环境的大数据计算框架。本文在参考业界惯例的基础上，对这些框架按下列标准分类：
如果不涉及上面提出的第8、9两个问题，则属于批处理框架。批处理框架重点关心数据处理的吞吐量，又可分为非迭代式和迭代式两类，迭代式包括DAG（有向无环图）、图计算等模型。
若针对第8个问题提出来应对方案，则分两种情况：如果重点关心处理的实时性，则属于流计算框架；如果侧重于避免重复计算，则属于增量计算框架。
如果重点关注的是第9个问题，则属于交互式分析框架。
本文下面分别讨论批处理、流计算、交互式分析三种类别的框架，然后简要介绍大数据计算框架的一些发展趋势。文章最后介绍这一领域的学习资料。
批处理框架
Hadoop
Hadoop最初主要包含分布式文件系统HDFS和计算框架MapReduce两部分，是从Nutch中独立出来的项目。在2.0版本中，又把资源管理和任务调度功能从MapReduce中剥离形成YARN，使其他框架也可以像MapReduce那样运行在Hadoop之上。与之前的分布式计算框架相比，Hadoop隐藏了很多繁琐的细节，如容错、负载均衡等，更便于使用。
Hadoop也具有很强的横向扩展能力，可以很容易地把新计算机接入到集群中参与计算。在开源社区的支持下，Hadoop不断发展完善，并集成了众多优秀的产品如非关系数据库HBase、数据仓库Hive、数据处理工具Sqoop、机器学习算法库Mahout、一致性服务软件ZooKeeper、管理工具Ambari等，形成了相对完整的生态圈和分布式计算事实上的标准。
图2. Hadoop生态圈（删减版）
MapReduce可以理解为把一堆杂乱无章的数据按照某种特征归并起来，然后处理并得到最后的结果。基本处理步骤如下：
把输入文件按照一定的标准分片，每个分片对应一个map任务。一般情况下，MapReduce和HDFS运行在同一组计算机上，也就是说，每台计算机同时承担存储和计算任务，因此分片通常不涉及计算机之间的数据复制。
按照一定的规则把分片中的内容解析成键值对。通常选择一种预定义的规则即可。
执行map任务，处理每个键值对，输出零个或多个键值对。
MapReduce获取应用程序定义的分组方式，并按分组对map任务输出的键值对排序。默认每个键名一组。
待所有节点都执行完上述步骤后，MapReduce启动Reduce任务。每个分组对应一个Reduce任务。
执行reduce任务的进程通过网络获取指定组的所有键值对。
把键名相同的值合并为列表。
执行reduce任务，处理每个键对应的列表，输出结果。
图3. MapReduce处理过程
在上面的步骤中，应用程序主要负责设计map和reduce任务，其他工作均由框架负责。在定义map任务输出数据的方式时，键的选择至关重要，除了影响结果的正确性外，也决定数据如何分组、排序、传输，以及执行reduce任务的计算机如何分工。前面提到的商品销售统计的例子，可选择商品种类为键。MapReduce执行商品销售统计的过程大致如下：
把销售记录分片，分配给多台机器。
每条销售记录被解析成键值对，其中值为销售记录的内容，键可忽略。
执行map任务，每条销售记录被转换为新的键值对，其中键为商品种类，值为该条记录中商品的销售额。
MapReduce把map任务生成的数据按商品种类排序。
待所有节点都完成排序后，MapReduce启动reduce任务。每个商品种类对应一个reduce任务。
执行reduce任务的进程通过网络获取指定商品种类的各次销售额。
MapReduce把同一种商品下的各次销售额合并到列表中。
执行reduce任务，累加各次销售额，得到该种商品的总销售额。
上面的过程还有优化的空间。在传输各种商品每次的销售额数据前，可先在map端对各种商品的销售额进行小计，由此可大大减少网络传输的负荷。MapReduce通过一个可选的combine任务支持该类型的优化。
DAG模型
现在假设我们的目标更进一步，希望知道销售得最好的前10种商品。我们可以分两个环节来计算：
统计各种商品的销售额。通过MapReduce实现，这在前面已经讨论过。
对商品种类按销售额排名。可以通过一个排序过程完成。假定商品种类非常多，需要通过多台计算机来加快计算速度的话，我们可以用另一个MapReduce过程来实现，其基本思路是把map和reduce分别当作小组赛和决赛，先计算各分片的前10名，汇总后再计算总排行榜的前10名。
从上面的例子可以看出，通过多个MapReduce的组合，可以表达复杂的计算问题。不过，组合过程需要人工设计，比较麻烦。另外，每个阶段都需要所有的计算机同步，影响了执行效率。
为克服上述问题，业界提出了DAG（有向无环图）计算模型，其核心思想是把任务在内部分解为若干存在先后顺序的子任务，由此可更灵活地表达各种复杂的依赖关系。Microsoft Dryad、Google FlumeJava、Apache Tez是最早出现的DAG模型。Dryad定义了串接、全连接、融合等若干简单的DAG模型，通过组合这些简单结构来描述复杂的任务，FlumeJava、Tez则通过组合若干MapReduce形成DAG任务。
图4. MapReduce（左）与Tez（右）
执行复杂任务时对比
MapReduce的另一个不足之处是使用磁盘存储中间结果，严重影响了系统的性能，这在机器学习等需要迭代计算的场合更为明显。加州大学伯克利分校AMP实验室开发的Spark克服了上述问题。Spark对早期的DAG模型作了改进，提出了基于内存的分布式存储抽象模型RDD（Resilient Distributed Datasets，可恢复分布式数据集），把中间数据有选择地加载并驻留到内存中，减少磁盘IO开销。与Hadoop相比，Spark基于内存的运算要快100倍以上，基于磁盘的运算也要快10倍以上。
图5. MapReduce与Spark中间结果
保存方式对比
Spark为RDD提供了丰富的操作方法，其中map、 filter、 flatMap、 sample、groupByKey、 reduceByKey、union、join、cogroup、mapValues、sort、partionBy用于执行数据转换，生成新的RDD，而count、collect、 reduce、lookup、save用于收集或输出计算结果。如前面统计商品销售额的例子，在Spark中只需要调用map和reduceByKey两个转换操作就可以实现，整个程序包括加载销售记录和保存统计结果在内也只需要寥寥几行代码，并且支持Java、Scala、Python、R等多种开发语言，比MapReduce编程要方便得多。下图说明reduceByKey的内部实现。
图6. RDD reduceByKey内部实现
RDD由于把数据存放在内存中而不是磁盘上，因此需要比Hadoop更多地考虑容错问题。分布式数据集的容错有两种方式：数据检查点和记录数据的更新。处理海量数据时，数据检查点操作成本很高， 因此Spark默认选择记录更新的方式。不过如果更新粒度太细太多，记录更新成本也不低。因此，RDD只支持粗粒度转换，即只记录单个块上执行的单个操作，然后将创建RDD的一系列变换序列记录下来，类似于数据库中的日志。
当RDD的部分分区数据丢失时，Spark根据之前记录的演变过程重新运算，恢复丢失的数据分区。Spark生态圈的另一项目Alluxio（原名Tachyon）也采用类似的思路，使数据写入速度比HDFS有数量级的提升。
下面总结Spark对MapReduce的改进：
MapReduce抽象层次低，需要手工编写代码完成；Spark基于RDD抽象，使数据处理逻辑的代码非常简短。
MapReduce只提供了map和reduce两个操作，表达力欠缺；Spark提供了很多转换和动作，很多关系数据库中常见的操作如JOIN、GROUP BY已经在RDD中实现。
MapReduce中，只有map和reduce两个阶段，复杂的计算需要大量的组合，并且由开发者自己定义组合方式；Spark中，RDD可以连续执行多个转换操作，如果这些操作对应的RDD分区不变的话，还可以放在同一个任务中执行。
MapReduce处理逻辑隐藏在代码中，不直观；Spark代码不包含操作细节，逻辑更清晰。
MapReduce中间结果放在HDFS中；Spark中间结果放在内存中，内存放不下时才写入本地磁盘而不是HDFS，这显著提高了性能，特别是在迭代式数据处理的场合。
MapReduce中，reduce任务需要等待所有map任务完成后才可以开始；在Spark中，分区相同的转换构成流水线放到同一个任务中运行。
流计算框架
流计算概述
在大数据时代，数据通常都是持续不断动态产生的。在很多场合，数据需要在非常短的时间内得到处理，并且还要考虑容错、拥塞控制等问题，避免数据遗漏或重复计算。流计算框架则是针对这一类问题的解决方案。流计算框架一般采用DAG（有向无环图）模型。图中的节点分为两类：一类是数据的输入节点，负责与外界交互而向系统提供数据；另一类是数据的计算节点，负责完成某种处理功能如过滤、累加、合并等。从外部系统不断传入的实时数据则流经这些节点，把它们串接起来。如果把数据流比作水的话，输入节点好比是喷头，源源不断地出水，计算节点则相当于水管的转接口。如下图所示。
图7. 流计算DAG模型示意图
为提高并发性，每一个计算节点对应的数据处理功能被分配到多个任务（相同或不同计算机上的线程）。在设计DAG时，需要考虑如何把待处理的数据分发到下游计算节点对应的各个任务，这在实时计算中称为分组（Grouping）。最简单的方案是为每个任务复制一份，不过这样效率很低，更好的方式是每个任务处理数据的不同部分。随机分组能达到负载均衡的效果，应优先考虑。不过在执行累加、数据关联等操作时，需要保证同一属性的数据被固定分发到对应的任务，这时应采用定向分组。在某些情况下，还需要自定义分组方案。
图8. 流计算分组
由于应用场合的广泛性，目前市面上已经有不少流计算平台，包括Google MillWheel、Twitter Heron和Apache项目Storm、Samza、S4、Flink、Apex、Gearpump。
Storm及Trident
在流计算框架中，目前人气最高，应用最广泛的要数Storm。这是由于Storm具有简单的编程模型，且支持Java、Ruby、Python等多种开发语言。Storm也具有良好的性能，在多节点集群上每秒可以处理上百万条消息。Storm在容错方面也设计得很优雅。下面介绍Storm确保消息可靠性的思路。
在DAG模型中，确保消息可靠的难点在于，原始数据被当前的计算节点成功处理后，还不能被丢弃，因为它生成的数据仍然可能在后续的计算节点上处理失败，需要由该消息重新生成。而如果要对消息在各个计算节点的处理情况都作跟踪记录的话，则会消耗大量资源。
Storm的解决思路，是为每条消息分派一个ID作为唯一性标识，并在消息中包含原始输入消息的ID。同时用一个响应中心（Acker）维护每条原始输入消息的状态，状态的初值为该原始输入消息的ID。每个计算节点成功执行后，则把输入和输出消息的ID进行异或，再异或对应的原始输入消息的状态。由于每条消息在生成和处理时分别被异或一次，则成功执行后所有消息均被异或两次，对应的原始输入消息的状态为0。因此当状态为0后可安全清除原始输入消息的内容，而如果超过指定时间间隔后状态仍不为0，则认为处理该消息的某个环节出了问题，需要重新执行。
图9. Storm保证消息可靠性过程示意图
Storm还实现了更高层次的抽象框架Trident。Trident以微批处理的方式处理数据流，比如每次处理100条记录。Trident提供了过滤、分组、连接、窗口操作、聚合、状态管理等操作，支持跨批次进行聚合处理，并对执行过程进行优化，包括多个操作的合并、数据传输前的本地聚合等。以微批处理方式处理数据流的框架还有Spark Streaming。
(1) 实时流处理
(2) 微批处理
图10. 实时流处理与微批处理比较
下面是Storm、Trident与另外几种流计算框架的对比：
交互式分析框架
概述
在解决了大数据的可靠存储和高效计算后，如何为数据分析人员提供便利日益受到关注，而最便利的分析方式莫过于交互式查询。这几年交互式分析技术发展迅速，目前这一领域知名的平台有十余个，包括Google开发的Dremel和PowerDrill，Facebook开发的Presto， Hadoop服务商Cloudera和HortonWorks分别开发的Impala和Stinger，以及Apache项目Hive、Drill、Tajo、Kylin、MRQL等。
一些批处理和流计算平台如Spark和Flink也分别内置了交互式分析框架。由于SQL已被业界广泛接受，目前的交互式分析框架都支持用类似SQL的语言进行查询。早期的交互式分析平台建立在Hadoop的基础上，被称作SQL-on-Hadoop。后来的分析平台改用Spark、Storm等引擎，不过SQL-on-Hadoop的称呼还是沿用了下来。SQL-on-Hadoop也指为分布式数据存储提供SQL查询功能。
Hive
Apache Hive是最早出现的架构在Hadoop基础之上的大规模数据仓库，由Facebook设计并开源。Hive的基本思想是，通过定义模式信息，把HDFS中的文件组织成类似传统数据库的存储系统。Hive 保持着 Hadoop 所提供的可扩展性和灵活性。Hive支持熟悉的关系数据库概念，比如表、列和分区，包含对非结构化数据一定程度的 SQL 支持。它支持所有主要的原语类型（如整数、浮点数、字符串）和复杂类型（如字典、列表、结构）。它还支持使用类似 SQL 的声明性语言 Hive Query Language (HiveQL) 表达的查询，任何熟悉 SQL 的人都很容易理解它。HiveQL被编译为MapReduce过程执行。下图说明如何通过MapReduce实现JOIN和GROUP BY。
(1) 实现JOIN
(2) 实现GROUP BY
图11. 部分HiveQL操作的实现方式
Hive与传统关系数据库对比如下：
Hive的主要弱点是由于建立在MapReduce的基础上，性能受到限制。很多交互式分析平台基于对Hive的改进和扩展，包括Stinger、Presto、Kylin等。其中Kylin是中国团队提交到Apache上的项目，其与众不同的地方是提供多维分析（OLAP）能力。Kylin对多维分析可能用到的度量进行预计算，供查询时直接访问，由此提供快速查询和高并发能力。Kylin在eBay、百度、京东、网易、美团均有应用。
SQL引擎Calcite
对于交互式分析，SQL查询引擎的优劣对性能的影响举足轻重。Spark开发了自己的查询引擎Catalyst，而包括Hive、Drill、Kylin、Flink在内的很多交互式分析平台及数据仓库使用Calcite（原名optiq）作为SQL引擎。Calcite是一个Apache孵化项目，其创建者Julian Hyde曾是Oracle数据库SQL引擎的主要开发者。Calcite具有下列几个技术特点：
支持标准SQL语言。
支持OLAP。
支持对流数据的查询。
独立于编程语言和数据源，可以支持不同的前端和后端。
支持关系代数、可定制的逻辑规划规则和基于成本模型优化的查询引擎。
支持物化视图（materialized view）的管理。
由于分布式场景远比传统的数据存储环境更复杂，Calcite和Catalyst都还处于向Oracle、MySQL等经典关系数据库引擎学习的阶段，在性能优化的道路上还有很长的路要走。
其他类型的框架
除了上面介绍的几种类型的框架外，还有一些目前还不太热门但具有重要潜力的框架类型。图计算是DAG之外的另一种迭代式计算模型，它以图论为基础对现实世界建模和计算，擅长表达数据之间的关联性，适用于PageRank计算、社交网络分析、推荐系统及机器学习。这一类框架有Google Pregel、Apache Giraph、Apache Hama、PowerGraph、，其中PowerGraph是这一领域目前最杰出的代表。很多图数据库也内置图计算框架。
另一类是增量计算框架，探讨如何只对部分新增数据进行计算来极大提升计算过程的效率，可应用到数据增量或周期性更新的场合。这一类框架包括Google Percolator、Microsoft Kineograph、阿里Galaxy等。
另外还有像Apache Ignite、Apache Geode（GemFire的开源版本）这样的高性能事务处理框架。
总结与展望
从Hadoop横空出世到现在10余年的时间中，大数据分布式计算技术得到了迅猛发展。不过由于历史尚短，这方面的技术远未成熟。各种框架都还在不断改进，并相互竞争。
性能优化毫无疑问是大数据计算框架改进的重点方向之一。而性能的提高很大程度上取决于内存的有效利用。这包括前面提到的内存计算，现已在各种类型的框架中广泛采用。内存资源的分配管理对性能也有重要影响，JVM垃圾回收在给开发人员带来便利的同时，也制约了内存的有效利用。另外，Java的对象创建及序列化也比较浪费资源。在内存优化方面做足功夫的代表是Flink。出于性能方面的考虑，Flink很多组件自行管理内存，无需依赖JVM垃圾回收机制。Flink还用到开辟内存池、用二进制数据代替对象、量身定制序列化、定制缓存友好的算法等优化手段。Flink还在任务的执行方面进行优化，包括多阶段并行执行和增量迭代。
拥抱机器学习和人工智能也是大数据计算的潮流之一。Spark和Flink分别推出机器学习库Spark ML和Flink ML。更多的平台在第三方大数据计算框架上提供机器学习，如Mahout、Oryx及一干Apache孵化项目SystemML、HiveMall、PredictionIO、SAMOA、MADLib。这些机器学习平台一般都同时支持多个计算框架，如Mahout同时以Spark、Flink、H2O为引擎，SAMOA则使用S4、Storm、Samza。在深度学习掀起热潮后，又有社区探索把深度学习框架与现有分布式计算框架结合起来，这样的项目有SparkNet、Caffe on Spark、TensorFrames等。
在同一平台上支持多种框架也是发展趋势之一，尤其对于那些开发实力较为雄厚的社区。Spark以批处理模型为核心，实现了交互式分析框架Spark SQL、流计算框架Spark Streaming（及正在实现的Structured Streaming）、图计算框架GraphX、机器学习库Spark ML。而Flink在提供低延迟的流计算的同时，批处理、关系计算、图计算、机器学习，一个也没落下，目标直奔大数据通用计算平台。Google的BEAM（意为Batch+strEAM）则试图把Spark、Flink、Apex这样的计算框架纳入自己制定的标准之下，颇有号令江湖之意。
Google的那几篇论文这里就不一一列出了，网上很容易搜到。其他推荐的论文如下：
还没有评论，来说两句吧...