前言

众所周知，hadoop的大数据生态的组件版本对依赖十分的繁杂，对此我们在如果需要用apache开源库来一点点堆起积木，有点繁琐
我们这个项目的目的只是为了更快更方便的构建大数据生态环境。
所以我们这里选择采用cdh的方式来构建大数据生态，但是由于我们希望在终端就部署好服务，而不需要客户端，所以这里就不选择用cmf

前言

由于之前一直没有整理过hadoop的内容，或者说整理得比较少，所以觉得有必要

前言

虽然自己对docker有了一定了解了，但是有一些比较零碎对知识点，一直没整理，所以现在用一篇文章来记录下一些零碎点知识点，方便自己查阅

前言

由于要造一些轮子，例如 像 laravel 一样的 Event组件，我参考了网上的几个库

• go-trigger
• go-events

这 2 个库，大同小异，只有一小部分差别，新打组件将会在这 2 个库的基础上再封装

这 2 个库都是比较早期的库，所以在实现上用到了 map，但是由于考虑到 map 的线程安全性问题，所以他们都使用了 go1.9 之前实现的方式，就是在结构体嵌入一个读写锁来避免线程安全问题。

在 Go 1.6 之前， 内置的 map 类型是部分 goroutine 安全的，并发的读没有问题，并发的写可能有问题。自 go 1.6 之后， 并发地读写 map 会报错，这在一些知名的开源库中都存在这个问题，所以 go 1.9 之前的解决方案是额外绑定一个锁，封装成一个新的 struct 或者单独使用锁都可以。

本文带你深入到 sync.Map 的具体实现中，看看为了增加一个功能，代码是如何变的复杂的,以及作者在实现 sync.Map 的一些思想。

前言

Redis 我们用的蛮多的了，但是一直也没有整理什么资料，刚好今天要处理一下，顺便一下相关的事务和 lua 脚本的内容，由于管道(pipeline)不在这次原子性问题当中，所以我们就不加进来比较说明了。

前言

由于我们部门的一些大数据服务是用到 kafka 的，这个时期正值我们对 golang 语言对一个转型阶段，对比了一下开源对 kafka 客户端，决定使用 confluent-kafka-go, 所以在这里记录一下confluent-kafka-go 的一些内容

前言

很多小伙伴或许还不清楚各个tag的区别，其实最大的一个问题在于，你需要了解各大操作系统的不同。

前言

目前一些传统的公司比较早期使用大数据计算引擎的，都会选择使用imapla做为计算引擎，所以对impala对一些sql使用还是需要熟悉的。

前言

由于部门的大数据服务一直都是用kafka，但是一些常规的业务系统，我们并不希望依赖kafka，所以我们引入了rabbitmq。

前言

Rust 中，crate 是一个独立的可编译单元。具体说来，就是一个或一批文件（如果是一批文件，那么有一个文件是这个 crate 的入口）。它编译后，会对应着生成一个可执行文件或一个库。

Rust 提供了一个关键字 mod，它可以在一个文件中定义一个模块，或者引用另外一个文件中的模块。