前⾔：
写在最前⾯的话，⼟豪以及数据中⼼提供统⼀服务的朋友基本可以⽆视，看看热闹就好，毕竟能⽤钱解决的问题都不是问题
汤炳正
需求来源：
由于各种原因，包含但不限于信息安全，⽅便管理，数据重⽤等原因，相当⼀部分的⼤数据业务产品需要进⾏本地化或者私有化部署，此时除了技术开销（产品成本）外，硬件开销也会成为⼀个头等⼤事，成为很多项⽬的重要考虑因素，所以在功能以及性能表现差不多的情况下，硬件成本更低成为产品竞争⼒的⼀个重要因素。 拆分成专业术语，上述需求其实就是内存，硬盘，CPU以及带宽资源的降低与优化，在当前⼤数据平台性能严重依赖内存的时代（尤其是⾮计算密集型或者没有机器学习或者深度学习的前提下），内存资源⼏乎是⽆法削减的，除⾮以牺牲性能为代价，所以优化的重点将从CPU.硬盘以及带宽上下⼿，如果内存有富余，尽量⽤内存去置换其他资源，从⽽达到性能最⼤化
设计⽅案：
平台现状：
capitel公司内部是elasticsearch，hbase以及redis的重度使⽤者，考虑到抓⼤放⼩，⽴竿见影的⽬标，⽽redis⼏乎只靠内存，所以硬盘以及CPU的优化⽬标就只有拿elasticsearch和hbase开⼑了，带宽毫⽆疑问只能拿传输的消息开⼑了，下⾯就从CPU，硬盘以及带宽来进⾏分开描述。
昆虫病毒
具体实现：
CPU：
提⾼CPU资源使⽤率：
对于绝⼤多数⾮计算密集型的⼤数据平台来说，CPU在标配的服务器上⼀般都是富余资源，所以可以考虑使⽤CPU资源去置换其他资源，提⾼CPU使⽤率。
具体⽅案如下：
1. CPU置换硬盘资源：对存储的数据进⾏Compression和Encoder，正巧elasticsearch和hbase（⼏乎所有的数据库）都⽀持，那就
搞起吧，具体的实施原则下⾯介绍，这⾥先提⼀嘴
2. CPU置换带宽资源：对传输的数据选取⾼性能的Serialize和DeSerialize，也有助于降低带宽资源，同样下⾯具体介绍
减少CPU空闲量：
1. 兼顾CPU密集型应⽤和⾮CPU密集型应⽤的混合使⽤，使CPU资源充分利⽤，较少空闲量
2. 针对部分场景下，如Hadoop主节点或者HBase的主节点，如果没⽤来存储数据，则节点负载理论上不会太⾼，在保证组件稳定性的
前提下可以在该节点上部署部分应⽤来充分利⽤CPU以及其他资源
硬盘：
数据库数据滚动存储：
⼤数据的特点就是数据量⼤，但是单位数据的价值⽐较低，在正常的业务条件下，可以保持⼀定时间内的明细数据，如半年或者⼀年，其余的数据在经过统计分析后可以进⾏转储或者直接删除，毕竟很多情况下，我们不会关⼼⼏年前发⽣的⼀条明细数据的情况。
针对这种场景，hbase以及elasticsearch中的数据可以设计滚动存储，只保留最近⼀段时间内的数据。elasticsearch可以通过curator或者定时任务来进⾏数据清理；hbase可以通过ttl或者定时任务来清理数据
使⽤压缩以及编码策略：
压缩以及编码策略是数据库节省硬盘资源的常规操作，有的默认开启了，有的未开启，有的可以优化。针对hbase以及elasticsearch 有如下⽅案：
1. Elasticsearch使⽤best_compression压缩，默认情况下Elasticsearch使⽤的是lz4压缩，理想情况下，使⽤best_compression能
节省⼤概15%-25%的存储，但是由于压缩只作⽤于source字段，所以如果禁⽤了source字段或者Field的索引量⽐较⼤，则压缩效果会⼤打折扣，具体以实际测试数据为准
2. 对于HBase，可以使⽤compression和encoder，具体参见这⾥
优化存储结构：
对于Elasticsearch来说，可以开箱即⽤，不建⽴索引也可以通过数据分析来创建索引和存储数据；对
于HBase来说，由于是⽆shema 的结构（表的配置只到列族⼀级），所以可以随便扩展列。这些功能再给我们带来很⼤便利，降低使⽤成本的前提下，也带来了巨⼤开销的代价，所以⾃定义存储⽅案，优化存储结构成为提⾼性能，降低硬件开销的⼀个重⼤突破⼝，具体操作如下：
1. Elasticsearch对不必要的特性进⾏禁⽤，这个内容⽐较多，⼤家可以⾃⾏在⽹上学习，如果需要的话，我个时间再整理⼀篇⽂档，
举两个例⼦来说明：对于⼀个String类型的字段，如果不需要分词，则将field类型设置为keyword代替text；对于int型的值，如果不需要进⾏⼤⼩⽐对，仅仅是精确查询，则将field类型设置为keyword代替number类型。总⽽⾔之，禁⽤⼀切不需要的属性和索引2. 在不影响查询的前提下，减少HBase列的个数，对关联性较⼤的字段进⾏统⼀存储，因为对于hbase来说，底层都是存储cell的，每多
⼀列，rowkey，columnFamily，timestamp等都需要冗余存储⼀份，所以对于关联性较⼤的列建议统⼀存储到⼀列，⽤json，⼆进制对象或者protocolbuffer进⾏处理
带宽：
带宽资源相⽐上⾯服务器资源的⼀次性投⼊，是⼀个持续投⼊的资源，对于某些数据量较⼤，数据敏感需要使⽤专线的场景，带宽费⽤⼀年动辄⼏⼗万甚⾄上百万，确实很吓⼈，哪怕在当今带宽费⽤已
经⼤幅削减的前提下，费⽤也是不菲的。所以针对上述情况，设计下⾯的两套⽅案进⾏带宽资源的削减：
使⽤码表转换减⼩消息体：
重商主义对于消息中重复率较⾼，字段体较⼤的部分，可以使⽤码表进⾏编码转换的⽅式进⾏传输，传输过程中使⽤转换了的编码，在server 端和client端存放解码字典进⾏解码。
对于部分固定类型的字段，如ip，date，time，位置信息等字段，可以转换成int或者其他更⼩的消息体来进⾏传输，在两端进⾏编解码。
贝壳董事长选⽤⾼效的序列化和反序列化算法：
序列化和反序列化对于⽹络传输来说是必需的，但是序列化和反序列化的算法确实可以优化的，笔者绝⼤部分使⽤的java，所以默认的序列化和反序列算法是java⾃带的defaultXXX的序列化和反序列算法，这个算法不需要额外实现或者处理就可以使⽤，但是缺点是性能和效果是真⼼的差，建议使⽤⾼效的序列化和反序列算法，在这⾥笔者建议使⽤kyro或者protocol Buffer，⼤体介绍下两者的优缺点和应⽤场景：
1. kyro很快，压缩⽐很⾼，spark默认就是⽤kyro进⾏序列化和反序列化，但是缺点就是不兼容变化，
如果元数据发⽣增量变化，则
kyro⽆法进⾏解析，所以针对实体固定，⼏乎不会发⽣变化的场景，kyro是个很好的选择
2. protocol Buffer是google出品，所以对性能不需要有任何担⼼，⽽且可以做到兼容增量变化，但是缺点是需要⼿动维护⼀个元数据
的proto⽂件，序列化和反序列化需要依赖该proto⽂件⽣成的实体⽂件，所以针对实体不固定，需要增量更新的场景，protocol Buffer是个很好地选择
具体的技术选型请⼤家⾃⾏学习。
结语：
降低硬件和带宽资源就和系统性能优化⼀样，总是永⽆⽌境的。所谓性能优化⼀时爽，⼀直优化⼀直爽，所以⼤家可以根据⾃⼰的实际需求进⾏选取，达到⼀个点即可。凡事都讲投⼊产出⽐，性能优化亦是如此。
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议