snappy

首先准备一个hadoop源码包，我选择的hadoop版本是：hadoop-2.7.7-src.tar.gz，在hadoop-2.7.7的源码包的根目录下有一个文档叫做BUILDING.txt，这其中说明了编译hadoop所需要的一些编译环境相关的东西。不同的hadoop版本的要求都不一样，对应的版本参照BUILDING.txt 安装对应软件（必须联网） 安装openssl-devel yum -y install svn yum -y install autoconf automake libtool cmake zlib-devel lzo-devel yum -y install ncurses-devel yum -y install openssl-devel yum -y install zlib1g-dev libssl-dev 安装gcc 检测gcc是否已经安装:gcc -v 如果最后一行出现gcc版本信息日志，表示已经安装成功过了 命令安装： yum install -y gcc 安装gcc-c++ 命令安装：yum -y install gcc-c++ 安装JDK 安装包：jdk-7u80-linux-x64.tar.gz 解压安装：tar -zxvf /root/jdk-7u80-linux-x64.tar.gz -C /root/apps/ 配置环境变量：

gpcopy 是新一代的 Greenplum 数据迁移工具，可以帮助客户在 不同集群间，不同版本间，快速稳定地迁移数据 。同上一代迁移工具 gptransfer 相比，gpcopy 具有巨大的优势： 更快，更稳定，更易用，功能更丰富 。另外，gpcopy 只包含在商业版本中。 gpcopy 可以干什么 gpcopy 可以迁移整个集群，也可以具体传输某些数据库、某些命名空间和某些表；可以从文件读取传输或者略过的表，支持正则表达式；可以略过、追加或者替换目标集群的数据；可以并行传输；可以只迁移结构信息；可以静默自动化执行…… 简单说，就是集群间迁移所存储的信息，使得用户业务可以迁移： 集群迁移 和 gptransfer 的速度对比 gpcopy vs. gptransfer 为什么 gpcopy 可以更快速 segment 间直接传输 gpcopy 的数据传输利用了 Greenplum 最新的 COPY ON SEGMENT 特性，首先 COPY 相较于 gptransfer 单纯使用的外部表就更快，因为它是批量操作，而外部表的 SELECT 和 INSERT 都是逐条操作；另外 COPY ON SEGMENT 特性使得 gpcopy 可以做到 两个集群的多节点间并发传输，快上加快 。 以下是 gpcopy 应用于相同节点数 Greenplum 集群间传输的架构，还是很简单直接的。

来源：Zohaib Sibte Hassan from Doordash and RedisConf 2020 (redisconf.com/) organized by Redis Labs (redislabs.com) 翻译：Wen Hui 转载：中间件小哥 Cache stampede问题： Cache stampede问题又叫做cache miss storm，是指在高并发场景中，缓存同时失效导致大量请求透过缓存同时访问数据库的问题。 如上图所示： 服务器a,b 访问数据的前两次请求因为redis缓存中的键还没有过期，所以会直接通过缓存获取并返回（如上图绿箭头所示），但当缓存中的键过期后，大量请求会直接访问数据库来获取数据，导致在没有来得及更新缓存的情况下重复进行数据库读请求 （如上图的蓝箭头），从而导致系统比较大的时延。另外，因为缓存需要被应用程序更新，在这种情况下，如果同时有多个并发请求，会重复更新缓存，导致重复的写请求。 针对以上问题，作者提出一下第一种比较简单的解决方案，主要思路是通过在客户端中，通过给每个键的过期时间引入随机因子来避免大量的客户端请求在同一时间检测到缓存过期并向数据库发送读数据请求。在之前，我们定义键过期的条件为： Timestamp+ttl > now() 现在我们定义一个gap值，表示每个客户端键最大的提前过期时间

问题描述 集群升级后，hadoop不能正常加载本地库 $ hadoop checknative -a 20/05/08 14:32:11 WARN bzip2.Bzip2Factory: Failed to load/initialize native-bzip2 library system-native, will use pure-Java version 20/05/08 14:32:11 WARN zlib.ZlibFactory: Failed to load/initialize native-zlib library 20/05/08 14:32:11 ERROR snappy.SnappyCompressor: failed to load SnappyCompressor java.lang.NoSuchFieldError: clazz at org.apache.hadoop.io.compress.snappy.SnappyCompressor.initIDs(Native Method) at org.apache.hadoop.io.compress.snappy.SnappyCompressor.<clinit>(SnappyCompressor.java:57) at org.apache.hadoop.io.compress

