数据处理

hadoop集群与伪分布式的性能对比 镜像centos6.5，hadoop-2.6.0，mysql-5.4.0，hive-1.2.1 集群配置：master 4g1核，2个处理器，子节点（2个）：1g1核，1个处理器 伪分布式：4g1核，2个处理器 使用hql测试： 数据： hive> select *from course; 01 语文 02 02 数学 01 03 英语 03 hive> select *from teacher; 01 张三 02 李四 03 王五 hive> select *from student; 01 赵雷 1990-01-01 男 02 钱电 1990-12-21 男 03 孙风 1990-05-20 男 04 李云 1990-08-06 男 05 周梅 1991-12-01 女 06 吴兰 1992-03-01 女 07 郑竹 1989-07-01 女 08 王菊 1990-01-20 女 hive> select *from score; 01 01 80 01 02 90 01 03 99 02 01 70 02 02 60 02 03 80 03 01 80 03 02 80 03 03 80 04 01 50 04 02 30 04 03 20 05 01 76 05 02 87 06 01 31 06 03 34 07 02 89 07

MapReudce(三) 本文项目地址: https://github.com/KingBobTitan/hadoop.git MR的Shuffle详解及Join实现 一、回顾 1、MapReduce的历史监控服务：JobHistoryServer 功能：用于监控所有在YARN上运行过的MapReduce程序的信息 配置YARN的日志聚集：存储在hdfs上 启动：web:19888 2、自定义数据类型：在Hadoop中封装JavaBean 封装需要实现序列化 实现接口 Writable：只实现了序列化 write：序列化 readFields：反序列化 WritableComparable：实现了序列化和比较器 write：序列化 readFields：反序列化 compareTo：比较的方法 如果自定义的类型作为key会经过shuffle过程，就需要实现WritableComparable接口 排序：自定义数据类型 先检查有没有排序器，如果有排序器就使用排序器 job.setSortComaparator(RawComparator<T>) => extends WritableComparator 如果没有，就调用该类型自带的comparableTo 如果两个都没有，就报错 排序：默认类型：Text、IntWritable 先检查有没有排序器，如果有排序器就使用排序器

解决这一问题的基本思路是让正负样本在训练过程中拥有相同的话语权，比如利用采样与加权等方法。为了方便起见，我们把数据集中样本较多的那一类称为“大众类”，样本较少的那一类称为“小众类”。 解决方式分为： 一、相关方法总结 1、采样 采样方法是通过对训练集进行处理使其从不平衡的数据集变成平衡的数据集，在大部分情况下会对最终的结果带来提升。 采样分为上采样（Oversampling，过采样）和下采样（Undersampling， 欠采样），上采样是把小种类复制多份，下采样是从大众类中剔除一些样本，或者说只从大众类中选取部分样本。 随机采样最大的优点是简单，但缺点也很明显。上采样后的数据集中会反复出现一些样本，训练出来的模型会有一定的过拟合；而下采样的缺点显而易见，那就是最终的训练集丢失了数据，模型只学到了总体模式的一部分。 上采样会把小众样本复制多份，一个点会在高维空间中反复出现，这会导致一个问题，那就是运气好就能分对很多点，否则分错很多点。为了解决这一问题，可以在每次生成新数据点时加入轻微的随机扰动，经验表明这种做法非常有效。 ——这一方式会加重过拟合！ 因为下采样会丢失信息，如何减少信息的损失呢？ 第一种方法叫做EasyEnsemble，利用模型融合的方法（Ensemble）：多次下采样（放回采样，这样产生的训练集才相互独立）产生多个不同的训练集，进而训练多个不同的分类器

