开发者学堂课程【企业运维训练营之大数据 EMR 原理与实践：视频-《E-MapReduce 组件介绍》】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1242/detail/18443
视频-《E-MapReduce 组件介绍》
3.Hue
像上面这个图所示的这个界面，最左端可以看到我们可以配置不同的数据源，其实这个这个功能大家应该都比较了解这块的话就跟我们的地位一样，我创建数据库A数据库B，然后通过不同的连接串，那这个其实也是一样的，它支持的数据库其实也是比较多的。这块儿其实ha也是基于一些JDBC或者是一些Python的引擎，它其实是可以兼容类似于我们现在讲的这种Have，然后我们之后会讲的spark crystal。这种大数据的计算引擎，它也兼容传统的数据库就想买Circle，然后post gre sql或者是像led的耳扣的图都是这种传统的关系型数仓都是可以的。
看完左边的话就去看一下中间的这一部分中间的这一部分的话，其实我们也比较就比较熟悉她的一个搜狗的编辑是在这个部分的可以做一个查询语句的编辑窗口，这块也会涉及所在丝杆落下，我们要查某个表他也会有一些提示，某些字段他也会有一些提示。同时它也支持一些高亮，下边这半部分的话其实就是包括几部分，我们挨个说一下，首先就是历史查询。历史查询是我们比较重要的一块，因为他其实会保存我们的以及一些保存的查询，然后以及当前查询的结果图表模块等。那最主要的就是我们在执行SQL语句的时候日志会展示在这里。比如说我如果SQL中写的，有一些语法错误的话，那其实我们在点执行的时候，他的报错会返回到这里或者是比如说我们刚才所讲的hive，在Have上，就像我这样在Have上输入一个Circle。那如果我这个写的不对的话，它会报错那，如果他写的对了的话，那它转化成map reduce之后，map和Reduce执行的一个百分比的一个执行情况，或者日志都可以在这一部分进行查看就是下边这一部分那在右侧的话，其实这个也比较好理解就是我们现在比如说我这个Employee的这个表儿它其实包括了什么呢，它包括了一个ID主键，然后这个员工的一个名称，然后它的一个Salary是多少，那他会有相对应的这个字段的类型，然后帮助你去比如说我现在要使用函数，那我肯定是要根据这个类型来看使用什么函数的，这块其实就是所说的这个第一个功能。
big data sys的这么一个表，这块建了一个内部表，然后给他指直接指定到了这个岗培训的目录下，然后这个目录下存的就是我刚才从本地上传的临时随机的一个数据，那这块的话我们可以看到它，其实我就是随便起了一些名字，然后最后几个是比较重要的，那我们其实说比如他的省、他的市，我随便创建了两个Begins的uv跟PV这块儿可能是在我们一些访问的数据，可以看到编辑了创建表的语句，当然这个我执行过了，不然大家肯定是看不到这个表在刚才的那个里边，这块可以看到我对这张表做了一个查询，我要看每个省市它一共有多少条记录，同时它的某一个字段加起来有多少，我们这边也执行看一下，这块跟后端看到的日志是比较相似的。
整个的sum和Count计算，一共是一个job。还有这块儿可能稍微慢点儿，这上面的话有它的计时。我们可以看到就是整个阶段的话，我们大概是花了24秒的时间，这个日志是显示他已经就是OK了，然后我们可以看一下这个结果这边大概是多少条数据30多条，按照省的这个维度，我们去进行了他的一个Count数和它的一个sum数就是做了一个简单的计算，这个其实没有实际意义。就是简单的做了一个测试，然后我们去看这个可视化界面去发送这个C口请求的一个样例，那这块的话我们也可以在一些比如说这种刚才所提到的数据库的这种客户端去连接到Have的集群。
这块的话就是之前我们班主任反馈可能同学们对于这个哈尔Soco感兴趣，然后我这边也是简单的做个介绍吧，剩下的一部分就是开发的部分的话可能会在第四讲的时候同学来做一个简单的分享，大概就通过两部分来说，一部分的话可能就是像这种建表，这种建表可以就是Have大家用过的话，可能知道的比较多，建表的时候有两个关键词，我是没有家的这两个关键词可能平时使用的比较广泛，就是我们所说的一个分区表，它的关键词是用Partition，Lost by去指定一个字段作为整个表的一个分区，Lost by其实是我们所说的一个分区跟分统表，比如说我在后边搜索查询的时候去做一个性能优化的一个基本。这块儿的话分区他会是一个怎么体现的呢，那比如说我这一个表现在指定在Location就是这个根目录下的培训文件夹下，这个表是没有分区的。
这个表通过dsa的方式看到这个我们现在这个表是没有分区的，可以看到下边的这些num buckets，比如说这个bucket column既没有分区也没有分统，然后我们也没有对某个字段去做一个排序的存储，可以看到现在这个表的类型，它的一个table type，他是Management的Table，它就是一个内部表，如果是我们在建表的时候指定Internal的话，它就会是一个外部表，这个是刚才的一个字段，这个我们建表时候的字段是一致的，分别就是字段名和它的字段名的类型。
如果两个表都指定了相同统数的一个分统建的话，那他其实会在关联的时候。举个非常简单的例子，比如说一所在的这个文件就会去关就会去关联那个另外一张表一所在的这个文件，他是有一个对应关系的，因为这样的话就可以保证，比如说我一个Matter只处理这部分数据它所有的数据都可以在这个统的一个文件下找到那他的观点就不用去做一个广播，他也是会节省或或者说是会加快我们计算速度的一个小技巧。
说完建表这块就可以说到Soho这块儿那既然刚才说到了这个关联，其实我们会考虑到比如说传统数据库传统的这种关系型数仓用的比较多的话，可能会涉及主键，那我们会都知道用主键关联就是会比非主键关联计算的快，他跑得快，因为他有索引，我们会用额外的空间创建索引来用空间换时间那，但是这个hive这块其实并不是这样，首先他没有主见，然后，其次就是我们就是关联的时候的话，其实并不是要这种比如说我可能会写多个观点，就像这种做完BCD，其实我们会把最后的Filter写到最后我们的VR条件是什么，当然就是Hive他其实比较智能的，它的一种成本，优化器会去帮我们作为私下推，比如说我把B的一个Column去做一个Filter让它等于a，其实他在scan b表的时候会把a的这个提前过滤出来，但是我们在关联的时候尽量不要用这种方式尽量的话，我们能做一些子查询去缩小数据量就去写一个字查询，缩小数据量这样的话对他的计算的速度是有帮助的。
这可能就是跟传统数仓在Circle写法上会有一些不同，这块就简单的介绍这么多，然后如果大家就是有其他问题的话，我们可以线下交流，就是我们一起在群里交流。这块是昨天班主任他们反馈的，根据同学问的问题所反馈的一块内容。
那我们就接着回到我们这个主线上，我们这边就继续因为这边可能刚才讲的稍微有一点多，我们这边加稍微加快一下节奏，其实我们刚才演示了一下这个SUV的可视化界面，刚才也配合了hive出仓的这个能力就是就是可以我们在web上使用Circle去对这种TB或者PB级别的数据去进行这个分布式计算和结果的查询，但是其实我们刚才深度体验之后，刚才可能就体验了一下，大家可能平时如果使用这个比较多的话，大家就会发现，相比于关系型数仓来说，比如说我这500万的数据，那它在分布式框架上计算的确实可以容纳更大体量的数据，但是相对也要耗费更长的时间，而且大多数的数据分析查询的表可能数据量并不是很大，横向比较传统收藏可能会有一个更慢的一个这么一个效果，比如说mysql的一个B加树在2000万以下的一个查询，其实是非常优秀的。这块就会引起了我们一个痛点，它的核心原因是一个C转化到f produce做这个计算框架的时候，他其实为了保证计算任务的一个容错性，它有一个分job的一个平凡的落盘，他若盘读盘根磁盘去做IO，它其实会导致我们这个计算效率是比较低下的那给用户使用上的体感就是我们刚才可能会遇到的这个问题，他就是交互式查询的响应会比较慢。
比如说我们500万的这个数据查了24秒，伴随着这个痛点，那其实就会大家都会比如说这个痛点，我要去解决，那这个痛点怎么解决或者说是否有主见，可以优化这个问题，那可以让我们的这个交互式数据分析更加的丝滑更加的流畅，答案是肯定的，这个就是要引入我们要讲的第四个和第五个组件就是Spark和Crystal的两个组件。那我们就先来说一说这个Spark。
4.Spark
第一个就是刚才所说的从痛点引入的这个组件就是Swap，他为什么快那其实总结起来非常简单，总结起来有两点，第一个就是DAG加内存计算AGD的话，它是有向无环图有向无环图呢，他会配合内存进行计算，以及缓存他会在他会把这个map reduce，这种多照顾的这种任务，他会把它串起来，他的核心的要义就是减少纱布的落盘减少跟磁盘的交互。昨天这部分也有同学提问就是什么时候会入盘，那就Spark其实也会。但是沙漠或者是M的时候，他会落盘，为了保证一个容错性。
第二点的话，它就是资源的申请力度，其实Spark的计算引擎跟这个X它其实是不一样的，那这块的话，一个就是进程跟线程的对比，那其实我们知道启动一个进程的时间，相对于我在一个进程中起一个现成的时间，那其实肯定还是有差距的，这块是一个比较比较主要的一个点，那其实我们从这个就是还就是Have的一个痛点切入Spark，通过Spark circle来切入Spark之后，其实我们也可以去看一下他的一个整体的一个架构，那我们刚才所说的就是spark circle跟这个help circle的一个对比，那其实Spark它的一个就是延伸来讲一下，Spark其实定位是一个通性很强的一个计算引擎，我们可以看到，在这个apache spark计算引擎的底座上，它其实是有四部分的。我们刚才所说的spark circle是一部分，同时也包括了spark streaming的一个流计算，它既支持pi计算也支持流计算。第三部分的话它会有一个machine learning的一个篱笆，他这块的话其实是涉及到机器学习。第四块的话就是我们可能平时用的比较少，这块儿试图计算相关的。它其实基本上可以说是涉猎涉猎了大数据计算的一个比较多的场景。
那这个我们更快的一个资源速度，那其实就是我们刚才所说的就是我们引入的这个Sparks为什么快，它的通用性其实我们刚才从价格的这块儿做了一个解释，那其实它其实涵盖了所有的一个就是大数据计算的一个场景，可以说是那他其实还剩下两个，一个易用性，一个是兼容性。先说这个兼容性，它其实是完全兼容Hadoop生态的他其实就像刚才说的他会利用哈尔的元数据读取HDFS的数据去做一些上层的计算，那一会儿我们也会演示一下这个Spark在Hive中的集成，那这个也是属于兼容性的一部分，然后我们再说这个第二点这个硬性的这一点，最后的这一点，那其实这部分的话，我们其实是对比Java实现麦克斯相对来说的刚才大家可能都觉得这个搜狗比较好实现，去做去实现一些计算，或者是一个迭代的任务，这一部分用Circle是不好不太好写的，那他们在串这些脚本儿的时候，比如说我去做一些机器学习的这种迭代，然后他其实避免不了要在led上就是我们Spark的弹性分布式数据上去做一些比如说像聚合的处理，其实他对于这个在这个场景下他去调用这个高级算子，它就会比从底层从map或者从轨道在网上实现就方便多了，这个是他的易用性的一个特点，对比去体验一下。
这边就是之前在准备的时候做了一个简单的截图就是我们同样是查这个Have的这张表，我们EMR的计算引擎，其实我们最后查完了是24秒，Spark其实只需要大概十四十五秒这块我们出去。快速的看一下，还是刚才这个页面我现在是在Have，然后刚才可以看到这个是我们刚才执行的那个。然后我们也是把这个接口去做一个spark sql的查询。我这边之前也执行过，然后我们去做一个spark sql的查询。可以看到这个景调他现在正在喷顶的一个状态。可以看到这边他的一个就是使用上的体感会相对这个hive来说会好一些，这个数据的结果跟刚才的计算是一样的，那我们刚才易用性还提到了一个就是他的一个完全兼容再回到Have来说。就是还有他，其实之城知识不同的多种不同的一个计算引擎就是它是通过这个参数去进行的控制，就是我们在比如说我们刚才在跑Have的时候，他会告诉已经不不太建议用这个Mapreduce的引擎，他会告诉你，当然它默认的是这个Mapreduce引擎，它会推荐你用tab或者用Spark这边也可以去就是我们可以通过这个方式的设定直接在Have里边儿去调用Spark的执行引擎去进行计算。
如果是Mapreduce引擎他会有一个Warning，我们可以看到这个Have对于Spark的这个兼容它其实也是可以在改变执行引擎之后去做这个同样的一个查询，我们就接下来继续往下看，我们刚才除了Spark之外，我们在解决查询的一个体验不好的这么一个痛点的时候提到的第二块儿就是这个Crystal。这个Crystal现在也有另外一个叫法就是它是Facebook开源的，现在的话改名叫也有叫Chino。就是新版本Chino，他是一种开源式分布式SQL车讯引擎。他的一个特点就是可以快速的完成这种交互式的查询，对于我们分析的这种场景，那从头开始设计的话是针对于任何规模的数据去进行快速分析查询，它是一个典型架构。
5.Presto
他也是典型的Master跟slave or的架构，它是由一个口奥迪特的节点和多个worker来组成的这种主从，我们应该是在大数据领域见得比较多。那同时他的这个Worker跟刚才看HDFS的那个架构图是一样的，它的这个Work也可以横向扩展。
Presto提供了多种的Connector，比如说我们就看一下我下边就是画的这一部分。我们比较熟悉的，就像mysql、Oracle这种关系型数仓，然后到这种比如说red is或者Mango。其实也一定程度上的解决了数据孤岛或者是某些数据未入壶，但是急需查询分析使用的场景。配置一个连接串配置一个用户就可以去做一个关联查询。那在当前的这种数据底座和计算框架的基础上，presto除了可以支持或者是。客户端的交互是请求其实还是有很大的一个上层的建筑的那其实我们可以看到最上面的这一部分呐，其实它广泛地适用于比如说像Q币以及开源的话就Supers或者是sin这两个也是偏于分析的，然后以及jupiter lab这三个都是开源的，然后会去做一些分析的一个场景，那这块的话我们也在app上去进行一下性能对比。
这块是我对于这个机器查询的这个场景在提前做了一个简单的截图，我们可以看到这个左边这个图还是刚才hive截图，那这个prada circle的这块儿执行相当相对恶一样的，这个就是一样的这个查询的话，他其实基基本上是毫秒级返回的。
可以看到是有一点延迟的不是像他这个，这个其实是执行市场执行市场，我们可以看到它的这个计算的返回跟刚才的是一样的，我们可以看提案就是从体验上来看这个基本上就分分钟就是秒出，刚才那个可能就是需要体感上稍微等一段时间，可能有的同学可能会问为什么会有这个差距呢，比如说跟Spark它其实也是有一些差距的那其实这个可以我们做一个简单的比喻，就对于某一个查询来说的话就是Spark虽然说优化了这个大量的楼盘，但是Spark还是需要单独的想，比如说我的资源调度管理器，如果是雅安需要向雅安去申请资源，而Presto则是不用的，其实也是可以担不担去部署这个计算节点集群，他其实Crystal在上做的这种计算差，其实都有查询是共用一套集群资源的且这个资源是已经准备好的。打个比方，就是Spark好比就是在自己家去做饭，Crystal好比就是在餐厅去点菜，那自己做饭往往会在这个比如说买菜上去花一点时间，但是餐厅的话，其实他就是菜已经买好了，准备好了，那我直接就坐你点啥我做啥就完了。这个是这个及查询这一块儿。
这块也是提前配置好了一个mysql的一个数据库，我这边就是简单的做了一个一等于一的笛卡尔积查询跟Have的人名的数据集，我们先来看一下。可以看到这个，这个是我们现在比如说SYF的这个库在这个域名下的一个马赛克的这么一个库里端口3306，我们可以看到它的这个表弟他v province在这里的，然后呢，我们也在Presto的集群后端去配了这个mysql的这么一个库。配成了刚才的那个127结尾的一个mysql。现在看一下就是在这个马斯克里边都有哪些表，我们可以看到，刚才跟DS里边儿是一致的，比如说我们一会要去关联查询的这张表，其他的乱七八糟的表都是之前去做的一些测试，那我们这块儿的话，我们可以看到，刚才这个Test01它其实是在这个海里的那我们可以直接去做这样的查询让他从两个库里查到结果我们可以看到这个一等于一的关联条件会让他出现笛卡尔积的情况。
这四条数据是从刚才我们看到那个Have里边就是Test01里边，这一条数据其实是就是马斯克里边他其实做了一个这种笛卡尔积的关联，这个其实就是一个联邦查询的一个能力。
