時序資料庫 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/