无水印视频素材下载免费网站,设计网站公司选泽y湖南岚鸿询 问,如何选择合适的建站公司,wordpress 引用js怎么理解即席查询 即席查询#xff08;Ad Hoc#xff09;是用户根据自己的需求#xff0c;灵活的选择查询条件#xff0c;系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的#xff0c;而即席查询是由用户自定义查…怎么理解即席查询 即席查询Ad Hoc是用户根据自己的需求灵活的选择查询条件系统能够根据用户的选择生成相应的统计报表。即席查询与普通应用查询最大的不同是普通的应用查询是定制开发的而即席查询是由用户自定义查询条件的。 即席查询与批处理的区别 批处理 在数据仓库系统中根据应用程序的需求需要对源数据进行加工这些加工过程往往是固定的处理原则这种情况下可以把数据的增删改查SQL语句写成一个批处理脚本由调度程序定时执行。 特点由于批处理脚本中的SQL语句是固定的所以可以提前完成SQL语句的调优工作使得批处理脚本的运行效率达到最佳。 即席查询 通常的方式是将数据仓库中的维度表和事实表映射到语义层用户可以通过语义层选择表建立表间的关联最终生成SQL语句。即席查询是用户在使用时临时生产的系统无法预先优化这些查询所以即席查询也是评估数据仓库的一个重要指标。在一个数据仓库系统中即席查询使用的越多对数据仓库的要求就越高对数据模型的对称性的要求也越高。 现在市场上运用更多的是Kylin、Druid、Presto、Impala等等这些框架去诠释大数据即席查询的功能。 此篇就来介绍四种框架的优缺点用途与场景选择。 Kylin Kylin特点 Kylin的主要特点包括支持SQL接口、支持超大规模数据集、亚秒级响应、可伸缩性、高吞吐率、BI工具集成等。 标准SQL接口Kylin是以标准的SQL作为对外服务的接口。支持超大数据集Kylin对于大数据的支撑能力可能是目前所有技术中最为领先的。早在2015年eBay的生产环境中就能支持百亿记录的秒级查询之后在移动的应用场景中又有了千亿记录秒级查询的案例。亚秒级响应Kylin拥有优异的查询相应速度这点得益于预计算很多复杂的计算比如连接、聚合在离线的预计算过程中就已经完成这大大降低了查询时刻所需的计算量提高了响应速度。可伸缩性和高吞吐率单节点Kylin可实现每秒70个查询还可以搭建Kylin的集群。BI工具集成 ODBC与Tableau、Excel、PowerBI等工具集成JDBC与Saiku、BIRT等Java工具集成RestAPI与JavaScript、Web网页集成Kylin开发团队还贡献了Zepplin的插件也可以使用Zepplin来访问Kylin服务。 Kylin工作原理 Apache Kylin的工作原理本质上是MOLAPMultidimension On-Line Analysis ProcessingCube也就是多维立方体分析。在这里需要分清楚两个概念 维度和度量 维度即观察数据的角度。比如员工数据可以从性别角度来分析也可以更加细化从入职时间或者地区的维度来观察。维度是一组离散的值比如说性别中的男和女或者时间维度上的每一个独立的日期。因此在统计时可以将维度值相同的记录聚合在一起然后应用聚合函数做累加、平均、最大和最小值等聚合计算。 度量即被聚合观察的统计值也就是聚合运算的结果。比如说员工数据中不同性别员工的人数又或者说在同一年入职的员工有多少。 Cube和Cuboid 有了维度跟度量一个数据表或者数据模型上的所有字段就可以分类了它们要么是维度要么是度量可以被聚合。于是就有了根据维度和度量做预计算的Cube理论。 给定一个数据模型我们可以对其上的所有维度进行聚合对于N个维度来说组合的所有可能性共有2n种。对于每一种维度的组合将度量值做聚合计算然后将结果保存为一个物化视图称为Cuboid。所有维度组合的Cuboid作为一个整体称为Cube 下面举一个简单的例子说明假设有一个电商的销售数据集其中维度包括 时间[time]、商品[item]、地区[location]和供应商[supplier] 度量为销售额。那么所有维度的组合就有16种如下图所示 一维度1D的组合有4种[time]、[item]、[location]和[supplier]4种 二维度2D的组合有6种[time, item]、[time, location]、[time, supplier]、[item, location]、[item, supplier]、[location, supplier] 三维度3D的组合也有4种 最后还有零维度0D和四维度4D各有一种总共16种 核心算法 Kylin的工作原理就是对数据模型做Cube预计算并利用计算的结果加速查询 指定数据模型定义维度和度量预计算Cube计算所有Cuboid并保存为物化视图 预计算过程是Kylin从Hive中读取原始数据按照我们选定的维度进行计算并将结果集保存到Hbase中默认的计算引擎为MapReduce可以选择Spark作为计算引擎。一次build的结果我们称为一个Segment。构建过程中会涉及多个Cuboid的创建具体创建过程由kylin.cube.algorithm参数决定参数值可选 autolayer 和 inmem 默认值为 auto即 Kylin 会通过采集数据动态地选择一个算法 (layer or inmem)如果用户很了解 Kylin 和自身的数据、集群可以直接设置喜欢的算法。执行查询读取Cuboid运行产生查询结果 逐层构建算法layer) 一个N维的Cube是由1个N维子立方体、N个(N-1)维子立方体、N*(N-1)/2个(N-2)维子立方体、......、N个1维子立方体和1个0维子立方体构成总共有2^N个子立方体组成在逐层算法中按维度数逐层减少来计算每个层级的计算除了第一层它是从原始数据聚合而来是基于它上一层级的结果来计算的。比如[Group by A, B]的结果可以基于[Group by A, B, C]的结果通过去掉C后聚合得来的这样可以减少重复计算当 0维度Cuboid计算出来的时候整个Cube的计算也就完成了。 每一轮的计算都是一个MapReduce任务且串行执行一个N维的Cube至少需要N次MapReduce Job。 算法优点 此算法充分利用了MapReduce的能力处理了中间复杂的排序和洗牌工作故而算法代码清晰简单易于维护受益于Hadoop的日趋成熟此算法对集群要求低运行稳定在内部维护Kylin的过程中很少遇到在这几步出错的情况即便是在Hadoop集群比较繁忙的时候任务也能完成。 算法缺点当Cube有比较多维度的时候所需要的MapReduce任务也相应增加由于Hadoop的任务调度需要耗费额外资源特别是集群较庞大的时候反复递交任务造成的额外开销会相当可观由于Mapper不做预聚合此算法会对Hadoop MapReduce输出较多数据; 虽然已经使用了Combiner来减少从Mapper端到Reducer端的数据传输所有数据依然需要通过Hadoop MapReduce来排序和组合才能被聚合无形之中增加了集群的压力;对HDFS的读写操作较多由于每一层计算的输出会用做下一层计算的输入这些Key-Value需要写到HDFS上当所有计算都完成后Kylin还需要额外的一轮任务将这些文件转成HBase的HFile格式以导入到HBase中去 总体而言该算法的效率较低尤其是当Cube维度数较大的时候。 快速构建算法inmem 也被称作“逐段”(By Segment) 或“逐块”(By Split) 算法从1.5.x开始引入该算法利用Mapper端计算先完成大部分聚合再将聚合后的结果交给Reducer从而降低对网络瓶颈的压力。该算法的主要思想是对Mapper所分配的数据块将它计算成一个完整的小Cube 段包含所有Cuboid每个Mapper将计算完的Cube段输出给Reducer做合并生成大Cube 与之前算法相比快速算法主要有两点不同 Mapper会利用内存做预聚合算出所有组合Mapper输出的每个Key都是不同的这样会减少输出到Hadoop MapReduce的数据量Combiner也不再需要一轮MapReduce便会完成所有层次的计算减少Hadoop任务的调配。 Kylin总结 Kylin的优点 写SQL查询,结果预聚合.有可视化页面 什么场景用Kylin 查询数据后想要立马可视化的 Kylin的缺点 集群依赖较多如HBase和Hive等属于重量级方案因此运维成本也较高。查询的维度组合数量需要提前确定好不适合即席查询分析预计算量大资源消耗多 什么时候不可以用Kylin 查询维度过多 Impala 什么是Impala Cloudera公司推出提供对HDFS、Hbase数据的高性能、低延迟的交互式SQL查询功能。 基于Hive使用内存计算兼顾数据仓库、具有实时、批处理、多并发等优点。 是CDH平台首选的PB级大数据实时查询分析引擎。 Impala为什么快 查询引擎都会分为Frontend和Backend两部分Frontend主要用于进行SQL的语法分析、词法分析、逻辑优化等Backend则偏向底层做物理优化。 Frontend Frontend主要负责解析编译SQL生成后端可以执行的查询计划。 SQL的查询编译器是个标准的流程SQL解析语法分析查询计划/优化。impala的查询分析器会把标准的SQL解析成一个解析树里面包含所有的查询信息比如表、字段、表达式等等。一个可执行的执行计划通常包含两部分单点的查询计划Single Node Planning 和 分布式并发查询计划 parallelization \ fragmentation。 在第一个阶段语法解析树会被翻译成一个单点的不可以直接执行的树形结构一般会包含HDFS\HBase scan, hash join, cross join, union, hash agg, sort, top-n, analytic eval等。这一步主要负责基于最下层的查询节点、谓词下推、限制查询数量、join优化等优化查询性能。主要是依赖于表或者分区的统计信息进行代价评估。 第二个阶段就是基于第一个阶段优化后的单点执行计划生成分布式的执行计划并尽量满足最小化数据移动以及最大化数据本地性。分布式执行主要通过在节点间增加数据交换节点或者直接移动少量的数据在本地进行聚合。目前支持的join策略有broadcast和partition两种。前者是把join的整个表广播到各个节点后者是基于hash重新分区使得两部分数据到同一个节点。Impala通过衡量哪一种网络传输压力小耗费的资源少就选哪种. 所有的聚合操作都是在本地进行预聚合然后再通过网络传输做最终的聚合。对于分组聚合会先基于分区表达式进行的预聚合然后通过并行的网络传输在各个节点进行每一部分的聚合。对于非分组的聚合最后一步是在单独的节点上进行。排序和TOPN的模式差不多都是现在单独的节点进行排序/topN然后汇总到一个节点做最后的汇总。最后根据是否需要数据交换为边界切分整个执行计划树相同节点的执行计划组成一个fragment。 Backend impala的backend接收到fragment后在本地执行它的设计采取了很多硬件上的特点backend底层是用C编写使用了很多运行时代码生成的技术对比java来说减轻内存的压力。 impala的查询设计思路也是按照volcano风格设计处理的时候是getNext一批一批处理的。大部分的命令都是管道形式处理的因此会消耗大量的数据存储中间数据。当执行的时候如果内存超出使用的范围也可以把结果缓存到磁盘经常有溢出可能的有如hash join, agg, sorting等操作。 运行时代码生成:impala内部使用了LLVM的机制性能提升5倍。LLVM是一套与编译器相关的库与传统的编译器不同它更注重模块化与重用性。允许impala应用在运行时进行即时编译以及代码生成。运行时代码生成通常用于内部处理比如用于解析文件格式的代码对于扫描一些大表这点尤为重要 总结几点就是 真正的MPP大规模并行处理查询引擎。使用C开发而不是Java降低运行负荷。运行时代码生成LLVM IR提高效率。全新的执行引擎不是Mapreduce。在执行SQL语句的时候Impala不会把中间数据写入到磁盘而是在内存中完成了所有的处理。使用Impala的时候查询任务会马上执行而不是生产Mapreduce任务这会节约大量的初始化时间。Impala查询计划解析器使用更智能的算法在多节点上分布式执行各个查询步骤同时避免了sorting和shuffle这两个非常耗时的阶段这两个阶段往往是不需要的。Impala拥有HDFS上面各个data block的信息当它处理查询的时候能够在各个datanode上面更均衡的分发查询。 Impala总结 Impala优点 基于内存运算不需要把中间结果写入磁盘省掉了大量的I/O开销。无需转换为Mapreduce直接访问存储在HDFSHBase中的数据进行作业调度速度快。使用了支持Data locality的I/O调度机制尽可能地将数据和计算分配在同一台机器上进行减少了网络开销。支持各种文件格式如TEXTFILE 、SEQUENCEFILE 、RCFile、Parquet。可以访问hive的metastore对hive数据直接做数据分析。 Impala缺点 对内存的依赖大且完全依赖于hive。实践中分区超过1万性能严重下降。只能读取文本文件而不能直接读取自定义二进制文件。 每当新的记录/文件被添加到HDFS中的数据目录时该表需要被刷新 Presto 什么是Presto Presto是一个facebook开源的分布式SQL查询引擎适用于交互式分析查询数据量支持GB到PB字节。presto的架构由关系型数据库的架构演化而来。presto之所以能在各个内存计算型数据库中脱颖而出在于以下几点 清晰的架构是一个能够独立运行的系统不依赖于任何其他外部系统。例如调度presto自身提供了对集群的监控可以根据监控信息完成调度。简单的数据结构列式存储逻辑行大部分数据都可以轻易的转化成presto所需要的这种数据结构。丰富的插件接口完美对接外部存储系统或者添加自定义的函数。 Presto的执行过程 Presto包含三类角色coordinator,discovery,worker。coordinator负责query的解析和调度。discovery负责集群的心跳和角色管理。worker负责执行计算。 presto-cli提交的查询实际上是一个http POST请求。查询请求发送到coordinator后经过词法解析和语法解析生成抽象语法树描述查询的执行。 执行计划编译器会根据抽象语法树层层展开把语法树所表示的结构转化成由单个操作所组成的树状的执行结构称为逻辑执行计划。 原始的逻辑执行计划直接表示用户所期望的操作未必是性能最优的在经过一系列性能优化和转写以及分布式处理后形成最终的逻辑执行计划。这时的逻辑执行计划已经包含了map-reduce操作以及跨机器传输中间计算结果操作。 scheduler从数据的meta上获取数据的分布构造split配合逻辑执行计划把对应的执行计划调度到对应的worker上。 在worker上逻辑执行计划生成物理执行计划根据逻辑执行计划会生成执行的字节码以及operator列表。operator交由执行驱动来完成计算。 Presto总结 优点 Presto与Hive对比都能够处理PB级别的海量数据分析但Presto是基于内存运算减少没必要的硬盘IO所以更快。能够连接多个数据源跨数据源连表查如从Hive查询大量网站访问记录然后从Mysql中匹配出设备信息。部署也比Hive简单因为Hive是基于HDFS的需要先部署HDFS。 缺点 虽然能够处理PB级别的海量数据分析但不是代表Presto把PB级别都放在内存中计算的。而是根据场景如countavg等聚合运算是边读数据边计算再清内存再读数据再计算这种耗的内存并不高。但是连表查就可能产生大量的临时数据因此速度会变慢反而Hive此时会更擅长。为了达到实时查询可能会想到用它直连MySql来操作查询这效率并不会提升瓶颈依然在MySql此时还引入网络瓶颈所以会比原本直接操作数据库要慢。 Druid Druid是什么 Druid是一个专为大型数据集上的高性能切片和OLAP分析而设计的数据存储druid提供低延时的数据插入实时的数据查询。Druid最常用作为GUI分析应用程序提供动力的数据存储或者用作需要快速聚合的高度并发API的后端。 Druid的主要特点 列式存储格式 Druid使用面向列的存储这意味着它只需要加载特定查询所需的精确列。这为仅查看几列的查询提供了巨大的速度提升。此外每列都针对其特定数据类型进行了优化支持快速扫描和聚合。高可用性与高可拓展性 Druid采用分布式、SN(share-nothing)架构管理类节点可配置HA工作节点功能单一不相互依赖这些特性都使得Druid集群在管理、容错、灾备、扩容等方面变得十分简单。Druid通常部署在数十到数百台服务器的集群中并且可以提供数百万条记录/秒的摄取率保留数万亿条记录以及亚秒级到几秒钟的查询延迟。实时或批量摄取 实时流数据分析。区别于传统分析型数据库采用的批量导入数据进行分析的方式Druid提供了实时流数据分析采用LSM(Long structure-merge)-Tree结构使Druid拥有极高的实时写入性能同时实现了实时数据在亚秒级内的可视化。容错恢复极好的架构不会丢失数据 一旦Druid摄取了您的数据副本就会安全地存储在深层存储通常是云存储HDFS或共享文件系统中。即使每个Druid服务器都出现故障您的数据也可以从深层存储中恢复。对于仅影响少数Druid服务器的更有限的故障复制可确保在系统恢复时仍可进行查询。亚秒级的OLAP查询分析 Druid采用了列式存储、倒排索引、位图索引等关键技术能够在亚秒级别内完成海量数据的过滤、聚合以及多维分析等操作。Druid的核心是时间序列把数据按照时间序列分批存储十分适合用于对按时间进行统计分析的场景Druid支持水平扩展查询节点越多、所支持的查询数据量越大、响应越快Druid支持低延时的数据插入数据实时可查不支持行级别的数据更新 Druid为什么快 我们知道Druid能够同时提供对大数据集的实时摄入和高效复杂查询的性能主要原因就是它独到的架构设计和基于Datasource与Segment的数据存储结构。 Druid在数据插入时按照时间序列将数据分为若干segment支持低延时地按照时间序列上卷所以按时间做聚合效率很高Druid数据按列存储每个维度列都建立索引所以按列过滤取值效率很高Druid用以查询的Broker和Historical支持多级缓存每个segment启动一个线程并发执行查询查询支持多Historical内部的线程级并发及Historical之间的进程间并发Broker将各Historical的查询结果做合并 Druid总结什么选择使用 需要交互式聚合和快速探究大量数据时需要实时查询分析时具有大量数据时如每天数亿事件的新增、每天数10T数据的增加对数据尤其是大数据进行实时分析时需要一个高可用、高容错、高性能数据库时。 即席查询总结 Kylin:核心是CubeCube是一种预计算技术基本思路是预先对数据作多维索引查询时只扫描索引而不访问原始数据从而提速。Impala:基于内存计算速度快支持的数据源没有Presto多。Presto:它没有使用Mapreduce大部分场景下比HIVE块一个数量级其中的关键是所有的处理都在内存中完成。Druid:是一个实时处理时序数据的OLAP数据库因为它的索引首先按照时间分片查询的时候也是按照时间线去路由索引。
