presto的动态化应用(一):presto节点的横向扩展与伸缩

一、presto动态化概述

　　近年来,基于hadoop的sql框架层出不穷,presto也是其中的一员.从2012年发展至今,依然保持年轻的活力(版本迭代依然很快),presto的相关介绍,我们就不赘述了,相信看官多对presto有或多或少的了解,详细的一些说明可以看官网(https://prestodb.io)的说明.

　　presto自身功能和思想富有先进性,虽然由于是内存计算,稳定性方面还有很大提升空间,但整体依然在adhoc方面有很好的竞争力,我们本次介绍针对我们团队对于presto部分应用个性化定制功能的阐述,如果设计不合理或有待改进的方面,请大家多多反馈,我们共同进步.

　　由于我们团队是围绕着hadoop相关项目进行,对于大数据的即席查询的需求是无可避免,最终选用presto和impala两款即席查询工具.一款新的开源工具从测试到生产环境,除了必要的覆盖测试,还要自动部署, 监控, 预警 , 日志分析 , 异常处理等等功能,还有一些来源业务部门的需求进行调整及改进(主要针对sql和易用性,性能改进,可后续其他系列文章进行说明).

我们针对presto动态开发,主要体现于三个方面:

• presto节点的横向扩展与伸缩(动态资源)

• presto的配置动态化(消除presto本地配置)

• presto动态加载更新插件(不停服务情况下,自动增加或升级插件)

二、资源动态化:充分利用集群资源,混搭才是王道

presto从上线到切入业务,一直在独立hadoop集群中,遵从不抢占线上集群资源,不影响线上核心任务的原则,但是迁入presto的业务方日渐增多,T-1的跨机群将数据拷贝至独立presto集群方式已然无法满足,我们做出大胆的决定,便是将presto迁入线上集群直接使用,于是我们必须能够对presto的资源管理有完善的把控和管理.

PrestoSchedule1.0功能点:

    1.presto on yarn

    2.presto Server(白天100%节点,晚上5%节点)

    3.presto 监控预警系统

    4.presto 权限管理

    5.presto 动态插件管理

    6.presto 分流管理

    7.presto 自动升级(用户无感知,保证task无失败)

三、PrestoSchedule1.0模块

1.Presto Server

　　prestoServer 是PrestoSchedule独立部署模块.是包括管理界面,监控,权限管理等功能,提供了自主运维管理后台，让管理员能通过页面来配置、启停和管理presto集群, 同时管理presto master与work的节点数，监控每个节点运行信息,从节点启动-运行-消亡-删除启动包痕迹都有详细记录，管理员可以定制work的启动时间和停止时间, 同时能够看到每次启动耗时和结束耗时以及能看到执行成功或者失败，还会为保留过去的work的记录，可以查看定时历史启动记录.

　　除此之外,prestoServer 还兼有管理多集群映射的职责(为presto性能考虑,尽量让presto使用hadoop block减少网络传输,我们在每个hadoop集群都部署一套对应的presto服务),让sql用户对于访问集群无任何感知,屏蔽具体master的地址,对master的迁移和 on yarn提供基础支撑.

• 权限,屏蔽连接master的直接访问,同时对于presto访问者细粒度到人,对于非内部人员或非授权人员禁止访问,管控presto程序访问入口如客户端,jdbc,restful等方式

• presto代理,甄别多个presto集群的所有入口方式及权限,用户无感知的使用presto, 使presto master完全进入黑盒子,便于动态迁移master, 新建presto集群,客户端无需感知或受到影响

• 分流,监控presto master压力,可将一部分查询流量实时切换到另一presto master,同时支持presto新开发功能的灰色发布及线上自测

• 运维管理,支持新建,启停presto集群,管理presto work的节点数,可以通过页面修改当前的presto work数量,及交互资源(将切换masterA的work转换为masterB的work).

• 监控,包括presto sql分析,presto监控情况, JMX监控, presto队列情况, presto自恢复机制.

2.presto on yarn

　　混搭性集群充分利用集群资源,一直是我们深入研究的主题,对于离线任务与实时任务,导数任务与计算任务应该各司其职,充分榨干集群每一寸土地,当然,这是理想的情况,presto on yarn是我们对于在离线集群进行长时间运行(long server)的服务的一次尝试.

　　因我们有on yarn需求时,社区的presto-yarn项目(https://github.com/prestodb/presto-yarn)才是初版,Slider也不是很成熟,测试过程中也很多不满足我们需求的地方,于是我们便开发presto on yarn的项目.

　　为了更好的融入混搭集群的方向, 我们需要解决如下几个问题:

资源:

    1.利用空闲的资源

    2.不能抢占核心任务的资源

    3.不能影响其他任务的运行

稳定性:

    1.保证presto在yarn上的稳定性

    2.保证presto master和work的数量

    3.保证用户查询不因平台框架原因查询失败

可伸缩性:

    1.保证随时可扩展,可缩减的可操作性

易部署:

    1.web页面一键部署,一键启停

    2.兼容运行环境(JDK版本)问题.

权限控制:

    1.表权限级别控制,与公司hadoop/hive权限验证打通(公司内部erp权限管理,请看hadoop erp权限管理)

定时性:

    1.保证白天100%资源运行,夜间5%资源运行

　　针对以上的问题,我们进行分解,针对问题进行对应涉及工作,其中思路与alluxio on yarn类似, 资源可以使用linux container 与 docker container 进行资源隔离.

　　稳定性则可以增加AM 作为管理节点及ETCD注册, 通过thrift接收外部请求,增加或减少资源,同时AM与APP又受到prestoServer管理,即便APP或AM失败或者被意外kill,也可以重启任务或监听重试.

　　可伸缩性,通过请求AM执行容器的创建及销毁工作,同时,对异常关闭(NodeManger异常关闭)的容器进程依然存在, AM定期向presto Master发送反向关闭无效work服务指令,Presto Master对于不在容器内的存活presto work发送关闭命令, presto work执行exit, 反向关闭presto work进程(需要增加presto API).

　　易部署,使用on yarn的方式,比较方便的便是部署,能够达到一键部署的特征,但是随即而来的便是容器环境问题, hadoop JDK版本多为1.6,1.7, 并没有使用JDK1.8, 但是presto对于JDK1.8是强依赖, 我们解决方式有两种,其一是使用docker container(公司内部hadoop已支持多种容器模式共存,通过参数选择container 类型) ,方案二,我们presto是支持动态插件功能,其中动态插件管理可选择是否包含JDK启动,原理是将JDK及备用jar放置HDFS中,通过外部配置(系列二的配置管理系统)决定, 是使用localjdk,还是使用远程jdk(如使用远程,依然会对比本地JDK版本以及是否曾经已下载进行复用),然后启动presto服务.

　　权限控制,除了与公司的权限管理系统贯通并兼容,presto server也作为所有用户访问presto的入口, 对于用户并不知道访问的具体hadoop集群或presto集群,将用户sql访问与presto技术实现松和耦合,我们随时可以将用户sql切换到其他平台中运行,如spark sql, hive, impala等.

　　定时性,自动化伸缩节点是初期最重要的功能之一, presto性质决定他的用户多为白天, hive的跑批脚本多为在凌晨开始,早晨结束,故此两者时间上可以进行互补,技术实现相对简单, 仅仅定时器触发AM的thrift接口发送伸缩命令即可.

3.presto 服务发现

　　服务发现现今使用的是etcd进行,原本有计划将presto的发现服务,转移到ETCD中,但开发计划一直未能展开,故此使得两个发现服务互补使用.(临时方案)

服务发现:

• presto集群信息

• yarn APP/AM 信息

• hadoop配置信息

• catalog版本信息

• catalog配置

• presto config信息

• presto 插件版本信息

• on yarn配置信息

4.presto IDE

　　presto的快速查询使用方式则是多种多样, 我们支持presto client, SQL IDE(公司内部web开发工具) JDBC, ODBC, restful接口方式等方式进行sql的查询工作,从而保证业务方在任何条件下都可以访问.

四、文章说明

　　本文出自本人的一个同事涵总之手，今天在本人的博客上晒一下！