郑昀 建立于2014/10/30 最后更新于2014/10/31
一)选型:Shib+Presto
应用场景:即席查询(Ad-hoc Query)
1.1.即席查询的目标
使用者是产品/运营/销售运营的数据分析师;
要求数据分析师掌握查询SQL查询脚本编写技巧,掌握不一样业务的数据存储在不一样的数据集市里;
无论他们的计算任务是提交给 数据库 仍是 Hadoop,计算时间均可能会很长,不可能在线等待;
因此,
使用者提交了一个计算任务(PIG/SQL/Hive SQL),控制台告知任务已排队,给出大体的计算时间等友情提示, 这些做业的权重较低,
使用者和管理员能够查看排队中的计算任务,包括已执行任务的执行时间、运行时长和运行结果;
当计算任务有结果后,控制台界面有通知提示,或者发邮件提示,使用者能够在线查看和下载数据。
1.2.即席查询的当下技术选型
图形交互界面:Shib;
数据查询引擎:Facebook Presto。
1.3.为何要更换数据查询引擎?
基于 MapReduce 的 Hadoop 适合数据批处理,但不适合即席查询场景。基于 InnoDB/MyISAM 存储引擎的 MySQL 天然也不适合。固然咱们也观察过 InfiniDB/InfoBright 这种列式存储数据库引擎(仍基于MySQL),它们更适合基本再也不变动的历史 归档数据,因此不太适合电商应用场景。
咱们的鹰眼(Tracing)项目就曾折翼在即时查询上,后端的 HBase 扛不住在大数据量下的实时插入和查询。
『
Hive 更适合于长时间的批处理查询分析,Impala、Shark、Stinger和Presto 适用于实时交互式SQL查询,它们给数据分析师提供了快速实验、验证想法的大数据分析工具。因此能够
先使用 Hive 进行数据转换处理,以后使用这四个系统中的一个在 Hive 处理后的结果数据集上进行快速的数据分析。
Impala、Shark、Stinger和Presto四个系统都是类SQL实时大数据查询分析引擎,可是它们的技术侧重点彻底不一样。并且
它们也不是为了替换Hive而生,Hive 在作数据仓库时是很是有价值的。这四个系统与Hive都是构建在Hadoop之上的数据查询工具,各有不一样的侧重适应 面,但从客户端使用来看它们与Hive有不少的共同之处,如数据表元数据、Thrift接口、ODBC/JDBC驱动、SQL语法、灵活的文件格式、存储 资源池等。』——《开源大数据查询分析引擎现状,2014》
最终咱们选择了 Presto。
FaceBook于2013年11月份开源了Presto,一个分布式SQL查询引擎,它被设计为用来专门进行高速、实时的数据分析。
它支持标准的ANSI SQL,包括复杂查询、聚合(aggregation)、链接(join)和窗口函数(window functions)。Presto设计了一个简单的数据存储的抽象层,来知足在不一样数据存储系统(包括HBase、HDFS、Scribe等)之上均可以使用SQL进行查询。
Presto 简化的架构以下图1所示,客户端将 SQL 查询发送到 Presto 的协调器。协调器会进行语法检查、分析和规划查询计划。调度器将执行的管道组合在一块儿,将任务分配给那些离数据最近的节点,而后监控执行过程。客户端从输 出段中将数据取出,这些数据是从更底层的处理段中依次取出的。 算法
Presto 的运行模型与 Hive 有着本质的区别。Hive 将查询翻译成多阶段的 Map-Reduce 任务,一个接着一个地运行。 每个任务从磁盘上读取输入数据而且将中间结果输出到磁盘上。然 而 Presto 引擎没有使用 Map-Reduce。它使用了一个定制的查询执行引擎和响应操做符来支持SQL的语法。除了改进的调度算法以外,全部的数据处理都是在内存中进行的。不 同的处理端经过网络组成处理的流水线。这样会避免没必要要的磁盘读写和额外的延迟。这种流水线式的执行模型会在同一时间运行多个数据处理段,一旦数据可用的 时候就会将数据从一个处理段传入到下一个处理段。 sql
这样的方式会大大的减小各类查询的端到端响应时间。 数据库
同时,Presto 设计了一个简单的数据存储抽象层,来知足在不一样数据存储系统之上均可以使用 SQL 进行查询。存储链接器目前支持除 Hive/HDFS 外,还支持 HBase、Scribe 和定制开发的系统。 后端
图1. Presto架构 网络
1.4.在HUE和Shib之间选择了后者
HUE 你们可能都据说过。Shib 相对陌生一些,它是这么介绍本身的:WebUI for query engines: Hive and Presto。
潘高锋介绍了两者的优缺点。
HUE
开发语言:Python
优 点:Hue 是一个可以与 Apache Hadoop 交互的 Web 应用程序。一个开源的 Apache Hadoop UI。咱们已经在生产环境使用Hue了,并且Hue在管理Hbase/Pig/Hive方面有很大的优点,它还附带了一个Oozie的应用程序,用于建立 和监控工做流程 。
缺点:Hue 是一个比较重的工具,改动起来涉及的东西会比较多,并且之后每次升级均可能会致使咱们改动的功能要再修改 。
Shib
开发语言:Nodejs
优势:Shib 经过简单的配置就能够直接操做 hive 和 presto。代码量比较小,修改起来工做量少不少 。
缺点:对 Nodejs 不熟悉,有学习成本 。
最后咱们选定了代码量和开发量相对较少的 Shib 。
1.5.即席查询的界面展现
登陆 shib 后,选择数据仓库 presto-wowo_dw。编写 sql 的时候,能够把表结构的提示框移到一边,边写边参照,以下图所示。
图2 边查询边看数据结构
因为全部的查询都是异步的,因此能够在“个人查询”列表中看到本身的查询语句的执行状态和执行结果,这样不用本身在一直在查询界面等待了,以下图所示。
图3 个人查询
还能够把本身经常使用的查询语句保存到“书签”里,这是一个很实用的功能。
接下来就能够开发SQL查询结果站内通知机制以及更复杂的用户访问权限控制机制了。
二)选型:HUE+Oozie
应用场景:Hadoop集群计算任务调度和管理平台。
2.1.数据平台跑数据所面对的困难
电商数据平台的报表维度有不少种,有整体简报角度、运营角度、媒体投放角度等,也能够有商品、商户、用户、竞品等维度,还有日报、周报和月报之分。因此对 应了不少个计算任务。每个计算任务能够视为一个工做流,毕竟计算过程是很复杂的、一环套一环。那么 HUE+Oozie 就是可视化管理和调度这些工做流的。
没有 Oozie 以前是什么样?
一,计算脚本被配置为定时任务,跑飞了只能从海量日志中大海捞针,不知道断在哪儿,只能手动清数据从头再跑。任务计算时间特别长,不知道当前跑到哪一步了,还须要多久能跑完。
二,难以精确控制任务A跑完了才能跑任务B,只能在不一样定时任务之间留足够长的时间间隔,缺少弹性。
2.2.Oozie是什么
Oozie是一种 Java Web 应用程序,它运行在 Tomcat 中,并使用数据库来存储如下内容:工做流定义、当前运行的工做流实例(包括实例的状态和变量)。
咱们最欣赏它的三点:
- Oozie容许失败的工做流从任意点从新运行,这对于处理工做流中因为前一个耗时活动而出现瞬态错误的状况很是有用。
- 工做流执行过程可视化。
- 工做流的每一步的日志、错误信息均可以点击查看,并实时滚动,便于排查问题。
2.3.仍是看截图吧
先选择HUE导航栏上的“Oozie Editor/Dashboard”,看到默认面板:
图5 oozie默认面板
点击某个工做流,进入详情页:
图6 工做流详情页
一个工做流的定义以下图7所示,XML格式的 hPDL。hPDL是一种很简洁的语言,只会使用少数流程控制和动做节点。控制节点会定义执行的流程,并包含工做流的起点和终点(start、end和 fail节点)以及控制工做流执行路径的机制(decision、fork和join节点)。
图7 工做流定义
如今,数据平台的各类计算任务都迁移到 Oozie 中,按照 hPDL 语言格式一一从新定义。
三)总结一下数据中心的各类技术选型
罗列以下,再也不解释:
Apache Hadoop/Hive/HBase
Apache Pig
Flume/Kafka/Storm/Sqoop/awk
Facebook Presto
MySQL
HUE/Shib
Oozie
-over-