最近掉进了“时序”的黑洞，不能自拔。
先是从监控层面学了Prometheus和Grafana，后来又转战到时序数据库学了InfluxDB，持续的输入让我在“时序”这事上精进了不少。
回首过往，相比之前写《物联网，时序数据猛于虎》时的自己，今非昔比。
把每次学的点串起来，慢慢的就能融会贯通，今天就从“小众点”的InfluxDB开始，带你走个时序中台的秀。
InfluxDB，让我重识时序数据库
写作时，回顾了自己的公众号文章，同样有关时序，看到的东西完全不同，有种盲人摸象的感觉。
InfluxDB是一个开源、高性能的时序数据库，专注于DevOps和IOT等场景。
下图是从DB-engines网站上截取的最新关于时序数据库的排名。可以看到，InfluxDB以绝对的优势在时序数据库细分领域中排名第一。
网站链接：https://db-engines.com/en/ranking/time+series+dbms
即使是某个细分领域，同样博大精深，面对时序数据库的前十名，我知道的还不到一半。庆幸，我这只井底之蛙还知道跳到井口边，看看外面的世界。
InfluxDB的重要概念
物联网和大数据让时序成了一个真实场景，针对时序数据多并发、快速写入和写多读少的特点，需要一个支持数据持久化、多维实时聚合计算和查询分析，同时支持高效压缩的低成本专业时序平台。
而InfluxDB就是目前最为流行的高性能开源时序数据库，由Go语言开发，没有环境依赖，而且部署简单。
InfluxDB v1.x版本使用类似SQL的InfluxQL查询语言接口，学习成本较低，涉及几个重要概念：
Measurement：相当于数据库中的表，一个时序数据库通常由多个Measurement组成。 Point：相当于数据表的一条记录，一个Measurement由大量Point组成。 Tag：相当于数据表的索引字段，每个Tag都是Key-Value的形式，这些字段放在一起就是TagSet。 Field：和Tag的概念类似，Field是具体指标的时序数据，也是Key-Value形式，多个Field在一起就是FieldSet。
Point=Timestamp+TagSet+FieldSet。
InfluxDB的关键特性
通常，大型时序数据库会接入海量数据写入请求，导致数据增长迅速，数据量大了，读写压力就会变大，同时存储的成本也会变高。
为解决上述问题，InfluxDB提供了两个Feature，一个是连续查询（CQ），另一个是保留策略（RP）。
连续查询（Continuous Query）
时序数据频度高，但很多细节数据随着时间的流逝变得没有价值。
连续查询功能，周期自动执行定制的条件查询，并将查询结果写入另一张数据表，通过降低时序数据的时间精度，减少存储数据的量，提升查询效率。
同时，也可以实现复杂查询的预处理，降低查询的复杂度，实现传统SQL的Having和函数嵌套等功能。
保留策略（Rentention Policy）
时序数据猛于虎，如果所有时序数据都长期保存，存储成本会非常高，除了数据压缩外，定期清除历史数据也是节约存储成本的重要手段。
InfluxDB会在创建数据库的时候自动生成一个autogen的默认数据保留策略，也允许定制数据保留策略，对过期数据进行删除。
总之，连续查询和保留策略的结合，可以降本增效。
其实，时序数据的设计都跟传统的数据仓库很相似，Tag类似维度，Field相当于实体属性，连续查询这种降低数据时间精度的方式，更是传统数仓的惯用伎俩，也颇有点物化视图的味道。
InfluxDB与其他数据库的对比
圈内有个MongoDB的朋友，看到我之前写的时序数据库的文章说，我们MongoDB也支持时序。
跟我之前的观点一样，每个数据库都有时间类型的字段，都可以存储时间数据，但不是每个数据库都可以叫时序数据库。
时序数据写多读少，除了写入吞吐量和查询效率外，存储的压缩效率也是重要考虑因素，而InfluxDB在这些方面，相对于和MongoDB和ElasticSearch等其他数据库拥有明显的技术优势。
而OpenTSDB，属于分布式时序数据库，需要依托Hadoop生态的HBase，并不是一个独立的存在，此时InfluxDB的原生存储就是其优势。
这跟ClickHouse的特性有点类似，独立于Hadoop而存在。
另外，排名没有进入前十的DolphinDB，也是一个分布式时序数据库，听说在证券行业的量化交易等场景中有不少创新应用。
不过当下信创正盛，有些事还看不清，但不管怎样，我觉得见识过什么是好的，这一点很重要。
目前，能与InfluxDB有可比性的，也就是Prometheus了。
TICK，不断演化的时序中台
说到日志分析，一定绕不开Splunk，后来开源圈有了ELK Stack（ElasticSearch，Logstash，Kibana），原本以为三剑客的ELK已经很复杂了，没想到时序圈竟然搞出了TICK这个四件套。
TICK，是InfluxData公司开源的一组时序产品套装的首字母组合。
这个基于InfluxDB 1.x的TICK时序中台，主要由四个技术栈组成：
Telegraf：通过灵活可配置的插件形式，采集和上报被监控IT资源的指标数据，类似Prometheus的Exporter。 InfluxDB：用于时序数据的存储和分析，并根据数据保留策略进行数据管理，提升存储效率，对应Prometheus。 Chronograf：用于数据的可视化配置和展现，类似Grafana。 Kapacitor：一个支持批流一体的数据处理引擎，集成了Prometheus的文件发现和报警功能，算是一个胖AlertManager。
不由想起了大数据的四字真经，“采、存、析、用”。
InfluxDB V2的新体验
书本上的InfluxDB大都还停留在v1.0版本，我动手实践时才发现已经是v2.0时代，或许是时代的脚本越来越快，又或许是我介入的时间点恰巧赶上了巨变，才让我有了如此感受。
InfluxDB OSS 2.0: open source platform solution in a single binary。这是官网对新版本的描述。
我的直观感受是Chronograf和Kapacitor被集成到InfluxDB v2中，另外，概念和体系也有不少变化，原来的InfluxQL变成了基于脚本的InfluxJS，数据库换成了Bucket，此外，还增加了Authentication Token的概念。
TICK时序中台四件套也精简成了IT二人转（InfluxDB+Telegraf），跟Prometheus+Grafana的组合大同小异。
InfluxDB与Prometheus的对比
从我了解的情况看，国内很多搞监控的都在玩Prometheus和Grafana，但我感觉传统企业对于Prometheus的使用大多还处于初级阶段。
监控本身还是业务支撑的工具，离数字化运营还有距离。另外，对于监控的可用性和连续性重视程度也不高。
随着Prometheus做大做强，联邦和分布式等问题就会浮出水面，数据时效性、持久化和存储可扩展性也会面临挑战。
好在Prometheus支持远程存储功能。现在看，比较好的解决方案是对Prometheus进行存储优化改造，将时序数据存到外部的InfluxDB中，既解决了长期持久化，也实现了Prometheus高可用。
所以，在监控侧优化方案变成了Prometheus+Granfana+InfluxDB的组合。
不过，天下没有免费的午餐，InfluxDB虽然开源，但只针对单机版，处理能力和高可用都受到限制，而付费的企业版才提供集群功能。
因此，不少互联网企业的时序系统都是针对InfluxDB做了二次开发，或者干脆自己另起炉灶。
而InfluxDB+Telegraf的组合，最大的问题在于自身的限制，只单一支持InfluxDB数据源。反观Grafana，生态更开放，除了支持Prometheus，也支持InfluxDB等其他数据源。
软件系统，只有当数量积累到一定规模的时候，才能真正看到技术上的差别。
换句话，如果没有数量和显著的压力，可选择的范围非常大，但是数据量越大，对技术要求越高，这时才能感受到什么才叫“高端制造”。
通过对InfluxDB v2的测试，感觉整合后的InfluxDB更简单，跟Prometheus和Grafana的组合在功能和界面上更为接近。
新的Telegraf和Exporter在数据采集端，我认为差别不大，毕竟监控对象都是标准化的组件，社区也提供了大量的知识库，复用性都很强。
持续的间歇性精进
一直以来，我都在不同的技术领域里切换，我把这些归结于甲方的缘故，搞得博而不精，不过也有优势，面对乙方，以一当十。
感觉自己也像CPU一样，在某个时间段专注于某个具体事情。不过，这次我没有停留在概念上，而是深入到设计和实施阶段做了实操，获得了不少微观体感，权当自娱自乐吧。
都说兴趣是最好的老师，我觉得，好奇心同样是最好的精进动力。
就好像这种持续的间歇性精进，也是一种时序。
眼界有限，潭主只能搞个小调查看看外面的世界，请大家多支持！
- END -
---全文完，感谢阅读。如果觉得写得还不错，就请点个赞或“在看”吧。
公众号所有文章仅代表个人观点，与供职单位无关。
