整套大数据学习资料(视频+笔记)百度网盘无门槛下载:http://www.edu360.cn/news/content?id=3377

16.2.3 Hive

hadoop 花牛 14℃ 0评论

刚开始使用Hadoop时,我们很快就倾倒于它的可扩展性和有效性。然而, 我们担心它是否可以被广泛采用,主要是因为用JavaMapReduce程序的

复杂度问题(还有培训用户写这种程序的代价)。我们知道很多公司的工程师 和分析师很了解SQL,它是一种査询和分析数据的工具,并且我们也清楚 很多人都精通几门脚本语言,如PHPPython。因此,我们必须开发出一 种软件来建立用户精通的脚本语言和Hadoop编程所需语言之间的沟通 渠道。

很明显,我们的很多数据集是结构化的,而且能够很容易进行数据分割。 这些要求很自然地形成一个结果:我们需要一个系统,它可以把数据模型 化成表格和数据块,并且它能够提供类似SQL的査询和分析语言。另外, 该系统能把用户所选编程语言编写的自定义MapReduce程序嵌入査询。这 个系统就是HiveHive是一个构建于Hadcwp之上的数据仓库架构,是 FacebookHadcwp中存储的数据进行査询的S"要工具。在下面几个小节, 我们将详细描述这一系统。

1.数据的组织

在所有数据集中,数据的组织形式是一致的,被压缩、分区和排序之后进 行存储。

• 压缩几乎所有数据集都采用gzip codec压缩存储成顺序文件。旧的数据采用bzip codec重新压缩,这样可以比用gzip编码压缩更 多。bzip压缩的速度比gzip慢,但是对旧数据的访问频率要低很 多,因此考虑到节省硬盘空间,这种性能损失还是很值得的。

• 分区大部分数据集根据日期进行分区。独立的分区块被加载到 Hive系统,实际是把每个分区块存入HDFS的一个单独的目录 下。大多数情况下,这种分区只根据相关联的记录日志文件(scribe logfile)的时间戳进行。然而,在某些情况下,我们扫描数据,然后 基于日志条目里能找到的时间戳进行数据划分。回顾前面的介绍, 我们也可以根据数据各种其他特征进行分区(如国家和日期)

• 排序在一张表里,每个分区块通常根据某个唯一标识(ID,如果 存在的话)进行排序。这样的设计有几个主要的优点:

在这样的数据集上容易执行取样查询操作 〇 我们能基于排序数据建立索引

对具有唯一标识的数据进行聚集和连接运算更有效

日常的MapReduce作业会把数据加载成这种数据长期保存格式(和近实时的 数据导入处理不同)。

2.查询语言

Hive査询语言和SQL类似。它具有传统的SQL的结构,如joingroup by, where, select, from从句和from从句的子査询等。它试图把SQL命令 转换成一系列的MapReduce作业。除普通的SQL从句之外,它还有一些扩 展功能,如在查询语句中嵌入自定义mapperreducer脚本,对数据进行 一次扫描就可以进行多个表、数据块、HDFS文件和本地文件插入,在样本 数据而不是全部数据集上执行查询的功能(在测试查询的时候,这个功能非 常有用)。Hive metastore存储了表的元数据信息,并将提供元数据给Hive 编译器,以便进行将SQL命令转换成MapReduce作业。通过数据块修剪, map端的聚合和其他一些特色功能,Hive编译器会努力构造可以优化查询 运行时间的执行计划。

3.在数据流水线管道中使用Hive

另外,Hive提供了在SQL语句里表述数据流水线的能力,这•功能能够并 且已经提供相当的灵活性来支持用简单方便的方式对数据流进行合并操 作。这一功能对于改进中或开发中的系统和产品尤其有用。处理数据流时 所需的许多操作都是大家非常了解的SQL操作,如join, group by, distinct aggregation等。由干Hive能够把SQL语句转换成一系歹lj Hadoop MapReduce作业,所以创建和维护这些数据流就非常容易。在这一节,我 们用一个虚构的网络广告例子,展示使用Hive计算广告商所需的某些典型 汇总表,从而说明Hive这些方面的功能。例如,假设某个在线广告网络在 Hive系统里把广告信息存储在dim_adS表中,把和某个广告曝光相关的信 息存储在impression_logs表中,impressionjogs表数据根据日期进 行分区,那么在Hive系统中査询2008-12-01这天的广告曝光数(广告网络 会把广告营销中的每个以及总的广告曝光数定期反馈给广告商)可以表达为 如下SQL语句:

SELECT a.campaign_id, countCl)^ count(DISTINCT b.user_id)
FROM dim_ads a DOIN impression_logs b 0N(b.ad_id = a.ad_id)
WHERE b.dateid = '2008-12-01'
GROUP BY a.campaign_id;

这也是大家能在其他RDMS(关系数据库系统)OracleDB2等上使用的 典型的SQL语句。

为了从前面同样的关联好的数据上以广告和账户为单位计算每天的广告曝 光次数,Hive提供了同时做多个group by操作的能力,査询如下所示(类似 SQL语句但不是严格意思上的SQL):

FROM(
SELECT a.ad_id, a.campaign_id, a.account_id, b.user_id 
FROM dim ads a JOIN impression_logs b ON (b.ad_id = a.ad_id)
WHERE b.dateid = '2008-12-01') x
 INSERT OVERWRITE DIRECTORY 'results_gby_adid'
SELECT x.ad_id, count(l), count(DISTINCT x.user_id) GROUP BY x.ad_id 
INSERT OVERWRITE DIRECTORY ' result s_gby._campaignid '
SELECT x.campaign_id, count(l), count(DISTINCT x.user_id) GROUP BY 
x.campaign_id
INSERT OVERWRITE DIRECTORY 1 results_gby_accountid1
SELECT x.account_id, count(l)j count(DISTINCT x.user_id) GROUP BY 
x.account_id;

Hive增添的一项优化功能是查询能被转换成一系列适用于“偏斜数据” (skewed data)Hadoop MapReduce作业。实际上,join操作转换成一个 MapReduce作业,三个group by操作转换成四个MapReduce任务,其中第 一个任务通过unique_id产生部分聚集数据。这样做非常重要,因为 impression_logs表的数据在unique_id的分布比在ad_id上的分布更 均匀(通常在一个广告网络中,有些广告因为其客户分布更均匀使得其广告 份额占主导地位)。因此,通过uniquejd进行部分聚集操作能让数据流把 工作更均勻地分配到各个reducer。简单改变査询中的日期谓词,同一个査询模板便可以用于计算不同时间段的性能数据。

但是计算整个广告周期的数据可以采用更好的方法,如果使用前面介绍的 计算策略,我们必须扫描impression_logs表中的所有分区。因此,为了计算整个广告周期的数据,一个更可行的方法是在每天的中间表的分区上 执行根据ad_iduniqUe_id的分组操作。这张表上的数据可以和次日的 impression_logs合并增量产生整个周期的广告效果数据。例如,要想得 到2008-12-01日的广告曝光数据,就需要用到2008-11-30日对应的中间表分区数据块。如下面的Hive查询语句所示:

INSERT OVERWRITE lifetime—partial—imps PARTITION(dateid='2008-12-01,) 
SELECT x.ad_id, x.user一id, sum(x.cnt)
FROM (
    SELECT a.ad_id, a.usen_id, a.cnt 
    FROM lifetime_partial_imps a 
    WHERE a.dateid = '2008-11-30'
    UNION ALL
    SELECT b.ad_id, b.user_id,1 as cnt 
    FROM impression_log b
    WHERE b.dateid = '2008-12-01'
)x
GROUP BY x.ad_idj x.user_id;

这个查询为2008-12-01计算局部汇总数据,它可以用来计算2008-12-01的 数据以及2008-12-02的数据(这里没有显示)。SQL语句转换成一个单独 Hadoop MapReduce作业,它实际上是在合并的输入流上做group by计 算。在这个SQL语句之后,可以做如下的Hive查询,它为每个分组计算 出实际的数据(与前面对日汇总的数据流水线的查询相似)

FR0M(
SELECT a.ad_id, a.campaign_id, a.account_id, b.user_id, b.cnt 
FROM dim_ads a DOIN lifetime_partial_imps b ON (b.ad_id = a.ad_id)
WHERE b.dateid = '2008-12-01') x
INSERT OVERWRITE DIRECTORY ' results_gby_adid '
SELECT x.ad_id^ sum(x.cnt), count(DISTINCT x.user_id) GROUP BY 
x.ad id
INSERT OVERWRITE DIRECTORY ' results_gby_campaignid'
SELECT x.campaign_id, sum(x.cnt), count(DISTINCT x.user_id) GROUP BY 
x.campaign_id
INSERT OVERWRITE DIRECTORY 'results—gby_accounticT
SELECT x.account—id, sum(x.cnt), count(DISTINCT x.u$e「_id) GROUP BY 
x.account_id;

Hive和Hadoop都是批处理系统,它们计算数据的延迟比标准RDBMS要 高,如OracleMySQL。因此,在许多情况下,把HiveHadoop系统产 生的概要信息加载到传统的RDBMS还是非常有用的,这样用户可以通过 不同的商业智能(BI)工具或网络门户来使用这些数据。 16.2.4存在的问题与未来工作计划

1.公平共享

Hadoop集群通常同时运行多个日常报表生成作业”(production daily job) 和“即席作业”(ad hoc job),日常报表生成作业需要在某个时间段内完成计算任务,而即席作业则可能具有不同的优先级以及不同的计算规模。在 选择典型安装时,日常报表生成作业倾向于夜间运行,这时来自用户运行 的即席作业的干扰最小。然而,大规模即席作业和日常报表生成作业之间 的工作时间重合常常是不可避免的,如果没有充分健壮的保障措施,这种 作业重合会导致报表生成作业的高延迟。ETL(数据提取、转换和加载)处理 也包含几个近实时的作业,它们都必须以小时为间隔地运行(包括对以下数 据进行处理:从NFS服务器复制Scribe数据以及在某些数据集上以小时为

单位计算得到的概要数据)。这也意味着只要有一个意外作业就会使整个集 群宕机,使结果生成处理作业处于危险境地。

Facebook开发并且贡献给Hadoop系统的Hadoop公平共享作业调度器(job scheduler)为许多类似的问题提供了解决方案。它为特定作业池中的作业保 留了保障性计算资源,同时让闲置资源可以被任何作业使用。通过在各个 作业池之间以一种公平手段分配计算资源也可以防止大规模作业霸占整个 集群资源。在集群里,内存是其中一种竞争比较激烈的资源。我们对 Hadoop系统做了一些修改,即如果发现jobtracker的内存短缺,Hadoop就 会减缓或遏制作业提交。这能保证用户进程能够得到合理的进程内存空间,并且为了阻止在同一个节点运行的MapReduce作业影响HDFS后台程 序(主要是因为大内存消耗),可以在节点运行时^玫置一些监控脚本程序。日志目录存储在单独的硬盘分区,并且定期清理,我们认为把MapReduce中 间结果存储放在单独的硬盘分区上也是有用的。

2.空间管理

硬盘容量管理仍然是一个大挑战——数据的增长带来了硬盘使用的急速增 加。许多数据集日益攀升的成长型公司面临着同样的问题。在许多情况下,很多数据实际是临时数据。这种情况下,我们可以使用Hive的保留 期设置,也可以用bzip格式重新压缩老数据以节省存储空间。尽管可以通 过设置配置项来减少硬盘存储空间,但增加一个高存储密度机器层来管理 旧数据可能会有很大好处。这将使Hadoop存储存档数据的代价变低。然而,对这些数据的访问应该是透明的。目前我们正在为这个数据存档层 的实现而努力工作,把对旧数据处理的方方面面的要求都加进来。

3.Scribe-HDFS 集成

目前,Scribe把数据写入一些NFS文件存档器(filer),然后前面所描述的自 定义复制作业(copier job)就从这里收集和传送数据给HDFS。我们正致力于 开发让Scribe直接把数据写入其他HDFS的方法。这将简化对Scribe的扩展和管理工作。基于对Scribe的正常运行时间的高要求,它的目标写入 HDFS很可能与数据产生HDFS不同(因此它不会产生由于用户作业而出现 负载/停机的问题)

4.改进Hive

对Hive系统的开发目前还是有很多工作要做。我们的开发关注着几个重要 特性,如支持order byhaving从句,更多聚集函数,更多内置函数,日期类型,数据类型等等。同时,我们也在进行大量优化工作,如谓词下推和共同子表达式消除等等。在集成方面,正在开发JDBCODBC驱动程 序用于和OLAPBI工具集成。通过所有这些优化措施,我们希望能够释 放MapReduceHadoop的潜能,把它更进一步推向非工程化社区以及用于 Facebook。该项目相关的更多详细信息,请访问http://hadoop.apache.org/hive/

转载请注明:全栈大数据 » 16.2.3 Hive

喜欢 (0)or分享 (0)
发表我的评论
取消评论

表情

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址