前言在计算机的世界中，数据计算和处理都是准确无误的，这在大多数人看来是理所当然的，确实也应该是这样的。但是在某些场景下完全的准确无误意味着很高的代价，不管是时间上还是空间上。于是大家都在考虑，能不能有一些方法能在很小的错误率的前提下，能大幅度提高效率减少资源消耗，而对于小概率误判的场景，能通过容错机制将窟窿补上。显然有，在这种背景下，咱们本文的主角，一个“不靠谱”的二愣子Bloom Filter（

互联网的快速发展，带来了一大批新的名词，这次名词的更新换代的速度也是快的惊人，往往一波未平一波又起，使得大家不能墨守成规，必须不断学习才能赶得上科技和技术的发展潮流。计算机行业更是如此，可能真的要实践活到老学到老的古训了。精通一个技术然后躺着赚钱是不存在的，因为可能几年后这项技术就被淘汰无人问津了。所以千万别再说计算机的高薪如何的不合理。计算机行业只能算门槛不低且付出和产出相对成正比的行业。回到本

说到HBase数据压缩，在HBase中有两种方式可以达到该目的，一个就是column family的compress，HBase支持none/snappy/lzo/lz4/gz等几种压缩方式来压缩数据，最后降低数据总量的大小；另一个是data block 的encoding，通过对data block中的KeyValue中key的相同部分进行处理来减少存储的占用，目前支持prefix/diff/f

背景为了配合公司产品K8S化，方便产品快速扩展以及部署，需要对当前的大数据组件进行相关的多租户以及资源隔离的配置，组件暂时包含但限于HBase、ElasticSearch、Kafka和Redis。下面将从不同角度对上面提到的四个组件进行多租户以及资源隔离方案的描述，并根据需求选取效果明显且性价比高的方案进行适配与实现。正文目标实现单集群支持多租户，租户之间相互不影响能够快速方便的管理单租户的数据对

前言随着大数据和人工智能行业的发展与成熟，各个行业各种业务场景下OLAP（联机分析处理）的需求越来越强；人工智能中的NLP（自然语言识别）的发展为文本分析以及全文检索带上了一个新的台阶，在这种背景下，作为上述两种需求的集大成者的elasticsearch的应用越来越广泛，elasticsearch中存储的数据也越来越多，在elasticsearch给我们带来很多便利的同时也带来了很多问题：查询数据

背景为了配合公司产品K8S化，方便产品快速扩展以及部署，需要对当前的大数据组件进行相关的多租户以及资源隔离的配置，组件暂时包含但限于HBase、ElasticSearch、Kafka和Redis。下面将从不同角度对上面提到的四个组件进行多租户以及资源隔离方案的描述，并根据需求选取效果明显且性价比高的方案进行适配与实现。正文目标实现单集群支持多租户，租户之间相互不影响能够快速方便的管理单租户的数据对

环境信息：CentOS 6.5现象：同事启动程序发现端口被占用，netstat查看之后发现如下现象：发现端口处于FIN_WAIT1状态以及CLOSE_WAIT状态，无法释放问题分析：FIN_WAIT1以及CLOSE_WAIT状态的原理以及产生的原因大家自行baidu，下面就说下怎么解决上述问题，释放端口FIN_WAIT1：1、sysctl -a |grep tc...

需求来源：客户现场redis内存飙升，由于无法远程连接客户现场环境，进而分析redis的内存中占用较大的key，无法进行问题精确定位，所以需要一个组件或者方法来查看redis内存占用大的key的列表，进而定位问题解决方案：依赖：redis持久化的rdb文件，以及开源的Redis Data Reveal（rdr）组件rdb文件：该文件有两个来源：redis配置的持久化策略，定期会生成一个rdb文件，

原文链接：https://blog.csdn.net/AaronLau_love/article/details/72864963 左侧栏，我的计算机，选择需要克隆的虚拟机，右键，管理->克隆点击下一步，选择虚拟机中的当前状态（如果有快照也可选择快照，方法是右键虚拟机，快照->拍摄快照），下一步，选择创建完整克隆（克隆一份独立的系统出来，需要较大的系统空间），填写虚拟机

前言说到elasticsearch，大家第一反应就是他是一款NOSQL数据库，既然是NOSQL数据库，则生产环境上必定是集群，由很多台服务器共同搭建而成。按照常理，分布式集群从搭建模式上分为中心化模式，即有主节点和从节点之分，即部分节点有成为主节点的资格，其余节点则只能是从节点，如Hadoop，HBase；另外一种模式是去中心化模式，即所有节点的角色都一样，任何一个节点都有可能成为主节点，如Zoo