用於區塊鏈的現代開源數據棧

1.現代區塊鏈數據棧的挑戰

現代區塊鏈索引初創公司可能面臨多項挑戰，包括：

• 海量數據。 隨著區塊鏈上數據量的增加，數據索引將需要擴展以處理增加的負載並提供對數據的高效訪問。 因此，它會導致更高的存儲成本、緩慢的指標計算以及增加數據庫服務器的負載。
• 複雜的數據處理管道。 區塊鏈技術複雜，構建全面可靠的數據索引需要對底層數據結構和算法有深刻理解。 區塊鏈實現的多樣性繼承了它。 舉個具體的例子，以太坊中的 NFT 通常是在遵循 ERC721 和 ERC1155 格式的智能合約中創建的。 相比之下，例如，Polkadot 上的實現通常直接在區塊鏈運行時內構建。 那些應該被視為 NFT，並且應該被保存為那些。
• 整合能力。 為了向用戶提供最大價值，區塊鏈索引解決方案可能需要將其數據索引與其他系統集成，例如分析平台或 API。 這是具有挑戰性的，需要在架構設計中投入大量精力。

隨著區塊鏈技術的普及，存儲在區塊鏈上的數據量也在增加。 這是因為越來越多的人在使用該技術，並且每筆交易都會向區塊鏈添加新數據。 此外，區塊鏈技術已經從簡單的匯款應用程序（例如涉及使用比特幣的應用程序）發展到涉及在智能合約中實施業務邏輯的更複雜的應用程序。 這些智能合約可以生成大量數據，導致區塊鏈的複雜性和規模增加。 隨著時間的推移，這導致了更大、更複雜的區塊鏈。

在本文中，我們以 Footprint Analytics 技術架構的階段性演變為案例，探討 Iceberg-Trino 技術棧如何應對鏈上數據的挑戰。

Footprint Analytics 已將大約 22 個公共區塊鏈數據、17 個 NFT 市場、1900 個 GameFi 項目和超過 100,000 個 NFT 集合編入語義抽像數據層。 它是世界上最全面的區塊鏈數據倉庫解決方案。

拋開區塊鏈數據不談，其中包括超過 20 億行的金融交易記錄，數據分析師經常查詢這些記錄。 它不同於傳統數據倉庫中的入口日誌。

我們在過去幾個月經歷了 3 次重大升級，以滿足不斷增長的業務需求：

2.架構1.0 Bigquery

在足跡分析開始時，我們使用 谷歌大查詢 作為我們的存儲和查詢引擎； Bigquery 是一個很棒的產品。 它速度極快，易於使用，並提供動態算術能力和靈活的 UDF 語法，可幫助我們快速完成工作。

然而，Bigquery 也有幾個問題。

• 數據未壓縮，導致成本高，尤其是在存儲 Footprint Analytics 超過 22 個區塊鏈的原始數據時。
• 並發不足：Bigquery僅支持100個並發查詢，不適合Footprint Analytics服務很多分析師和用戶的高並發場景。
• 鎖定 Google Bigquery，它是一個閉源產品。

所以我們決定探索其他替代架構。

3.架構2.0 OLAP

我們對一些非常流行的 OLAP 產品非常感興趣。 OLAP 最吸引人的優勢是它的查詢響應時間，通常需要亞秒級才能返回海量數據的查詢結果，並且它還可以支持數千個並發查詢。

我們選擇了最好的 OLAP 數據庫之一， 多麗絲, 試一試。 該引擎性能良好。 然而，在某些時候我們很快遇到了一些其他問題：

• 尚不支持 Array 或 JSON 等數據類型（2022 年 XNUMX 月）。 數組是一些區塊鏈中常見的數據類型。 例如， 話題領域 在 evm 日誌中。 無法在 Array 上計算直接影響我們計算許多業務指標的能力。
• 對 DBT 和合併語句的支持有限。 這些是數據工程師對 ETL/ELT 場景的常見要求，我們需要更新一些新索引的數據。

話雖這麼說，但我們不能將 Doris 用於生產上的整個數據流水線，因此我們嘗試使用 Doris 作為 OLAP 數據庫來解決我們在數據生產流水線中的部分問題，充當查詢引擎並提供快速和高度並發查詢能力。

不幸的是，我們無法用 Doris 替換 Bigquery，因此我們不得不使用 Bigquery 作為查詢引擎定期將數據從 Bigquery 同步到 Doris。 這個同步過程有幾個問題，其中之一是當 OLAP 引擎忙於為前端客戶端提供查詢服務時，更新寫入很快堆積起來。 隨後，寫入過程的速度受到影響，同步時間變長，有時甚至無法完成。

