分布式时序数据库-不破不立

题外话:

时间过了这么久(最近确实有点忙),才开始说时序数据库背景、需求及现状。其实主要想说明一个问题:为什么需要做一个分布式时序数据库?


DBEngine 数据库关注度趋势

过去24个月,时序数据库关注度趋势遥遥领先于其他类型的数据库。从数据库细分领域产品的维度,至少说明了时序数据库很"火”。

IT - DT IOE时代变革

万物互联 IOE 时代的到来,驱动着传统IT时代->DT时代的伟大变革。如果说,前几年Hadoop的商业化,代表了大数据时代的到来。那么,当前的IOE则带着大数据时代深刻的变革而来。


对于各个行业来说,大数据驱动着传统IT行业的数据变革。在数据归集化、资产化、运营化、智能化、生态化5个阶段,交叉并行。每个行业大数据项目的不同建设阶段,决定了当前的数据应用水平,决定了当前数据所发挥的价值。

那么在这个不同阶段中,需求的变化对于产品和技术的要求,会表现出不同的生命周期。也许在某个阶段、某个时间,某个以前很火的大数据产品就会在这个不断变革的时代悄悄消失?

如果单纯地从数据角度来说,时序数据库可以算做是传统大数据产品和技术的细小分支。因为殊途同归,都是围绕着数据存储、数据计算、数据接入做文章。 只不过,面向的业务领域不同,解决的问题域不同而已。时序数据库面向的是:

1、IT基础设施的资源监控分析

2、业务系统的运行监控分析

3、工业生产的安全监控分析

4、物联网设备的实时分析

......


有趣地是,这些细分领域中,数据就像时间流水线一样,源源不断。而基于时间戳地时序分析、时序预测、时序存储才是时序数据库要解决的问题。那么为什么我们不用Hadoop、不用RDBMS?

无人驾驶领域

存储:每辆车每天产生8TB+ 的数据存储

分析:多种维度组合聚合、统计、关联和机器学习

读写:各种状态监控数据,包括温度、湿度、方向、坐标、速度、告警、运行数据的高并发写入和查询。

计算:时序范围的窗口计算,要求近实时返回结果。


也许数据依然是那些类型,结构化、半结构化、非结构化。但是IOE领域,对于时序数据存储和计算的要求更高了。

1、数据分析的维度更加复杂

2、数据计算的效率要求更高

3、数据存储的成本要求更低

4、数据读写的能力要求更强


在这里,我不得不吐槽一下围绕着Hadoop做的时序数据库,真的太重了,那么多组件要维护,好复杂。

1、可能,有同学会基于Hadoop来做时序数据的存储和分析。OK,我告诉你,没有问题。

但是,我想要时序数据在边缘设备进行部署,这个Hadoop是不是太重了呢?

我还想要做海量数据多维分析计算,你能忍受Hadoop的计算延迟吗?

2、可能,有同学会基于RDBMS来作为时序数据,OK,我告诉你,也没有问题。

但是,你可以忍受海量时序数据巨大的数据冗余和高昂的存储成本吗?

我还想要基于时间和计数器的窗口计算,这个怎么搞?


抽象一下,其实落脚到时序数据库具体设计目标上,其实我们要解决的问题域应该以下一些,是不是?

1、高效地时序数据压缩,降低存储成本,为用户省钱啊。

2、支持时间范围,维度组合、指标组合的数据检索,比如数亿时序点的秒级响应

3、支持时间范围,维度组合、指标组合的数据计算,

4、支持海量数据高并发的持续写入,比如每秒写个上千万的时序点

5、支持基于计数和时间的窗口计算

6、当然,你还要足够轻量级。我既可以放在边缘侧做边缘侧的数据存储和计算;也可以放在大数据中心,海量数据的存储。

7、还有很多....


这里主要先明确一下问题域,大概知道我们要做的时序数据库的设计目标。才能将目标拆分,是吧。具体看看一下篇吧。里面会涉及到时序数据库功能架构,然后会分别介绍一下每个模块的功能和一些设计思路。 当然,技术架构要放到后面一篇,是不是?


好了! 时序数据库开胃菜 --不破不立。 做事情,一定要说服自己为什么?


今天,心情色。灰色!

发布于 05-21

文章被以下专栏收录