snappy

本篇介绍典型的基于SStable的存储。适用于与SSD一起使用。更多存储相关见： https://segmentfault.com/a/11... 。涉及到leveldb,rocksdb。基本上分布式都要单独做，重点是单机架构，数据写入，合并，ACID等功能和性能相关的。 先对性能有个直观认识： mysql写入千条/s，读万应该没问题。redis 写入 万条/s 7M/s(k+v 700bytes，双核)读是写入的1.4倍 mem 3gb 2核。这两个网上搜的，不保证正确，就看个大概吧。 SSD上 rocksdb随机和顺序的性能差不多，写要比读性能稍好。随机读写1.7万条/s 14M/s （32核）。batch_write/read下SSD单线程会好8倍。普通write只快1.2倍。 没有再一个机器上的对比。rocksdb在用SSD和batch-write/read下的读写性能还是可以的。 第一章 levelDb 架构图 读取过程 数据的读取是按照 MemTable、Immutable MemTable 以及不同层级的 SSTable 的顺序进行的，前两者都是在内存中，后面不同层级的 SSTable 都是以 *.ldb 文件的形式持久存储在磁盘上 写入过程 1.调用 MakeRoomForWrite 方法为即将进行的写入提供足够的空间； 在这个过程中，由于 memtable

一 磁盘读写原理 磁盘的结构图： 当需要从磁盘读取数据时，要确定读的数据在哪个磁道，哪个扇区： 首先必须找到柱面，即磁头需要移动对准相应磁道，这个过程叫做寻道，所耗费时间叫做寻道时间; 然后目标扇区旋转到磁头下,这个过程耗费的时间叫做旋转时间； 一次访盘请求（读/写）完成过程由三个动作组成 寻道（时间）：磁头移动定位到指定磁道; 旋转延迟（时间）：等待指定扇区从磁头下旋转经过； 数据传输（时间）：数据在磁盘、内存与网络之间的实际传输 由于存储介质的特性，磁盘本身存取就比主存慢，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分之一甚至几千分支一 二 利用page cache+mmap 1.page cache Page Cache ：以Page为单位，缓存文件内容。缓存在Page Cache中的文件数据，能够更快的被用户读取。同时对于带buffer的写入操作，数据在写入到Page Cache中即可立即返回，而不需等待数据被实际持久化到磁盘，进而提高了上层应用读写文件的整体性能。cached这列的数值表示的是当前的页缓存（page cache）的占用量，page cache文件的页数据，页是逻辑上的概念，因此page cache是与文件系统同级的 buffer cache：磁盘等块设备的缓冲，内存的这一部分是要写入到磁盘里的 。buffers列 表示当前的块缓存（buffer

一、Kafka概述 关于Kafka，我们在之前的文章里也介绍，简而言之Kafka是一个分布式消息引擎与流处理平台，经常用做企业的消息总线、实时数据管道，有时还可以当做存储系统来用。Kafka的设计遵循生产者消费者模式，其中生产者和消费者都属于客户端，服务端则是由多个broker实例组成，broker主要负责接收和处理来自客户端的请求，以及对消息进行持久化。基本架构如下： 二、broker端核心参数 1. broker.id 参数说明：broker的唯一标识id，默认值为-1，如果不指定Kafka会自动生成一个id。生产环境推荐设置从0开始，按1递增的数字，比如0,1,2,3...等。 2. log.dirs 参数说明：设置Kafka持久化消息的数据目录，如果不设置Kafka会将消息持久化到/tmp/kafka-logs，通常都需要我们手动设置。多个目录逗号分隔，也就是一个csv列表。 调优建议：这是必须要上线前规划好的，建议设置成挂载不同磁盘的多个数据目录。创建topic时分区会自动均匀的分布到不同目录里，磁盘的io请求与空间占用也会负载均衡。 3. zookeeper.connect 参数说明：指定Kafka依赖的ZK连接信息，这个参数同样是一个csv列表，比如：zk1:2181,zk2:2181,zk3:2181。因为Kafka依靠Zookeeper做分布式协调服务

