Heim >Datenbank >MySQL-Tutorial >ThinkinginBigDate(九)大数据hadoop集群下离线数据存储和挖掘

ThinkinginBigDate(九)大数据hadoop集群下离线数据存储和挖掘

WBOY
WBOYOriginal
2016-06-07 15:28:421199Durchsuche

前序: 2月23日,在中关村,海淀黄庄丹棱街SOHO大厦好未来会议室,hadoop专家吴超大侠,分享使用hadoop进行论坛日志分析。在回来的第二天,赶上了这次草根面对面交流。说是草根,像我这样的是草根,其余的都是大侠。在这一次交流中,主要是针对初级想了解had

前序:

2月23日,在中关村,海淀黄庄丹棱街SOHO大厦好未来会议室,hadoop专家吴超大侠,分享使用hadoop进行论坛日志分析。在回来的第二天,赶上了这次草根面对面交流。说是草根,像我这样的是草根,其余的都是大侠。在这一次交流中,主要是针对初级想了解hadoop的人员的,主要讲的内容,在我的上一篇Thinking in BigDate(八)大数据Hadoop核心架构HDFS+MapReduce+Hbase+Hive内部机理详解 博客中基本都有所涉及。这里我们又为什么又费言说这么多,只有一个目的,从这里你可以获得扩展你知识的另一个途径。

这段时间一直忙着,架构图的梳理与后期项目该如何开展,以及自己的学习状况。虽然看上去很简单的一个架构图,其实它需要你了解其中每一个点。我记得上次July和夏粉来北航讲座,July说到一句话:当你把你知道的东西,写下来,让人看明白是一种境界;当你能把自己写下来的东西给人讲明白,又是另一种境界。在这个过程中,我们都需要历练。虽然自己写博客并没有太长的时间,但是我深知吴超大侠、July的痛苦,说明白点,博客就是一件太耽误时间的事,而选择权在你手上。就这样还有人一直傻二愣的的再写。

基于hadoop集群下海量离线数据存储和挖掘分析架构:

架构图采用主流的Hadoop+Hive+Hbase集群架构平台。最简单的利用,包含了基本的基于hadoop集群下的日志分析过程。但此架构图,又不仅局限于简单的基于日志数据处理。我们可以把它定位到,把基于传统数据挖掘技术,移植到Hadoop集群平台上,提高计算效率,节省时间,降低开发成本。说到这里就必须多说一点,传统数据挖掘和基于Hadoop集群下的数据分析过程有什么区别?

我想这也是一直困扰大家的问题。旁人看热闹,行人看门道。把基于传统数据挖掘的过程移植到hadoop集群中,好在哪儿?问题在于:传统数据挖掘过程,基于单机或放在内存比较大的小型机上去跑数据,去建模型,7-8GB的数据,在参数不多的情况下,建模的过程,我想稍微熟悉建模过程的人,会有一个时间上的概念,10几个小时或者上天已经是好的了。太耗时了,太耽误时间了。而当数据越来越大,就面临这一瓶颈。自此,分布式的概念提出来了,分布式出来了,自然就会引入集群的概念。集群就是一群机器处理一个问题,或集群中不同的机器处理不同阶段的问题。除此时间问题之外,还有什么优势?其实,也一直困扰着我,我一有机会就会向那些大牛去请教,还有什么优点,他们也是堂堂不知其所言。

这里再多说两句还有什么优势:1、非关系型数据(Nosql),类日志文件数据。2、实时性。但这两点又不是传统数据挖掘的核心。其实,一个时间节省的问题,就足可以为之探究了。

这里没有采用现主流基于内存计算引擎Spark集群架构。后续如有涉及,再细讨论。

1、数据存储层

功能:数据收集、处理、存储、装载

包含:数据集成、ETL、数据仓库

工具:Sqoop、Flume、Kettle、Hive。

简介:

(1)Sqoop:数据收集工具,用于把相关数据导入Hadoop集群中。

(2)Flume:分布式日志收集工具,适用于网站、服务器等日志文件的收集。

(3)Kettle:一种开源免费的ETL工具。还有很多收费的ETL工具。在中国这都免费。

(4)Hive:基于Hadoop集群架构下的数据仓库的建立工具。主要是为了,类SQL与SQL之间的转换。

数据存储层,是前提。而前提的前提,就是数据的收集与ETL,在前面的博客中提到前期数据搜集和ETL过程可能会占整个项目工程的75%甚至以上的时间。可见,前期的工作多么的重要,没有前面,后面无从谈起。

2、集群架构层

功能:离线数据分析系统

核心:大数据存储和集群系统:Hive0.12.0 & Hadoop2.2.0 & HBase0.96.1

简介:

(1)Hadoop:开源集群分布式架构平台。2.2.0为最新版本。

(2)HBase:面向列的分布式数据库,适合构建低并发延时性数据服务系统。

