数据处理

随着两会中间央视新闻天天说大数据，很多人纷纷开始关注大数据和Hadoop以及数据挖掘和数据可视化了，我现在创业，遇到很多传统数据行业往Hadoop上面去转型的公司和个人，提了很多问题，大多数问题还都是差不多的。所以我想整理一些，也可能是很多人都关注的问题。 关于 Hadoop版本的选择？ 目前为止，作为半只脚迈进Hadoop大门的人，我建议大家还是选择Hadoop 1.x用。可能很多人会说，Hadoop都出到2.4，为啥还用1.x呢，说这话一听就没玩过hadoop。 理由一： Hadoop 1.x和2.x是完全两个不同的东西， 并不是像说单机的webserver从1.0升级到2.0那么简单的事情。也不是说我现在用的mysql 5.0，只要编译一个新版本就直接无缝迁移到5.5的事情。Hadoop从1.0过度到2.0是整个架构体系全部推翻重写的。从实现方式到用户接口完全是两个完全不同的东西，不要简单的认为那不过就像nginx从0.8升级到1.4一样。所以我给的建议是，生产环境用1.x，实验环境部署2.x作为熟悉使用。 理由二： 依然是，Hadoop不是webserver，分布式系统尽管Hadoop实现出来了 ，但是他仍然是非常复杂的一套体系，单说HDFS存储，以前Hadoop 0.20.2想升级到0.20.203，首先你需要在所有节点部署上新版的Hadoop，然后停止整个集群的所有服务

Parquet是一种存储格式，其本身与任何语言、平台都没有关系，也不需要与任何一种数据处理框架绑定。但是一个开源技术的发展，必然需要有合适的生态圈助力才行，Spark便是Parquet的核心助力之一。作为内存型并行计算引擎，Spark被广泛应用在流处理、离线处理等场景，其从1.0.0便开始支持Parquet，方便我们操作数据。 在Spark中操作Parquet文件有两种方式，一种是直接加载文件，另一种是透过Hive表来读取数据。我们姑且称之为文件加载、表加载。这两种方式在API层面都非常简洁，它隐藏了底层推导Schema、并行加载数据等细节。 # By File df = spark . read . parquet ( "s3://mydata/type=security" ) # By Table df = spark . read . table ( "data_mine.security_log" ) 在实际使用中，我们经常会遇到 Schema兼容 的问题，其根源是Schema不一致，主要有以下两种情况： 存放在HDFS/S3上面的Parquet文件具有不同的Schema Hive Metastore Schema与Parquet文件自带的Schema不一致 不管是需求变化、产品迭代还是其他原因，总是会出现Schema变化的情况，导致不同Parquet文件的Schema不同

1.概述 　　在Hadoop应用，随着业务指标的迭代，而使其日趋复杂化的时候，管理Hadoop的相关应用会变成一件头疼的事情，如：作业的依赖调度，任务的运行情况的监控，异常问题的排查等，这些问题会是的我们日常的工作变得复杂。那么，在没有条件和精力去开发一套调度系统的情况下，我们去选择一款第三方开源的调度系统，来尽量减轻和降低我们日常工作的复杂度，也是极好的。今天，笔者给大家比较几种常见的调度系统，供大家去选择。 2.内容 2.1 Oozie 　　Oozie目前是托管在Apache基金会的，开源。在之前的博客《 Oozie调度 》一文当中，介绍相关Oozie的调度，如何去调度Hadoop的相关，大家可以从博客的文中所描述的内容看出，配置的过程略显繁琐和复杂，配置相关的调度任务比较麻烦，然其可视化界面也不是那么的直观，另外，对UI界面要求较高的同学，此调度系统估计会让你失望。若是对改调度系统感兴趣的同学可以到《 Oozie调度 》一文中做相关细节的了解。这里就不多做赘述了。 2.2 Zeus 　　它是一个Hadoop的作业平台，从Hadoop任务的调试运行到生产任务的周期调度，它支持任务的整个生命周期。从其功能来看，它支持以下任务： Hadoop的MapReduce任务调度运行 Hive任务的调度运行 Shell任务的运行 Hive元数据的可视化展示查询及数据预览

