大数据之Presto&Druid&Kylin
一：Presto
1、概念
Presto是一个开源的分布式SQL查询引擎， 数据量支持GB到PB字节， 主要用来处理秒级查询的场景。
注意：虽然Presto可以解析SQL， 但它不是一个标准的数据库。 不是MySQL、Oracle的代替品， 也不能用来处理在线事务（OLTP） 。
2、架构
3、Presto优缺点
1） 优点
（1） Presto基于内存运算， 减少了硬盘IO， 计算更快。
（ 2） 能够连接多个数据源， 跨数据源连表查， 如从Hive查询大量网站访问记录， 然后从Mysql中匹配出设备信息。
2） 缺点
Presto能够处理PB级别的海量数据分析， 但Presto并不是把PB级数据都放在内存中计算的。 而是根据场景， 如Count，AVG等聚合运算， 是边读数据边计算， 再清内存， 再读数据再计算， 这种耗的内存并不高。 但是连表查， 就可能产生大量的临时数据， 因此速度会变慢， 反而Hive此时会更擅长。
4、基本概念
catalog：相当于关系型数据库的实例
schema：相当于database
5、角色介绍
coordinator：中心的查询角色 接收查询请求、解析SQL 生成执行计划 任务调度 worker管理coordinator进行是presto集群的master进程。
worker：执行任务的节点
connector：presto以插件形式对数据存储层进行了抽象，它叫做连接器，不仅包含Hadoop相关组件的连接器还包括RDBMS连接器具体访问哪个数据源是通过catalog 中的XXXX.properties文件中connector.name决定的提取数据 负责实际执行查询计划。
discovery service：将coordinator和worker结合在一起服务；worker节点启动后向discovery service服务注册coordinator通过discovery service获取注册的worker节点。
6、优化
1）数据存储
合理设置分区：与 Hive 类似， Presto 会根据元数据信息读取分区数据，合理的分区能减少 Presto 数据读取量，提升查询性能。
使用列式存储：Presto 对 ORC 文件读取做了特定优化，因此在 Hive 中创建 Presto 使用的表时，建议采用 ORC 格式存储。相对于 Parquet， Presto 对 ORC 支持更好。
使用压缩：数据压缩可以减少节点间数据传输对 IO 带宽压力，对于即席查询需要快速解压，建议采用 Snappy 压缩。
2）查询SQL
只选择使用的字段：由于采用列式存储，选择需要的字段可加快字段的读取、减少数据量。避免采用*读取所有字段。
过滤条件必须加上分区字段：对与对分区的表，where语句中优先使用分区字段进行过滤。
Group By语句优化：合理安排 Group by 语句中字段顺序对性能有一定提升。将 Group By 语句中字段按照每个字段 distinct 数据多少进行降序排列。
使用join语句将大表放在左边：Presto 中 join 的默认算法是 broadcast join，即将 join 左边的表分割到多个 worker，然后将 join右边的表数据整个复制一份发送到每个worker 进行计算。如果右边的表数据量太大，则可能会报内存溢出错误。
7、注意事项
1）避免和关键字冲突： MySQL 对字段加反引号`、 Presto 对字段加双引号分割当然， 如果字段名称不是关键字，可以不加这个双引号。
2）时间函数：对于 Timestamp，需要进行比较的时候，需要添加 Timestamp 关键字，而 MySQL 中对Timestamp 可以直接进行比较。
3）不支持insert overwrite 语法，只能先 delete，然后 insert into。
4）Presto 目前支持 Parquet 格式，支持查询，但不支持 insert
二：Druid
1、简介
Apache Druid 是一个实时分析数据库，旨在对大型数据集进行快速的切片和切分分析（“ OLAP ”查询） 。 Druid 最常用作数据库，以支持对实时摄取，快速查询性能和高正常运行时间很重要的用例。 因此， Druid 通常用于为分析应用程序的 GUI，或用作需要快速聚合的高并发 API 的后端。 Druid 最适合面向事件的数据。
Druid 的常见应用领域包括：
⚫ 点击流分析（网络和移动分析）
⚫ 网络遥测分析（网络性能监控）
⚫ 服务器指标存储
⚫ 供应链分析（制造指标）
⚫ 应用程序性能指标
⚫ 数字营销/广告分析
⚫ 商业智能/ OLAP
2、概念
Druid是一个快速的列式分布式的支持实时分析的数据存储系统。 它在处理PB级数据、 毫秒级查询、 数据实时处理方面， 比传统的OLAP系统有了显著的性能改进。
注意： 阿里巴巴也曾创建过一个开源项目叫作Druid（简称阿里Druid） ， 它是一个数据库连接池的项目。 阿里Druid和本文讨论的Druid没有任何关系， 它们解决完全不同的问题。
3、特点
Druid特点
1） 列式存储格式。 Druid使用面向列的存储， 它只需要加载特定查询所需要的列。 查询速度迅速快。
2） 可扩展的分布式系统。 Druid通常部署在数十到数百台服务器的集群中， 并且提供数百万条/秒的摄取率， 保留数百万条记录， 以及亚秒级到几秒钟的查询延迟。
3） 大规模的并行处理。 Druid可以在整个集群中进行大规模的并行查询。
4） 实时或批量摄取。 Druid可以实时摄取数据（ 实时获取的数据可立即用于查询） 或批量处理数据。
5） 自愈， 自平衡， 易操作。 集群扩展和缩小， 只需添加或删除服务器， 集群将在后台自动重新平衡，无需任何停机时间。
6） 数据进行了有效的预聚合或预计算， 查询速度快。
7） 数据的结果应用了Bitmap压缩算法。
4、应用场景
1） 适用于清洗好的记录实时录入， 但不需要更新操作
2） 适用于支持宽表， 不用Join的方式（换句话说就是一张单表）
3） 适用于可以总结出基础的统计指标， 用一个字段表示
4） 适用于实时性要求高的场景
5） 适用于对数据质量的敏感度不高的场景
5、框架原理
6、数据结构
与 Druid 架构相辅相成的是其基于 DataSource 与 Segment 的数据结构，它们共同成就了 Druid 的高性能优势。
三：Kylin
1、概念
Apache Kylin™是用于大数据的开源分布式分析数据仓库；它旨在提供大数据时代的OLAP（在线分析处理）功能。通过在Hadoop和Spark上革新多维多维数据集和预计算技术，无论数据量如何增长，Kylin都能实现近乎恒定的查询速度。Kylin将查询延迟从几分钟减少到亚秒级，将在线分析重新带回大数据。
Apache Kylin™使您可以分三步以亚秒级的延迟查询数十亿行。
-
确定Hadoop上的星型/雪花模式。
-
2从已识别的表中构建多维数据集。
-
3使用ANSI-SQL查询并通过ODBC，JDBC或RESTful API在不到一秒的时间内获得结果。
Apache Kylin™还可以与您喜欢的BI工具（如Tableau和PowerBI等）集成，以在Hadoop上启用BI。
2、OLAP（数据分析的目标则是探索并挖掘数据价值，作为企业高层进行决策的参考，通常被称为OLAP（On-Line Analytical Processing，联机分析处理））的实现方式：
- ROLAP:
基于关系数据库的OLAP实现（Relational OLAP）。ROLAP将多维数据库的多维结构划分为两类表:一类是事实表,用来存储数据和维关键字;另一类是维表,即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。维表和事实表通过主关键字和外关键字联系在一起,形成了"星型模式"。对于层次复杂的维,为避免冗余数据占用过大的存储空间,可以使用多个表来描述,这种星型模式的扩展称为"雪花模式"。特点是将细节数据保留在关系型数据库的事实表中，聚合后的数据也保存在关系型的数据库中。这种方式查询效率最低，不推荐使用。
- MOLAP:
多维数据组织的OLAP实现（Multidimensional OLAP。以多维数据组织方式为核心,也就是说,MOLAP使用多维数组存储数据。多维数据在存储中将形成"立方块（Cube）“的结构,在MOLAP中对"立方块"的"旋转”、“切块”、"切片"是产生多维数据报表的主要技术。特点是将细节数据和聚合后的数据均保存在cube中，所以以空间换效率，查询时效率高，但生成cube时需要大量的时间和空间。
- HOLAP:
基于混合数据组织的OLAP实现（Hybrid OLAP）。如低层是关系型的，高层是多维矩阵型的。这种方式具有更好的灵活性。特点是将细节数据保留在关系型数据库的事实表中，但是聚合后的数据保存在cube中,聚合时需要比ROLAP更多的时间,查询效率比ROLAP高，但低于MOLAP。 kylin的cube数据是作为key-value结构存储在hbase中的，key是每一个维度成员的组合值，不同的cuboid下面的key的结构是不一样的，例如cuboid={brand，product，year}下面的一个key可能是brand=‘Nike’，product=‘shoe’，year=2015，那么这个key就可以写成Nike:2015，但是如果使用这种方式的话会出现很多重复，所以一般情况下我们会把一个维度下的所有成员取出来，然后保存在一个数组里面，使用数组的下标组合成为一个key，这样可以大大节省key的存储空间，kylin也使用了相同的方法，只不过使用了字典树（Trie树），每一个维度的字典树作为cube的元数据以二进制的方式存储在hbase中，内存中也会一直保持一份。
kylin是一个MOLAP系统，通过预计算的方式缓存了所有 需要查询的的数据结果，需要大量的存储空间（原数据量的10+倍）。一般我们要分析的数据可能存储在关系数据库、HDFS上数据、文本文件、excel 等。kylin主要是对hive中的数据进行预计算，利用hadoop的mapreduce框架实现
2、框架架构
3、组件介绍
核心引擎：
Kylin OLAP引擎的基本框架包括运行整个堆栈的元数据引擎，查询引擎，作业引擎和存储引擎。它还包括一个REST Server，可满足客户端请求。
REST Server
REST Server是一套面向应用程序开发的入口点。此类应用程序可以提供查询、获取结果、触发cube构建任务、获取元数据以及用户权限等等。另外可以通过Restful借口实现SQL查询。
查询引擎（Query Engine）
当cube准备就绪后，查询引擎能够获取并解析用户查询。他随后会与系统中的其他组件进行交互，从而向用户返回对应的结果。
Routing
负责将解析SQL生成的执行计划转换成cube缓存查询，cube是通过预计算缓存在hbase中。
元数据管理工具
Kylin是一款元数据驱动型应用程序。元数据管理工具十一大关键性组件，用于对保存在Kylin当中的所有元数据进行管理，其中包括最为重要的cube元数据。其他全部组件的正常运作都需以元数据管理工具为基础。Kylin的元数据存储在Hbase中。
任务引擎（Cube Build Engine）
这套引擎的设计目的在于处理所有离线任务，其中包括shell脚本、Java API以及MapReduce任务等等。任务引擎对Kylin当中的全部任务加以管理与协调，从而确保每一项任务都能得到切实执行并解决其间出现的故障。
组件的正常运作都需以元数据管理工具为基础。Kylin的元数据存储在Hbase中。
任务引擎（Cube Build Engine）
这套引擎的设计目的在于处理所有离线任务，其中包括shell脚本、Java API以及MapReduce任务等等。任务引擎对Kylin当中的全部任务加以管理与协调，从而确保每一项任务都能得到切实执行并解决其间出现的故障。
1459
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
