点击图片下载：《翅片式换热器设计与仿真课程资料》
 
 
 
 
制冷百家VIP群里刚刚有人在讨论关于压缩比、内容积比的问题，我们整理了一些相关的知识，供各位同行学习下。
 
 
 
一、压缩比（外压比），内容积比，内压比的概念
 
 
 
压缩比：（外压比）是制冷系统冷凝压力和蒸发压力的比值（即设计的冷凝温度与蒸发温度对应的压力）（均采用绝对压力）。压缩比是指绝对排气压力和绝对吸气压力的比值。比如排气绝对压力是20bar，吸气绝对压力是5bar，那么压缩比就是4。
 
 
 
内容积比：是容积型压缩机等连续压缩机型压缩机的一个重要参数。排气容积是齿间容积与排气孔口相连通时的容积值，即压缩过程结束时的容积值；吸气容积为齿间容积与吸气孔口断开瞬间时的容积值，即吸气过程结束时的容积值。内容积比是机械结构确定下来的参数，即吸气容积与排气容积的比值。
 
 
 
 
内压比：是制冷压缩机排气腔内的压力和吸气腔压力的比值，（即吸气终了和排气终了时汽缸内的压力）（均采用绝对压力）。
 
 
 
 
二、过压缩与欠压缩的概念
 
 
 
对于压缩机来说，压缩比是衡量压缩机压缩冲程大小的一个关键概念，也是压缩机效率优化点的一个参照值。（文章来自制冷百家网，更多资料请登录制冷百家网下载和学习）
 
 
 
通俗来说，以自行车打气筒这种手动的压缩机举例，打气筒的长短意味着不同的压缩比，但是肯定有一个最佳的长度，是最适合自行车轮胎使用的，打气筒的吸气压力基本上和大气压相等，排气压力就是轮胎所需要的胎压，是一个相对稳定的运行工况，比较容易确定压缩比。
 
 
 
 
如果拿该打气筒给气球打气，所需的压力相对自行车轮胎来说就偏小，就会存在过压缩的问题。意味着压缩机压缩完成排气之前那一瞬间的气体压力是超出所需要的压力的，压缩机白白耗功。
 
 
 
另一方面，如果拿自行车打气筒给汽车轮胎打气，同样道理，就会发生欠压缩，压缩完成之后的压力不满足需求，这样就只能依靠重复压缩和单向背压阀等装置来实现所需要的压力。
 
 
 
 
同样因为压缩机结构的设计，对于涡旋压缩机、螺杆压缩机来说，其为连续吸气排气原理，可以出现过压缩和欠压缩；
 
而对于使用背压控制（限定压力装置）的单个容积腔实现压缩功能的压缩机，如活塞压缩机，滚动转子压缩机等，不会出现过压缩，但是会发生欠压缩。
 
 
 
 
螺杆机欠压缩，在压缩终了时，排气时的压力小于冷凝压力，会形成瞬间的回流，等到转子的排气压力与冷凝压力平衡时，气体才会排出，这种回流会使压缩机耗功增大。
 
 
 
无论是过压缩还是欠压缩，压缩机的性能都会在一定程度上低于最优化点，同时可靠性也会降低。
 
 
 
涡旋压缩机的内容积比计算公式：
 
 
 
 
三、压缩比的意义
 
 
 
当排气压力升高吸气压力降低时，压缩比增大，压缩机耗功增加，压缩机的性能下降，系统的性能降低。反过来，当排气压力降低而吸气压力升高时，压缩比减小，虽然压缩机的性能降低，但是整个系统的制冷能力增加，综合来讲，系统的效率是增加的。
 
 
 
压缩比的概念和系统之间的关系，最大的意义在于，帮助我们在压缩机选型时，判断出哪种压缩机是最适合当下应用的压缩机。
 
 
 
如下图所示是几种同样类型涡旋压缩机的运行范围图，运行压缩比的定义，图中任一点与原点联线的斜线的斜率就是该压缩机工作在这点的压缩比。这样可以帮助我们快速定向的进行对比不同工作点时的压比大小。
 
 
 
 
在做压缩机选型时，需要考虑实际应用的系统在整年四季当中所有运行工况当中的压缩比范围，高压范围和低压的范围，然后对应到这个运行图当中，判断的依据就是压缩机的运行范围可以覆盖系统实际运行会发生的范围，那么这个压缩机才是合适的选择，否则就不是。
 
 
 
如果同时有很多压缩机都可以满足应用的需求，才有余地去考虑其他的性能指标，如COP，噪音，尺寸，接口等，首要的先决条件是确定该压缩机能不能正常全年运转。
 
 
 
点击图片下载：《excel做制冷系统计算和仿真》的资料包：
 
 
 
 
 
 
 

 
哈夫曼树中压缩率到底是什么意思

 
 