环境描述 根据需求，部署hadoop-3.0.0基础功能架构，以三节点为安装环境，操作系统CentOS 7 x64； openstack创建三台虚拟机，开始部署； IP地址 主机名 10.10.204.31 master 10.10.204.32 node1 10.10.204.33 node2 功能节点规划 master node1 node2 NameNode DataNode DataNode DataNode HQuorumPeer NodeManager NodeManager ResourceManager SecondaryNameNode HMaster 三节点执行初始化操作； 1.更新系统环境； yum clean all && yum makecache fast && yum update -y && yum install -y wget vim net-tools git ftp zip unzip 2.根据规划修改主机名； hostnamectl set-hostname master hostnamectl set-hostname node1 hostnamectl set-hostname node2 3.添加hosts解析； vim /etc/hosts 10.10.204.31 master 10.10.204.32 node1 10.10

1. 需求 在处理时间序列或者是有序数据时候，经常会越到这样的情形：1、求客户最近一个月的平均消费金额；2、求客户最近一个月的消费次数；3、求与客户在最近一个月内发生大额消费的客户数量 上述问题中，问题1与问题2是典型的求指定客户在指定时间段的行为统计值，可以通过客户进行分组然后过滤统计即可，而问题三则是求解与该客户在指定时间段内发生某种行为的客户数量，即没有具体的聚合Key，从而不同按照问题1与问题2进行分组的方式求解，而通过类似时间序列中求一个序列的移动平均方法来求解 针对上述两类情形，下面分别提供了两个函数，这个两个函数，一个是aggregateByKey，根据key聚合，并对聚合后的每一条记录采用窗口函数获取聚合数据，即该函数是对每一个key对应的value进行移动聚合操作。另一个是aggregateByAll，根据key进行排序，通过窗口函数获取结果进行聚合。这两个函数都是根据窗口函数进行聚合操作，但不同点在于作用范围不同。 窗口函数与聚合函数用户定义可以自由定义，通过定义不同的窗口函数与聚合函数，可以实现不同的移动逻辑以及聚合运算。 2. 实现思路 2.1 aggregateByKey aggregateByKey实现起来比较简单，因为一般情况先，单个key对应的value不会很大（单个executor的内存是可以装得下的）

1. 需求 在处理时间序列或者是有序数据时候，经常会越到这样的情形：1、求客户最近一个月的平均消费金额；2、求客户最近一个月的消费次数；3、求与客户在最近一个月内发生大额消费的客户数量 上述问题中，问题1与问题2是典型的求指定客户在指定时间段的行为统计值，可以通过客户进行分组然后过滤统计即可，而问题三则是求解与该客户在指定时间段内发生某种行为的客户数量，即没有具体的聚合Key，从而不同按照问题1与问题2进行分组的方式求解，而通过类似时间序列中求一个序列的移动平均方法来求解 针对上述两类情形，下面分别提供了两个函数，这个两个函数，一个是aggregateByKey，根据key聚合，并对聚合后的每一条记录采用窗口函数获取聚合数据，即该函数是对每一个key对应的value进行移动聚合操作。另一个是aggregateByAll，根据key进行排序，通过窗口函数获取结果进行聚合。这两个函数都是根据窗口函数进行聚合操作，但不同点在于作用范围不同。 窗口函数与聚合函数用户定义可以自由定义，通过定义不同的窗口函数与聚合函数，可以实现不同的移动逻辑以及聚合运算。 2. 实现思路 2.1 aggregateByKey aggregateByKey实现起来比较简单，因为一般情况先，单个key对应的value不会很大（单个executor的内存是可以装得下的）

本期内容 exactly once 输入不重复 输出不重复 exactly once ：有且仅被执行一次。（不多，不少，一次刚好） 首先和大家聊下概念： 事务是恢复和 并发控制 的基本单位。 事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为 ACID特性 。 原子性（atomicity）。一个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。 一致性（consistency）。事务必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。 隔离性（isolation）。一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务是隔离的，并发执行的各个事务之间不能互相干扰。 持久性（durability）。持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。接下来的其他操作或故障不应该对其有任何影响。 简单记忆法则(一持原隔) 如：银行转账，A向B转账500元，这个步骤可以分为A扣500元，B加500元 两部分。 如果 A减500元成功后，在B加500元的时候失败了，那么A减掉的500就不生效。也就是说。要么两个操作都成功，要么两个操作都失败。 先了解下SparkStreaming的数据流转流程 数据一致性的要求： 数据源可靠。数据源产生出来后

