大数据

前言 最近家里事情比较多，逃了很久的更。终于找到了点时间继续写一写，好不容易坚持下来的写东西的习惯可不能半途而废了。 上一篇文章吐槽了下技术快速发展对技术人员带来的各种深远影响，但是主要是从总体上来说

前言 logstash作为elastic公司elkb体系中的一环，在日志处理中被广泛应用。它可以实现数据传输，数据过滤，格式化输出，还有强大的官方以及自定义插件功能，因而在很久之前就已经闻其大名了。也

前言 写在最前面的话，土豪以及数据中心提供统一服务的朋友基本可以无视，看看热闹就好，毕竟能用钱解决的问题都不是问题 需求来源 由于各种原因，包含但不限于信息安全，方便管理，数据重用等原因，相当一部分的

前言 缩小数据体积，减少硬盘占用，进而减少内存以及缓存占用，这基本上是数据库的常规操作。而说到这个需求，大家肯定会想到各种各样的压缩算法。毋庸置疑，这是最基本的一条路，那么今天的主角HBase除了这条

前言 之前的文章中讲到了位图 BitMap（下文简称BM），大家应该被它的性能深深折服。在它适用的场景，无论是查询的时间复杂度O(1),还是存储的空间复杂度(理想情况下是int数组的1/32),都是无

前言 如果大家经常看抗战相关的电影或者电视剧，一定会对里面出场率很高的边三轮记忆犹新，这种绿色的三轮摩托几乎成了“太君”的代名词。而且战斗打响后，这个边三轮肯定第一时间被打爆，要么是被地雷炸飞，要么是

前言 数据处理从诞生至今也不过几十年，如果针对大数据处理，那也是本世纪初才真正开始。但就是这么短的时间内，大数据处理技术却更迭频繁，从架构到具体技术实现都是如此。生命力弱的如昙花一现，很快被别人忘记；

需求 本文档描述大段落文本信息的存储，查询功能实现 需求：能够从Web页面上通过各种条件查看大段文本信息，能够下载完整文本信息 环境信息 Hadoop2.6，HBase1.2，Elasticsearc

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 需求来源 在ElasticSearch的生产应用中，尤其在数据量比较大的场景下，性能优化就显得十分重要。可以说在ElasticSearch的使用场

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 背景 上文曾经留下了一个问题未详细说明，那就是ElasticSearch在对应RDS的概念中少了数据库这一曾经的对应关系，大家想想这是为什么呢？

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 需求背景 虽然说redis是纯内存操作，效率非常高，但是一次插入或者删除千万级或者亿级的操作，如果采用单条处理的api，整体处理效率还是很低的；另

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 前言 schema即元数据，自从数据库诞生的那一天，这个东西就作为数据库最重要的组成部分而出现了。schema就如同现实世界中的配方或者图纸，被数

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 前言 ElasticSearch在当今NOSQL中也算独树一帜的存在了，借助于强大的全文搜索能力以及本身具备的多维度搜索以及聚合能力，再加上母公司

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 Coprocessor简介及使用场景 HBase在使用过程中已经初步具备了RDS中的CRUD的操作，能够满足基础数据的查询和管理。但是这对于常规的

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 名词解释 相信做过数据处理的小伙伴们对于kafka肯定是熟悉的。基础的kafka知识这里就不过多陈述了。今天主要来讲一下kafka的几个特性，下面

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 前言 讲解HBase事务的文章很多，这里就不过多赘述了，大家应该都知道是通过MVCC实现的。但是今天这篇文章的背景是一个同事和我讨论一个问题引发的

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 前言 spark 3.X发布到现在已经有1年多了，很多小伙伴已经尝过鲜了，很多小伙伴准备去尝鲜，最近看了下spark 3.X相关的新特性，发现了3

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 前言 俗话说得好，架构重构一时爽，一直重构一直爽，又到了架构重构的时节；俗话又说了，饱暖思X欲，在产品技术架构稳定运行了好久之后，又迎来了躁动的撩

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 背景 为了配合公司产品K8S化，方便产品快速扩展以及部署，需要对当前的大数据组件进行相关的多租户以及资源隔离的配置，组件暂时包含但限于HBase、

本文已参与「新人创作礼」活动，一起开启掘金创作之路。 前言 东北有句名言叫做能动手就别吵吵，虽然听起来简单粗暴，但是不可否认的是带来了高效的解决问题的方式。毕竟吵吵基本上最后的结果就两种：没啥事白吵吵