【原创】分布式大数据时间序列数据库设计概述

最新推荐文章于 2022-01-23 09:44:39 发布

weixin_34192816

最新推荐文章于 2022-01-23 09:44:39 发布

阅读量219

点赞数

文章标签：数据库大数据前端 ViewUI

原文链接：https://my.oschina.net/JJREN/blog/100594

版权

为什么80%的码农都做不了架构师？>>>

需求：

一个拥有10年以上寿命的监控系统。它常常会出现什么样的问题？

1 、中心化的数据存储，进而导致单点故障，从而系统无法提供有效服务。也就是业务和节点绑定。

2 、有限的存储空间，不易扩展。追求单机性能，无法做到系统性能随容量的增加线性增加。

3 、数据因为时间的问题而变得复杂、不准确、管理成本增大。

4 、不能扩展采集数据点到亿级别，数据测点数的管理受制于系统内存容量。

5 、不易于定制图形。

6 、测点间缺乏必要的关系与管理。

特性：

满足大数据的IT架构，应该具备的特质：

1 、横向扩展：线性的横向扩展，叠加容量或性能节点，使容量性能得到扩展。

2 、低成本硬件：通过使用普通硬件，降低采购成本。

3 、高可用：硬件故障作为常态而非特例来解决

4 、不共享架构：节点之间相互独立

以此为基础，继续探讨应用。

部署结构图：

HBASE 集群 :

Hadoop是Apache 基金会下的一款开源软件，实现了包括分布式文件系统和MapReduce框架基础架构。并且在其上整合了包括HBASE数据库、云计算管理、数据仓储HIVE等一系列平台。

用HBASE作为存储中心,存储所有的时序数据来构建一个分布式、可伸缩的时间序列数据库。

1 、完整的收集和存储上亿的数据点。

2 、支持秒级别的数据监控。

MEMCACHE 集群 :

Memcache集群构建了一个高性能分布式对象缓存系统，提供数据库系统的缓存服务。

一、根据对象模型，缓存、提前预存数据库的服务所需要的数据，大大减轻HBASE的负载，从而提高数据库的访问效率。

二、构建动态的、多进程的、可管理的分布式数据交互区域。

BASE 集群 :

在整个系统中，BASE集群中运行的程序是HBASE集群对外通信的守护进程。

1 、没有master/slave之分。

2 、没有共享状态。

因此利用以上两点和HBASE集群的特点就可以消除单点。

用户可以通过传统的API或者HTTP协议直接访问BASE集群的接口，也可以通过RPC访问BASE。

在BASE集群中分为前端平台和后端平台。

1 、前端平台通过MemCache集群与客户端程序数据进行交换。

2 、后端平台与Hbase进行数据交换，采用完全异步、非阻塞、线程安全方式。

数据流向图：

BASE需要运行一个或多个守护进程（BASEs）。每个BASE是独立的，没有主节点和从节点的区分，也无需BASE共享其状态，所以可以消除单点状态。

BASE使用HBase作为存储中心，完整的收集和存储数据点。

BASE的用户从来不需要直接访问HBase的数据。

可以通过BASE提供的API。或者是基于二进制RPC协议与BASE进行通讯。所有的通讯发生在相同的端口。由BASE负责存储和检索数据。

Collector收集器，从被监测的系统群集Objects上收集有用的数据，以数据点的形式推送到BASEs中，时间精度在秒级别。

用户可以根据自己的情况，使用和分配多个BASE完成不同的任务，例如BASE1完成数据写入，BASE2可以负责数据检索与查询，这样可以完成任务时候获得最高的效率。

可度量单位(Metrics)

可度量单位(metrics)和时间序列

BASE是一个时间序列数据库。时间序列是指随着时间的增加在可度量单位(metrics)上的一系列数据点的序列。每一个时间序列由可度量单位加上零个或者多个附加在这个可度量单位(metrics)上的tag标签组成。可度量单位(metrics)是希望跟踪的随时间变化的数据。例如（温度、压力）。

在BASE中，一个可度量单位(metrics)用字符串来命名，类似于http.hits。在BASE中能够存储所有不同的可度量单位(metrics)的字符串值。这些信息存储在tsdb-uid表中。

