Iceberg-Trino 如何解決鏈上數據面臨的挑战

 1.鏈上數據處理面臨的挑战

區塊鏈數據公司，在索引以及處理鏈上數據時，可能會面臨一些挑战，包括：

• 海量數據。隨着區塊鏈上數據量的增加，數據索引將需要擴大規模以處理增加的負載並提供對數據的有效訪問。因此，它導致了更高的存儲成本；緩慢的指標計算和增加數據庫服務器的負載。

• 復雜的數據生產流程。區塊鏈技術是復雜的，建立一個全面和可靠的數據索引需要對底層數據結構和算法有深刻的理解。這是由區塊鏈實現方式的多樣性所決定的。舉一個具體的例子，以太坊中的 NFT 通常是在遵循 ERC721 和 ERC1155 格式的智能合約中進行創建的，而像Polkadot 上通常是直接在區塊鏈運行時間內構建的。對於用戶來說，不管是任何形式的存在，這些數據應該被視為 NFT 的交易，需要被存儲，並且處理為可讀狀態，方便分析以及進行計算。

• 集成能力。為了給用戶提供最大的價值，區塊鏈索引解決方案可能需要將其數據索引與其他系統集成，如分析平臺或 API。這很有挑战性，需要在架構設計上投入大量精力。

隨着區塊鏈技術的使用越來越廣泛，存儲在區塊鏈上的數據量也在增加。這是因為更多的人在使用該技術，而每筆交易都會給區塊鏈增加新的數據。此外，區塊鏈技術的使用已經從簡單的資金轉移應用，如涉及使用比特幣的應用，發展到更復雜的應用，包括智能合約之間的相互調用。這些智能合約可以產生大量的數據，從而造成了區塊鏈數據的復雜性和規模的增加。隨着時間的推移，這導致了更大、更復雜的區塊鏈數據。

本文中，我們將以 Footprint Analytics 的技術架構演變作為分析案例，探索 Iceberg-Trino 如何解決鏈上數據面臨的挑战。

Footprint Analytics 擁有最全面的鏈上數據索引倉庫，目前涵蓋 22 個公鏈，17 個 NFT 市場，超過 1900 個 GameFi 項目，以及超過 66 萬個 NFT 收藏。當我們談及 22 條公鏈底層數據時，不同與其他行業，區塊鏈的數據大部分都是交易數據，而非單純傳統行業的日志數據，22 條公鏈大概數量級行數大概是 200 億以上，而這些是經常需要被查詢的數據。

在過去幾個月中，我們經歷了以下三次大的系統版本升級，以滿足不斷增長的業務需求：

2. 架構 1.0 Bigquery

在 Footprint Analytics 初創階段，我們使用 Bigquery 作為存儲和查詢引擎。Bigquery 是一款優秀的產品，它提供的動態算力，和靈活的 UDF 語法幫助我們解決了很多問題。

不過 Bigquery 也存在着一些問題：

• 數據沒有經過壓縮，存儲費用過高，特別是我們需要存儲將近 20 條區塊鏈的原始數據；

• 並發能力不足：Bigquery 同時運行的 Query 只有 100 條，不能為 Footprint Analytics 提供高並發查詢；

• 非开源產品，綁定 Google 一家供應商。

所以我們決定探索新架構。

3. 架構 2.0 OLAP

我們對最近很火熱的 OLAP 產品非常感興趣，OLAP 讓人印象深刻的地方就是其查詢反應速度，僅需亞秒級響應時間即可返回海量數據下的查詢結果，對高並發的點查詢場景也支持比較好。

我們挑選了其中一款 OLAP 數據庫，Doris 進行了深入的嘗試。

但是很快，我們碰到了以下問題：

• 不支持 Array JSON 等數據類型

  • 在區塊鏈的數據中，數組 Array  是個很常見的類型，例如 evm logs 中的 topic 字段，無法對 Array 進行計算處理，會影響我們計算很多指標。

• DBT 支持有限，不支持 merge 語法來 update data

  • DBT 是數據工程師比較典型的處理ETL/ELT 的工具，尤其是Footprint Analytics 團隊。merge and update這也是很常見的需求，我們需要對一些新探索的數據進行更新操作。

也就是說，我們無法在 Doris 上完成我們的數據生產流程，所以我們退而求其次，讓 OLAP 數據庫解決我們的部分問題，作為查詢引擎，提供快速且高並發的查詢能力。

很遺憾的是，該方案 無法將 Bigquery 作為 Data Source替換掉，我們必須把不斷地把 Bigquery 上的數據進行同步，同步程序的不穩定性給我們帶來了非常多的麻煩，因為在使用存算分離的架構，當其查詢壓力過大時，也會影響寫入程序的速度，造成寫入數據堆積，同步無法繼續進行嗎，我們需要有固定的人員來處理這些同步問題。

我們意識到，OLAP 可以解決我們所面臨的幾個問題，但不能成為 Footprint Analytics 的全套解決方案，特別是在數據處理以及生產方面。我們的問題更大更復雜，我們可以說，OLAP 作為一個查詢引擎對我們來說是不夠的。