编码的含义
 编码就是将一系列个体赋予一个能唯一标识的信息标志，这个标志可以简单的是一个编号，或者更复杂的约定好的其他数据结构。目的就是将电脑不能用0、1表示的物体（声音、视频、模式类别等），变成最终能用0/1编码来唯一标识的“码”。正因为有相互对应的特性，因而可以进行译码这样的逆操作。
 
 
哈夫曼树对应着一种编码方式，叫哈夫曼编码。被编码的对象，是一组有出现频率这个属性的对象。这种编码方式能够赋予出现频率值更大的对象更短的编码。同时任何一个编码不会是另一个编码的前缀（编译原理术语）。
 
 
假设有n种对象，且知道各自的出现频率，所谓压缩率是指
 $$压缩率=\frac{{\sum }_1^n每种对象出现频率\times 哈夫曼编码码长}{n\times \lceil logn\rceil }.$$
 

更高的压缩比，更好的性能–使用ORC文件格式优化Hive

  Hive 
  lxw1234@qq.com 
  2年前 (2016-04-05) 
  15492℃ 
  2评论

关键字：orc、index、hive
Hive从0.11版本开始提供了ORC的文件格式，ORC文件不仅仅是一种列式文件存储格式，最重要的是有着很高的压缩比，并且对于MapReduce来说是可切分（Split）的。因此，在Hive中使用ORC作为表的文件存储格式，不仅可以很大程度的节省HDFS存储资源，而且对数据的查询和处理性能有着非常大的提升，因为ORC较其他文件格式压缩比高，查询任务的输入数据量减少，使用的Task也就减少了。关于Orc文件格式的官网介绍，见：
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+ORC
需要注意的是，ORC能很大程序的节省存储和计算资源，但它在读写时候需要消耗额外的CPU资源来压缩和解压缩，当然这部分的CPU消耗是非常少的。
对性能提升的另一个方面是通过在ORC文件中为每一个字段建立一个轻量级的索引，来判定一个文件中是否满足WHERE子句中的过滤条件。比如：当执行HQL语句”SELECT COUNT(1) FROM lxw1234_orc WHERE id = 0”时候，先从ORC文件的metadata中读取索引信息，快速定位到id=0所在的offsets，如果从索引信息中没有发现id=0的信息，则直接跳过该文件。详见后面介绍。
说明一下：本文使用Hive2.0.0 + hadoop-2.3.0-cdh5.0.0作为测试环境。
ORC的压缩比

上图中原始的TEXT文本文件为585GB，使用Hive早期的RCFILE压缩后为505GB，使用Impala中的PARQUET压缩后为221GB，而Hive中的ORC压缩后仅为131GB，压缩比最高。
查看ORC的文件元数据
先准备一张ORC的示例表：

CREATE TABLE lxw1234_orc1 (
id INT,
name STRING
) stored AS ORC;
 
INSERT overwrite TABLE lxw1234_orc1 
SELECT CAST(siteid AS INT) AS id,
pcid 
FROM lxw1234_text 
limit 10;
 
SELECT * FROM lxw1234_orc1 ORDER BY id;
139 89578071000037563815CC
139 E811C27809708556F87C79
633 82E0D8720C8D1556C75ABA
819 726B86DB00026B56F3F151
1134 8153CD6F059210539E4552
1154 5E26977B0EEE5456F7E7FB
1160 583C0271044D3D56F95436
1351 FA05CFDD05622756F953EE
1351 16A5707006C43356F95392
1361 3C17A17C076A7E56F87CCC
ORC表lxw1234_orc1对应的HDFS文件为：
/hivedata/warehouse2/lxw1234_orc1/000000_0
新版本的Hive中提供了更详细的查看ORC文件信息的工具 orcfiledump。
执行命令：./hive –orcfiledump -j -p /hivedata/warehouse2/lxw1234_orc1/000000_0
返回一段JSON，将其格式化后：

schema

为每一个字段做了编号，从1开始，编号为0的columnId中描述了整个表的字段定义。
stripeStatistics

这里是ORC文件中所有stripes的统计信息，其中有每个stripe中每个字段的min/max值，是否有空值等等。
fileStatistics

