InfluxDB 2 Alpha 14 版本中引入多数据源 Flux

作者：Nate Isley / 产品, 开发者
2019 年 7 月 18 日

导航至

正如我们的联合创始人 Paul 在 InfluxDB 2.0 Alpha 版本发布公告 中广泛撰写的那样，我们认为 Flux 将在将时间序列数据与许多不同的数据源结合方面发挥重要作用。 Flux 的第一个官方多数据存储步骤是 InfluxDB 2.0 Alpha 14 的 from SQL 发布。鉴于数据存储的数量不断增加以及满足这些数据存储的需求，Flux 的这一新增功能意义重大。

这是一个多数据存储的世界

多年前，当我还是 Wily Technology 的顾问时，在 APM 行业新兴爆发期间，我处理了数百个处于不同困境状态的应用程序。我一次又一次地看到应用程序忽略其特定数据的性质，这总是导致数据存储的减速和错误，因为这些数据存储以它们根本不适合的方式被滥用。

随着不同应用程序数据集的扩展，它们被赋予了使其适合特定数据存储处理程序的特征。使用专门为每个数据集构建的工具和存储机制来处理、存储和处理每个数据集，可以构建维护良好且可随增长扩展的系统。

以下是一些不同数据集和为其构建的数据存储类型的示例

  • 关系数据（如电子商务商店的库存、客户订单和客户数据及其关系）最好由 RDBMS 系统处理，该系统旨在对该关系进行建模。
  • 与物联网设备相关的资产信息在专用数据存储（如 IBM 的 Maximo 和 SAP 的 Intelligent Asset Management）中取得了巨大成功。资产元数据可通过这些应用程序公开的集成 API 获得。
  • 依赖关系数据（如业务流程、集成应用程序和底层网络拓扑）最好由 图形数据库 处理
  • 时间序列数据（如来自堆栈、传感器和系统的数百万个流式数据点）最好由时间序列数据库处理。

在遥远的过去，有些人认为使用不同的数据存储会给程序员带来太大的压力，让他们学习不同的数据工具。在今天广泛而统一的 API 使用之前，这可能是真的。但如今，开发人员非常习惯使用数据源驱动程序和 API 从不同的地方提取数据并将它们组合在一起。

依靠开发人员来塑造和处理数据对于解决特定问题的专用自定义软件来说效果很好。但是，开发人员永远不够用，通用数据分析和可视化工具已经证明了它们对许多分析师和数据科学家的价值。单数据源分析工具有时有效，但分析师通常希望合并来自不同数据存储的数据，并且经常发现将数据源拉到一起是一项艰巨的任务。

提供一种工具来灵活地合并数据源并跨时间分析它们是 Flux 的主要用例之一。开源 Flux 旨在为每个查询和可视化工具赋能，以便它们可以使用通用、强大且统一的语言将相关数据集汇集在一起以生成见解。

将时间序列数据与来自 SQL 数据存储的数据一起使用

Flux 的第一个可以从非 InfluxDB 数据存储中提取数据的函数实现是 InfluxDB 2.0 Alpha 14 的 SQL.from() 函数。让我们深入研究一个特定的物联网用例来探索此函数。

物联网资产数据存储

最近，我与在物联网用例中使用 InfluxDB 的客户进行了几次 InfluxDB 深入探讨。这些物联网从业者拥有数以万计的设备和传感器，将他们捕获的所有数据流式传输到 InfluxDB 中，而处理所有这些数据带来了一些独特的挑战。

在没有连接不同数据存储的方法的情况下，许多物联网从业者重用所有元数据作为时间序列指标上的标签，以便他们可以进行基于元数据的时间序列分析，例如

“每种设备类型的过去一天报告的错误率是多少？”

当然，在 SQL.from() 之前，InfluxDB 回答该问题的唯一方法是将设备类型作为标签添加到来自其传感器的每个时间序列指标。