4. 架構 3.0 Iceberg + Trino

在 Footprint Analytics 架構 3.0 的升級中，我們從頭开始重新設計了整個架構，將數據的存儲、計算和查詢分成三個不同的部分。從 Footprint Analytics 早期的兩個架構中吸取教訓，並從其他成功的大數據項目中學習經驗，如 Uber、Netflix 和 Databricks。

4.1. 數據湖的引入

我們首先把注意力轉向了數據湖，這是一種新型的結構化和非結構化數據的存儲方式。數據湖非常適合鏈上數據的存儲，因為鏈上數據的格式範圍很廣，從非結構化的原始數據到結構化的抽象數據，都是 Footprint Analytics 特色亮點。我們期望用數據湖來解決數據存儲的問題，最好還能支持主流的計算引擎，如 Spark 和 Flink，這樣隨着 Footprint Analytics的發展，與不同類型的處理引擎整合起來能更容易，更具備拓展性。

Iceberg 可以與 Spark，Flink，Trino 等計算引擎都有着非常良好的集成，我們可以為我們的每一個指標選擇最合適的計算方式。例如：

• 需要復雜計算邏輯的，選擇 Spark；

• 需要實時計算的，選擇 Flink；

• 使用 SQL 就能勝任的簡單 ETL 任務，選擇 Trino。

4.2. 查詢引擎

有了 Iceberg 解決了存儲和計算的問題，我們接下來就要思考，如何選擇查詢引擎。實際上可以選的方案不多，備選的有：

• Trino: SQL Query Engine

• Presto: SQL Query Engine

• Kyuubi：Serverless Spark SQL

在深度使用之前，我們考慮最多的是，未來的查詢引擎必須要兼容我們當前的架構。

• 要支持將 Bigquery 作為 Data Source

• 要支持 DBT，我們要很多指標是依賴 DBT 完成生產的

• 要支持 BI 工具 metabase

基於以上個點，我們選擇了 Trino，Trino 對 Iceberg 的支持非常完善，而且團隊執行力非常強，我們提了一個 BUG，在第二天就被修復，並且在第二周就發布到了最新版本中。這對同樣要求高執行響應速度的 Footprint Analytics 團隊，無疑是最佳選擇。

4.3 性能測試

選定了方向之後，我們對 Trino+Iceberg 這個組合做了個性能測試，以確定其性能是否能滿足我們的需求，結果出乎我們依賴，查詢速度不可思議地快。

要知道，在各大 OLAP 的宣傳文章中，Presto + Hive 可是常年作為最差的對比項存在的，Trino + Iceberg 的組合完全刷新了我們的認知。

下面是我們的測試結果：

case 1: join  big table

一個 800 GB 的 table1 join 另一個 50 GB 的 table2 並做復雜業務計算

case2: 大單表做 distinct 查詢

測試用的 sql ： select distinct(address) from table group by day 

相同配置下，Trino+Iceberg 組合速度大約是 Doris 的 3 倍。

除此之前，還有一個驚喜，因為 Iceberg 底層可以使用 Parquet、ORC 等 data format，會對數據進行壓縮存儲，Icberg 的 table 存儲空間只需要其他數據倉庫的 1/5 左右。

同樣一個 table，在三個數據庫中的存儲大小分別是：

注：以上測試都是我們實際生產中碰到的個別業務例子，結論不嚴謹，僅供參考。

4.4 升級效果

性能測試報告給了我們足夠的性能，我們團隊使用了大概 2 個月時間來完成遷移，這個是我們升級之後的架構圖：

• 豐富的計算引擎讓我們可以應對各種計算需求；

• Trino 可以直接查詢 Iceberg，我們再也不用處理數據同步問題；

• Trino + Iceberg 讓人驚豔的性能，讓我們可以开放所有 Bronze 數據給到用戶。

總結

自2021年8月推出以來，Footprint Analytics 團隊在不到一年半的時間裏完成了三次架構升級，這得益於其為加密貨幣用戶帶來最佳數據庫技術優勢的強烈愿望和決心，以及在實施和升級其底層基礎設施和架構方面的扎實執行。

• Footprint Analytics 架構升級3.0為其用戶买到了全新的體驗，讓來自不同背景的用戶在更多樣化的使用和應用中獲得洞察力。

• 與 Metabase 商業智能工具一起構建的 Footprint 便於分析師獲得已解析的鏈上數據，完全自由地選擇工具（無代碼或編寫代碼 ）進行探索，查詢整個歷史，交叉檢查數據集，在短時間內獲得洞察力。

• 整合鏈上和鏈下的數據，在 web2 和 web3 之間進行分析。

• 通過在 Footprint 的業務抽象之上建立/查詢指標，分析師或开發人員可以節省80% 的重復性數據處理工作的時間，並專注於有意義的指標，研究和基於其業務的產品解決方案。

• 從Footprint Web 到 REST API 調用的無縫體驗，都是基於 SQL 的。

• 對關鍵信號進行實時提醒和可操作的通知，以支持投資決策。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。