大数据的热度在持续的升温，继云计算之后大数据成为又一大众所追捧的新星。我们暂不去讨论大数据到底是否适用于您的公司或组织，至少在互联网上已经被吹嘘成无所不能的超级战舰。好像一夜之间我们就从互联网时代跳跃进了大数据时代!关于到底什么是大数据，说真的，到目前为止就和云计算一样，让我总觉得像是在看电影《云图》——云里雾里的感觉。或许那些正在向你推销大数据产品的公司会对您描绘一幅乌托邦似的美丽画面，但是您至少要保持清醒的头脑，认真仔细的慎问一下自己，我们公司真的需要大数据吗? 做为一家第三方支付公司，数据的确是公司最最重要的核心资产。由于公司成立不久，随着业务的迅速发展，交易数据呈几何级增加，随之而来的是系统的不堪重负。业务部门、领导、甚至是集团老总整天嚷嚷的要报表、要分析、要提升竞争力。而研发部门能做的唯一事情就是执行一条一条复杂到自己都难以想象的SQL语句，紧接着系统开始罢工，内存溢出，宕机........简直就是噩梦。OMG!please release me!!! 其实数据部门的压力可以说是常人难以想象的，为了把所有离散的数据汇总成有价值的报告，可能会需要几个星期的时间或是更长。这显然和业务部门要求的快速响应理念是格格不入的。俗话说，工欲善其事，必先利其器。我们也该鸟枪换炮了......。 网上有一大堆文章描述着大数据的种种好处，也有一大群人不厌其烦的说着自己对大数据的种种体验

1.基于内存 2.迭代式计算 3.分布式 基本工作原理： 将spark的程序提交到spark集群上，在Hadoop的HDFS或者Hive上读取数据，读取的数据存放在各个spark的节点上，分布式的存放在多个节点上，主要在每个节点的内存上，这样可以加快速度。 对节点的数据进行处理，处理后的数据存放在其他的节点的内存上。对数据的 计算操作针对多个节点上的数据进行并行操作。处理之后的数据可以到hadoop或者mysql或hbase中，或者结果直接返回客户端。 每一批处理的数据就是一个RDD spark开发：离线批处理，延迟性的交互式数据处理；SQL查询；实时查询。底层都是RDD和计算操作。 1.创建RDD 2.定义对RDD的计算操作 3.循环往复的过程，第一次计算之后，数据到了新的一批节点上，变成新的RDD，在进行计算操作。 4.获得最终的数据，将数据存储火哦返回给客户端。 spark与mapreduce的不同在于分布式处理，mapreduce里只有map和reduce两个 过程，spark在处理一个阶段之后可以继续处理很多个阶段，不止两个阶段，spark可以处理更多的数据 RDD（弹性分布式数据集）是spark提供的核心抽象 RDD在抽象上是一种元素集合，包含了数据，他是被分区的，分为多个分区，每个分区分布在集群中的不同节点上，从而让RDD中的数据 可以被并行操作。（分布式）

在spark streaming读取kafka的数据中，spark streaming提供了两个接口读取kafka中的数据，分别是KafkaUtils.createDstream，KafkaUtils.createDirectStream，前者会自动把offset更新到zk中，默认会丢数据，效率低，后者不会经过zk，效率更高，需要自己手动维护offse，通过维护护offset写到zk中，保障数据零丢失，只处理一次，下面来看看KafkaUtils.createDirectStream的使用，我把zk的端口改成了9999，防止和kakfa自带的zk的端口产生冲突，下面我写了一些测试代码，经自己测试数据没任何问题，即使spark streaming挂了 ，另一方往topic中写数据，下次启动streaming程序也能读取，做到数据零丢失，不同的group.id下只读取一次，看看下面代码吧(代码是自己查看kafka中自带的接口和一些其他的资料组合而成，简单的写了一些，参数没写成配置) 来源： https://www.cnblogs.com/chong-zuo3322/p/12244342.html

计数器 计数器是一种收集作业统计信息的有效手段，用于质量控制或应用级统计。说白了就是统计整个mr作业所有数据行中符合某个if条件的数量，（除某些内置计数器之外）。仅当一个作业执行成功之后，计数器的值才是完整可靠的。如果一个任务在作业执行期间失败，则相关计数器值会减小，计数器是全局的。 计数器分为以下几种： 1）内置计数器，内置的作业计数器实际上由jobtracker维护，而不必在整个网络中发送； 2）用户自定义的java计数器，由其关联任务维护，并定期传到tasktracker，再由tasktracker传给jobtracker，可以定义多个枚举类型，每个枚举类型有多个字段，枚举类型名称即为组名，枚举字段名称即为计数器名称。 Reporter对象的incrCounter()方法重载： public void incrCounter(enum,long amout) 3）动态计数器，不由java枚举类型定义的计数器，由于在编译阶段就已指定java枚举类型的字段，故无法使用枚举类型动态新建计数器。 Reporter对象的incrCounter()方法重载： public void incrCounter(String group,String counter,long amout) 自定义java计数器由于使用枚举类型，默认名称为（枚举名称）$（枚举字段名称），可读性较差

