大数据架构之道

在HBase中，我们存储的数据是时序数据。时序数据的特点是，只关心实时数据，历史数据一般不关心。因此，我们在设计RowKey时，充分根据时间特性来进行设置：bucket_time_xxx。

背景 QE是一个查询代理服务。它包含实时查询（redis）、历史查询（tsdb）和 数据库查询（cube）。其中，实时查询的特点是：查询比较重要 查询量小 响应时间短 查询频率相对稳定

yarn的核心思想是将集群资源进行管理。例如：任务的调度与监控。为达到该目的，yarn提供了两个组件：ResourceManager 和 NodeManager。其中，ResourceManager用来管理集群资源，NodeManager是每台机器的框架代理

上一篇记录了在进行bulkload编码时遇到的坑，这一篇记录一下，实际执行过程中遇到的坑。采坑集 采坑1——单次load太多hfile后，hmaster飘红 现象 单次load了太多的hfile，每个region接近100个hfile

当我们分析了问题，并改进了新的rowkey结构，那么我们为了做到无缝对接，需要将历史数据进行迁移。迁移历史数据的思路大体为：1. 读取原数据 2. 按新结构生成RowKey 3. 写入新表

当前我们的数据是时间序列数据。由OpenTsdb写入。OpenTsdb在HBase中设计的RowKey格式：metric_time_tagk1_tagv1…tagkn_tagvn这种时间序列的数据，存在一个很严重的问题：数据热点。

长时间gc，在部分节点，每个小时，都有一个长时间gc的尖峰。关于G1 GC，对HBase进行进一步改进。对于HBase，我们当前的配置：

对读写缓存进行了分离，使用了堆外内存，读缓存不再往内存中写。整体gc有了一定的提升，但还是会有整点尖峰情况。查看HBase的读写请求，基本趋于稳定，所以整点的尖峰，猜测和调整HBase参数基本无关。

HBase is the big data store of choice for engineering at HubSpot. It’s a complicated data store with a multitude of levers and knobs that can be adjusted to tune performance.

HubSpot engineering is a invested heavily in microservices and continuous deployment. Java is not only used to run our thousands of deployables, but also our queues