开发者学堂课程【企业运维训练营之大数据 EMR 原理与实践：视频-《E-MapReduce》】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1242/detail/18440
视频-《E-MapReduce》
（10）2010年，Shay Banon重写了compass，命名为ElasticSearch，从此开启了ElasticSearch的时代，这个之后其他人在使搜索引擎的功能会方便很多。
①举例说明
有一个故事，这个人其实是一个失业开发者，跟着他的妻子去了伦敦，他的妻子学习厨师，而他在寻找一个赚钱工作的同时，想给他妻子做一个食谱的搜索引擎。他最开始是使用了Lucene的早期的版本，直接使用Lucene是很难的，因此他做了一个抽象层。开发者可以使用它很简单的给他的程序添加搜索功能，他发布了他的开源项目compass，后来获取了一份工作，这份工作对于高性能还有实时分布式的一个双引擎的需求很突出，所以他决定重写compass，把它变成一个独立的服务，并命名为ElasticSearch。ElasticSearch和Lucene的关系，其实与pig和hive与mapreduce的关系是类似的，在Lucene的上面包装了一层，使用起来更加方便，ElasticSearch提供了一个rest风格的API，通过HTTP的协议就能实现ES的语法传递，就可以索引和搜索数据了，这样是非常方便的。
本次的性能结束后，会给带来一次ElasticSearch专题分享训练营，感兴趣的同学后续可以关注。
②mapreduce存在的问题
在2010年左右，这个时候的大数据计算已经是mapreduce的天下，mapreduce本身是存在让数据工作者诟病的地方的，第一个是与SQL相比mapreduce显得过于低层，使用起来非常复杂，Hive的出现改善这种状况。第二个诟病是mapreduce的执行速度非常慢，一个普通的mapreduce作业一般在分钟级别完成，复杂的作业或者是数据量大的情况下，他可能会花费一个小时或者更多，好在一线的计算对于时间没有敏感。map reduce的慢主要是由于磁盘IO， mapreduce会将大量的中间结果写到磁盘上，并且通过网络进行传输，这样就耗去了大量时间，所以当时的业界也在不断的研究如何提升效率，当时有两个主流的研究方向，第一个是提升计算速度和追求，第二个就是追求实时计算。
（11）实时计算方面，在2011年推特公司正式的开源了storm。从此开启了流式数据处理的时代。
STORM的逻辑是来一条数据，就处理一条数据，因此它的延迟是非常小的，但是可以想象，它的吞吐量肯定是个问题。所以storm最大的局限在于它只处理流数据，无法处理批数据。并且storm对于数据消费的态度不丢还好，一旦发现数据丢了，就要重新再计算一次，这个时候如果发现原来的数据没有丢，它只是网络延迟，这个数据就会重新计算，导致计算结果出错，即数据流里的事件投递，只能保证至少一次或者至多一次，不能保证只有一次，这也是诸多使用者极为诟病的地方。除了这个实时计算的方面，另一个研究方向提升计算速度方面
（12）在2012年UC伯克利的AMD实验室的一位博士在使用mapreduce进行大数据实验时，发现它的性能非常差，不能满足他的计算需求。为了改进这种效率低下的工作方式，开发出了一个性能优越的代理产品，就是Spark。mapreduce之所以慢是它要保证集群的容错。将所有的中间结果落盘一次，这个大量的磁盘刷写还有网络传输是非常耗时的，Spark的解决方案其实就出来了，所有的操作全在内存里进行，没有了磁盘的刷写，效率要高很多倍，Spark把它处理的数据集叫RD。把计算的逻辑抽象成了算子。整个的计算过程其实就是输入数据，执行filter的算子、map算子、count汇总算子，把这个结果数据输出。
Spark获得成功之后AMP实验室没有停止脚步，也开始选择另一个方向进行突破，就是实时计算。
（13）2013年发布了Spark streaming，AMP实验室认为流式数据其实是连续的批数据，因此认定流是批的特例。
①流式数据计算
流式数据的计算就是将连续不断的批数据进行持续的批计算。
②对比发展
Spark streaming输入的数据流，它是以时间为单位来进行拆分的。如果把数据切成足够小的部分，就是实时的
如果它的流计算根据时间为单位，这个时间片它有四条数据。就将四条数据再切一下。按照时间片再切一下。这一批就剩两条数据，这两条数据进行批处理。下两道数据也是进行批处理，这样连续的这小批处理，它就构成了一个流处理，虽认为这个是流处理，但是严格意义上，Spark streaming其实是VP处理，这个设计给Spark streaming带来了非常优秀的特效。它比storm更高的吞吐量，它不是一条一条，而是几条几条的处理，失败恢复也非常快。因为都是小批的计算，失败了再起一个就好。并且他与Spark的数据逻辑几乎一样，数据工作者只需搞定一套ETL的逻辑，就能够同时跑批和流的计算，而Spark加上Spark streaming的组合也成为了当时几年的业界的主流。就在所有人都认为Spark加上Spark streaming是数大据计算最佳实践的时候，Apache也没有停止脚步。与AMP实验室的流式批的特点不一样，他对流式数据的认知正好反了过来，认为批是流的特点。
（14）2014年，Flink开源，并且同年成为Apache的一个顶级项目。
①Flink
基于批是流的特例的认知，Flink它是类似于storm，它也是数据来一条，就处理一条。真正的实现了流式数据处理
②Flink优点
这种处理模式storm一样，它可以拥有极低的延迟，并且，flink支持事件投递，保证只有一次，不多也不少，数据的准确性也得到了提升，相比storm，flink的吞吐量更高，延迟更低，对些流式计算的一些过程、算法、架构做了一些优化。flink比storm的存储更高，延迟更低，准确性也得到了保障，比起Spark streaming，flink是真正意义上的实时计算，并且flink也是支持批处理的，关键flink还是非常还非常简单和易用，所以flink一经推缩就受关注。
（15）阿里云E-MapReduce是在2016年正式的商业化，后面会给详细的介绍一下。
4.大数据技术发展过程
1997年，Doug Cutting开发出了Lucene
1998年大数据作为一个专用名词出现在了公共的期刊上
2002年，Cutting将基于Lucene开发出了Nutch，随着时间的推移数据越来越多，Google为了面临搜索数据不断增多的问题，重新设计了数据存储和计算系统。
2003年，Google发布了一篇技术论文GFS，同年，cutting基于Google的论文，在Nutch搜索引擎上实现了分布式文件系统，命名为NDFS。
2004年Google又发表了一个技术学术论文，介绍他自己的MapReduce模型
2005年Cutting又基于Google发表的论文，在Nutch上实现了。06年cutting将NDFS和MapReduce进行了升级改造，重新命名为Hadoop，从此开启了Hadoop的时代。但是mapreduce使用起来是非常繁琐的，开发出了一个新的系统pig，pig是一个基于Mapreduce，它的语法是一个类似SQL的脚本语言，经过编译后，它会直接生成mapreduce程序，只了解picg的语法，不用了解Java也可以用mapreduce进行计算，但是对于熟悉关系型数据库的开发人员或者是数据分析师，使用pig还是不太方便，于是hive出现了，hive能用SQL直接进行数据计算。
2010年ES被开发出来。ES使得搜索引擎使用起来更加的方便。mapreduce存在的两个问题，第一个是使用繁琐，hive解决了这个问题，第二个问题是mapreduce执行慢。对于数据延迟低的场景，mapreduce没有办法支持，这个时候出现了两个研究方向，实时计算和更高效的批量计算。
实时计算方面，2011年出现了storm ，storm可以一条数据一条数据的处理。
2012年另一个方向更高效的批量计算它发展出的Spark。Spark计算的中间数据不在落盘，在内存里进行效率提高了很多
随后实验室2013年又开发出了实时计算Spark streaming。有了storm，为什还要耗费精力开发Spark streaming？storm虽然它是实时的，但是它的存储量是个问题，并且它不能保证只投递一次，数据准确性没有办法保证，而Spark streaming它会将流数据圈成足够小的批。延续的非常小的P就是流了，这样就是Spark streaming的存储量很高，并且失败重新运行就好了，反正P很小运行起来也很快，但是Spark streaming也存在问题，Spark streaming其实是VP处理，它不是流处理，所以它的延迟还达不到像storm那么快。
2014年flink出现了，flink支持四件投递，保证只有一次，不多也不少，这样的数据的准确性得到提升，比起storm，Flink的吞吐量更高，延迟更低，准确性也比较好，比起Spark streaming，flink是真正意义的实时计算，并且Flink也是支持批处理。
最后一个是2016年商业化的EMR。
四、EMR 产品介绍
通过EMR产品简介、EMR产品架构、EMR应用场景、EMR产品优势、EMR与开源Hadoop对比、EMR基本概念、EMR运维功能介绍、EMR开发功能介绍8部分，了解EMR是什么，产品架构是什么、常见的使用场景，产品优势，与Hadoop集群的对比、基本概念以及运维和开发功能，重点理解EMR是什么，基本概念。
1.EMR 产品简介
（1）EMR
开源大数据开发平台E-MapReduce (简称EMR)是运行在阿里云平台上的一种大数据处理的系统解决方案。EMR构建于云服务器ECS或者容器服务ACK之上，EMR的集成节点可以选择云服务器ECS，也可以选择容器服务。基于开源的Apache Hadoop和Apache Spark，可以方便地使用Hadoop和Spark生态系统中的其他周边系统分析和处理数据。刚刚讲的些技术，还有包括Hadoop和Spark一些周边的数据技术，都可以在EMR上很方便的创建和使用。EMR还可以与阿里云其他的云数据存储系统和数据库系统进行数据传输。比如阿里云的对象存储oss，还有阿里云的rds。
2.EMR 产品架构
能更直观的了解EMR的产品组成，产品架构一共分为六层
（1）计算资源
主要就是一层的ECS/神龙
（2）调度管理
主要就是YARN和ACK。
（3）数据集成
就是开源的Sqoop、dataX、logstash，阿里云的有dataWorks数据集成，SLS、DTS、data
（4）数据存储层
包括HDFS，OSS
（5）计算引擎
包括hive、Spark、flink，HBase、clickhouse
（6）数据应用平台管理
开源Oozie/Azkaban，还有阿里云的dataworks产品，dataworks产品。
现在的EMR的数据开发功能，全部都建议或者是推荐使用dataWorks产品，在dataworks产品上进行EMR的作业开发的操作也可以通过上图看出，这些组件或者是服务它有四类。
四类组件
①开源的产品
比如阿里云页集成的这个Apache社区的开源的组件，比如Hadoop、scoop都是开源的
②阿里云产品
比如OSS，DataWorrks、SLS。
③基于开源优化的、EMR基于开源社区版本的组件
增强了它的性能还有功能，例如Spark中增加了这个Spark streaming SQL性能角，并且它的性能也较开源的版本有了大幅的提升。
④阿里云的自研组件
为了让开源的大数据组件和服务更好的运行在阿里云的技术设施上，EMR也自研了一些组件，例如shuffeservice。shuffeservice是EMR在优化计算引擎的shuffe操作上推出的一个扩展组件。
3.EMR 应用处理场景
EMR本质就是Hadoop或者是Spark集群，就完全可以将使用的ECS主机或者ACK视作是一个物理机。
（1）批量数据处理
EMR将ecs还有这个oss上的海量日志同步到EMR的数据节点，使用mapreduce、hive、Spark等主流的框架对这些数据进行分析处理，还可以使用scoop等工具，将rds，MYSQL，space、max compute中的数据同步到这个EMR上，进行统一的数据分析和处理。可以把这些处理后的数据再同步回rds，为数据可视化等应用提供数据支撑。
（2）Ad hoc数据分析查询
ad ho又称为计时查询，是用户根据自己的需求，灵活的选择查询条件，系统能根据用户的选择生成相应的搜狗和数据报表。EMR可以将海量数据通过导入或者是外表的形式。将oss、MaxCompute、MYSQL等数据源的数据同步到阿里云的一个OLEP的分析引擎里，例如同步到clickhouse等。它可以提供高效、实时和灵活的数据分析能力，能够满足用户画像，还有BI报表以及业务分析等一系列的业务场景。
（3）海量数据在线服务
EMR基于web和移动应用程序等生成的PB级别的结构化、半结构化，还有非结构化的数据，通过Hbase进行在线分析以方便web应用或者是数据可视化产品快速的获取分析结果，进行处理或者是实时的一个展示。
（4）流式数据处理
通过Spark streaming、storm、Flink，使用来自阿里云的日志服务或者是消息中间件，或者是消息服务或者是开源的、自建的Flume、Kafka这些数据流入到实时数据，将相应的处理结果可以写入到这个阿里云的对象存储，写入到Hbase，写入到其他的目的数据源中。
4.EMR 的产品优势
（1）前期准备
为什么要选择EMR产品，而不是在本地自己搭建集群？如果要在本地搭建一个Hadoop集群，流程首先要对自己的业务进行调研，评估业务特点，选择机器类型，第三步去采购机器，第四步准备机房这些硬件的环境，第五步为购买的服务器安装操作系统，第六步是部署Hadoop，Spark这些服务组件。第七步启动集群
（2）用户应用逻辑相关
第八步开始编写应用程序，第九步运行这个作业，第十步获取到数据。
（3）举例说明
在这个使用流程中，真正跟应用逻辑相关的是步骤八到十，而步骤一到七都是前期的准备工作，但是这些准备工作非常繁琐，EMR提供了集群的管理工具的一些集成的解决方案，例如主机选型、环境部署、集群搭建、集群配置、集群管理、性能监控，包括日志的采集和分析等功能，通过EMR可以从繁琐的集群构建的相关采购、准备和运维这些工作中释放出去。自己只关心应用程序的处理逻辑就行，并且EMR还提供了灵活的搭配的着方式，可以根据自己的业务特点去选择不同的信息服务。例如如果需求是对数据进行日常的统计，还有简单的批量运算。可以选择EMR中安装Hadoop服务，如果有流式计算和实时计算的需求，可以选择运行安装Flink服务。
