共计 7449 个字符，预计需要花费 19 分钟才能阅读完成。
简介：随着 IoT 技术的疾速倒退，物联网设施产生的数据呈爆炸式增长，数据的总量（Volume）、数据类型越来越多（Variety）、访问速度要求越来越快（Velocity）、对数据价值（Value）的开掘越来越器重。物联网产生的数据通常都具备工夫序列特色，时序数据库是以后针对物联网 IoT、工业互联网 IIoT、利用性能监控 APM 场景等垂直畛域定制的数据库解决方案，本文次要剖析物联网场景海量时序数据存储与解决的关键技术挑战及解决方案。
作者 | 林青
起源 | 阿里技术公众号
随着 IoT 技术的疾速倒退，物联网设施产生的数据呈爆炸式增长，数据的总量（Volume）、数据类型越来越多（Variety）、访问速度要求越来越快（Velocity）、对数据价值（Value）的开掘越来越器重。物联网产生的数据通常都具备工夫序列特色，时序数据库是以后针对物联网 IoT、工业互联网 IIoT、利用性能监控 APM 场景等垂直畛域定制的数据库解决方案，本文次要剖析物联网场景海量时序数据存储与解决的关键技术挑战及解决方案。
一 时序数据存储挑战
1 典型时序利用场景
随着 5G/IoT 技术的倒退，数据呈爆炸式增长，其中物联网 (IoT) 与利用性能监控 (APM) 等是时序数据最典型的应用领域，覆盖物联网、车联网、智能家居、工业互联网、利用性能监控等常见的利用场景，海量的设施继续产生运行时指标数据，对数据的读写、存储管理都提出了很大的挑战。
2 时序数据的特色
在典型的物联网、APM 时序数据场景里，数据的产生、拜访都有比拟显著的法则，有很多独特的特色，相比以后互联网典型的利用特色有比拟大的区别。
- 数据按工夫程序产生，肯定带有工夫戳，海量的物联网设施或者被监控到应用程序，按固定的周期或特定条件触发，继续一直的产生新的时序数据。
- 数据是绝对结构化的，一个设施或利用，产生的指标个别以数值类型（绝大部分）、字符类型为主，并且在运行过程中，指标的数量绝对固定，只有模型变更、业务降级时才会新增 / 缩小 / 变更指标。
- 写多读少，极少有更新操作，无需事务能力反对，在互联网利用场景里，数据写入后，往往会被屡次拜访，比方典型的社交、电商场景都是如此；而在物联网、APM 场景，数据产生存储后，往往在须要做数据经营剖析、监控报表、问题排查时才会去读取拜访。
- 按时间段批量拜访数据，用户次要关注同一个或同一类类设施在一段时间内的拜访趋势，比方某个智能空调在过来 1 小时的平均温度，某个集群所有实例总的拜访 QPS 等，须要反对对间断的时间段数据进行罕用的计算，比方求和、计数、最大值、最小值、平均值等其余数学函数计算。
- 近期数据的拜访远高于历史数据，拜访法则显著，历史数据的价值随工夫一直升高，为节省成本，通常只须要保留最近一段时间如三个月、半年的数据，须要反对高效的数据 TTL 机制，能主动批量删除历史数据，最小化对失常写入的影响。
- 数据存储量大，冷热特色显著，因而对存储老本要求比拟高，须要有针对性的存储解决方案。
联合时序的特色，要满足大规模时序数据存储需要，至多面临如下的几个外围挑战：
- 高并发的写入吞吐：在一些大规模的利用性能监控、物联网场景，海量的设施继续产生时序数据，例如某省域电网用电测量数据，9000 万的电表设施，原来每个月采集一次，后续业务降级后 15 分钟采集一次，每秒的时序数据点数达到数百万甚至千万工夫点，须要数十到上百台机器的集群规模来撑持全量的业务写入；时序数据存储须要解决大规模集群的横向扩大，高性能安稳写入的需要。
- 高效的时序数据查问剖析：在典型的监控场景，通常须要对长周期的数据进行查问剖析，比方针对某些指标最近 1 天、3 天、7 天、1 个月的趋势剖析、报表等；而在物联网场景，有一类比拟典型的断面查问需要，例如查问某个省指定工夫所有电表的用电量量明细数据，查问某个品牌空调的某个工夫的均匀运行温度；这些查问都须要扫描大量的集群数据能力拿到后果，同时查问的后果集也可能十分大；时序数据存储须要反对多维工夫线检索、并具备流式解决、预计算等能力，能力满足大规模 APM、IoT 业务场景的典型查问需要，并且针对时序大查问要最小化对写入的影响。
- 低成本的时序数据存储：某典型的车联网场景，仅 20000 辆车每小时就产生近百 GB 的车辆指标数据，如果要保留一年的运行数据就须要 PB 级的数据存储规模；因为数据规模微小，对存储的低成本要求很高，另外时序数据的冷热特色显著。时序数据存储须要充分利用好时序数据量大、冷热拜访特色显著、做好计算、存储资源的解耦，通过低成本存储介质、压缩编码、冷热拆散、高效 TTL、Servereless 等技术将数据存储老本升高到极致。
- 简略便捷的生态协同：在物联网、工业互联网等场景，时序数据通常有进一步做经营剖析解决的需要，在很多状况下时序数据只是业务数据的一部分，须要与其余类型的数据组合来实现查问剖析；时序数据存储须要能与生态 BI 剖析工具、大数据处理、流式剖析零碎等做好对接，与周边生态造成协同来发明业务价值。
为了应答海量时序数据的存储与解决的挑战，从 2014 年开始，陆续有针对时序数据存储设计的数据库诞生，并且时序数据库的增长趋势继续当先，时序数据库联合时序数据的特色，尝试解决时序数据存储在高写入吞吐、横向扩大、低成本存储、数据批量过期、高效检索、简略拜访与时序数据计算等方面面临的挑战。
3 业界时序数据库倒退
时序数据库通过近些年的倒退，大抵经验了几个阶段：
- 第一阶段，以解决监控类业务需要为主，采纳工夫程序组织数据，不便对数据按工夫周期存储及检索，解决关系型数据库存储时序数据的局部痛点，典型的代表包含 RDDTool、Wishper（Graphite）等，这类零碎解决的数据模型比拟繁多，单机容量受限，并且通常内嵌于监控告警解决方案。
- 第二阶段，随同大数据和 Hadoop 生态的倒退，时序数据量开始迅速增长，业务对于时序数据存储解决扩展性方面提出更高的要求。基于通用可扩大的分布式存储专门构建的工夫序列数据库开始呈现，典型的代表包含 OpenTSDB（底层应用 HBase）、KairosDB（底层应用 Cassandra）等，利用底层分布式存储可扩大的劣势，在 KV 模型上构建定制的时序模型，反对海量时序的倒排检索与存储能力。这类数据库的数据存储实质依然是通用的 KV 存储，在时序数据的检索、存储压缩效率上都无奈做到极致，在时序数据的解决反对上也绝对较弱。
- 第三阶段，随着 Docker、Kubernetes、微服务、IoT 等技术的倒退，工夫序列数据成为增长最快的数据类型之一，针对时序数据高性能、低成本的存储需要日益旺盛，针对时序数据定制存储的数据库开始呈现，典型的以 InfluxDB 为代表，InfluxDB 的 TSM 存储引擎针对时序数据定制，反对海量工夫线的检索能力，同时针对时序数据进行压缩升高存储老本，并反对大量面向时序的窗口计算函数，InfluxDB 目前也是 DB Engine Rank 排名第一的时序数据库。InfluxDB 仅开源了单机版本，高可用集群版仅在企业版和云服务的版本里提供。
- 第四阶段，随着云计算的高速倒退，云上时序数据库服务逐渐诞生，阿里云早在 2017 年就推出了 TSDB 云服务，随后 Amazon、Azure 推出 Amazon TimeStream、Azure Timeseires Insight 服务，InfluxData 也逐渐往云上转型，推出 InfluxDB 云服务；时序数据库云服务能够与云上其余的基础设施造成更好的协同，云数据库已是不可逆的发展趋势。
二 Lindorm TSDB 背地的技术思考
1 Lindorm 云原生多模数据库
为了迎接 5g/IoT 时代的数据存储挑战，阿里云推出云原生多模数据库 Lindorm，致力于解决海量多类型低成本存储与解决问题，让海量数据存得起、看得见。
Lindorm 反对宽表、时序、搜寻、文件等多种模型，满足多类型数据对立存储需要，广泛应用于物联网、车联网、广告、社交、利用监控、游戏、风控等场景。其中 Lindorm TSDB 时序引擎提供高效读写性能、低成本数据存储、时序数据聚合、插值、预测等计算能力，次要利用于物联网(IoT)、工业互联网（IIoT）、利用性能监控（APM）等场景。
2 Lindorm TSDB 外围设计理念
Lindorm TSDB 做为下一代时序数据库，在架构降级过程中，咱们认为时序数据库的倒退会有如下趋势：
- 多模交融：将来时序数据库与通用 KV 数据库、关系型数据库等的配合分割会越来越严密，例如在物联网场景，设施元数据的存储、运行时数据的存储、业务类数据的存储通常会应用不同的数据模型来存储。
- 云原生：随着云计算的倒退，将来时序数据库的存储要基于云原生技术，充分利用云上的基础设施，造成相互依赖或协同，进一步构建出时序存储的竞争力。
- 时序原生：将来时序数据库的存储引擎是针对时序数据高度定制化的，保障高效的时序多维检索能力，高写入吞吐及高压缩率，反对冷热数据自动化治理。
- 分布式弹性：将来时序数据库要具备分布式扩大的能力，应答大规模的时序数据库存储，在时序的典型利用场景，例如物联网、工业电网、监控、都有海量设施数据写入和存储的需要，必须要做到弹性扩大，通过分布式、Serverless 等技术实现规模从小到大的弹性伸缩。
- 时序 SQL：将来时序数据库的拜访要反对规范 SQL（or SQL Like 表达方式），一方面应用上更加便捷，升高数据库的应用门槛，同时也能基于 SQL 提供更加弱小并有时序特色的计算能力。
- 云边一体：将来时序数据库在边缘设施端不再是孤立的数据存储，边缘侧会一直加深与云端协同，造成一体化的时序存储解决方案。
- 基于以上判断，咱们构建了云原生多模数据库 Lindorm，反对宽表、时序、搜寻、文件等多种罕用模型，解决物联网 / 互联网海量数据存储的常见需要，其中 Lindorm TSDB 采纳计算存储拆散的架构，充分利用云原生存储基础设施，定制时序存储引擎，相比业界的解决方案更具竞争力。
- 多模交融、对立存储：Lindorm TSDB 引擎与宽表、搜寻、文件等造成配合，解决用户多类型数据的对立存储解决需要。
- 云原生低成本存储，计算存储拆散：Lindorm TSDB 引擎基于云原生分布式存储平 LindormStore，提供高牢靠的数据存储，并反对弹性扩大，提供标准型、性能型、容量型等多种存储状态，满足不同场景的需要，同时反对冷热数据一体化治理的能力。
- 时序定制存储引擎：Lindorm TSDB 引擎针对时序数据的特色，定制基于 LSM Tree 构造的时序引擎，在日志写入、内存组织构造、时序数据存储构造以及 Compaction 策略上都针对时序特色优化，保障极高的写入吞吐能力。在引擎外部反对内置的预处理计算引擎，反对对时序数据进行预降采样、预聚合，来优化查问效率。
- 多维数据分片、弹性伸缩：Lindorm TSDB 引擎反对横向扩大，通过对工夫线进行 Hash 分片，将海量工夫线数据扩散到多个节点存储；在节点外部，反对按工夫维度进一步切分，反对集群的无缝扩容，同时也能解决云原生监控场景工夫线膨胀的问题；通过 Serverless 状态实现任意规模的弹性伸缩。
- 定制时序 SQL 查问：Lindorm TSDB 引擎提供时序 SQL 拜访能力，针对时序场景定制特色计算算子，用户学习、应用成本低。
- 边云同步一体化：Lindorm TSDB 引擎提供轻量级边缘部署的版本，解决边缘时序存储需要，并反对边缘侧数据与云端无缝同步，以便充分利用云上基础设施来进一步开掘数据价值。
三 Lindorm TSDB 关键技术
1 时序定制存储引擎
Lindorm 基于存储计算拆散架构设计，以适应云计算时代资源解耦和弹性伸缩的诉求，其中云原生存储分布式存储 Lindorm Store 为对立的存储底座，向上构建各个垂直专用的多模引擎，包含宽表引擎、时序引擎、搜索引擎、文件引擎。LindormStore 是面向公共云根底存储设施(如云盘、DBFS、OSS) 设计、兼容 HDFS 协定的分布式存储系统，并同时反对运行在本地盘环境，以满足局部专有云、专属大客户的需要，向多模引擎和内部计算零碎提供对立的、与环境无关的标准接口。
基于云原生分布式存储 LindomStore，Lindorm TSDB 采纳针对写入优化的 LSM Tree 构造来存储时序数据，并联合时序数据的特色，在日志写入、内存组织构造、时序数据存储构造进行时序压缩，最大化内存利用效率、磁盘存储效率；同时在 Compaction 策略上也针对数据通常有序产生的特色进行优化。通过引擎自带的 WAL 日志，Lindorm TSDB 能十分不便的反对实时的数据订阅，以及在引擎外部对数据进行针对性的降采样、聚合等预处理操作。
Lindorm TSDB 针对时序数据的查问，反对丰盛的解决算子，包含降采样、聚合、插值、过滤等。用户的查问申请通过 Parser 解析后，通常分为多个次要的解决阶段，以 Pipeline 的模式高效解决。
Index Scan：依据用户指定的查问条件，基于正排索引 + 倒排索引找出所有满足条件的工夫线 ID 汇合。
Data Scan：基于第 1 阶段找出的工夫线 ID，从 TSFile 读取对应工夫范畴的数据。
Aggregation/Filter: 针对第 2 阶段的扫描后果，对工夫线数据进一步的解决，包含在一条工夫线上对数据按肯定周期进行降采样，或对多条工夫线雷同工夫点上的数据进行聚合（sum、count、avg、min、max 等）操作等。
image.png
2 分布式弹性
Lindorm TSDB 具备横向扩大的能力，海量的工夫线数据会被扩散存储到多个 Shard 中，Shard 是集群中独立的数据管理单元，Shard 外部是一个自治治理的 LSM Tree 存储引擎（参考 2.2），蕴含独自的 WAL、TPI、TSFile 等文件。
在程度方向，工夫序列数据会依据 metric + tags 组成的工夫线标识，采纳 Hash 分片的策略，将数据分到多个节点；在垂直方向（时间轴维度），分到同一个节点的数据，可依照工夫维度进行切分，这样每个 Shard 就负责一部分工夫线在肯定工夫范畴内的数据管理。
程度方向的分片能保障集群的负载均分到各个节点，后续还会联合业务特色，反对业务自定义的分片策略，优化读写效率；垂直方向（按工夫范畴）的分片，对于收缩型工夫线场景（比方云原生监控的场景，容器频繁高低线导致大量老工夫线的沦亡，新工夫线的创立）十分有帮忙，同时在集群扩容时，也能够借助工夫分片策略来尽可能的减小对写入的影响。
3 TSQL 时序查问
Lindorm TSDB 提供 SQL 拜访能力，Lindorm TSDB 的数据模型针对物联网场景高度优化定制，概念上尽量保留开发者对数据库的广泛了解，一个实例蕴含多个数据库，一个数据库蕴含多张表，表里存储多个设施的时序数据，每个设施蕴含一组用于形容设施的 Tag、设施蕴含多个 Field 指标，新的指标数据随工夫继续一直的产生。除了反对惯例的 SQL 根底能力，Lindorm TSDB 还定制了 sample by、latest 等算子，用于不便的表白时序降采样、时序聚合、最新点查问等常见的时序操作，简化应用的同时，加强了时序 SQL 的表达能力，让用户应用时序数据库更加简略、高效。
基于 TSQL 查问接口，Lindorm TSDB 还能针对时序数据进行一系列的拓展剖析，包含时序数据预测、异样检测等，让利用能更好的施展时序数据价值。
4 Serverless
Lindorm TSDB 通过时序定制的存储引擎、联合分布式扩大的能力，能很好的满足大规模时序场景的业务需要。但对于一些业务拜访较小的利用场景起步老本绝对较高，例如在平台级的利用监控、IoT 场景，平台须要治理大量用户的时序数据，而大部分用户的数据规模初期都绝对较小，为了进一步升高用户的应用老本，适应从小到大任意规模的时序存储需要，更好的赋能下层的利用监控、物联网类 SaaS 平台服务，将来 Lindorm 将会沿着多租户 Serverless 服务模式继续演进，晋升弹性能力。
5 边云同步
随着 IoT 技术的倒退，边缘计算需要日益显著，在智能家居、工业工控、智慧园区、交通大脑等场景，思考到网络带宽老本等起因，数据通常须要先就近本地存储，并周期性的同步到云端进行进一步剖析解决。为了不便边缘侧的部署，Lindorm TSDB 反对边缘轻量级部署的版本，并反对数据全量、增量同步到云端，造成边云一体化的解决方案。
四 时序存储解决方案
1 物联网设施数据存储
Lindorm TSDB 是物联网设施运行数据存储的最佳抉择，无缝与阿里云 IoT 平台、DataHub、Flink 等进行连贯，极大的简化物联网利用开发流程。例如通过 Lindorm TSDB，你能够收集并存储智能设施的运行指标，通过自带的聚合计算引擎或 BI 类工具进行智能剖析，深刻理解设施运行状态。
2 工业边缘时序存储
Lindorm TSDB 边缘版非常适合工业互联网场景，在边缘侧轻量化输入，与工业设施就近部署，同时反对将数据同步到 Lindorm 云端。例如通过 Lindorm TSDB，你能够实时采集工业生产线设施的运行指标，对产线的运行状况进行剖析及可视化，从而优化产线运行效力。
3 利用监控数据存储
Lindorm TSDB 非常适合利用监控数据存储，无缝对接 Prometheus、Telegraf、ARMS 等监控生态，提供针对监控指标的高效读写与存储，同时提供聚合剖析、插值计算等能力。例如通过 Lindorm TSDB，你能够收集应用程序的 CPU、内存、磁盘等指标的应用状况，并进行剖析及可视化，实时监测利用运行状况。
五 总结
从互联网 & 大数据时代的分布式，到云计算、5G/IoT 时代的云原生多模，业务驱动是 Lindorm 不变的演进准则。面对资源按需弹性和数据多样化解决的新时代需要，Lindorm 以对立存储、对立查问、多模引擎的架构进行全新降级，并借助云基础设施红利，重点施展云原生弹性、多模交融解决、极致性价比、企业级稳定性的劣势能力，全力承载好经济体外部和企业客户的海量数据存储解决需要。
Lindorm TSDB 时序引擎面向物联网、工业互联网、利用性能监控等畛域的时序数据存储需要，全面拥抱云原生，并充分利用云原生基础设施，定制时序存储引擎，构建海量低成本的时序数据存储与解决能力，提供边云一体化的时序存储解决方案。将来 Lindorm 引擎将持续在弹性伸缩、低成本海量存储、多模交融、时序流计算等方向继续冲破，构建万物互联的数据底座。
原文链接
本文为阿里云原创内容，未经容许不得转载。