我們意識到 OLAP 可以解決我們面臨的幾個問題，不能成為 Footprint Analytics 的交鑰匙解決方案，尤其是對於數據處理管道。 我們的問題更大更複雜，我們可以說 OLAP 僅作為查詢引擎對我們來說是不夠的。

4. Architecture 3.0 Iceberg + Trino

歡迎使用 Footprint Analytics 架構 3.0，這是對底層架構的徹底改造。 我們從頭開始重新設計了整個架構，將數據的存儲、計算和查詢分為三個不同的部分。 從 Footprint Analytics 的兩個早期架構中汲取教訓，並藉鑑其他成功的大數據項目（如 Uber、Netflix 和 Databricks）的經驗。

4.1. 數據湖介紹

我們首先將注意力轉向數據湖，這是一種用於結構化和非結構化數據的新型數據存儲。 數據湖非常適合鏈上數據存儲，因為鏈上數據的格式範圍廣泛，從非結構化原始數據到結構化抽像數據，足跡分析是眾所周知的。 我們期望使用數據湖來解決數據存儲的問題，理想情況下它也支持主流的計算引擎，如Spark和Flink，這樣隨著Footprint Analytics的發展，與不同類型的處理引擎集成並不困難.

Iceberg 與 Spark、Flink、Trino 等計算引擎集成得很好，我們可以為每個指標選擇最合適的計算。 例如：

• 對於那些需要復雜計算邏輯的人，Spark 將是不二之選。
• Flink 用於實時計算。
• 對於可以使用 SQL 執行的簡單 ETL 任務，我們使用 Trino。

4.2. 查詢引擎

隨著 Iceberg 解決了存儲和計算問題，我們不得不考慮選擇查詢引擎。 可用的選項不多。 我們考慮的替代方案是

在深入研究之前，我們考慮的最重要的事情是未來的查詢引擎必須與我們當前的架構兼容。

• 支持 Bigquery 作為數據源
• 支持 DBT，我們依賴它來生成許多指標
• 支持BI工具元數據庫

基於以上，我們選擇了 Trino，它對 Iceberg 的支持非常好，團隊反應非常迅速，我們提出了一個錯誤，第二天就修復了，並在下週發佈到最新版本。 對於 Footprint 團隊來說，這是最佳選擇，他們也需要高實施響應能力。

4.3. 性能測試

一旦我們確定了方向，我們就對 Trino + Iceberg 組合進行了性能測試，看它是否能滿足我們的需求，令我們驚訝的是，查詢速度非常快。

知道 Presto + Hive 多年來一直是所有 OLAP 炒作中最差的比較器，Trino + Iceberg 的組合完全讓我們大吃一驚。

這是我們的測試結果。

案例 1：加入大型數據集

一個800GB的table1加入另一個50GB的table2做複雜的業務計算

case2：使用一個大的單表做一個不同的查詢

測試sql: select distinct(address) from the table group by day

Trino+Iceberg 組合比同配置的 Doris 快 3 倍左右。

此外，還有一個驚喜是Iceberg可以使用Parquet、ORC等數據格式，將數據進行壓縮存儲。 Iceberg的表存儲佔用空間僅為其他數倉的1/5左右三庫中同一張表的存儲大小如下：

注：以上測試均為我們在實際生產中遇到的例子，僅供參考。

4.4. 升級效果

性能測試報告給了我們足夠的性能，我們的團隊花了大約 2 個月的時間才完成遷移，這是升級後的架構圖。

• 多個計算機引擎滿足我們的各種需求。
• Trino支持DBT，可以直接查詢Iceberg，不再需要處理數據同步問題。
• Trino + Iceberg 的驚人性能使我們能夠向用戶開放所有 Bronze 數據（原始數據）。

5。 總結

自 2021 年 XNUMX 月推出以來，Footprint Analytics 團隊在不到一年半的時間內完成了三項架構升級，這要歸功於其將最好的數據庫技術的好處帶給加密用戶的強烈願望和決心，以及在實施和實施方面的紮實執行。升級其底層基礎設施和架構。

Footprint Analytics架構升級3.0為用戶帶來了全新的體驗，讓不同背景的用戶獲得更多樣化的使用和應用洞察：

• Footprint 使用 Metabase BI 工具構建，可幫助分析師訪問已解碼的鏈上數據，完全自由地選擇工具（無代碼或硬編碼）進行探索，查詢整個歷史記錄並交叉檢查數據集，以深入了解沒時間。
• 整合鏈上和鏈下數據，跨 web2 + web3 進行分析；
• 通過在 Footprint 的業務抽象之上構建/查詢指標，分析師或開發人員可以節省 80% 的重複數據處理工作的時間，並專注於基於其業務的有意義的指標、研究和產品解決方案。
• 從 Footprint Web 到 REST API 調用的無縫體驗，全部基於 SQL
• 針對關鍵信號的實時警報和可操作通知，以支持投資決策