青云QingCloud 大数据课堂 第二课
-
为了方便各位钢蹦之间交流学习经验,大家可以进入我们首页,加入【QingCloud钢蹦社区】微信群
第二课讲义PPT
-
第二课笔记:数据格式
计算跟着存储走
格式要求
- 可分割 Splittable
- 可块压缩 Block Compressible
File Format Splittable Block Compressible Text/CSV Y N JSON Records Y N Sequence Files Y Y RC Files Y Y ORC Files Y Y Avro Format Y Y Parquet Files Y Y 错误的格式
- 时间:性能成倍下降
- 空间:空间成倍上升
-
第二节课打卡
数据格式
错误的格式导致的后果:
* 性能成倍下降
* 空间成倍上升因为大数据的特性和数据量,因此前期设计上对数据格式要求很高,如果对数据格式的设计没有前瞻性,将带来很严重的后果(以T为单位的数据洪流铺面而来)
大数据格式选择的两个基本原则:
-
1.可分割性(Splittable)
整块文件是完整且有意义的,大数据的数据格式要求对数据进行分割后,分割开的两部分可解析,即有意义。 -
2.可块压缩(Block Compressable)
对单块数据进行压缩和解压缩,不需要和其他数据进行交互。
i.g返例:ZIP格式分割后,需要寻找到其他块才能组合成整体。
大数据的一个特性:计算跟着存储走。(与传统存储跟着计算走相反)
不可分割的例子:
XML、JSON文件(x)
-
-
第二讲:计算跟着存储走。
-
-
学习,数据格式要有前瞻性,格式选择遵循Splittable、Block Compressable,计算依赖存储
-
计算跟着存储走
错误的格式导致的后果
签到
-
第一课 part2
数据格式
- 错误的格式:
- 性能成倍下降
- 空间成倍上升
-
可分割性(Splittable)
- xml, json文件 -> 不可分割的
- csv, json纪录, Avro -> 可分割的
-
可块压缩的(Block Compressable, 分割成块之后可以压缩)
- csv, json纪录 -> 不是可块压缩
- Avro, Parquet -> 可块压缩
- 同时需要注意与传统数据库的交互
- 错误的格式:
-
感觉老师重点已经讲的很清楚,PPT上的内容就不再赘述,针对于引导过,却为完全展开的知识点,课后就数据块压缩做了一些功课,分享一下。
大数据处理的数据量如果以
TB
作为单位的话,那么我们一般的x86
台式机是不容易处理甚至没法处理的。一来数据是分布式存储在多个节点上,二来数据容量大,考虑到安全和不易失,基本也都是多副本(至于是用RAID
还是超融合,都是数据分片后,有多个分片副本)。那么假设计算load
一个数据块Block1
,而Block1
是一个2个GB的压缩文件,那么计算尚未开始之前,就得解压获取原始数据,2GB解压搞不好CPU都过半了,这样多不值当,所以通常来说将大文件都分片成一个个64M
的小片来处理(譬如HDFS默认是64M)那为什么是通常默认是64M?
- 块太小不行, 会导致namenode节点由于元数据太多, 而导致内存消耗太大, 容易宕机
- 块太大也不行, 网络传输的时候, 容易出现中断;
- 通常文件系统的块大小的几千个字节,设置为64M是为了加快文件读写速度。读取一个文件的时候,需要先知道这个文件由哪些块组成,然后对每个块进行寻址,然后读取。hdfs的block设置的比较大,这样寻址时间大大减少,读取文件的时间就约等于磁盘传输时间,更加适合大文件的访问
常用压缩格式(就Hadoop而言)
DEFLATE 无 DEFLATE .deflate 不 不 gzip gzip DEFLATE .gz 不 不 ZIP zip DEFLATE .zip 是 是,在文件范围内 bzip2 bzip2 bzip2 .bz2 不 是 LZO lzop LZO .lzo 不 是
-
@fiona 认真起来自己都害怕
-
签到。
记住要选用正确的格式,错误的格式会导致严重的后果。
-
此回复已被删除!
-
还不错,进度有点慢一样
-
这是在哪个学校开的讲座?