会议： 以太坊2.0会议#43 会议日期: 2020 年7月9日 会议时长： 1 小时 会议视频链接： https://youtu.be/4IooxDX_GfU 会议日程： 1. 测试和版本更新 2. 测试网更新 3. 客户端更新 4. 应急响应 5. 关系到用户安全和用户体验的弱主观性 6. 研究更新 7. 网络侧更新 8. 规范讨论 9. 开放讨论/总结 会议主要内容： 1. 会议开始，主持人Danny先开始第一个议题，即 测试和版本更新 。Danny介绍说v12.2版本马上就要发布，并能完全向后兼容。现在主要做的就是在发布前再调试一下gossipsub的参数。 Proto 对团队的进展进行了介绍。其中，最重大的进展是上周发布了Rumor v2，里面包含了许多新的命令，并对脚本进行了优化。现在仍然在做一些类似同步命令的优化工作。Proto说针对Phase1的测试才刚开始，同时Python Eth2的规范同步在升级。他认为现阶段测试分叉选择实施方法的最佳方案是在Rumor上面测试，而不是之前大家认为的在每个不同的客户端上面开放接口来测试，所以他会准备一个Rumor教程给大家。Danny强烈推荐各个客户端团队都仔细地阅读这个教程。 Mehdi 介绍说上周更新了信标模糊测试，文字帖在同步准备。Docker化和信标模糊测试都完成了，这样用户就可以轻松地在家使用

概述 对象存储服务（Object Storage Service，简称 OSS），是海量、安全、低成本、高可靠的云存储服务。OSS与日志服务相比，OSS存储的成本更低，不过日志服务中查询、结果展示、实时监控、数据加工等功能是OSS所不具备的。所以，可以将历史数据投递到OSS进行长期保存，SLS存储近期有查询分析需要的数据。 当历史数据有查询、分析需求时可以将OSS中的数据重新导入到SLS。 前提条件 已创建OSS Bucket，并将待导入的日志文件存储到OSS Bucket中，详情请参见 上传文件 。 已创建Project和Logstore，详情请参见 准备流程 。 已经完成 云资源访问授权 。 导入的OSS文件格式支持：JSON、CSV、Parquet、TEXT。 文件压缩格式支持：Gzip、Bzip2、Snappy，以及未压缩文件。 流程总览 检查导入日志服务的文件格式是否满足前提条件。 检查子账号是否有权限操作。主账号可以直接配置。 登陆 日志服务 配置OSS数据导入。 等待任务执行，查看数据及任务状态。 操作详情 测试导入的文件是之前从SLS发送到OSS的日志文件，bucket类型为标准存储。如果bucket是归档存储类型，建议提前解冻；在配置中也能进行解冻，不过解冻有一两分钟延迟，配置过程中解冻有可能误认为解冻不成功。 1. 检查OSS中待导入文件格式 在 oss控制台

简洁而不简单 Hadoop数据压缩 数据压缩优点和缺点 ​ 压缩技术能够 有效减少底层存储系统（HDFS）读写字节数 。压缩提高了网络带宽和磁盘空间的效率。在 Hadoop下，尤其是数据规模很大和工作负载密集的情况下，使用数据压缩显得非常重要。在这种情况下， IO操作和网络数据传输要花大量的时间 。还有， Shuffle与 Merge过程同样也面临着巨大的IO压力鳘于磁盘IO和网络带宽是 Hadoop的宝贵资源， 数据压缩对于节省资源、最小化磁盘IO和网络传输非常有帮助 。 ​ 不过，尽管压缩与解压操作的CPU开销不髙， 其性能的提升和资源的节省并非没有代价 。如果磁盘IO和网络带宽影响了 MapReduce作业性能，在任意 MapReduce阶段启用压缩都可以改善端到端处理时间并減少IO和网络流量。 压缩策略和原则 ​ 压缩是提高 Hadoop运行效率的一种优化策略通过对 Mapper、 Reducer运行过程的数据进行压缩， 以减少磁盘IO，提高MR程序运行速度 。 ​ 注意：釆用压缩技术减少了磁盘IO，但同时 增加了CPU运算负担 。所以，压缩特性运用得当能提高性能，但运用不当也可能降低性能压缩基本原则： （1）运算密集型的job，少用压缩 （2） IO密集型的job，多用压缩 ！！ MR支持的压缩编码 压缩格式 hadoop自带？ 算法 文件扩展名 是否可切分