这里是整个文件中每个字段的统计信息，该表只有一个文件，也只有一个stripe。
stripes
这里列出了所有stripes的元数据信息，包括index data, row data和stripe footer。
ORC查询优化
经过上面ORC文件的元数据了解了一个ORC文件会被分成多个stripe，而且文件的元数据中有每个字段的统计信息（min/max,hasNull等等），这就为ORC的查询优化做好了基础准备。假如我的查询过滤条件为WHERE id = 0;在Map Task读到一个ORC文件时，首先从文件的统计信息中看看id字段的min/max值，如果0不包含在内，那么这个文件就可以直接跳过了。
基于这点，还有一个更有效的优化手段是在数据入库的时候，根据id字段排序后入库，这样尽量能使id=0的数据位于同一个文件甚至是同一个stripe中，那么在查询时候，只有负责读取该文件的Map Task需要扫描文件，其他的Map Task都会跳过扫描，大大节省Map Task的执行时间。海量数据下，使用ORDER BY可能不太现实，另一个有效手段是使用DISTRIBUTE BY id SORT BY id;
使用下面的HQL构造一个较大的ORC表：

CREATE TABLE lxw1234_orc2 stored AS ORC 
AS 
SELECT CAST(siteid AS INT) AS id,
pcid 
FROM lxw1234_text 
DISTRIBUTE BY id sort BY id;
该语句保证相同的id位于同一个ORC文件中，并且是排序的。
SELECT DISTINCT INPUT__FILE__NAME FROM lxw1234_orc2 WHERE id = 0;
hdfs://cdh5/hivedata/warehouse2/lxw1234_orc2/000000_0
id=0的数据只存在于这一个文件中，而这个表有33个文件。

也可以通过命令
./hive –orcfiledump -j -p hdfs://cdh5/hivedata/warehouse2/lxw1234_orc2/000000_0
查看文件的统计信息：

该文件中id的最小值为0，最大值为1155.
因此，对于HQL查询”SELECT COUNT(1) FROM lxw1234_orc2 WHERE id = 0”，优化器在执行时候，只会扫描这一个文件，其他文件都应该跳过。
 
在验证之前，先介绍一个参数：
hive.optimize.index.filter，是否自动使用索引，默认为false（不使用）；如果不设置该参数为true，那么ORC的索引当然也不会使用。
在Hive中执行set hive.optimize.index.filter=true;
SELECT COUNT(1) FROM lxw1234_orc2 WHERE id = 0;
查看日志，该查询一共有13个MapTask，
找到包含/hivedata/warehouse2/lxw1234_orc2/000000_0的MapTask，查看日志：

查看其它MapTask，均没有扫描记录的日志。
不使用索引，再执行一次：
set hive.optimize.index.filter=false;
SELECT COUNT(1) FROM lxw1234_orc2 WHERE id = 0;
再查看日志时，每个MapTask中都有扫描记录的日志，说明每个MapTask都对自己的分片进行了扫描。
两次执行，MapTask的执行时间也能说明问题。
 
使用索引的耗时：

不使用索引的耗时（明显多于上面）：

 
由此可见，Hive中的ORC不仅仅有着高压缩比，很大程序的节省存储空间和计算资源，而且在其上还做了许多优化（这里仅仅介绍了row_index）。如果使用Hive作为大数据仓库，强烈建议主要使用ORC文件格式作为表的存储格式。
后面将介绍更多关于Hive的优化策略。

声音是一种波，人耳能够听到的频率范围在 20Hz - 20kHz 之间。
 
为了将音频变成数字信号，需要对音频进行抽样。每秒之内的抽样次数越多，就能越好地还原声音。CD 质量的音频就是每秒进行抽样44100次，也就是 44.1kHz。由于至少两次抽样才能确定一个波峰或波谷，所以 44.1kHz 的抽样频率，最高可以记录 22kHz 频率的声音。
 
抽样频率越高，所能记录的声音频率也就越高。但是，人耳最高只能听到 20kHz 频率的声音，所以抽样频率太高，意义不大。另一方面，抽样频率太低，高频声音无法记录到，会影响音质。比如，电话质量的声音，抽样频率是 8KHz，因此记录不到 4kHz 以上的声音。
 
CD 质量的音频在抽样以后，使用16个二进制位保存每一次抽样结果。所以，每秒的数据量是 16位 x 44,100 x 2个立体声声道 = 1411.2kbps，即 176.4KB，保存成 wav 文件，一分钟就是10.1MB。
 
wav 文件体积太大，一首歌有几十MB，因此人们就发明了音频压缩技术，缩小音频文件的体积。"无损"的音频压缩（比如 FLAC、ALAC、MP3 HD 格式），跟普通的文件压缩技术并无太大不同。为了达到更好的压缩效果，一般都是使用"有损"的音频压缩（比如 MP3、AAC、WMA、Ogg Vorbis 格式）。它的原理是，随着年龄增长，中年人会逐渐听不到 16kHZ 以上的声音，所以这部分信号可以抛弃掉。
 
MP3 格式可以把每秒钟的数据量压缩到 128kbps（即 16KB），一分钟只有 960KB，比起 wav 格式小了90%多。
 
https://www.soundonsound.com/techniques/what-data-compression-does-your-music