用友：时序数据库要更懂业务场景

本文来自IT168 作者卢敏

时序数据库是针对时间戳或时间序列数据优化的数据库。比如工业企业为了管好工业设备，需要用传感器收集一些带有时间标签的数据，这些数据既要求“超大规模数据瞬时写入”，又要求实现乱序管理。

用友网络助理总裁何冠宇表示，时序数据库的技术发展与上层应用的关系密切，上游应用的需求，对时序数据库的发展，在目前阶段有非常大的牵引作用。用友作为领先的企业服务提供商,为了满足工业企业多场景、高性能、高可用性需求，研发了TimensionDB时序数据库，搭载存储引擎、查询引擎、流计算引擎、消息引擎四大核心能力，高效释放数据价值。用友TimensionDB时序数据库，更懂企业业务，已经获得众多行业领先企业的认可。

问题1：现在数据库市场百花齐放，时序数据库其实只是其中比较小的分类，如何定义时序数据库，是不是加了时间标签就叫时序数据库？

时序数据是随时间不断产生的一系列数据，简单来说，就是带时间戳的数据。时序数据库就是专门用来存储、处理时序数据的系统。

一般来所时序数据产生量非常大，比如设备只要运行，就会源源不断的产生数据。但时序数据里面的每个数据点其实不像关系数据库那么丰富，大部分情况数据都具有很强的时效性。因此时序数据库，需要结合时序数据的特点，支持要大量数据的摄入、低成本的存储和高效的处理。

问题2：时序数据是如何诞生的？在哪些行业上会比较有优势？

随着技术的发展，人们对事物的连续性观察的需求也越来越多，典型的连续性观查如服务器的性能监控、锅炉的压力监控、体检时的心电图等等，在这种背景下专门针对时序数据进行存储处理优化的技术被提了出来，最终产生了时序数据库系统。

时序数据库在很多行业里面都有广泛的应用，时序数据库从理论上，在各行各业都有应用场景落地，但我们相信在制造、金融、电力、交通等行业上，已经形成了丰富的应用场景，具备应用上的优势。在这些行业中已经有很多应用，建立在时序数据库的存储计算能力上，为企业构建了丰富的可视化、分析和决策控制等方面的解决方案。

问题3：您怎么去看待时序数据库的发展趋势，针这些趋势有哪些布局？比方说生态、人才、开源。

时序数据库主要是处理时序数据的摄入、存储、查询、分析、计算能力。目前看时序数据库，在技术上分布式和集群这两种是企业的主流的需求。分布式时序数据库是一种将数据分散存储在多个节点上的技术，每个节点都可以独立地处理数据查询和写入请求。集群式时序数据库是一种将多个节点组织在一起，共同处理数据请求的技术，这种架构模式可以提供更高的数据吞吐量和更强的数据处理能力。最近一些公司，提出了模态数据库的概念，支持多数据库引擎整合在一个数据库系统界面下，有些公司提出了超融合架构，大体解决的问题是类似的，就是丰富时序数据库的数据类型，支持更广泛的场景。随着云原生技术的发展，我们看到时序数据库与容器技术的结合也越来越紧密。

我们对时序数据库的发展，结合自身的业务需要，有自己的发展方向选择。边缘端场景是我们首要支持的场景，因此我们聚焦发展如下的一些技术：

实时+高吞吐：通过创新的存储引擎，支持高吞吐数据摄入，同时又满足高并发的实时数据摄入需求，简化数据摄入架构。
多维数据计算和分析：引入类SQL的DSL，结合分布式的内存计算技术，支持多业务维度观察数据，满足可视化和分析的需求。
灵活的数据发布：支持在空(On-Air)数据、落盘数据相结合的数据发布，以DSL描述数据发布规则，发布数据支持以流方式、事件驱动方式被北向消费使用
低资源消耗：适合部署在车间、工厂等有限资源环境，持续提高数据压缩比，降低存储成本，优化内存布局，降低内存消耗，提升计算效率，降低CPU开销。
多中心架构：支持多中心数据实时同步，满组端、边、云协同的数据协作需求。

问题4：除了技术，在其他的方面，比方说像生态、人才、开源，对于得国内时序数据库的发展有什么建议吗？

数据库涉及到系统、存储，系统方面的开发，存储、查询、分布式以及计算等等方面的核心人才的需求，往往企业自身很难具备这些能力，特别需要和外部的合作。用友和清华大学等高校合作，一起去解决时序数据库的关键技术问题。在开源方面，用友时序数据库有很大部分的代码也来源于开源，同时给开源进行贡献，很多工作成果，也进入到一些开源的产品中去。整个数据库产品离不开应用场景生态，因此我们的产品技术发展要具有足够的生态支持能力，在服务生态上，我们的技术提供了一站式的多场景多范式计算支持能力，简化使用方式，降低生态产品在使用我们的产品时的技术开销。

国内时序数据库的发展，还是要结合应用场景进行，我们不太建议把时序是库的边界拓展的太广，还是得专注，解决时序数据库的关键问题。时序数据库的标准，现在也没有完全形成工业标准，不同数据库之间的查询语言、处理能力都各自不同，希望国内各大时序数据库的开发商能够联合起来，制定出能够互操作的标准，共同扩大生态。

问题5：现在时序数据库市场规模有多大？