一个数据可以通过一个或者多个tag标签标记的可度量单位(metrics)来指明。BASE存储了这个数据的时间戳、值、以及tag标签，这些信息存储在tsdb表中。当检索数据的时候，BASE根据指明的可度量单位(metrics)检索范围内的所有的数据值，也可以用tag标签标记可度量单位(metrics)来检索数据。

到目前为止，介绍了一些概念和内容，为了更好的说明这些概念和内容是如何工作的，这里用一个例子来说明。

场景：假设监测一个由成千上万台计算机组成的计算机集群系统，该系统对外提供公用事业的WEB服务。

事件：为了了解整个计算机集群系统的使用情况，我们跟踪两个事情：资源平均使用率和WEB服务器访问压力即命中次数计数器。

过程：首先建立两个可度量单位(metrics)，对于资源平均使用率给它命名为:proc.loadavg.1min在Linux平台上这个数据可以方便的从/proc/loadavg文件中获取。对于提供WEB服务的服务器，有一种方法可以访问从WEB服务器开始运行被访问命的次数，它的可度量单位(metrics)命名为http.hits 。

理由：选择这两个例子有两个理由。第一，我们将看到BASE如何方便的处理随时间增加而变化的整型值，例如，命中次数。和如何处理不停变化的浮点型值，例如，资源平均使用率。BASE的一个优势是用户不需要为命中次数计数器做任何速率计算，这个工作可以由BASE系统完成。第二，BASE可以在同一个画面上用不同的刻度绘制两个不同的可度量单位(metrics)表示的数据值。

第一个数据点

在文档的前面关于收集器collector发送数据到BASE中并没有做过多详细的描述，但是你需要提供一个收集器collector可以周期性的为每一台服务器发送数据点的当前值到BASE中。所以BASE能汇聚来自不同主机的数据，可以用tag标签“host”为每一个值进行标记。所以，如果集群中有提供WEB服务的服务器A、B、C…..。他们分别定期的像如下这样发送数据到BASE中：

Putdata ( http.hits , 1234567890 , 34877 , host = A )
Putdata (proc.loadavg.1min , 1234567890 , 1.35 , host=A)
这里的"1234567890"是当前用秒表示的时间值（BASE系统支持的时间分辨率在秒级），下一个值是可度量单位(metrics)在这个时间的值。这个数据来自于主机A。所以用host=A标记。来自主机B的数据将会用host=B标记，依次类推。

聚合器

通过聚合器的sum参数检索数据，意味着什么？用tag标签标记的host=A、B、C的可度量单位(metrics)表示的是三个时间序列，那么所有的WEB服务器在同一个给定时间的总命中次数只需要使用聚合器的sum参数检索数据即可。注意：客户无需在精确的同一时间发送你的数据点，BASE会解决的。所以，如果集群中你的主机A、B、C在每一秒命中了1000次，那么将返回3000次。
如果要获取集群中单台服务器被命中的次数。有两种方法：第一种如果只关心集群中单台服务器的平均命中次数，那么只需要把聚合器的sum参数修改为avg，检索数据即可。也可以使用聚合器的max，min参数，检索最大和最小值。更多的聚合功能开发需要漫长的过程。第二种方法见下面的tag标签小节说明。

减少采样

为了减少返回数据点的个数，可以指定减少采样的间隔和方法，例如用以下字符串指明一小时的平均值"1h-avg "或者一天的总和"1d-sum"。这也有助于（例如使用max和min）在一段给定的时间范围内发现最好和最槽糕情况下的数据点。减少采样最大的用处在于使图形图像不那么密集而且更美观易看。

Tag标签过滤

BASE在检索数据的时候，可以使用一个或者多个"Tags"标签，之前使用的tag标签是host。BASE展示了在这个时间范围内被host标签标记过的数据。你能过滤图形以便只绘制一台主机的数据。如果使用tag标签host为A，那么意味着只希望得到主机A的值。如果你想要获得多个主机的值，那么可用分隔符连接主机列表，例如A|B。这将给你同一个tag标签下的两个可以绘制的实例，一个是主机A，另一个是主机B。最后，也能指定特殊的通配符*来绘制每一台机器数据。