大数据处理系统可以分为批式(batch)大数据和流式(streaming)大数据两类。其中，批式大数据又被称为历史大数据，流式大数据又被称为实时大数据。 目前主流的三大分布式计算系统Hadoop、Storm、Spark被广泛运用于大数据领域。 批处理大数据系统代表：Hadoop 注：这类系统虽然可对完整大数据集实现高效的即席查询，但无法查询到最新的实时数据，存在数据迟滞高等问题 流处理大数据系统代表：Spark Streaming、Storm（计算系统） 注：此类系统可以对最新实时数据实现高效预设分析处理模型的查询，数据迟滞低 1、分布式计算架构Hadoop Hadoop作为分布式系统的基础架构，数据处理工作在硬盘层面，借助HDFS(分布式文件系统)，可以将架构下每一台电脑中的硬盘资源聚集起来，不论是存储计算还是调用都可以视为一块硬盘使用。之后使用集群管理和调度软件YARN，相当于Windows操作系统，最后利用Map/Reduce计算框架就可以在这上面进行计算编程。从而大幅降低了整体计算平台的硬件投入成本。 2、流数据处理Spark和Storm 由于Hadoop的计算过程放在硬盘，受制于硬件条件限制，数据的吞吐和处理速度明显不如使用内存来的快。于是Spark和Storm开始登上舞台。 Spark和Storm两者最大的区别在于实时性：Spark是准实时

主要问题 处理流式数据的两种方法 静态数据的几种格式 要介绍流式数据的处理，首先要介绍spark的几种静态的数据结构：RDD、dataset和dataframe。 简单来讲，RDD是spark最基础的数据，可以看出一行行独立的数据，每一行内部是封闭的黑箱，在MapReduce之前不知道是啥（MapReduce是hadoop的一种计算模型，浅显一点理解就是做筛选统计之类的活的，就是下图紫色的过程）。 图出自https://blog.csdn.net/MrZhangBaby/article/details/88840635，看不清可以点进去看 Dataset是整理过的RDD，同样可以理解为一行行的数据，只是里面更有序（有了固定的结构schema） Dataframe就是Python和R里的那种dataframe，也就是最常见的带表头的表，是Dataset的特例，链接里的图就很形象 https://blog.csdn.net/weixin_42702831/article/details/82492421 RDD Dataframe Dataset 或者是 流式数据的2种处理方式 从文件里读数据，读一次就产生一个静态数据，而像日志之类的记录这种不断增长的数据，可以看做是一个瀑布流，源源不断的增长。针对这种流式数据（data stream）的处理，要么用flink

Hadoop集群安装和配置 1、 Hadoop的介绍 2、hadoop的历史版本和发行版公司 2.1 Hadoop历史版本 2.2 Hadoop三大发行版公司 3、hadoop的架构模型 1.x的版本架构模型介绍 2.x的版本架构模型介绍 四种 4、appache版本hadoop重新编译 4.1为什么要编译hadoop 4.2编译环境的准备 4.2.1：准备linux环境 4.2.2：虚拟机联网，关闭防火墙，关闭selinux 4.2.3：安装jdk1.7 4.2.4：安装maven 4.2.5：安装findbugs 4.2.6：在线安装一些依赖包 4.2.7：安装protobuf 4.2.8、安装snappy 4.2.9：编译hadoop源码 5、Hadoop安装 第一步：上传apache hadoop包并解压 第二步：修改配置文件 修改core-site.xml 修改hdfs-site.xml 修改hadoop-env.sh 修改mapred-site.xml 修改yarn-site.xml 修改mapred-env.sh 修改slaves 第三步：配置hadoop的环境变量 第四步：启动集群 第五步：jps命令查看三台虚拟机的服务阶段状态 第四步：三个端口查看界面 安装包资料： 链接： https://pan.baidu.com/s