这可以正常工作，但在对元数据集随时间的变化做出反应时存在问题。例如，如果物联网设备制造商最初使用特定的安全分类标记时间序列指标，但分类发生变化，则只有新数据会在使用新分类进行查询时显示出来，因为旧数据在标签中具有旧值。

更好的解决方案是通过将元数据保存在关系存储中，并将时间序列数据保存在 InfluxDB 中，从而实现数据的清晰分离。使两个数据存储解决方案工作的关键是 Flux 语言，它可以无缝查询时间序列数据和关系数据。

鱼缸健康服务供应商

为了充实一个示例，让我们假设有一个供应商提供自动监控和调整客户鱼缸水质健康的服务。该供应商租赁了数千个物联网设备，这些设备 监控鱼缸水的许多方面 并将其数据流式传输到 InfluxDB。在此示例中，供应商没有使用所有元数据标记流式指标，而是仅使用数据来源的唯一设备 ID 标记每个指标。该 ID 将设备的指标与传感器元数据联系起来，传感器元数据可能包括设备类型、购买者的客户 ID、安装街道城市和州、设备修订号、设备名称等信息。我们的鱼缸供应商已在 MySQL 数据库中实施了自制资产跟踪器，以跟踪所有这些关系信息。该供应商的许多客户都是拥有数十个鱼缸的大型企业客户。每当客户致电时，他们的客户成功代表非常重要地了解客户鱼缸在过去一小时内的 pH 值平衡以及它们的位置。以下是一个 Flux 脚本示例，可能用于查找一位客户的鱼缸 pH 值平衡
import "sql"

phBalances = from(bucket: "PH_Balances")
  |> range(start: now-60)
  |> filter(fn: (r) => r._measurement == "water_sensor" )

deviceIds = sql.from(driverName: "mysql", dataSourceName: "username:password@tcp(host)/dbname", query: "SELECT customer_name, customer_location, device_id AS device FROM DeviceTable WHERE customer_name = 'InfluxData'")

join(tables: {t1: phBalances, t2: deviceIds}, on: ["device"])
	|> aggregateWindow(every: v.windowPeriod, fn: mean)
 	 |> yield(name: "mean")
此脚本的结果是一个可能如下所示的表格： 绿色数据来自 MySQL，橙色数据来自 InfluxDB，蓝色数据是两个数据存储中连接的数据。从这个简单的例子中需要注意几件事：首先，这是一个非常幼稚的例子，因为构建 phBalances 表的第一个查询从 InfluxDB 中提取了整个数据集。当两个数据表连接在设备 ID 上时，存在数据的隐式丢弃。但是，在连接完成之前，整个数据集都在查询内存中，并且很容易想象数千万个数据点会压倒所有可用内存。其次，没有特别需要按原样连接。我们真正想要做的是将 pH 值平衡数据集过滤到我感兴趣的指标子集。Flux 团队正在进行几项简化此类查询的计划，以便我可以直接在过滤器中使用 SQL 结果。最后，示例 Flux 脚本都是低级 SQL 和 Flux。它要求用户拼凑他们自己对数据存储的相当完整的先验知识。Flux 的长期计划是提供库和工具，以减轻低级知识先决条件，并提供更平易近人的体验；例如，ORM 工具或数据存储可视化，以帮助用户识别、合并和塑造他们的数据和分析。

多数据存储的未来之路

随着 SQL.from() 的首次亮相，Flux 已经进入了一个激动人心的新篇章，成为一种以时间序列为中心的多数据存储编程语言。此初始 SQL 版本支持从 MySQL 和 Postgres 中提取数据，但我们有很多数据存储希望从中提取数据和写入数据。Flux 团队雷达上的可能连接器列表很长且动态。列表中的首要位置是 SQLite、MS SQL Server、我们的 开源 Google Cloud Compute 合作伙伴 的连接器，当然还有 Google 的数据源（如 BigQuery）。但我们希望听到您的声音 — 您希望 Flux 连接到哪些顶级数据源？前往 Flux 社区论坛 并告诉我们！