云HBase助力物联网建设

云HBase助力物联网建设

其实我觉得题目说的很清楚，随着物联网时代的到来，万物都在产数据，大数据的时代永远不会过去了。那么数据怎么存呢？存储了怎么低延迟，高并发的访问呢？这都面临着挑战。

1. 传统的关系型数据库使用B+树来构建索引，随着数据p级，百p级，终端不断增加，数据库可能会拒绝服务，甚至奔溃的，即使这可以通过数据库的一些切分等优化手段得到缓解，但是关系型数据的扩展性也不好啊。
2. habse的索引是采用LSM，可以转化随机读写为顺序读写，时延低，而且对扩展性的要求较好，因此存储容量大。但是文章没有提及高性能和低延迟原因，但是我觉得这和HDFS 的存储，还有MAPREDUCE的高吞吐计算也是有关系的。
3. 最后就是一般数据会走2条链路，
   1. 消息队列+实时计算+入库（hbase）
   2. 取需要持久化的重要消息入库（hbase）+数据离线分析（hive，pig等）
   3. 最终都可以通过websocket，或者restful接口进行界面展示。

下面是原文。

摘要： 物联网最大的特点写入量大，要求延迟低，且数据存量巨大。云HBase非常满足物联网存储需求，存储数P甚至百P的空间存储需求，延迟稳定在数毫秒之内，跟Hadoop分析体系有较为深入的结合，满足分析类的需求。

引言

从有线互联网到无线互联网，本质是加强了人与人之间随时随地的关联。下一个互联的时代是万物互联，也就是物联网。有人说，这个是第三次信息革命，不管咋样，这都会产生大量的数据。
举一个例子，杭州市有200w辆汽车(具体肯定比这个多)，我们给每辆车安装一个传感器，每隔10s，上传1k的数据量，说明这个车的位置，一些情况。QPS为20w，1年的数据量为：365*360*24*200w*1k=5.73P ，如果不做任何的容灾，每个磁盘4T来算，则需要 5.73*1024/4T=1466块磁盘，做一些容灾，则至少需要2000+的磁盘。这些数据蕴含着巨大的价值，分析这些数据后，则会改变整个杭州的交通。

架构

在我们传统架构下，一般会使用关系型数据库，关系型数据库索引结构基本上都是类B+树，随着终端设备数增多，读写压力剧增，读写延迟增大，数据库面临崩溃；其次，关系型数据库也无法做到存储容量无限扩容，目前有一些分库分表的方案，实现起来比较复杂，往往有较多的限制。

物联网最大的特点写入量大，要求延迟低，且数据存量巨大。HBase基于LSM，把磁盘的随机写改为顺序写，写吞吐高，不受SSD随机写入放大干扰，也不受空间放大的干扰。目前HBase非常满足物联网存储需求，存储数T、数P甚至百P的空间，延迟稳定在数毫秒之内，跟Hadoop分析体系有较为深入的结合，满足分析类的需求。具体物理网的大致结构如下：

主要流程：
1、一部分实时，直接走MQ，到流式系统，做一些实时的分析，后写入HBase。
2、一部分写入HBase，一般是全量数据，后接入Hadoop/Spark，做一些离线分析，后续结果写入HBase中。
往往在使用HBase时，使用的rowkey设计是：设备ID+地点+xxx+时间xxx

每个云公司，都在前端的一些环节做了很多事情，比如提供硬件支持、协议支持、ECS可以使用一些弹性方案，当然也有不少公司是自己做方案。
针对数据从云HBase到EMR Hadoop/Spark中，目前有两种方案，其一是Hadoop、Spark直接连接云HBase分析；其二是云HBase提供一些导出数据的功能，在EMR中自动生成一张表（目前云HBase在实现中）。

云HBase地址：https://cn.aliyun.com/product/hbase