　　时至今日，已然看到第十章，似乎越是焦躁什么时候能翻完这本圣经的时候也让自己变得更加浮躁，想想后面还有一半的行程没走，我觉得这样“有口无心”的学习方式是不奏效的，或者是收效甚微的。如果有幸能有大牛路过，请指教如何能以效率较高的方式学习Hadoop。 　　我已经记不清圣经《hadoop 实战2》在我手中停留了多久，但是每一页每一章的翻过去，还是在脑壳里留下了点什么。 　　一段时间以来，我还是通过这本书加深以及纠正了我对于MapReduce、HDFS乃至Hadoop的新的认识。本篇主要介绍MapReduce作业的工作机制，并介绍介于Map和Reduce过程中的Shuffle和排序过程。 　　为响应标题，我们今天谈的MapReduce机制，切入点是一张图。先上图： 　　 　　从图中不难看出，整个MapReduce分为以下流程：代码编写->作业配置->作业提交->Map任务的分配和执行->处理中间结果->Reduce任务的分配和执行->作业完成 　　图中： 　　1.运行作业 　　2.获取作业ID 　　3.复制作业资源 　　4.提交作业 　　5.初始化作业 　　6.获取输入分割 　　7.心跳通信 　　8.获取作业资源 　　9.发布 　　10.运行 　　以上过程主要涉及到的实体有客户端（用于MR代码的编写，配置作业，提交作业）；TaskTracker（保持与JobTracker通信

　　数据排序是许多实际任务在执行时要完成的第一项工作，比如学生成绩评比、数据建立索引等。这个实例和数据去重类似，都是先对原始数据进行初步处理，为进一步的数据操作打好基础。 1.实例描述 　　对输入文件中的数据进行排序。输入文件中的每行内容均为一个数字，即一个数据。要求在输出中每行有两个间隔的数字，其中，第二个数字代表原始数据，第一个数字这个原始数据在原始数据集中的位次。 　　样例输入： 　　file1: 　　2 　　32 　　654 　　32 　　15 　　756 　　65223 　　file2: 　　5956 　　22 　　650 　　92 　　file3: 　　26 　　54 　　6 　　样例输出： 　　 2.设计思路 　　这个实例仅仅要求对输入数据进行排序，熟悉MapReduce过程的读者很快会想到在MapReduce过程中就有排序。是否可以利用这个默认的排序、而不需要自己在实现具体的排序呢？答案是肯定的。但是在使用之前首先要了解MapReduce过程中的默认排序规则。它是按照key值进行排序，如果key为封装int的IntWritable类型，那么MapReduce按照数字大小对key排序；如果key为封装String的Text类型，那么MapReduce按照字典顺序对字符串排序。需要注意的是，Reduce自动排序的数据仅仅是发送到自己所在节点的数据

前言    当今天下，大数据组件百花齐放，满足不同应用场景的计算框架层出不穷，mapreduce似乎早已很难有一席之地，但是天下武功，殊途同归，不管怎么变化，都离不开mapreduce的基础，今天，就一起揭开下最原始的计算框架mapreduce的面纱。 核心设计理念    分布式计算，即移动计算 而不移动数据。 原理剖析    如图1，官方给出的mapreduce剑谱，一招一式，尽显奥妙无穷，整体个人觉得分为4部分，split阶段，map阶段，shuffle阶段，reduce阶段，具体如下： 图1 官方mapreduce原理图谱 Split阶段    Map阶段之前还有个准备，就是split，中文意思就是分片，顾名思义就是当一个大文件要进行mapreduce计算时，假设2T，不可能把2T文件全部加载到内存，先要对文件进行切割，就是对应的split操作，那切割成多大才合理呢？split有个原理公式： long minSize = Math . max ( getFormatMinSplitSize ( ) , getMinSplitSize ( job ) ) ; long maxSize = getMaxSplitSize ( job ) ; long blockSize = file . getBlockSize ( ) ; long splitSize =