flume下沉到ftp
1. 数据仓库数据建模的几种思路
数据仓库数据建模的几种思路主要分为一下几种
1. 星型模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心,所有的维度表直接连接在事实表上,像星星一样。星形模式的维度建模由一个事实表和一组维表成,且具有以下特点:a. 维表只和事实表关联,维表之间没有关联;b. 每个维表主键为单列,且该主键放置在事实表中,作为两边连接的外键;c. 以事实表为核心,维表围绕核心呈星形分布;
星座模型
2. 大数据需要学编程吗
导读:
第一章:初识Hadoop
第二章:更高效的WordCount
第三章:把别处的数据搞到Hadoop上
第四章:把Hadoop上的数据搞到别处去
第五章:快一点吧,我的sql
第六章:一夫多妻制
第七章:越来越多的分析任务
第八章:我的数据要实时
第九章:我的数据要对外
第十章:牛逼高大上的机器学习
数据量大,TB->PB
数据类型繁多,结构化、非结构化文本、日志、视频、图片、地理位置等;
商业价值高,但是这种价值需要在海量数据之上,通过数据分析与机器学习更快速的挖掘出来;
处理时效性高,海量数据的处理需求不再局限在离线计算当中。
Hadoop 1.0、Hadoop 2.0
MapRece、HDFS
NameNode、DataNode
JobTracker、TaskTracker
Yarn、ResourceManager、NodeManager
0和Hadoop2.0的区别;
MapRece的原理(还是那个经典的题目,一个10G大小的文件,给定1G大小的内存,如何使用Java程序统计出现次数最多的10个单词及次数);
HDFS读写数据的流程;向HDFS中PUT数据;从HDFS中下载数据;
自己会写简单的MapRece程序,运行出现问题,知道在哪里查看日志;
会写简单的SELECT、WHERE、GROUP BY等SQL语句;
Hive SQL转换成MapRece的大致流程;
Hive中常见的语句:创建表、删除表、往表中加载数据、分区、将表中数据下载到本地;
为什么Spark比MapRece快。
使用SparkSQL代替Hive,更快的运行SQL。
使用Kafka完成数据的一次收集,多次消费架构。
自己可以写程序完成Kafka的生产者和消费者。
经常有初学者在博客和QQ问我,自己想往大数据方向发展,该学哪些技术,学习路线是什么样的,觉得大数据很火,就业很好,薪资很高。如果自己很迷茫,为了这些原因想往大数据方向发展,也可以,那么我就想问一下,你的专业是什么,对于计算机/软件,你的兴趣是什么?是计算机专业,对操作系统、硬件、网络、服务器感兴趣?是软件专业,对软件开发、编程、写代码感兴趣?还是数学、统计学专业,对数据和数字特别感兴趣。。
其实这就是想告诉你的大数据的三个发展方向,平台搭建/优化/运维/监控、大数据开发/设计/架构、数据分析/挖掘。请不要问我哪个容易,哪个前景好,哪个钱多。
先扯一下大数据的4V特征:
现如今,正式为了应对大数据的这几个特点,开源的大数据框架越来越多,越来越强,先列举一些常见的:
文件存储:Hadoop HDFS、Tachyon、KFS
离线计算:Hadoop MapRece、Spark
流式、实时计算:Storm、Spark Streaming、S4、Heron
K-V、NOSQL数据库:HBase、Redis、MongoDB
资源管理:YARN、Mesos
日志收集:Flume、Scribe、Logstash、Kibana
消息系统:Kafka、StormMQ、ZeroMQ、RabbitMQ
查询分析:Hive、Impala、Pig、Presto、Phoenix、SparkSQL、Drill、Flink、Kylin、Druid
分布式协调服务:Zookeeper
集群管理与监控:Ambari、Ganglia、Nagios、Cloudera Manager
数据挖掘、机器学习:Mahout、Spark MLLib
数据同步:Sqoop
任务调度:Oozie
……
眼花了吧,上面的有30多种吧,别说精通了,全部都会使用的,估计也没几个。
就我个人而言,主要经验是在第二个方向(开发/设计/架构),且听听我的建议吧。
第一章:初识Hadoop
1.1 学会网络与Google
不论遇到什么问题,先试试搜索并自己解决。
Google首选,翻不过去的,就用网络吧。
1.2 参考资料首选官方文档
特别是对于入门来说,官方文档永远是首选文档。
相信搞这块的大多是文化人,英文凑合就行,实在看不下去的,请参考第一步。
1.3 先让Hadoop跑起来
Hadoop可以算是大数据存储和计算的开山鼻祖,现在大多开源的大数据框架都依赖Hadoop或者与它能很好的兼容。
关于Hadoop,你至少需要搞清楚以下是什么:
自己搭建Hadoop,请使用第一步和第二步,能让它跑起来就行。
建议先使用安装包命令行安装,不要使用管理工具安装。
另外:Hadoop1.0知道它就行了,现在都用Hadoop 2.0.
1.4 试试使用Hadoop
HDFS目录操作命令;
上传、下载文件命令;
提交运行MapRece示例程序;
打开Hadoop WEB界面,查看Job运行状态,查看Job运行日志。
知道Hadoop的系统日志在哪里。
1.5 你该了解它们的原理了
MapRece:如何分而治之;
HDFS:数据到底在哪里,什么是副本;
Yarn到底是什么,它能干什么;
NameNode到底在干些什么;
ResourceManager到底在干些什么;
1.6 自己写一个MapRece程序
请仿照WordCount例子,自己写一个(照抄也行)WordCount程序,
打包并提交到Hadoop运行。
你不会java?Shell、python都可以,有个东西叫Hadoop Streaming。
如果你认真完成了以上几步,恭喜你,你的一只脚已经进来了。
第二章:更高效的WordCount
2.1 学点SQL吧
你知道数据库吗?你会写SQL吗?
如果不会,请学点SQL吧。
2.2 SQL版WordCount
在1.6中,你写(或者抄)的WordCount一共有几行代码?
给你看看我的:
SELECT word,COUNT(1) FROM wordcount GROUP BY word;
这便是SQL的魅力,编程需要几十行,甚至上百行代码,我这一句就搞定;使用SQL处理分析Hadoop上的数据,方便、高效、易上手、更是趋势。不论是离线计算还是实时计算,越来越多的大数据处理框架都在积极提供SQL接口。
2.3 SQL On Hadoop之Hive
什么是Hive?官方给的解释是:
The Apache Hive data warehouse software facilitates reading, writing, and managing large datasets residing in distributed storage and queried using SQL syntax.
为什么说Hive是数据仓库工具,而不是数据库工具呢?有的朋友可能不知道数据仓库,数据仓库是逻辑上的概念,底层使用的是数据库,数据仓库中的数据有这两个特点:最全的历史数据(海量)、相对稳定的;所谓相对稳定,指的是数据仓库不同于业务系统数据库,数据经常会被更新,数据一旦进入数据仓库,很少会被更新和删除,只会被大量查询。而Hive,也是具备这两个特点,因此,Hive适合做海量数据的数据仓库工具,而不是数据库工具。
2.4 安装配置Hive
请参考1.1 和 1.2 完成Hive的安装配置。可以正常进入Hive命令行。
2.5 试试使用Hive
请参考1.1 和 1.2 ,在Hive中创建wordcount表,并运行2.2中的SQL语句。
在Hadoop WEB界面中找到刚才运行的SQL任务。
看SQL查询结果是否和1.4中MapRece中的结果一致。
2.6 Hive是怎么工作的
明明写的是SQL,为什么Hadoop WEB界面中看到的是MapRece任务?
2.7 学会Hive的基本命令
创建、删除表;
加载数据到表;
下载Hive表的数据;
请参考1.2,学习更多关于Hive的语法和命令。
如果你已经按照《写给大数据开发初学者的话》中第一章和第二章的流程认真完整的走了一遍,那么你应该已经具备以下技能和知识点:
从上面的学习,你已经了解到,HDFS是Hadoop提供的分布式存储框架,它可以用来存储海量数据,MapRece是Hadoop提供的分布式计算框架,它可以用来统计和分析HDFS上的海量数据,而Hive则是SQL On Hadoop,Hive提供了SQL接口,开发人员只需要编写简单易上手的SQL语句,Hive负责把SQL翻译成MapRece,提交运行。
此时,你的”大数据平台”是这样的:
那么问题来了,海量数据如何到HDFS上呢?
第三章:把别处的数据搞到Hadoop上
此处也可以叫做数据采集,把各个数据源的数据采集到Hadoop上。
3.1 HDFS PUT命令
这个在前面你应该已经使用过了。
put命令在实际环境中也比较常用,通常配合shell、python等脚本语言来使用。
建议熟练掌握。
3.2 HDFS API
HDFS提供了写数据的API,自己用编程语言将数据写入HDFS,put命令本身也是使用API。
实际环境中一般自己较少编写程序使用API来写数据到HDFS,通常都是使用其他框架封装好的方法。比如:Hive中的INSERT语句,Spark中的saveAsTextfile等。
建议了解原理,会写Demo。
3.3 Sqoop
Sqoop是一个主要用于Hadoop/Hive与传统关系型数据库Oracle/MySQL/SQLServer等之间进行数据交换的开源框架。
就像Hive把SQL翻译成MapRece一样,Sqoop把你指定的参数翻译成MapRece,提交到Hadoop运行,完成Hadoop与其他数据库之间的数据交换。
自己下载和配置Sqoop(建议先使用Sqoop1,Sqoop2比较复杂)。
了解Sqoop常用的配置参数和方法。
使用Sqoop完成从MySQL同步数据到HDFS;
使用Sqoop完成从MySQL同步数据到Hive表;
PS:如果后续选型确定使用Sqoop作为数据交换工具,那么建议熟练掌握,否则,了解和会用Demo即可。
3.4 Flume
Flume是一个分布式的海量日志采集和传输框架,因为“采集和传输框架”,所以它并不适合关系型数据库的数据采集和传输。
Flume可以实时的从网络协议、消息系统、文件系统采集日志,并传输到HDFS上。
因此,如果你的业务有这些数据源的数据,并且需要实时的采集,那么就应该考虑使用Flume。
下载和配置Flume。
使用Flume监控一个不断追加数据的文件,并将数据传输到HDFS;
PS:Flume的配置和使用较为复杂,如果你没有足够的兴趣和耐心,可以先跳过Flume。
3.5 阿里开源的DataX
之所以介绍这个,是因为我们公司目前使用的Hadoop与关系型数据库数据交换的工具,就是之前基于DataX开发的,非常好用。
可以参考我的博文《异构数据源海量数据交换工具-Taobao DataX 下载和使用》。
现在DataX已经是3.0版本,支持很多数据源。
你也可以在其之上做二次开发。
PS:有兴趣的可以研究和使用一下,对比一下它与Sqoop。
如果你认真完成了上面的学习和实践,此时,你的”大数据平台”应该是这样的:
第四章:把Hadoop上的数据搞到别处去
前面介绍了如何把数据源的数据采集到Hadoop上,数据到Hadoop上之后,便可以使用Hive和MapRece进行分析了。那么接下来的问题是,分析完的结果如何从Hadoop上同步到其他系统和应用中去呢?
其实,此处的方法和第三章基本一致的。
4.1 HDFS GET命令
把HDFS上的文件GET到本地。需要熟练掌握。
4.2 HDFS API
同3.2.
4.3 Sqoop
同3.3.
使用Sqoop完成将HDFS上的文件同步到MySQL;
使用Sqoop完成将Hive表中的数据同步到MySQL;
4.4 DataX
同3.5.
如果你认真完成了上面的学习和实践,此时,你的”大数据平台”应该是这样的:
如果你已经按照《写给大数据开发初学者的话2》中第三章和第四章的流程认真完整的走了一遍,那么你应该已经具备以下技能和知识点:
知道如何把已有的数据采集到HDFS上,包括离线采集和实时采集;
你已经知道sqoop(或者还有DataX)是HDFS和其他数据源之间的数据交换工具;
你已经知道flume可以用作实时的日志采集。
从前面的学习,对于大数据平台,你已经掌握的不少的知识和技能,搭建Hadoop集群,把数据采集到Hadoop上,使用Hive和MapRece来分析数据,把分析结果同步到其他数据源。
接下来的问题来了,Hive使用的越来越多,你会发现很多不爽的地方,特别是速度慢,大多情况下,明明我的数据量很小,它都要申请资源,启动MapRece来执行。
第五章:快一点吧,我的SQL
其实大家都已经发现Hive后台使用MapRece作为执行引擎,实在是有点慢。
因此SQL On Hadoop的框架越来越多,按我的了解,最常用的按照流行度依次为SparkSQL、Impala和Presto.
这三种框架基于半内存或者全内存,提供了SQL接口来快速查询分析Hadoop上的数据。关于三者的比较,请参考1.1.
我们目前使用的是SparkSQL,至于为什么用SparkSQL,原因大概有以下吧:
使用Spark还做了其他事情,不想引入过多的框架;
Impala对内存的需求太大,没有过多资源部署;
5.1 关于Spark和SparkSQL
什么是Spark,什么是SparkSQL。
Spark有的核心概念及名词解释。
SparkSQL和Spark是什么关系,SparkSQL和Hive是什么关系。
SparkSQL为什么比Hive跑的快。
5.2 如何部署和运行SparkSQL
Spark有哪些部署模式?
如何在Yarn上运行SparkSQL?
使用SparkSQL查询Hive中的表。
PS: Spark不是一门短时间内就能掌握的技术,因此建议在了解了Spark之后,可以先从SparkSQL入手,循序渐进。
关于Spark和SparkSQL,可参考http://lxw1234.com/archives/category/spark
如果你认真完成了上面的学习和实践,此时,你的”大数据平台”应该是这样的:
第六章:一夫多妻制
请不要被这个名字所诱惑。其实我想说的是数据的一次采集、多次消费。
在实际业务场景下,特别是对于一些监控日志,想即时的从日志中了解一些指标(关于实时计算,后面章节会有介绍),这时候,从HDFS上分析就太慢了,尽管是通过Flume采集的,但Flume也不能间隔很短就往HDFS上滚动文件,这样会导致小文件特别多。
为了满足数据的一次采集、多次消费的需求,这里要说的便是Kafka。
6.1 关于Kafka
什么是Kafka?
Kafka的核心概念及名词解释。
6.2 如何部署和使用Kafka
使用单机部署Kafka,并成功运行自带的生产者和消费者例子。
使用Java程序自己编写并运行生产者和消费者程序。
Flume和Kafka的集成,使用Flume监控日志,并将日志数据实时发送至Kafka。
如果你认真完成了上面的学习和实践,此时,你的”大数据平台”应该是这样的:
这时,使用Flume采集的数据,不是直接到HDFS上,而是先到Kafka,Kafka中的数据可以由多个消费者同时消费,其中一个消费者,就是将数据同步到HDFS。
如果你已经按照《写给大数据开发初学者的话3》中第五章和第六章的流程认真完整的走了一遍,那么你应该已经具备以下技能和知识点:
从前面的学习,你已经掌握了大数据平台中的数据采集、数据存储和计算、数据交换等大部分技能,而这其中的每一步,都需要一个任务(程序)来完成,各个任务之间又存在一定的依赖性,比如,必须等数据采集任务成功完成后,数据计算任务才能开始运行。如果一个任务执行失败,需要给开发运维人员发送告警,同时需要提供完整的日志来方便查错。
第七章:越来越多的分析任务
不仅仅是分析任务,数据采集、数据交换同样是一个个的任务。这些任务中,有的是定时触发,有点则需要依赖其他任务来触发。当平台中有几百上千个任务需要维护和运行时候,仅仅靠crontab远远不够了,这时便需要一个调度监控系统来完成这件事。调度监控系统是整个数据平台的中枢系统,类似于AppMaster,负责分配和监控任务。
7.1 Apache Oozie
1. Oozie是什么?有哪些功能?
2. Oozie可以调度哪些类型的任务(程序)?
3. Oozie可以支持哪些任务触发方式?
4. 安装配置Oozie。
第八章:我的数据要实时
在第六章介绍Kafka的时候提到了一些需要实时指标的业务场景,实时基本可以分为绝对实时和准实时,绝对实时的延迟要求一般在毫秒级,准实时的延迟要求一般在秒、分钟级。对于需要绝对实时的业务场景,用的比较多的是Storm,对于其他准实时的业务场景,可以是Storm,也可以是Spark Streaming。当然,如果可以的话,也可以自己写程序来做。
8.1 Storm
1. 什么是Storm?有哪些可能的应用场景?
2. Storm由哪些核心组件构成,各自担任什么角色?
3. Storm的简单安装和部署。
4. 自己编写Demo程序,使用Storm完成实时数据流计算。
8.2 Spark Streaming
1. 什么是Spark Streaming,它和Spark是什么关系?
2. Spark Streaming和Storm比较,各有什么优缺点?
3. 使用Kafka + Spark Streaming,完成实时计算的Demo程序。
如果你认真完成了上面的学习和实践,此时,你的”大数据平台”应该是这样的:
至此,你的大数据平台底层架构已经成型了,其中包括了数据采集、数据存储与计算(离线和实时)、数据同步、任务调度与监控这几大模块。接下来是时候考虑如何更好的对外提供数据了。
第九章:我的数据要对外
通常对外(业务)提供数据访问,大体上包含以下方面:
离线:比如,每天将前一天的数据提供到指定的数据源(DB、FILE、FTP)等;离线数据的提供可以采用Sqoop、DataX等离线数据交换工具。
实时:比如,在线网站的推荐系统,需要实时从数据平台中获取给用户的推荐数据,这种要求延时非常低(50毫秒以内)。
根据延时要求和实时数据的查询需要,可能的方案有:HBase、Redis、MongoDB、ElasticSearch等。
OLAP分析:OLAP除了要求底层的数据模型比较规范,另外,对查询的响应速度要求也越来越高,可能的方案有:Impala、Presto、SparkSQL、Kylin。如果你的数据模型比较规模,那么Kylin是最好的选择。
即席查询:即席查询的数据比较随意,一般很难建立通用的数据模型,因此可能的方案有:Impala、Presto、SparkSQL。
这么多比较成熟的框架和方案,需要结合自己的业务需求及数据平台技术架构,选择合适的。原则只有一个:越简单越稳定的,就是最好的。
如果你已经掌握了如何很好的对外(业务)提供数据,那么你的“大数据平台”应该是这样的:
第十章:牛逼高大上的机器学习
关于这块,我这个门外汉也只能是简单介绍一下了。数学专业毕业的我非常惭愧,很后悔当时没有好好学数学。
在我们的业务中,遇到的能用机器学习解决的问题大概这么三类:
分类问题:包括二分类和多分类,二分类就是解决了预测的问题,就像预测一封邮件是否垃圾邮件;多分类解决的是文本的分类;
聚类问题:从用户搜索过的关键词,对用户进行大概的归类。
推荐问题:根据用户的历史浏览和点击行为进行相关推荐。
大多数行业,使用机器学习解决的,也就是这几类问题
3. flume如何监听日志数
1.采集日志文件时一个很常见的现象
采集需求:比如业务系统使用log4j生成日志,日志内容不断增加,需要把追加到日志文件中的数据实时采集到hdfs中。12
1.1.根据需求,首先定义一下3大要素:
采集源,即source—监控日志文件内容更新:exec ‘tail -F file’
下沉目标,即sink—HDFS文件系统:hdfs sink
Source和sink之间的传递通道—-channel,可用file channel也可以用 内存channel。
1.2.进入/home/tuzq/software/apache-flume-1.6.0-bin/agentconf,编写配置文件tail-hdfs.conf,文件内容如下:
# Name the components on this agenta1.sources = r1a1.sinks = k1
a1.channels = c1# Describe/configure the source## exec表示flume回去调用给的命令,然后从给的命令的结果中去拿数据a1.sources.r1.type = exec## 使用tail这个命令来读数据a1.sources.r1.command = tail -F /home/tuzq/software/flumedata/test.loga1.sources.r1.channels = c1# Describe the sink## 表示下沉到hdfs,类型决定了下面的参数a1.sinks.k1.type = hdfs## sinks.k1只能连接一个channel,source可以配置多个a1.sinks.k1.channel = c1## 下面的配置告诉用hdfs去写文件的时候写到什么位置,下面的表示不是写死的,而是可以动态的变化的。表示输出的目录名称是可变的a1.sinks.k1.hdfs.path = /flume/tailout/%y-%m-%d/%H%M/##表示最后的文件的前缀a1.sinks.k1.hdfs.filePrefix = events-## 表示到了需要触发的时间时,是否要更新文件夹,true:表示要a1.sinks.k1.hdfs.round = true## 表示每隔1分钟改变一次a1.sinks.k1.hdfs.roundValue = 1## 切换文件的时候的时间单位是分钟a1.sinks.k1.hdfs.roundUnit = minute## 表示只要过了3秒钟,就切换生成一个新的文件a1.sinks.k1.hdfs.rollInterval = 3## 如果记录的文件大于20字节时切换一次a1.sinks.k1.hdfs.rollSize = 20## 当写了5个事件时触发a1.sinks.k1.hdfs.rollCount = 5## 收到了多少条消息往dfs中追加内容a1.sinks.k1.hdfs.batchSize = 10## 使用本地时间戳a1.sinks.k1.hdfs.useLocalTimeStamp = true#生成的文件类型,默认是Sequencefile,可用DataStream:为普通文本a1.sinks.k1.hdfs.fileType = DataStream# Use a channel which buffers events in memory##使用内存的方式a1.channels.c1.type = memory
a1.channels.c1.capacity = 1000a1.channels.c1.transactionCapacity = 100# Bind the source and sink to the channela1.sources.r1.channels = c1
a1.sinks.k1.channel = 940414243444546474849
1.3.编写完成之后,启动flume,执行的命令是:
[root@hadoop1 flumedata]#cd /home/tuzq/software/apache-flume-1.6.0-bin/agentconf[root@hadoop1 flumedata]#bin/flume-ng agent -c conf -f agentconf/tail-hdfs.conf -n a112
1.4.通过写一个死循环往test.log中写数据的方式模式日志文件增长
编写shell脚本,模拟日志增长变化。
[root@hadoop1 flumedata]# cd /home/tuzq/software/flumedata[root@hadoop1 flumedata]# while true>do> date >> test.log> sleep 2> done123456
查看日志变化
[root@hadoop1 ~]# cd /home/tuzq/software/flumedata/[root@hadoop1 flumedata]# lsaccess.log error.log test.log[root@hadoop1 flumedata]# tail -f test.log 2017年 06月 13日 星期二 22:02:22 CST2017年 06月 13日 星期二 22:02:24 CST2017年 06月 13日 星期二 22:02:26 CST2017年 06月 13日 星期二 22:02:28 CST2017年 06月 13日 星期二 22:02:30 CST2017年 06月 13日 星期二 22:02:32 CST12345678910
通过上面的文件,可以看到test.log在不停的追加数据。
到hdfs中进行查看,效果如下:
[root@hadoop1 ~]# hdfs dfs -ls /Found 5 items
drwxr-xr-x - root supergroup 0 2017-06-13 12:01 /40000drwxr-xr-x - root supergroup 0 2017-06-13 22:01 /flume
-rw-r--r-- 3 root supergroup 3719 2017-06-10 12:11 /kms.sh
drwxrwxrwx - root supergroup 0 2017-06-10 22:06 /tmp
drwxr-xr-x - root supergroup 0 2017-06-10 22:27 /user
[root@hadoop1 ~]# hdfs dfs -ls /flumeFound 1 items
drwxr-xr-x - root supergroup 0 2017-06-13 22:01 /flume/tailout
[root@hadoop1 ~]# hdfs dfs -ls /flume/tailoutFound 1 items
drwxr-xr-x - root supergroup 0 2017-06-13 22:03 /flume/tailout/17-06-13[root@hadoop1 ~]# hdfs dfs -ls /flume/tailout/17-06-13Found 4 items
drwxr-xr-x - root supergroup 0 2017-06-13 22:01 /flume/tailout/17-06-13/2201drwxr-xr-x - root supergroup 0 2017-06-13 22:03 /flume/tailout/17-06-13/2202drwxr-xr-x - root supergroup 0 2017-06-13 22:04 /flume/tailout/17-06-13/2203drwxr-xr-x - root supergroup 0 2017-06-13 22:04 /flume/tailout/17-06-13/2204[root@hadoop1 ~]# hdfs dfs -ls /flume/tailout/17-06-13Found 5 items
drwxr-xr-x - root supergroup 0 2017-06-13 22:01 /flume/tailout/17-06-13/2201drwxr-xr-x - root supergroup 0 2017-06-13 22:03 /flume/tailout/17-06-13/2202drwxr-xr-x - root supergroup 0 2017-06-13 22:04 /flume/tailout/17-06-13/2203drwxr-xr-x - root supergroup 0 2017-06-13 22:05 /flume/tailout/17-06-13/2204drwxr-xr-x - root supergroup 0 2017-06-13 22:05 /flume/tailout/17-06-13/2205[root@hadoop1 /]# hdfs dfs -ls /flume/tailout/17-06-13Found 6 items
drwxr-xr-x - root supergroup 0 2017-06-13 22:01 /flume/tailout/17-06-13/2201drwxr-xr-x - root supergroup 0 2017-06-13 22:03 /flume/tailout/17-06-13/2202drwxr-xr-x - root supergroup 0 2017-06-13 22:04 /flume/tailout/17-06-13/2203drwxr-xr-x - root supergroup 0 2017-06-13 22:05 /flume/tailout/17-06-13/2204drwxr-xr-x - root supergroup 0 2017-06-13 22:06 /flume/tailout/17-06-13/2205drwxr-xr-x - root supergroup 0 2017-06-13 22:06 /flume/tailout/17-06-13/2206[root@hadoop1 /]
通过上面的案例可以知道,增加的日志文件已经被写入到HDFS中。
4. 如何使用Spooling Directory Source
最近在弄一个信令数据汇聚的事情,主要目的是把FTP上的信令数据汇聚到HDFS上去存储。 逻辑是这样的:把FTP服务器上的文件下载到一台主机上,然后SCP到另外一台主机上的Spooling Directory Source所监控的目录下面去,sink是hdfs(这里解释一下,由于网络环境的因素,另一台不能访问到内网的FTP服务器,所以只能这样中转一下)。 嗯,想法不错,逻辑上看上去也应该没啥问题,于是就开始吭哧吭哧写脚本了。FTP上每个信令数据的每个文件的大小差不多都有300M左右。SCP到远端服务器也没出现问题,可就是agent老是会挂掉,报这个异常: 2014-11-26 12:30:16,942 ERROR org.apache.flume.source.SpoolDirectorySource: FATAL: Spool Directory source source1: { spoolDir: /var/log/apache/flumeSpool }: Uncaught exception in SpoolDirectorySource thread. Restart or reconfigure Flume to continue processing. java.nio.charset.MalformedInputException: Input length = 1 at java.nio.charset.CoderResult.throwException(CoderResult.java:277) at org.apache.flume.serialization.ResettableFileInputStream.readChar(ResettableFileInputStream.java:195) at org.apache.flume.serialization.LineDeserializer.readLine(LineDeserializer.java:134) at org.apache.flume.serialization.LineDeserializer.readEvent(LineDeserializer.java:72) at org.apache.flume.serialization.LineDeserializer.readEvents(LineDeserializer.java:91) at org.apache.flume.client.avro..readEvents(.java:241) at org.apache.flume.source.SpoolDirectorySource$SpoolDirectoryRunnable.run(SpoolDirectorySource.java:224) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheledThreadPoolExecutor$ScheledFutureTask.access$301(ScheledThreadPoolExecutor.java:178) at java.util.concurrent.ScheledThreadPoolExecutor$ScheledFutureTask.run(ScheledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) 然后让我重启agent才会把Spooling Directory Source所监控的目录下面的文件抽取到HDFS上去,感觉很莫名,网上搜索了一下这个错误的原因,很多都是说可能传输的文件字符集的原因,不以为然,因为我反复测试了一下,如果是字符集的原因,那么为什么我重启一下agent又可以成功的抽取数据了。 于是我想了想是不是由于同时读写导致的问题,因为我SCP文件过去,文件较大,需要一定的时间,而flume监测到有文件马上就开始逐行读取文件转化成EVENT发送到HDFS上去,这中间肯定存在同时读写一个文件了,然后就产生的这个异常问题? 目前仅仅是猜测,于是我修改了Spooling Directory Source的配置,加了这么一个配置: tier1.sources.source1.ignorePattern = ^(.)*\\.tmp$ 就是忽略监控目录下面的.tmp文件。然后我修改了scp的逻辑,拷贝到另一台主机上时,先命名为:原文件名.tmp(由于是.tmp文件,agent不会采集此类文件),等SCP执行成功之后,在mv这个.tmp文件,去掉.tmp后缀,这样agent又会抽取这个文件的数据了,通过这么一处理,就巧妙的避免了同时读写一个文件的问题。 脚本调整好之后,重新运行脚本,惊喜的发现成功了,这次agent没有挂掉,大功告成了。 总结:使用Spooling Directory Source的时候,一定要避免同时读写一个文件的情况。采用上面提到的方法就可以巧妙的避开这个问题。
5. 数据仓库和数据库有什么区别和联系
简而言之,数据库是面向事务的设计,数据仓库是面向主题设计的。
数据库一般存储在线交易数据,数据仓库存储的一般是历史数据。
数据库设计是尽量避免冗余,一般采用符合范式的规则来设计,数据仓库在设计是有意引入冗余,采用反范式的方式来设计。
数据库是为捕获数据而设计,数据仓库是为分析数据而设计,它的两个基本的元素是维表和事实表。维是看问题的角度,比如时间,部门,维表放的就是这些东西的定义,事实表里放着要查询的数据,同时有维的ID。
单从概念上讲,有些晦涩。任何技术都是为应用服务的,结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台,客户在银行做的每笔交易都会写入数据库,被记录下来,这里,可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台,它从事务系统获取数据,并做汇总、加工,为决策者提供决策的依据。比如,某银行某分行一个月发生多少交易,该分行当前存款余额是多少。如果存款又多,消费交易又多,那么该地区就有必要设立ATM了。
显然,银行的交易量是巨大的,通常以百万甚至千万次来计算。事务系统是实时的,这就要求时效性,客户存一笔钱需要几十秒是无法忍受的,这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的,它要提供关注时间段内所有的有效数据。这些数据是海量的,汇总计算起来也要慢一些,但是,只要能够提供有效的分析数据就达到目的了。
数据仓库,是在数据库已经大量存在的情况下,为了进一步挖掘数据资源、为了决策需要而产生的,它决不是所谓的“大型数据库”。那么,数据仓库与传统数据库比较,有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。
“面向主题的”:传统数据库主要是为应用程序进行数据处理,未必按照同一主题存储数据;数据仓库侧重于数据分析工作,是按照主题存储的。这一点,类似于传统农贸市场与超市的区别—市场里面,白菜、萝卜、香菜会在一个摊位上,如果它们是一个小贩卖的;而超市里,白菜、萝卜、香菜则各自一块。也就是说,市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的,超市里面则是按照菜的类型(同主题)归堆的。
“与时间相关”:数据库保存信息的时候,并不强调一定有时间信息。数据仓库则不同,出于决策的需要,数据仓库中的数据都要标明时间属性。决策中,时间属性很重要。同样都是累计购买过九车产品的顾客,一位是最近三个月购买九车,一位是最近一年从未买过,这对于决策者意义是不同的。
“不可修改”:数据仓库中的数据并不是最新的,而是来源于其它数据源。数据仓库反映的是历史信息,并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此,数据仓库中的数据是极少或根本不修改的;当然,向数据仓库添加数据是允许的。
数据仓库的出现,并不是要取代数据库。目前,大部分数据仓库还是用关系数据库管理系统来管理的。可以说,数据库、数据仓库相辅相成、各有千秋。
补充一下,数据仓库的方案建设的目的,是为前端查询和分析作为基础,由于有较大的冗余,所以需要的存储也较大。为了更好地为前端应用服务,数据仓库必须有如下几点优点,否则是失败的数据仓库方案。
1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等,可以看出,日为周期的数据要求的效率最高,要求24小时甚至12小时内,客户能看到昨天的数据分析。由于有的企业每日的数据量很大,设计不好的数据仓库经常会出问题,延迟1-3日才能给出数据,显然不行的。
2.数据质量。客户要看各种信息,肯定要准确的数据,但由于数据仓库流程至少分为3步,2次ETL,复杂的架构会更多层次,那么由于数据源有脏数据或者代码不严谨,都可以导致数据失真,客户看到错误的信息就可能导致分析出错误的决策,造成损失,而不是效益。
3.扩展性。之所以有的大型数据仓库系统架构设计复杂,是因为考虑到了未来3-5年的扩展性,这样的话,客户不用太快花钱去重建数据仓库系统,就能很稳定运行。主要体现在数据建模的合理性,数据仓库方案中多出一些中间层,使海量数据流有足够的缓冲,不至于数据量大很多,就运行不起来了。
6. flume 下沉到hdfs的配置文件中round如何理解
返回某个数字按指定位数取整后的数字。 语法 ROUND(number,num_digits) Number 需要进行四舍五入的数字。 Num_digits 指定的位数,按此位数进行四舍五入。 如公式:=ROUND(5.555,2)将数值5.555保留两位小数,返回值是5.56 如公式:=ROUND(5.554,2)将数值5.554保留两位小数,返回值是5.55
7. flume 抽取的数据怎么格式化
最近在弄一个信令数据汇聚的事情,主要目的是把FTP上的信令数据汇聚到HDFS上去存储。 逻辑是这样的:把FTP服务器上的文件下载到一台主机上,然后SCP到另外一台主机上的Spooling Directory Source所监控的目录下面去,sink是hdfs(这里解释一下,...
8. 大数据如何入门
首先我们要了解Java语言和Linux操作系统,这两个是学习大数据的基础,学习的顺序不分前后。
大数据
Java :只要了解一些基础即可,做大数据不需要很深的Java 技术,学java SE 就相当于有学习大数据基础。
Linux:因为大数据相关软件都是在Linux上运行的,所以Linux要学习的扎实一些,学好Linux对你快速掌握大数据相关技术会有很大的帮助,能让你更好的理解hadoop、hive、hbase、spark等大数据软件的运行环境和网络环境配置,能少踩很多坑,学会shell就能看懂脚本这样能更容易理解和配置大数据集群。还能让你对以后新出的大数据技术学习起来更快。
Hadoop:这是现在流行的大数据处理平台几乎已经成为大数据的代名词,所以这个是必学的。Hadoop里面包括几个组件HDFS、MapRece和YARN,HDFS是存储数据的地方就像我们电脑的硬盘一样文件都存储在这个上面,MapRece是对数据进行处理计算的,它有个特点就是不管多大的数据只要给它时间它就能把数据跑完,但是时间可能不是很快所以它叫数据的批处理。
Zookeeper:这是个万金油,安装Hadoop的HA的时候就会用到它,以后的Hbase也会用到它。它一般用来存放一些相互协作的信息,这些信息比较小一般不会超过1M,都是使用它的软件对它有依赖,对于我们个人来讲只需要把它安装正确,让它正常的run起来就可以了。
Mysql:我们学习完大数据的处理了,接下来学习学习小数据的处理工具mysql数据库,因为一会装hive的时候要用到,mysql需要掌握到什么层度那?你能在Linux上把它安装好,运行起来,会配置简单的权限,修改root的密码,创建数据库。这里主要的是学习SQL的语法,因为hive的语法和这个非常相似。
Sqoop:这个是用于把Mysql里的数据导入到Hadoop里的。当然你也可以不用这个,直接把Mysql数据表导出成文件再放到HDFS上也是一样的,当然生产环境中使用要注意Mysql的压力。
Hive:这个东西对于会SQL语法的来说就是神器,它能让你处理大数据变的很简单,不会再费劲的编写MapRece程序。有的人说Pig那?它和Pig差不多掌握一个就可以了。
Oozie:既然学会Hive了,我相信你一定需要这个东西,它可以帮你管理你的Hive或者MapRece、Spark脚本,还能检查你的程序是否执行正确,出错了给你发报警并能帮你重试程序,最重要的是还能帮你配置任务的依赖关系。我相信你一定会喜欢上它的,不然你看着那一大堆脚本,和密密麻麻的crond是不是有种想屎的感觉。
Hbase:这是Hadoop生态体系中的NOSQL数据库,他的数据是按照key和value的形式存储的并且key是唯一的,所以它能用来做数据的排重,它与MYSQL相比能存储的数据量大很多。所以他常被用于大数据处理完成之后的存储目的地。
Kafka:这是个比较好用的队列工具,队列是干吗的?排队买票你知道不?数据多了同样也需要排队处理,这样与你协作的其它同学不会叫起来,你干吗给我这么多的数据(比如好几百G的文件)我怎么处理得过来,你别怪他因为他不是搞大数据的,你可以跟他讲我把数据放在队列里你使用的时候一个个拿,这样他就不在抱怨了马上灰流流的去优化他的程序去了,因为处理不过来就是他的事情。而不是你给的问题。当然我们也可以利用这个工具来做线上实时数据的入库或入HDFS,这时你可以与一个叫Flume的工具配合使用,它是专门用来提供对数据进行简单处理,并写到各种数据接受方(比如Kafka)的。
Spark:它是用来弥补基于MapRece处理数据速度上的缺点,它的特点是把数据装载到内存中计算而不是去读慢的要死进化还特别慢的硬盘。特别适合做迭代运算,所以算法流们特别稀饭它。它是用scala编写的。Java语言或者Scala都可以操作它,因为它们都是用JVM的。
9. 如何使用Spooling Directory Source
最近在弄一个信令数据汇聚的事情,主要目的是把FTP上的信令数据汇聚到HDFS上去存储。 逻辑是这样的:把FTP服务器上的文件下载到一台主机上,然后SCP到另外一台主机上的Spooling Directory Source所监控的目录下面去,sink是hdfs(这里解释一下,由于网络环境的因素,另一台不能访问到内网的FTP服务器,所以只能这样中转一下)。
嗯,想法不错,逻辑上看上去也应该没啥问题,于是就开始吭哧吭哧写脚本了。FTP上每个信令数据的每个文件的大小差不多都有300M左右。SCP到远端服务器也没出现问题,可就是agent老是会挂掉,报这个异常:
2014-11-26 12:30:16,942 ERROR org.apache.flume.source.SpoolDirectorySource: FATAL: Spool Directory source source1: { spoolDir: /var/log/apache/flumeSpool }: Uncaught exception in SpoolDirectorySource thread. Restart or reconfigure Flume to continue processing.
java.nio.charset.MalformedInputException: Input length = 1
at java.nio.charset.CoderResult.throwException(CoderResult.java:277)
at org.apache.flume.serialization.ResettableFileInputStream.readChar(ResettableFileInputStream.java:195)
at org.apache.flume.serialization.LineDeserializer.readLine(LineDeserializer.java:134)
at org.apache.flume.serialization.LineDeserializer.readEvent(LineDeserializer.java:72)
at org.apache.flume.serialization.LineDeserializer.readEvents(LineDeserializer.java:91)
at org.apache.flume.client.avro..readEvents(.java:241)
at org.apache.flume.source.SpoolDirectorySource$SpoolDirectoryRunnable.run(SpoolDirectorySource.java:224)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at java.util.concurrent.ScheledThreadPoolExecutor$ScheledFutureTask.access$301(ScheledThreadPoolExecutor.java:178)
at java.util.concurrent.ScheledThreadPoolExecutor$ScheledFutureTask.run(ScheledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
然后让我重启agent才会把Spooling Directory Source所监控的目录下面的文件抽取到HDFS上去,感觉很莫名,网上搜索了一下这个错误的原因,很多都是说可能传输的文件字符集的原因,不以为然,因为我反复测试了一下,如果是字符集的原因,那么为什么我重启一下agent又可以成功的抽取数据了。
于是我想了想是不是由于同时读写导致的问题,因为我SCP文件过去,文件较大,需要一定的时间,而flume监测到有文件马上就开始逐行读取文件转化成EVENT发送到HDFS上去,这中间肯定存在同时读写一个文件了,然后就产生的这个异常问题?
目前仅仅是猜测,于是我修改了Spooling Directory Source的配置,加了这么一个配置:
tier1.sources.source1.ignorePattern = ^(.)*\\.tmp$
就是忽略监控目录下面的.tmp文件。然后我修改了scp的逻辑,拷贝到另一台主机上时,先命名为:原文件名.tmp(由于是.tmp文件,agent不会采集此类文件),等SCP执行成功之后,在mv这个.tmp文件,去掉.tmp后缀,这样agent又会抽取这个文件的数据了,通过这么一处理,就巧妙的避免了同时读写一个文件的问题。
脚本调整好之后,重新运行脚本,惊喜的发现成功了,这次agent没有挂掉,大功告成了。
总结:使用Spooling Directory Source的时候,一定要避免同时读写一个文件的情况。采用上面提到的方法就可以巧妙的避开这个问题。