时序数据库 InfluxDB 2.0 alpha 发布：主推新的 Flux 查询语言，TICK 栈将成为整体

InfluxDB 2.0 的第一个 alpha 版本正式发布。2.0 版本的愿景是将 TICK 整合成一个整体，将时序数据库、UI、仪表盘工具以及后台处理和监控代理置于一组 API 后面。从 1.x 到 2.0 产品线代表了自 2013 年以来 InfluxDB 产品的最大一次转变。这篇文章将介绍 InfluxDB 和 Flux 的 2.x 版本系列将要实现的目标、它们的构建方式，以及 2.0 版本 alpha、beta 和最终版的开发过程。

Flux，一门新语言

Flux 是 InfluxDB 2.0 的一个重要组成部分，也就是我们的新数据脚本和查询语言。在总结了多年以来的用户功能请求、社区问题、当前的查询语言 InfluxQL 和 TICKscript 之后，我们决定构建一门新语言。Flux 的设计目标是：

支持驱动图形用户体验的语言服务，让用户无需学习新语言即可完成更多任务。Flux 应该比使用其他语言更容易做到这一点。

集成不同的数据源。这些数据源可能是其他数据库、第三方 API、文件系统或任何存在数据的地方。与其他系统集成是这门语言的核心功能。

交叉编译。现在我们可以在时序数据库中使用多种语言，如 InfluxQL、PromQL、Flux，等等。我们希望可以使用单个优化器，能够针对多个不同数据源制定计划。

除了支持多种查询语法外，Flux 还必须能够与其他分析工具和环境无缝集成，包括 Jupyter，以及使用 Apache Arrow 作为底层数据交换格式，以便与其他大数据分析系统集成。

Flux 是第四代编程语言，专为数据脚本、ETL、监控和警报而设计。它的作用超越了一门查询语言和编程语言。它提供了一个规划器和优化器，无缝地结合了查询和编程，形成了一个统一的整体。

实现这些设计目标最终将得到图灵完备的 Flux，不仅可以用于查询和处理时间序列数据，还可以用于处理一般的数据。在接下来的几个月，我们将详细介绍如何创建这些连接器，并将它们与查询规划器和优化器结合在一起，从而让 Flux 查询可以使用各个数据存储系统的独特功能。

在这个版本中，我们把重点放在 InfluxDB 2.0 嵌入式数据存储的查询能力上。像跨度量数学操作、top N、time shift、group by 和按值排序这样的请求功能都有可能在这个初始 alpha 版本中实现。创建一门新的语言和一个新的查询引擎是一项艰巨而又重要的任务，不过我们的努力已经开始为我们带来回报。例如，可以看一下count是如何实现的。Flux 代码库的一个主要设计目标是让外部贡献者能够很容易地添加新函数，就像 Telegraf 中的输入函数那样。

我们将 Flux 作为一个独立于 InfluxDB 的代码库，因为它将拥有自己的开源生命周期，无论你是否使用 InfluxDB，它都是有用的。为此，我们采用了 MIT 许可，并接受将 Flux 与第三方系统进行集成的拉取请求，即使这些系统可能是 InfluxDB 的竞争对手。这也反映了我们在 Telegraf 上的一贯理念。Telegraf 不仅被 InfluxDB 用户广泛使用，还被微软、DataDog、SignalFX、Wavefront 等很多其他公司的客户广泛使用。

我们接受可能引来竞争的连接器的原因非常简单：我们意识到，Telegraf 的价值源于那些输入插件，如果用户可以将这些插件作为他们的数据收集器，那么将吸引更大的社区来贡献插件，这对于 InfluxDB 用户来说也是有利的。在过去的三年半，Telegraf 的 200 多个插件主要由社区（包括竞争对手）提供，而且社区的贡献和使用量超过了 InfluxDB 本身。

TICK 成为一个整体

TICK 就是我们所说的构成 InfluxData 平台的组件集，代表了我们用于解决时序数据库问题的四个组件：Telegraf（我们的数据收集器）、InfluxDB（我们的时序数据库）、Chronograf（我们的可视化 UI）和 Kapacitor（我们的处理和监控服务）。这些组件的当前版本是公司随时间推移而逐步推出的工件。

2014 年，我们萌生了构建 TICK 组件的想法，当时正在为 Influx 进行 A 轮融资。我们的想法非常简单：时序是一种基础级的抽象概念，可用于解决很多问题，而我们正在构建一个处理时序数据的平台。换句话说：很多数据问题实际上是时序数据问题，我们将帮助人们解决这些问题。我们有一个原型数据库，需要聘请开发人员和设计人员来完成这项工作并构建其他三个组件。在 2015 年和 2016 年期间，我们开始组建团队开发这些组件，包括 2015 年 6 月的 Telegraf 初始版本、2015 年 11 月的 Kapacitor、2016 年 9 月的 InfluxDB 1.0，以及 2016 年 11 月重新启动的 Chronograf。

在那段时间里，我们了解到更多有关人们如何使用这个平台的信息以及他们经常遇到的问题类型。有大量关于 InfluxQL 的功能请求，但我们却没办法找到一种优雅的方式来添加这门新语言。

目前，大约有 13%的 InfluxDB 用户在使用 Kapacitor。我们经常听到用户抱怨 TICKscript 难学，也很难调试，但对于那些经历了这段旅程的用户来说，他们认为它是一个杀手级的应用程序。在 InfluxDB 的早期阶段，我们将 UI 作为数据库的一部分。将所有 UI 放入 Chronograf 的做法在当时是有争议的，现在我们意识到，如果我们只是将 UI 作为数据库的一部分，那么用户体验可能会更好。

以上这些因素导致了 Flux 的诞生。Flux 是一门新语言，解决了我们无法在 InfluxQL 中解决的功能性问题。作为一门语言，Flux 看起来比 TICKscript 更熟悉。将 Flux 作为交互式查询和后台处理语言将使开发工具变得更加容易，能够帮助用户进行调试，并查看监控、警报和 ETL 任务中都发生了什么。

另一个重要的推动因素是我们希望创建一个统一的平台 API，旨在让 InfluxDB 成为一个多租户的时序数据服务。因为有了这些组件，InfluxDB 实际上不仅仅是一个数据库，它是一个监控系统、一个仪表盘引擎、一个分析服务，还是一个事件和指标处理器。随着 Flux 的功能不断扩展，InfluxDB 的功能和应用范围也将进一步扩展。

Telegraf 继续在 InfluxDB 之外拥有自己的生命周期，同时我们将在 InfluxDB 2.0 中添加 API，用于集成 Telegraf。alpha 版本提供了一个示例，可以通过用户界面创建 Telegraf 配置，直接从 InfluxDB 中获取数据。

集中的推送和拉取

InfluxDB 2.0 的另一个重要部分是支持 Prometheus 格式。InfluxDB 2.0 可以充当指标刮板，在初始入门体验中，可以选择设置本地 InfluxDB 服务器指标。InfluxDB 2.0 提供了开箱即用的推送和拉取模型，最后我们还将支持开箱即用的 PromQL 查询。

未来的工作

我们希望为社区用户提供早期版本，用于收集用户反馈。在我们准备进入 beta 阶段之前，仍然缺少一些需要完成的核心功能。我们仍然需要提升兼容性（通过 InfluxQL 和 1.x API 查询 InfluxDB 2.0），并且能够写入 InfluxDB 2.0，就好像它是 1.x 服务器一样。我们还需要添加备份和还原、批量数据导入和导出以及数据删除功能。

这些特性大多是较低级别的 API 工作。在我们完成这些工作之后，UI 团队将能够基于用户反馈进行快速迭代，并能够添加更多以 2.0 API 为基础的面向用户的特性。

我们计划从 2 月的第一周开始减少每周的 alpha 版本构建。在得到最小的特性集后，我们将进入 beta 阶段。在 beta 测试期间，我们将进行额外的 bug 修复、性能测试和其他准备活动。alpha 构建的目的不是测试性能，而是收集有关 UI 和 API 的反馈。

整个 InfluxDB 2.0 API 都是基于这个Swagger文件记录和实现的。在项目进入 beta 阶段后，API 应该是稳定的，只会有一些附加的变化。我们仍然需要将 TICKscript 的所有功能添加到 Flux 中，可以在监控和警告工作负载中使用 Tasks。我们还必须创建一个 TICKscript 到 Flux 的转换器，帮助 Kapacitor 用户迁移到 InfluxDB 2.0。

这只是一个早期版本，我们计划在 InfluxDB 2.x 系列版本中做更多的工作。我们还将构建我们的新 InfluxData 云产品——InfluxDB 2.x API 的全托管版本。

InfuxDB 2.0 上手指南：https://v2.docs.influxdata.com/v2.0/get-started/

英文原文：https://www.influxdata.com/blog/influxdb-2-0-alpha-release-and-the-road-ahead/