presto在点我达的使用

于冬

使用原因:

点我达大数据开发人员、BI同事每天需要使用hive查询各种数据,越来越多的报表业务使用到hive。虽然使用的CDH集群已经部署了impala,但我们大多数的hive表使用了ORC格式,impala对ORC支持不友好。使用presto之前,点我达大数据主要使用hive,走mapreduce来查询相关表。查询效率低。
使用presto初期,运维搭建了3节点的体验环境,通过presto来查询了hive,并体验了简单的sql查询,发现效率很不错。
我们现有的方案无法同时查询历史数据和实时数据,有一次在过需求时,BI提出需要我们大数据解决hive和mysql交互查询的问题。我们大数据团队内部分别使用spark、presto等工具进行了测试,发现presto相对最容易上手。也最适合BI的同事使用,内部商讨后,决定大力推广presto。
我们在hadoop的节点上面搭建了presto集群,配置了1coordinator,3worker。后来随着使用presto的业务越来越多,现在已经扩容到了7worker。worker节点的内存也由原来的8G增加到了24G;

presto介绍:

Presto是一个开源的分布式SQL查询引擎,适用于交互式分析查询,支持海量的数据;主要是为了解决商业数据仓库的交互分析,和处理速度低下的问题。它支持标准的ANSI SQL,包括复杂查询、聚合(aggregation)、连接(join)和窗口函数(window functions)。
Presto支持在线数据查询,包括Hive, Cassandra, 关系数据库以及专有数据存储。 一条Presto查询可以将多个数据源的数据进行合并,可以跨越整个组织进行分析。

工作原理:

Presto的运行模型和Hive或MapReduce有着本质的区别。Hive将查询翻译成多阶段的MapReduce任务, 一个接着一个地运行。 每一个任务从磁盘上读取输入数据并且将中间结果输出到磁盘上。 然而Presto引擎没有使用MapReduce。它使用了一个定制的查询和执行引擎和响应的操作符来支持SQL的语法。除了改进的调度算法之外, 所有的数据处理都是在内存中进行的。 不同的处理端通过网络组成处理的流水线。 这样会避免不必要的磁盘读写和额外的延迟。 这种流水线式的执行模型会在同一时间运行多个数据处理段, 一旦数据可用的时候就会将数据从一个处理段传入到下一个处理段。 这样的方式会大大的减少各种查询的端到端响应时间。

使用场景:

1、常用的hive查询:已经有越来越多的同事通过presto来查询hive。相对于走MR的hive查询,presto的效率有了很大的提升;
2、数据平台通过presto来查询hive,做业务展示;
3、cobar的union。cobarc有5个分片,数据存在5个分片中,原先如果需要查询cobarc,需要分别查询5个分片的数据,然后再手动合到一起。查询效率低下。cobarb有8个库,数据存在8个库里面。同样存在cobarc的问题。通过presto,将5个分片的表union到一起,提升了查询效率,简化查询;
4、hive和mysql的交互。以前无法将hive的历史数据与cobarc的实时数据join到一起。只能分别查询前一天的数据或者当天的数据。使用presto可以将hive和cobarc的表join到一起;
5、kafka的topic映射成表;现有的kafka中,有部分topic的数据是结构化的json数据。通过presto,将json映射成表。可以直接使用sql查询。不过暂时还没有应用使用到此场景;
6、目前使用hue、zeppelin等web工具,来操作presto,支持结果集的导出。