Flux（原名 IFQL）与 InfluxData 的未来

作者：Paul Dix / 产品，用例，开发者，公司
2018 年 2 月 12 日

随着今天关于我们 C 轮融资的大新闻，我想花点时间谈谈 InfluxData 平台和 InfluxDB 的未来。关于我们首席执行官 Evan Kaplan 的观点，请看这里：CEO 的观点。

为了理解未来的方向，我应该简单谈谈过去五年的工作和我们在过程中学到的东西。在公司成立初期，我使用 Scala 编写了一个“时序 API”，以 Cassandra 作为后端数据存储，以 Redis 作为缓存和索引层。这个 API 的初始版本是 RESTful 的。大约六个月后，我使用 LevelDB 作为底层存储引擎，将这个 API 实现为一个单个二进制文件，但保留了相同的 RESTful API 以及一些关键的新增功能。

虽然那个原始应用程序没有存活很长时间，但我们看到了一个模式。许多组织和初创公司都在重复同样的努力，为他们的应用程序和监控需求创建一个时序 API。看到这种常见的重复努力，驱使我们一年后在 2013 年开源了这个基础设施，作为一个新的开源项目：InfluxDB。我们还利用这个新的起点，将 API 改变为使用类似于 SQL 的查询语言。它在当时的主要优势是它对开发者来说看起来很熟悉，学习曲线很容易。

平台的重要性

在早期，我们只是构建数据库，但我们看到用户正在采用这项技术，并重复解决一组常见问题的努力。鉴于我们在数据库方面的成功，我们提出了创建一个用于处理时序数据的整个平台的愿景。我们不仅帮助开发者存储和查询数据，还帮助他们收集、处理、监控和可视化数据。我们当时和现在都认为，如果我们围绕时序数据构建整个平台，我们就能让开发者更快地构建他们的解决方案（我称之为“快速构建”）。

因此，在2014年，我筹集了A轮融资，目的是聘请团队来构建平台的其余组件。首先我们构建了Telegraf（数据收集器），然后我们构建了Kapacitor（处理和监控代理），最后我们构建了Chronograf（UI和可视化引擎）。我们将其命名为TICK Stack，以纪念金融时间序列中的个体点，每个点被称为tick。但TICK Stack是这个公司随着时间的推移而构建的产物。整体愿景不是构建四个独立的应用程序，而是创建一个帮助开发者解决与时间序列数据相关问题的平台。

数据语言的重要性

InfluxDB目前提供的类似于SQL的语言也是过去10年间数据库发展演变的结果。作为开发者，我们从SQL过渡到NoSQL，再到NewSQL，现在似乎我们又回到了SQL。

然而，我认为有机会创造一些与SQL无关的新方法来处理时间序列数据。虽然SQL是一个伟大的工具，但它不是唯一的工具。时间序列数据不是集合，大部分也不是关系型。它们更频繁地以矩阵的方式被访问和处理，这可能在非SQL语言中更好地进行查询、处理和分析。因此，我们开始构建一个新的查询语言，专门用于处理时间序列数据，称为IFQL（后来更名为Flux）。作为一种函数式语言，它允许用户通过数据的一系列函数式转换来定义复杂查询。虽然我们称它为查询语言，但它迅速地变得远不止于此，允许你在语言本身中进行复杂分析。它还允许用户使用用户定义的函数重新组合查询函数的部分，从而创建常见功能的快捷方式。用户将能够围绕他们的问题领域构建Flux。有关Flux的更多详细信息，请查看我今天在InfluxDays NYC的演讲幻灯片。

我们还希望创建一种语言，使UI开发者更容易创建有趣的构建器和可视化工具。我们预计大多数用户一开始甚至不需要与查询语言打交道，而是使用Chronograf、Grafana或其他用户界面来与其数据交互。我们不会在Chronograf内部发布查询构建器之前锁定Flux语言设计。这将是为了验证语言是否容易让UI设计师使用。

基于API的平台

我们将统一整个堆栈背后的通用API。它将通过gRPC、REST以及可能的GraphQL向开发者公开单个入口点。它将从第一天开始设计为多租户，包括组织、用户、API令牌和访问规则。它将使用户能够不仅写入和查询数据，还可以定义收集、监控和警报、后台处理、与系列相关的元数据和用户数据（如仪表板和注释）的规则。

用于处理数据的堆栈语言将是Flux，而API将统一其余堆栈。其中一些我们已经开始以开源的形式发布（如Flux）。其他部分将在今年内构建并开源。

InfluxData的未来不仅是一个时间序列数据库。我们正在创建一个处理时间序列数据的平台。我们的目标是使开发者围绕指标和事件创建应用程序时更加高效。无论你是可视化数据、收集和抓取、监控和警报，还是转换为发送到其他来源，我的目标是InfluxData能够提供一切即开即用。请期待我们将在实现这一目标方面进行大量投资，并将继续向社区贡献优秀的开源软件。