MapReduce的shuffle 1.input map shuffle reduce output 2.shuffle的实现的功能：分区 分组 排序(key字典序) 3.map端的shuffle context.write() 写入到环形缓冲区（内存区域），假设缓冲区设置的是100M，当达到缓冲区的80%的时候，就会溢写出一个小文件，溢出到磁盘之前做了二件事，分区 排序 两个reduce merge 将小文件进行合并 合并之后 分区内有序 merge之后 maptask结束 ，会通知appmaster我已经结束任务，am通知reduce拉取数据。 reduce shullfe: reduce启动线程通过网络到每台机器上拉取属于自己的数据 reduce1会拉取属于自己的数据： 将整体分区的数据进行排序 MapReduce shuffle 优化 1.合理设置partition 使用多个reduce处理输出结果 2.减少reducer从map拉取的数据量 （1）将map数据进行压缩（snappy 压缩质量不高 但是读取速度快，） 也可以在reduce输出的时候增加gzip 压缩实现 保证压缩率快速输出 （2）合理使用combiner（减少reducer输入数据量） spark 的shuffle ShuffleManager管理 HashShuffleManager

今天遇到一个情况使用了 Kafka-python 1.3.3 来操作读取 broker 1.0.1 版本的 kafka。出现了 rebalance 之后分配到了客户端，但是 cpu 利用率很高且无法消费的情况。 先是排查了连接方面和代码方面的问题，后来发现都没有问题就把注意力转移到了 kafka-client 本身。 搜索相关问题首先搜到了 kafka-python issues 1033 When no module exists to handle Snappy decompression, the KafkaConsumer returns no messages, rather than reporting the problem. This differs from the legacy Consumer API which provides a much more useful error message. Background I was attempting to fetch some data from a Kafka topic which was using snappy compression. No data was ever returned even though I knew data was being landed in the topic

Hive 总结 总结人：连志鹏 2020.04.29 一、HiveJDBC客户端基本操作 1.1 HvieJDBC的登入与退出 -- 方式一：使用beeline方式 访问方式：beeline - u jdbc:hive2: //hadooop102:10000 -n atguigu 退出方式：！quit 、 ! exit 、 ctrl + c -- 方式二： 使用hive的方式 访问方式：hive 退出方式：quit； exit ； 1.2 Hive常用的交互命令 “-e” 不进入hive的交互窗口执行sql语句** “-f” 执行脚本中sql语句** 1.3 Hive数据类型 基本数据类型 Hive数据类型 Java数据类型 长度 例子 TINYINT byte 1byte有符号整数 20 SMALINT short 2byte有符号整数 20 INT int 4byte有符号整数 20 BIGINT long 8byte有符号整数 20 BOOLEAN boolean 布尔类型，true或者false TRUE FALSE FLOAT float 单精度浮点数 3.14159 DOUBLE double 双精度浮点数 3.14159 STRING string 字符系列。可以指定字符集。可以使用单引号或者双引号。 ‘now is the time’ “for all good

一、 Kafka的组成 kafka是一个发布与订阅消息系统 消息：kafka的数据单元称为"消息"。可以把消息看成是数据库中的一个"数据行"。 消息的key：为key生成一个一致性散列值(HashCode)，然后使用散列值对主题分区数进行取模，为消息选取分区。 消息被分批次写入kafka。 批次：就是一组消息，这些消息属于同一个主题和分区。 主题(topic)：kafka的消息，是通过topic来分类的。topic，好比数据库里的表，或者文件系统里的文件夹。 topic，可分为若干个分区(partition)。 由于一个topic一般分为几个partition，因此整个Topic范围内无法保证消息的顺序，但可以保证消息在单个Partition内的顺序。 生产者(producer)：创建消息。 消费者(consumer)：订阅读取消息。 consumer可以订阅一个或多个topic，并按照消息生成的顺序去读取它们。消费者通过检查消息偏移量来区分已经读取过的消息。 偏移量(offset)：是一个不断递增的整数值，在创建消息时，Kafka会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。 消费者群组： 消费者群组中，会有一个或多个消费者读取同一个topic。 另外，群组能保证每个分区只能被一个消费者使用。 服务器(broker)：Kafka的服务器broker