snappy

表现：通过JNI打开RocksDB报错：snappy压缩库没有被链接： org . rocksdb . RocksDBException : Compression type Snappy is not linked with the binary . at org . rocksdb . RocksDB . open ( Native Method ) ~ [ rocksdbjni - 6.6 .0 - fix - osx . jar : ? ] at org . rocksdb . RocksDB . open ( RocksDB . java : 290 ) ~ [ rocksdbjni - 6.6 .0 - fix - osx . jar : ? ] at com . baidu . hugegraph . backend . store . rocksdb . RocksDBStdSessions . < init > ( RocksDBStdSessions . java : 130 ) ~ [ classes / : ? ] at com . baidu . hugegraph . backend . store . rocksdb . RocksDBStore . openSessionPool ( RocksDBStore . java : 299 ) ~ [

1.HBase基础 1.1.HBase基本介绍 1.2.HBase配置安装 1.3.HBase使用用例 1.3.1.增 1.3.2.删 1.3.3.改 1.3.4.查 1.4.HBase基本概念 1.4.1.表，rowkey，列蔟，列 1.4.2.数据版本TTL 1.4.3.root，meta，namespace表 1.4.4.master，regionserver，thriftserver 1.4.5.get，scan 1.5.HBase常用命令 1.5.1.shell所有命令 2.HBase进阶 2.1.HBase架构 2.1.1.写流程 2.1.2.读流程 2.1.3.split流程 2.1.4.merge流程 2.1.5.compact流程 2.1.6.balancer路程 2.1.7.WAL 2.2.HBase API 2.2.1.JAVA API 2.2.2.MapReduce API 2.3.HBase配置解析 2.3.1.hbase-env.sh 2.3.2.hbase-site.xml 2.4.HBase性能优化 2.4.1.客户端 2.4.2.服务端 2.4.3.ycsb 3.HBase高阶 3.1.HBase运维 3.1.1.节点启停 3.1.2.meta表修复 3.1.3.HBase监控 3.2.HBase协处理器 3.2.1.observer协处理器 3

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Impala 表使用 Parquet 文件 格式 Impala 帮助你创建、管理、和查询 Parquet 表。Parquet 是一种面向列的二进制文件格式，设计目标是为 Impala 最擅长的大规模查询类型提供支持(Parquet is a column-oriented binary file format intended to be highly efficient for the types of large-scale queries that Impala is best at)。Parquet 对于查询扫描表中特定的列特别有效，例如查询一个包含许多列的"宽"表，或执行需要处理列中绝大部分或全部的值的如 SUM(),AVG() 等聚合操作(Parquet is especially good for queries scanning particular columns within a table, for example to query "wide" tables with many columns, or to perform aggregation operations such as SUM() and AVG()that need to process most or all of

MapReduce 的数据压缩 hive 的数据压缩 hive 支持的文件格式 hive日志分析,各种压缩的对比 hive 的函数HQL 查询 一： mapreduce 的压缩 - mapreduce 压缩 主要是在shuffle阶段的优化。 shuffle 端的 --partition （分区） -- sort （排序） -- combine (合并) -- compress (压缩) -- group （分组） 在mapreduce 优化shuffle 从本质上是解决磁盘的IO 与网络IO 问题。 减少 集群件的文件传输处理。 二： hive 的压缩： 压缩的和解压需要cpu的，hive 的常见的压缩格式： bzip2,gzip,lzo,snappy等 cdh 默认采用的压缩是snappy 压缩比：bzip2 > gzip > lzo bzip2 最节省存储空间。 注意： sanppy 的并不是压缩比最好的 解压速度： lzo > gzip > bzip2 lzo 解压速度是最快的。 注意：追求压缩速率最快的sanppy 压缩的和解压需要cpu 损耗比较大。 集群分： cpu 的密集型 （通常是计算型的网络） hadoop 是 磁盘 IO 和 网络IO 的密集型， 网卡的双网卡绑定。 三： hadoop 的检查 是否支持压缩命令 bin/hadoop checknative 3

看一个压缩算法的优劣，有两个重要的指标： 一个指标是压缩比 ，原先占 100 份空间的东西经压缩之后变成了占 20 份空间，那么压缩比就是 5，显然压缩比越高越好； 另一个指标就是压缩 / 解压缩吞吐量 ，比如每秒能压缩或解压缩多少 MB 的数据。同样地，吞吐量也是越高越好。 从表中我们可以发现 zstd 算法有着最高的压缩比，而在吞吐量上的表现只能说中规中矩。 反观 LZ4 算法，它在吞吐量方面则是毫无疑问的执牛耳者。 GZIP、Snappy、LZ4 甚至是 zstd 的表现各有千秋。 但对于 Kafka 而言，它们的性能测试结果却出奇得一致，即在吞吐量方面： LZ4 > Snappy > zstd 和 GZIP ； 而在压缩比方面， zstd > LZ4 > GZIP > Snappy 。 如果网络不好且 CPU 资源够的话,建议使用 zstd 压缩 具体到物理资源，使用 Snappy 算法占用的网络带宽最多，zstd 最少，这是合理的，毕竟 zstd 就是要提供超高的压缩比； 在 CPU 使用率方面，各个算法表现得差不多，只是在压缩时 Snappy 算法使用的 CPU 较多一些，而在解压缩时 GZIP 算法则可能使用更多的 CPU 。 原文引用: zstd git lab : https://github.com/facebook/zstd Kafka核心技术与实战 - 胡夕