一、Hive的压缩和存储 1，MapReduce支持的压缩编码 压缩格式 工具 算法 文件扩展名 是否可切分 对应的编码/解码器 DEFLATE 无 DEFLATE .deflate 否 org.apache.hadoop.io.compress.DefaultCodec Gzip gzip DEFLATE .gz 否 org.apache.hadoop.io.compress.GzipCodec bzip2 bzip2 bzip2 .bz2 是 org.apache.hadoop.io.compress.BZip2Codec LZO lzop LZO .lzo 是 com.hadoop.compression.lzo.LzopCodec Snappy 无 Snappy .snappy 否 org.apache.hadoop.io.compress.SnappyCodec 2，文件压缩格式: 　　TEXTFILE和SEQUENCEFILE的存储格式都是基于 行式存储 的； 　　ORC和PARQUET是基于 列式存储 的。 a> TextFile格式: 　　 默认格式，数据不做压缩，磁盘开销大，数据解析开销大。可结合Gzip、Bzip2使用，但使用Gzip这种方式，hive不会对数据进行切分，从而无法对数据进行并行操作。 b> Orc格式: 　　 Hive 0

Hadoop优化 主要内容： ① MapReduce跑得慢的原因 ② MapReduce/Hadoop优化方法 MapReduce 优化方法主要从 六个方面考虑 ： 数据输入、 Map 阶段、 Reduce 阶段、 IO 传输、数据倾斜问题和常用的调优参数。 （ 6 条 -10 条） 1）数据输入 合并小文件：在执行MR任务前将小文件进行合并，大量的小文件会产生大量的Map任务，增大Map任务装载次数，而任务的装载比较费时，导致MR变慢； 采用 ConbinFileInputFormat 来作为输入，解决输入端大量小文件场景； 2）map阶段 增大环形缓冲区大小。由 100m 扩大到 200m ； 增大环形缓冲区溢写的比例。由 80%扩大到 90% ； 减少对溢写文件的 merge 次数 ； 不影响实际业务的前提下，采用 combiner 提前合并，减少 I/O ； 3） reduce阶段 合理设置 map 和 reduce 数：两个都不能设置太少，也不能设置太多。太少，会 导致 task 等待，延长处理时间；太多，会导致 map、reduce 任务间竞争资源，造成 处理超时等错误 ； 设置 map、reduce 共存：调整 slowstart.completedmaps 参数，使 map 运行到一定程度后，reduce 也开始运行，减少 reduce 的等待时间； 规避使用

MapReduce 主要内容 ① MapReduce概述 1.1 MapReduce定义 1.2 优缺点 优点： 缺点： 1.3 MR核心编程思想 MR进程： ② MR框架原理 2.1 MapReduce工作流程 Map Task工作机制： 具体过程： Read阶段 ：从文本中一行一行的读取数据，并返回一个个的k,v数据，并将数据交给map函数处理； Map阶段 ：用map函数处理读取到的k,v数据，并得到新的k,v数据； Collect收集阶段 ：将map函数处理的结果存储到环形内存缓存区中； Spill溢写阶段 ：当环形缓存区达到阈值时，就会将数据溢写到磁盘上。溢写前要对数据进行排序、合并等操作；（溢写阶段详情见文档） Combine合并阶段 ：当所有数据处理完以后，对磁盘上的所有数据进行一次归并排序，合并成一个文件；（详情见文档） Reduce Task工作机制： 具体流程： Copy阶段 ：当Map Task任务结束以后，Reduce Task从各个Map Task上去拷贝数据，放到内存或者磁盘中； Merge阶段 ：对内存和磁盘上拷贝过来的数据进行合并，防止内存和磁盘被占用过多； Sort 阶段： 和Merge阶段一起工作，在合并的同时使用归并排序进行排序； Reduce 阶段 ： reduce() 函数将计算结果写到 HDFS 上。 MR整体流程图： 2.2

问题描述 Hive ORC table常规小文件过多问题，于是用Spark写了一个Application来自动的Merge分区数据，思路很简单 大概就是 insert overwrite table partition (分区 XXX) select * from table where (分区 XXX) 当然已经把该dataframe repartition到想要的目标并发度，来控制最终分区下的文件个数 但是发现生成的文件个数虽然是对的，但是最后整个分区的Size竟然几乎翻倍。 排查过程以及结论 怀疑是Spark SQL没有压缩或者压缩格式不对 https://stackoverflow.com/questions/48759909/how-to-check-if-zlib-compression-is-enabled-in-hive-tables 用这个链接的方式自查一下 发现 hive 生成的文件默认是zlib 而spark生成的文件默认是snappy 这个导致了最终文件大小相差较大 来源： oschina 链接： https://my.oschina.net/u/4303818/blog/4287399