时序数据库，现在越来越重要，连接的设备越来越多。根据看到的一些情况，包括传感器设备接入的情况来判断，整个数据的价值是面对千亿生态的市场，但是时序数据库市场十分分散，竞争特别激烈，而且很多数据库和场景的结合不是那么密切，所以作为独立市场培育的机会现在刚刚开始。

问题6：你觉得现在时序数据库有技术路线之分吗？比方说全自研，比方说架构上都有什么技术路线？

自研不自研，这不是技术路线，是我们选择数据库发展的模式。但是不同数据库可能有不同的发展路线。之前说了，市面上数据库有超融合的数据库，有多模态的数据库，还有的做一些跟流计算相结合的数据库。

用友时序数据库技术路线选择多计算范式融合的技术路线，也就是支持在一个数据库里面，支持多种计算范式的融合如流计算、事件驱动、多维查询分析等。

我们选择的技术路线主要是进行时序数据库计算处理这块的核心技术进行突破。这是由于我们服务的核心市场决定的。我们服务的北向产品主要包括MES系统、ERP系统、资产管理系统、设备维保系统，我们的应用直接服务工厂、车间系统，核心诉求还是端边协同。应用要与实物系统连接，面对的是海量的设备、时效性要求很高的时间数据，这些系统的计算范式都是反应式的，与一般的报表、仪表板等为功能输出达的系统的计算范式有有所不同。

问题7：用友的时序数据库在产品性能上有什么优势？

海量数据的采集、存储、查询一直是数据库面临的难点，用友时序数据库可实现高性能的数据读写，并可对数据进行实时分析，快速处理海量数据，具有五大核心优势。

1、写入性能高

基于两阶段LSM合并的tLSM算法，有效保障了任何情况下均能轻松实现单机每秒1000万数据点的高速写入能力，实现百万级智能物联网设备接入和高速写入。

2、硬件成本低

专为时序数据设计和优化的TsFile存储格式，支持多种数据类型和相应的SNAPPY、LZ4、GZIP、SDT等压缩算法，可实现1:150甚至更高的压缩比。通过高压缩比的硬盘存储，10亿数据点存储成本将低于1.4元，极大降低了硬件成本。

3、查询速度快

用友时序数据查询引擎采用列式存储、预计算和索引技术，可有效减少数据查询时读取的数据量，极大地降低磁盘I/O次数，轻松实现10亿级数据量、千万数据点查询的毫秒级响应。

4、分析能力强

分析引擎基于用友深厚的行业知识积累，自主研发高性能多维分析引擎和分析DSL，提供便捷的维度管理和分析脚本管理能力；简洁的DSL语法可使零基础人员轻松对业务数据进行复杂的多维分析。

5、扩展能力好

弹性伸缩采用大规模并行处理（MPP）架构和火山模型进行数据处理，具有很高的扩展性，支持秒级增加节点而无需进行数据迁移，适应不同规模时序数据的存储与分析需求。

问题8：您面对客户的时候，他们选择时序数据库都关注哪些指标？为什么？

用友服务的某钢铁行业领军企业，也是跨国型的企业，这种企业对数据的可靠性、稳定性提出较高要求，对宕机、以及维护里面宕机数据丢失不能容忍的，要求产品的高可用。还有一些客户，他们的系统与生产执行紧密关联，对数据的抖动、延迟，有很高的要求，不希望由于压力高增，而影响数据存入。此外客户会具体对内存、IO、CPU等提出一些指标要求，保障在客户的工厂、车间等环境上的稳定运行。一些工业企业为了管好核心的生产制造的高效稳定执行，既要求“超大规模数据瞬时写入”，又要求实现乱序管理。为了满足工业企业多场景、高性能、高可用的需求，用友TimensionDB时序数据库，搭载存储引擎、查询引擎、流计算引擎、消息引擎四大核心能力四大超强引擎，高效释放数据价值。

存储引擎实现高压缩比低成本存储，支持单机每秒1000万数据点的高速写入、实现1:150高压缩比，10亿数据点硬盘成本低于1.4元；

查询引擎提供面向时间序列的丰富查询语义，面向时序数据特征的计算，面向时间维度的丰富聚合函数支持，实现10亿级数据量、千万数据点查询的毫秒级响应；同时支持切片计算、四则运算、周期性分桶聚合等操作，基于专用的多线程多维计算算法，充分利用服务器的硬件资源来提高计算速度。

流计算引擎，提供了与时序数据紧密结合的流计算处理能力，能够持续不断的进行数据消费计算，满足数据实时处理的需要，TimensionDB提供的流计算引擎，未来在语法上可良好兼容Streaming SQL的标准。

消息引擎，提供了工业标准的消息队列能力，支持时序数据基于业务规则，快速发布到消息队列，被消费和处理，满足复杂业务场景下的集成需求。

问题9：客户在做时序数据库选型的时候，应该做哪些准备？有没有建议？

对于时序数据库选型来说，主要不是选时序数据库，首先是要看上游应用，时序数据库市场是上游应用决定的。因为不同时序数据库的特点和适用场景不同，而上层应用的需求和场景也不尽相同，因此时序数据库的选择需要我们结合具体的业务需求，一般来说考虑这个几个因素：数据模型、查询语言、可靠性、性能、生态以及技术支持：