(3)HDFS:分布式文件系统,是海量数据存储的标准。

集群架构层:说的是,也是集群平台的核心。我们常说的搭建hadoop平台,一般指的就是Hive+Hadoop+HBase。这需要自己去按照说明文档,在linux下搭建平台。其实,在我们配置Hadoop相关系统文件的时候,我们已经可以测试数据了,我们可以通过上传一个不是很大数据,测试hadoop是否运行成功。HBase+Hive是为大数据处理准备的。这里不介绍如何去配置系统文件,综合网上相关的文档,配置安装应该都没有问题。

目的在于,梳理一下整个大数据挖掘整体的流程。在脑海里梳理一下,有一张架构图。

3、分布式计算引擎层

功能:针对密集型数据计算

核心:Yarn、MapReduce

简介:

(1)Yarn:分布式资源管理框架,也可以理解为管理类MapReduce这种分布式处理平台的框架。

(2)Map/Reduce:基于密集型离线数据分析框架。这区别于现在很火的基于内存数据处理的Spark架构。

这里可能涉及到数据处理的过程,在上一篇博客中,谈到MapReduce的内部机理。其实就是把数据分块分发到不同机器上并发处理数据,最后把处理完的数据整合到一起,输出。其实看似简单,细分到每一块,我们就会看到,数据是如何在单机上去走的。这里逃不掉到的是数据还是一行行的读取,你也没有别的办法。这里你要做的工作就是,去写MapReduce函数,这个是根据数据的类型,业务需求,去写相应的函数。

4、算法合成层

功能:集成数据挖掘算法

核心:HiveQL、R语言、Mahout

简介:

(1)HiveQL:上面提到,类SQL,这也是选择Hive的原因,有利于传统数据库操作员到NoSql数据库操作之间的转型。

(2)R语言:主要用与统计分析、绘图的语言等。提供了一套完整的数据处理、计算和制图软件系统,也为下面的数据可视化提供了前提。

(3)Mahout:主要是集成机器学习等相关经典算法的实现。可以更有效的提供,挖掘数据背后隐藏的规律。

算法合成层,其实是数据挖掘,数据规律之间挖掘的核心。通过这些经典的或优化过的算法,为我们在海量数据面前,挖掘出有用价值的数据提供了方面。如果大家,了解一些数据挖掘和机器学习的一些内容的话,我们会知道两个概念:一、训练集。二、测试集。这里我们也会更多的提到建模,而构建模型的两个范畴就是,构建训练集合测试集的过程。训练集,是把原始数据抽取一部分用来构建模型,找到其中的一些规律。然后用剩下的数据,当测试集,去测试模型构建的准确率。其实更深入讨论一下,我们就会面临一个业界头疼的问题,准确率问题。因为我们所有的测试都是针对线下的数据去构建模型,这种方式对离线数据分析没有太大的影响,原因在于:离线数据,是不可变的,在很大情况下满足,在训练集测试的规律满足测试集的规律。而在更多的情况下,如基于实时线上数据的机器学习,这要求就非常的高了。这就会遇到一个通用的诟病:如何解决线下测试准确了极高的模型,如何保证在线上准确率却很差。他们给出的办法:就是没有办法,调参数,不断的测试,提高准确率。

这里不再多说,先梳理整个架构。

5、数据可视化层

其实上面已经讲到了一个可视化集成工具,就是R语言。当我们把通过Hadoop集群,业务梳理后的数据再写回HDFS中时候,这些数据有些已经是有规律的数据了。有些数据是提取出来制作报表、饼图或柱状图等。其实对上面已经处理完的数据还有下一步的处理过程就是:把HDFS或Hive数据仓库中的数据导入传统关系型数据库。用传统可视化工具进行展示,这是目前很主流的方法。当数据导入传统关系型数据库中,最后一步就是BI,传统BI。大家都在忙着吵大数据概念,可不要把传统的优势忘记,不然也只是丢了西瓜,捡了芝麻。

说了这么多废话,其实就是为了引出,基于传统离线数据存储和挖掘架构图。这是为我们自己接下来的工作,提前梳理好要做的内容。

\

(自己梳理的过程)

总结:

最近一段时间,一直在整理技术核心架构,一方面为写策划方案;一方面是为了接下来学习打下基础。上面的架构图基本已经涉及基于传统数据挖掘移植到Hadoop集群的一些流程。为不清楚或初学者提供一个解决方案,知道一个流程应该从哪方面入手。对于熟悉整个流程的Hadoop工程师来说,可能上面的工作是多此一举。但是能整理出来,在时间上的消费,为后来者提供一个解决方案,自是一件好事。

自己也是作为一个初学者。还有时间,也愿意抽出时间,把最近一段时间的学习整理一下,是为了积累。如有不足,后续改正。

Copyright?BUAA

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn