数据处理

一、什么是RDD RDD（Resilient Distributed Dataset）叫做 弹性分布式数据集 ， 是Spark中最基本的数据抽象 ，它代表一个不可变、可分区、里面的元素可并行计算的集合。RDD具有数据流模型的特点：自动容错、位置感知性调度和可伸缩性。RDD允许用户在执行多个查询时显式地将工作集缓存在内存中，后续的查询能够重用工作集，这极大地提升了查询速度。 1.1 RDD属性 （1）Partition 即数据集的基本组成单位。对于RDD来说，每个分片都会被一个计算任务处理，并决定并行计算的粒度。用户可以在创建RDD时指定RDD的分片个数，如果没有指定，那么就会采用默认值。默认值就是程序所分配到的集群的CPU Core的总数目。 （2）一个计算每个分区的函数。 Spark中RDD的计算是以分片为单位的，每个RDD都会实现compute函数以达到这个目的。compute函数会对迭代器进行复合，不需要保存每次计算的结果。 （3）RDD之间的依赖关系。 RDD的每次转换都会生成一个新的RDD，所以RDD之间就会形成类似于流水线一样的前后依赖关系。在部分分区数据丢失时，Spark可以通过这个依赖关系重新计算丢失的分区数据，而不是对RDD的所有分区进行重新计算。 （4）一个Partitioner，即RDD的分片函数。控制分区数和分区策略 当前Spark中实现了两种类型的分片函数

流式大数据处理的三种框架：Storm，Spark和Samza 2017-06-01 Spark技术日报 本文来自CSDN博客，ID「秋夜无霜」 原文：http://blog.csdn.net/shichen2010/article/details/72758300 许多分布式计算系统都可以实时或接近实时地处理大数据流。本文将对三种Apache框架分别进行简单介绍，然后尝试快速、高度概述其异同。 Apache Storm 在Storm中，先要设计一个用于实时计算的图状结构，我们称之为拓扑（topology）。这个拓扑将会被提交给集群，由集群中的主控节点（master node）分发代码，将任务分配给工作节点（worker node）执行。一个拓扑中包括spout和bolt两种角色，其中spout发送消息，负责将数据流以tuple元组的形式发送出去；而bolt则负责转换这些数据流，在bolt中可以完成计算、过滤等操作，bolt自身也可以随机将数据发送给其他bolt。由spout发射出的tuple是不可变数组，对应着固定的键值对。 Apache Spark Spark Streaming是核心Spark API的一个扩展，它并不会像Storm那样一次一个地处理数据流，而是在处理前按时间间隔预先将其切分为一段一段的批处理作业。Spark针对持续性数据流的抽象称为DStream

我们知道，HDFS 被设计成存储大规模的数据集，我们可以在 HDFS 上存储 TB 甚至 PB 级别的海量数据。而这些数据的元数据（比如文件由哪些块组成、这些块分别存储在哪些节点上）全部都是由 NameNode 节点维护，为了达到高效的访问，NameNode 在启动的时候会将这些元数据全部加载到内存中。而 HDFS 中的每一个文件、目录以及文件块，在 NameNode 内存都会有记录，每一条信息大约占用150字节的内存空间。由此可见，HDFS 上存在大量的小文件（ 这里说的小文件是指文件大小要比一个 HDFS 块大小(在 Hadoop1.x 的时候默认块大小64M，可以通过 dfs.blocksize 来设置；但是到了 Hadoop 2.x 的时候默认块大小为128MB了，可以通过 dfs.block.size 设置) 小得多的文件。 ） 至少会产生以下几个负面影响： 大量小文件的存在势必占用大量的 NameNode 内存，从而影响 HDFS 的横向扩展能力。 另一方面，如果我们使用 MapReduce 任务来处理这些小文件，因为每个 Map 会处理一个 HDFS 块；这会导致程序启动大量的 Map 来处理这些小文件，虽然这些小文件总的大小并非很大，却占用了集群的大量资源！ 以上两个负面影响都不是我们想看见的。那么这么多的小文件一般在什么情况下产生？我在这里归纳为以下几种情况：

动态扩容，顾名思义，就是通过增加节点实现集群服务能力的提升。是hadoop，或者说分布式集群的特性之一； 同理，部分节点可能老化，升级换代，节点需要对应的下线处理。今天就分别介绍这两部分操作： 1，动态扩容 1.1，在新增节点配置环境，可以参考 Hadoop集群的搭建 里如何配置节点，主要是配置ssh免密登录，配置java环境。步骤都是一样的，不在赘述。 1.2，在主节点修改hosts文件，增加新增节点，并同步到集群所有节点 [hadoop@server45 hadoop]$ cat /etc/hosts 10.1.197.50 server50 10.1.197.51 server51 10.1.197.41 server41 10.1.197.42 server42 10.1.197.43 server43 10.1.197.44 server44 10.1.197.45 server45 1.3,修改 hadoop目录下的etc/hadoop/下的slaves文件，增加新节点 [hadoop@server45 hadoop]$ cat slaves server45 server44 server43 server42 [hadoop@server45 hadoop]$ pwd /opt/bigdata/hadoop/hadoop-2.6.5/etc/hadoop 1.4

大家好, 我是上白书妖! 知识源于积累,登峰造极源于自律 今天我根据以前所以学的一些文献,笔记等资料整理出一些小知识点,有不当之处,欢迎各位斧正 package com . alibaba . hdfs ; import org . apache . hadoop . conf . Configuration ; import org . apache . hadoop . fs . * ; import org . junit . Test ; import java . io . File ; import java . io . IOException ; import java . net . URI ; import java . net . URISyntaxException ; /** * @author 上白书妖 * @date 2020/2/26 21:48 * @Desription:获取客户端的连接对象,操作hadoop集群 * */ public class HdfsClient { /* 创建目录 */ @Test public void testMkdirs ( ) throws IOException , InterruptedException , URISyntaxException { // 1 获取文件系统 Configuration

最近几次被问到关于数据倾斜的问题，这里找了些资料也结合一些自己的理解. 在并行计算中我们总希望分配的每一个task 都能以差不多的粒度来切分并且完成时间相差不大，但是集群中可能硬件不同，应用的类型不同和切分的数据大小不一致总会导致有部分任务极大的拖慢了整个任务 的完成时间，硬件不同就不说了，应用的类型不同其中就比如page rank 或者data mining 里面一些计算，它的每条记录消耗的成本不太一样，这里只讨论关于关系型运算的（一般能用SQL表述的) 数据切分上的数据倾斜问题. hadoop 中数据倾斜会极大影响性能的一个背景是mapreduce 框架中总是不分条件的进行sort . 在通用情况下map sort + partition +reduce sort 可以得到结果，但是这个过程不一定是最优的. 对于关系型计算,其中数据倾斜影响最大的地方在reduce 的sort , reduce 处理的数据量的大小如果超过给定的reduce jvm 的大小的2倍不到的阈值的时候(这个阈值是我猜测的，具体以实际监控运行情况为准)，reduce 端会发生multi-pass merge sort 的情况， 这个时候观察这些运行较慢的reduce task 的metrics 会发现reduce 跟IO 相关的metrics 会比其他reduce 大很多. 具体的细节参考今年hadoop

　　不多说，直接上干货！ 　　这篇博客里的算法部分的内容来自《数据算法：Hadoop/Spark大数据处理技巧》一书，不过书中的代码虽然思路正确，但是代码不完整，并且只有java部分的编程，我在它的基础上又加入scala部分，当然是在使用Spark的时候写的scala。 一、输入、期望输出、思路。 输入为SecondarySort.txt，内容为： 2000,12,04,10 2000,11,01,20 2000,12,02,-20 2000,11,07,30 2000,11,24,-40 2012,12,21,30 2012,12,22,-20 2012,12,23,60 2012,12,24,70 2012,12,25,10 2013,01,23,90 2013,01,24,70 2013,01,20,-10 意义为：年，月，日，温度 期望输出： 2013-01 90,70,-10 2012-12 70,60,30,10,-20 2000-12 10,-20 2000-11 30,20,-40 意义为： 年-月 温度1，温度2，温度3，…… 年-月从上之下降序排列， 温度从左到右降序排列 思路： 抛弃不需要的代表日的哪一行数据 将年月作为组合键（key），比较大小，降序排列 将对应年月（key）的温度的值（value）进行降序排列和拼接 二

Spark流计算 概述 ⼀般流式计算会与批量计算相⽐较。在流式计算模型中，输⼊是持续的，可以认为在时间上是⽆界的，也就意味着，永远拿不到全量数据去做计算。同时，计算结果是持续输出的，也即计算结果在时间上也是⽆界的。流式计算⼀般对实时性要求较⾼，同时⼀般是先定义⽬标计算，然后数据到来之后将计算逻辑应⽤于数据。同时为了提⾼计算效率，往往尽可能采⽤增量计算代替全量计算。批量处理模型中，⼀般先有全量数据集，然后定义计算逻辑，并将计算应⽤于全量数据。特点是全量计算，并且计算结果⼀次性全量输出。 ⽬前主流流处理框架：Kafka Streaming、Storm（JStrom）、Spark Streaming 、Flink（BLink） ①：Kafka Streaming:是⼀套基于Kafka-Streaming库的⼀套流计算⼯具jar包，具有⼊⻔⻔槛低，简单容易集成等特点。 ②：Apache Storm:⼀款纯粹的流计算引擎，能够达到每秒钟百万级别数据的低延迟处理框架。 ③：Spark Streaming：是构建在Spark 批处理之上⼀款流处理框架。与批处理不同的是，流处理计算的数据是⽆界数据流，输出也是持续的。Spark Streaming底层将Spark RDD Batch 拆分成 Macro RDDBatch实现类似流处理的功能。因此spark Streaming在微观上依旧是批处理框架

HDFS 定义 HDFS(Hadoop Distributed File System) ，它是一个文件系统，用于储存文件，通过目录树来定位文件；其次，它是 分布式 的，由很多服务器联合起来实现其功能，集群中的服务器有各自的角色。    HDFS的使用场景：适合一次写入，多次读出的场景，且不支持文件的修改。 HDFS 优缺点 优点： 1）高容错性 数据自动保存多个副本,某个副本丢失以后，它可以自动恢复 2）适合处理大数据 能够处理数据规模大的数据；能够处理百万规模以上的文件数量 3）可构建在廉价机器上，通过多副本机制，提高可靠性 缺点： 1）不适合低延时数据访问 2）无法高效的对大量小文件进行存储 存储大量小文件会占用namenode大量的内存来存储文件目录和块信息，并且小文件存储的寻址时间会超过读取时间 3）不支持并发写入，不支持文件随机修改 HDFS组成架构 1) NameNode(NN)：就是Master，是一个主管者 （1）管理HDFS名称空间 （2）配置副本信息 （3）管理数据块映射空间 （4）处理客户端读写请求 2）DataNode(DN)：就是Slave,NameNode下达命令，DataNode执行实际操作 （1）存储实际的数据块 （2）执行数据块的读写操作 3）Client:就是客户端 （1）文件切分，文件上传HDFS的时候，Client将文件切分成Block

拆分单元格内容 import pandas as pd employees = pd.read_excel('C:/employee.xlsx') df = employees['Full Name'].str.split(n=2, expand=True) employees['First Name'] = df[0] employees['Last Name'] = df[1] 数据统计,统计每个学员的总分，平均分，所有学员各科平均分，总分 students = pd.read_excel('C:/students.xlsx') temp = students[['Test1', 'Test2', 'Test3']] row_sum = temp.sum(axis=1) row_mean = temp.mean(axis=1) students['Total'] = row_sum students['Average'] = row_mean col_mean = students[['Test1', 'Test2', 'Test3', 'Total', 'Average']].mean(axis=0) col_mean['Name'] = 'Summary' students.append(col_mean, ignore_index=True) 去除重复数据