想象一下，你的服务器运行了两个web服务，一个负责动态的内容，另一个负责静态的内容，并且不再建立其它的的可度量单位(metrics)，它仍只用http.hits标记。
并且假设已经有一个collector收集器发送数据到BASE，类似于下面这样：
put http.hits 1234567890 34877 host=A webserver=static put http.hits 1234567890 4357 host=A webserver=dynamic put proc.loadavg.1min 1234567890 1.35 host=A
Putdata ( http.hits , 1234567890 , 34877 , host = A webserver=static )
Putdata ( http.hits , 1234567890 , 34877 , host = A webserver= dynamic)
Putdata (proc.loadavg.1min , 1234567890 , 1.35 , host=A)
为什么不建立其它的可度量单位(metrics)呢？根据应用情景来说，有时候要关注的事情是总的命中次数，有时候可能要分别关注动态和静态的命中次数。用tag标签标记可以很容易做到这些。这里用一个新的tag标签webserver，可以轻易的做到以上提到的两种情况。

新建可度量单位(metrics)的一些原则

标签tags与可度量单位metrics可度量单位(metrics)应该表示一个事物的抽象特性，举例来说，像“以太网数据包”。一般来说，不会去采集像这样的可度量单位(metrics)：net.bytes.eth0 、net.bytes.eth1等等，而是采集可度量单位(metrics)命名为metrics =“net.bytes”并且tag标签标记为iface = “eth0”的数据点，等等。
也不用麻烦费事的建立表示网络数据“流入”和“流出”的两个可度量单位(metrics)，只要添加一个表示方向的tag标签direction=in 或者direction=in就好了。这种方法能很容易的看到网络数据的活动情况。也可以很灵活的看到针对指定网卡和网络数据流向的详细情况。

Tag的更多使用

在很多情况下，你可能有许多机器组成的集群或者一个组来做相同的事情。然而，随着时间的流逝。当你发送关于集群信息的相关数据到BASE中时，只需要使用一个tag标签即可。就像这样，添加一个tag标签cluster=webserver，然后集群中的每一台webservers中的点被会发送。如果cluster= db ，那么集群中的每一台dbs中的点就会被发送。当你图形化webserver中cpu的负载率，所有的指标可以聚合到一个图形上。我们可以添加一个webserver或者database，你必须保证标签的正确性，才能显示相应标签的显示的数据

可度量单位(metrics)和tags标签的精度

最大Tags标签数默认是（Const.MAX_NUM_TAGS）,时间戳占有8位。可度量单位(metrics)名字、tags标签名字和tag值是数字和字符组合，还可以包括 “-”，“_”,“.”，“/”。

负载平衡工具

开源Varnish是一个强大的HTTP负载平衡工具，也是一个非常好的缓冲技术。当允许多个BASEs时，Varnish对于通过BASEs的分布HTTP请求会有帮助，默认情况下对于写操作不通过HTTP 协议，所以只能对于读请求使用Varnish，使用Varnish能轻松的为read设计BASEs的规模与容量。

表结构设计

在HBASE集群系统中，包含了两个表tsdb和tsdb-uid 。

tsdb-uid用来存储所有的基础信息，包含可度量单位(metrics)名称、可度量单位(metrics)名称的ID、tag标签名称、tag标签名称ID、tag标签值、tag标签值的ID等。

tsdb-uid包含两个列簇分别是tsdb-id::name , tsdb-id::id，在列簇name和id下又包含了metric 、 tagv 、tagk三列。

HBASE查询相当简单，提供了get和scan两种方式。 HBASE还提供了很多过滤器，可对行键，列，值进行过滤。过滤方式可以是子串，二进制，前缀，正则比较等。条件可以是AND,OR等组合。

通过rowkey定位查询速度很快。

每个数据点存储在HBase中的单元格中。Rowkey是由可度量单位(metrics)的ID，时间戳，tags标签构成。每个标签是由tag标记名称，tag标记ID组成。

例如，你有以下数据点:
Metric_1 1292148123 42 reqtype=foo host=web42
Metric_1 的可度量单位(metrics) ID是 [0, 0, -69]
reqtype 的tag标签名ID是[0, 0, 1]
foo的tag标签值ID是[0, 1, 11]
host的tag标签名ID是[0, 0, 2],
web42的tag标签值ID是[0, -7, 42],
那么将得到以下row key。注意：时间戳的字节数组是[77, 4, -99, 32] = 1292148000