Iceberg+Spark+Trino：區塊鏈的現代開源數據堆棧
在本章中，你將認識Footprint的關鍵架構更新、特色功能；以及它在數據收集和整理方面的表現
現代區塊鏈數據堆棧面臨的挑戰
現代區塊鏈索引初創公司可能面臨幾個挑戰，包括：
- 巨大的數據量。隨著區塊鏈上數據量的增加，數據索引將需要擴展以處理增加的負載並提供高效的數據訪問。這會導致更高的存儲成本、緩慢的指標計算和數據庫服務器負載的增加。
- 複雜的數據處理管道。區塊鏈技術很複雜，構建全面可靠的數據索引需要深入瞭解底層數據結構和算法。這也受到區塊鏈實現方案多樣性的影響。舉個具體的例子，以太坊中的NFT通常是在遵循ERC721和ERC1155格式的智能合約中創建的，而Polkadot上的NFT通常是直接在區塊鏈運行時構建的。但最終，它們都應被視為NFT並應以此方式保存。
- 集成能力。為了為用戶提供最大價值，區塊鏈索引解決方案可能需要將其數據索引與其他系統（如分析平臺或API）集成。這是具有挑戰性的，需要在架構設計上投入大量努力。
隨著區塊鏈技術的使用越來越廣泛，存儲在區塊鏈上的數據量也增加了。這是因為隨著越來越多的人使用該技術，每筆交易都會向區塊鏈添加新數據。此外，區塊鏈技術的使用已經從簡單的貨幣轉移應用（如關於比特幣使用的應用）發展到在智能合約中實現業務邏輯的更復雜的應用。這些智能合約會產生大量數據，導致區塊鏈更加複雜、更加龐大。
在本文中，我們分階段回顧了Footprint Analytics技術架構的演變，並以此為例，探討了Iceberg-Trino技術堆棧如何應對鏈上數據的挑戰。
Footprint Analytics已經將大約22個公鏈數據、17個NFT市場、1900個GameFi項目和超過10萬個NFT集合索引到語義抽象數據層中。它是世界上最全面的區塊鏈數據倉庫解決方案。
區塊鏈數據包括超過200億行的金融交易記錄，經常被數據分析師查詢。
為滿足不斷增長的業務需求，在過去的幾個月中，我們進行了3次重大升級，包括：
架構1.0 Bigquery
在Footprint Analytics最初，我們使用谷歌Bigquery作為我們的存儲和查詢引擎。Bigquery是一個很棒的產品，它速度極快，易於使用，並提供動態算術能力和靈活的UDF語法，能夠幫助我們快速完成工作。
然而，Bigquery也存在一些問題。
- 數據沒有壓縮，導致存儲成本很高，特別是在存儲Footprint Analytics超過22個區塊鏈的原始數據時。
- 併發能力不足：Bigquery僅同時支持100條查詢，不適用於Footprint Analytics的高併發場景，因為需要為大量分析師和用戶提供服務。
- 非開源產品，綁定 Google 一家供應商。
因此，我們決定探索其他替代架構。
架構2.0 OLAP
我們對一些非常流行的OLAP（聯機分析處理）產品感興趣，OLAP最吸引人的優勢是它的查詢響應時間，通常能在亞秒內返回大量數據的查詢結果，並且還支持數千個同時查詢。
我們選擇了最好的OLAP數據庫之一Doris。這個引擎表現不錯，但我們很快遇到了一些其他問題：
- 尚不支持數組或JSON等數據類型（截至2022年11月）。數組是某些區塊鏈中常見的數據類型。例如，evm日誌中的topic字段。無法直接對數組進行計算，會影響我們計算許多業務指標。
- 對DBT和merge語法的支持有限。它們是數據工程師在ETL/ELT(數據提取-加載-轉換）場景中常見的需求，我們需要更新一些新索引的數據。
話雖如此，我們無法在生產中完全使用Doris作為整個數據管道，因此我們嘗試將Doris作為OLAP數據庫來解決我們在數據生產管道中的一部分問題，作為查詢引擎並提供快速和高併發的查詢能力。
然而，我們無法用Doris替代Bigquery，因此需要定期將數據從Bigquery同步到Doris，僅將Doris作為查詢引擎。這個同步過程存在許多問題，其中之一是當OLAP引擎忙於向前端客戶端提供查詢時，寫入數據會迅速堆積起來。隨後，寫入過程的速度受到影響，同步會花費更長的時間，有時甚至無法完成。
我們意識到，OLAP可以解決我們面臨的幾個問題，但無法成為Footprint Analytics的一站式解決方案，特別是對於數據處理管道而言。我們的問題更大更復雜，可以說，OLAP僅僅作為一個查詢引擎對我們來說還不夠。
架構3.0 Iceberg + Trino
歡迎來到Footprint Analytics架構3.0，這是對底層架構的全面重構。我們從頭開始重新設計了整個架構，將數據的存儲、計算和查詢分成三個不同的部分，從Footprint Analytics早期的兩個架構中吸取教訓，並從其他成功的大數據項目如Uber、Netflix和Databricks中學習經驗。
數據湖的引入
我們首先將注意力轉向了數據湖，這是一種用於結構化和非結構化數據的新型數據存儲方式。數據湖非常適合鏈上數據的存儲，因為鏈上數據的格式範圍廣泛，包括非結構化原始數據和Footprint Analytics所著名的結構化抽象數據。我們期望用數據湖來解決數據存儲問題，理想情況下，它還將支持Spark和Flink等主流計算引擎，這樣，隨著Footprint Analytics的發展，在與不同類型的處理引擎集成就不會出現額外問題。
Iceberg與Spark、Flink、Trino和其他計算引擎可以非常好地集成到一起，我們可以為每個指標選擇最合適的計算方式。例如：
- 對於需要複雜計算邏輯的指標，Spark將是首選。
- Flink適用於實時計算。
- 對於可以用SQL執行的簡單ETL任務，我們使用Trino。
查詢引擎
Iceberg解決了存儲和計算問題，接下來，我們將需要考慮如何選擇查詢引擎。可用的選項並不多，我們考慮的替代方案包括：
- Trino：SQL查詢引擎
- Presto：SQL查詢引擎
- Kyuubi：無服務器Spark SQL
在深入研究之前，我們考慮的最重要的事情是，未來的查詢引擎必須與我們當前的架構兼容。
- 支持Bigquery作為數據源
- 支持DBT（我們依賴它來生成許多指標）
- 支持BI（商業智能）工具Metabase
基於以上考慮，我們選擇了Trino，它對Iceberg有很好的支持，團隊響應非常迅速，我們曾提出的bug在第二天便修復了，並在第二週發佈了最新版本。對於需要較高響應能力的團隊Footprint而言，這絕對是Footprint的最佳選擇。
性能測試
定好方向之後，我們就對Trino+Iceberg組合進行了性能測試，看看它是否能滿足我們的需求。出乎意料的是，它的查詢速度非常快。
我們知道多年來，Presto+Hive一直是OLAP領域中性能最差的對手，但Trino+Iceberg組合完全顛覆了我們的認知。
我們的測試結果如下。
示例1：連接大型數據集
將一個800 GB的表1與另一個50 GB的表2連接，並進行復雜的業務計算。
示例2：大表單執行不重複查詢
測試用的sql：從表中按日期分組選擇不同的地址
Trino+Iceberg組合在相同配置下比Doris快約3倍。
此外，Iceberg可以使用Parquet、ORC等數據格式，這些格式會對數據進行壓縮存儲。Iceberg的表存儲佔用的空間僅為其他數據倉庫的1/5左右，三個數據庫中相同表的存儲大小如下：
注：以上測試是我們在實際生產中遇到的個別示例，僅供參考。
升級效果
性能測試報告為我們提供了足夠的性能，以至於我們的團隊花了大約2個月的時間才完成遷移。以下是我們升級後的架構圖。
- 多個計算機引擎滿足我們的各種需求。
- Trino支持DBT，可以直接查詢Iceberg，所以我們不再需要處理數據同步。
- Trino+Iceberg的驚人性能使我們能夠向用戶開放所有黃銅數據（原始數據）。
小結
自2021年8月推出以來，Footprint Analytics團隊在不到一年半的時間內完成了三次架構升級，這要歸功於團隊為加密貨幣用戶帶來最佳數據庫技術優勢的渴望和決心，以及在實施和升級底層基礎設施和架構方面的出色表現。
Footprint Analytics架構3.0升級為用戶帶來了全新的體驗，讓具有不同背景的用戶能夠深入瞭解更多樣化的用途和使用場景：
- Footprint使用Metabase BI工具進行構建，有助於分析師訪問解碼的鏈上數據，完全自由地選擇工具（無需代碼或硬編碼）進行探索，查詢完整的歷史記錄，交叉檢查數據集，及時獲得深入分析。
- 將鏈上和鏈下數據整合到Web2+Web3的分析中。
- 通過在Footprint的業務抽象之上構建/查詢指標，分析師或開發人員可以節省80%的重複數據處理時間，並專注於基於其業務的有意義的指標、研究和產品解決方案。
- 從Footprint Web到REST API調用的無縫體驗，全部基於SQL。
- 提供關鍵信號的實時警報和可操作通知，以支持投資決策。
Iceberg+Spark+Trino：區塊鏈的現代開源數據堆棧
在本章中，你將認識Footprint的關鍵架構更新、特色功能；以及它在數據收集和整理方面的表現
現代區塊鏈數據堆棧面臨的挑戰
現代區塊鏈索引初創公司可能面臨幾個挑戰，包括：
- 巨大的數據量。隨著區塊鏈上數據量的增加，數據索引將需要擴展以處理增加的負載並提供高效的數據訪問。這會導致更高的存儲成本、緩慢的指標計算和數據庫服務器負載的增加。
- 複雜的數據處理管道。區塊鏈技術很複雜，構建全面可靠的數據索引需要深入瞭解底層數據結構和算法。這也受到區塊鏈實現方案多樣性的影響。舉個具體的例子，以太坊中的NFT通常是在遵循ERC721和ERC1155格式的智能合約中創建的，而Polkadot上的NFT通常是直接在區塊鏈運行時構建的。但最終，它們都應被視為NFT並應以此方式保存。
- 集成能力。為了為用戶提供最大價值，區塊鏈索引解決方案可能需要將其數據索引與其他系統（如分析平臺或API）集成。這是具有挑戰性的，需要在架構設計上投入大量努力。
隨著區塊鏈技術的使用越來越廣泛，存儲在區塊鏈上的數據量也增加了。這是因為隨著越來越多的人使用該技術，每筆交易都會向區塊鏈添加新數據。此外，區塊鏈技術的使用已經從簡單的貨幣轉移應用（如關於比特幣使用的應用）發展到在智能合約中實現業務邏輯的更復雜的應用。這些智能合約會產生大量數據，導致區塊鏈更加複雜、更加龐大。
在本文中，我們分階段回顧了Footprint Analytics技術架構的演變，並以此為例，探討了Iceberg-Trino技術堆棧如何應對鏈上數據的挑戰。
Footprint Analytics已經將大約22個公鏈數據、17個NFT市場、1900個GameFi項目和超過10萬個NFT集合索引到語義抽象數據層中。它是世界上最全面的區塊鏈數據倉庫解決方案。
區塊鏈數據包括超過200億行的金融交易記錄，經常被數據分析師查詢。
為滿足不斷增長的業務需求，在過去的幾個月中，我們進行了3次重大升級，包括：
架構1.0 Bigquery
在Footprint Analytics最初，我們使用谷歌Bigquery作為我們的存儲和查詢引擎。Bigquery是一個很棒的產品，它速度極快，易於使用，並提供動態算術能力和靈活的UDF語法，能夠幫助我們快速完成工作。
然而，Bigquery也存在一些問題。
- 數據沒有壓縮，導致存儲成本很高，特別是在存儲Footprint Analytics超過22個區塊鏈的原始數據時。
- 併發能力不足：Bigquery僅同時支持100條查詢，不適用於Footprint Analytics的高併發場景，因為需要為大量分析師和用戶提供服務。
- 非開源產品，綁定 Google 一家供應商。
因此，我們決定探索其他替代架構。
架構2.0 OLAP
我們對一些非常流行的OLAP（聯機分析處理）產品感興趣，OLAP最吸引人的優勢是它的查詢響應時間，通常能在亞秒內返回大量數據的查詢結果，並且還支持數千個同時查詢。
我們選擇了最好的OLAP數據庫之一Doris。這個引擎表現不錯，但我們很快遇到了一些其他問題：
- 尚不支持數組或JSON等數據類型（截至2022年11月）。數組是某些區塊鏈中常見的數據類型。例如，evm日誌中的topic字段。無法直接對數組進行計算，會影響我們計算許多業務指標。
- 對DBT和merge語法的支持有限。它們是數據工程師在ETL/ELT(數據提取-加載-轉換）場景中常見的需求，我們需要更新一些新索引的數據。
話雖如此，我們無法在生產中完全使用Doris作為整個數據管道，因此我們嘗試將Doris作為OLAP數據庫來解決我們在數據生產管道中的一部分問題，作為查詢引擎並提供快速和高併發的查詢能力。
然而，我們無法用Doris替代Bigquery，因此需要定期將數據從Bigquery同步到Doris，僅將Doris作為查詢引擎。這個同步過程存在許多問題，其中之一是當OLAP引擎忙於向前端客戶端提供查詢時，寫入數據會迅速堆積起來。隨後，寫入過程的速度受到影響，同步會花費更長的時間，有時甚至無法完成。
我們意識到，OLAP可以解決我們面臨的幾個問題，但無法成為Footprint Analytics的一站式解決方案，特別是對於數據處理管道而言。我們的問題更大更復雜，可以說，OLAP僅僅作為一個查詢引擎對我們來說還不夠。
架構3.0 Iceberg + Trino
歡迎來到Footprint Analytics架構3.0，這是對底層架構的全面重構。我們從頭開始重新設計了整個架構，將數據的存儲、計算和查詢分成三個不同的部分，從Footprint Analytics早期的兩個架構中吸取教訓，並從其他成功的大數據項目如Uber、Netflix和Databricks中學習經驗。
數據湖的引入
我們首先將注意力轉向了數據湖，這是一種用於結構化和非結構化數據的新型數據存儲方式。數據湖非常適合鏈上數據的存儲，因為鏈上數據的格式範圍廣泛，包括非結構化原始數據和Footprint Analytics所著名的結構化抽象數據。我們期望用數據湖來解決數據存儲問題，理想情況下，它還將支持Spark和Flink等主流計算引擎，這樣，隨著Footprint Analytics的發展，在與不同類型的處理引擎集成就不會出現額外問題。
Iceberg與Spark、Flink、Trino和其他計算引擎可以非常好地集成到一起，我們可以為每個指標選擇最合適的計算方式。例如：
- 對於需要複雜計算邏輯的指標，Spark將是首選。
- Flink適用於實時計算。
- 對於可以用SQL執行的簡單ETL任務，我們使用Trino。
查詢引擎
Iceberg解決了存儲和計算問題，接下來，我們將需要考慮如何選擇查詢引擎。可用的選項並不多，我們考慮的替代方案包括：
- Trino：SQL查詢引擎
- Presto：SQL查詢引擎
- Kyuubi：無服務器Spark SQL
在深入研究之前，我們考慮的最重要的事情是，未來的查詢引擎必須與我們當前的架構兼容。
- 支持Bigquery作為數據源
- 支持DBT（我們依賴它來生成許多指標）
- 支持BI（商業智能）工具Metabase
基於以上考慮，我們選擇了Trino，它對Iceberg有很好的支持，團隊響應非常迅速，我們曾提出的bug在第二天便修復了，並在第二週發佈了最新版本。對於需要較高響應能力的團隊Footprint而言，這絕對是Footprint的最佳選擇。
性能測試
定好方向之後，我們就對Trino+Iceberg組合進行了性能測試，看看它是否能滿足我們的需求。出乎意料的是，它的查詢速度非常快。
我們知道多年來，Presto+Hive一直是OLAP領域中性能最差的對手，但Trino+Iceberg組合完全顛覆了我們的認知。
我們的測試結果如下。
示例1：連接大型數據集
將一個800 GB的表1與另一個50 GB的表2連接，並進行復雜的業務計算。
示例2：大表單執行不重複查詢
測試用的sql：從表中按日期分組選擇不同的地址
Trino+Iceberg組合在相同配置下比Doris快約3倍。
此外，Iceberg可以使用Parquet、ORC等數據格式，這些格式會對數據進行壓縮存儲。Iceberg的表存儲佔用的空間僅為其他數據倉庫的1/5左右，三個數據庫中相同表的存儲大小如下：
注：以上測試是我們在實際生產中遇到的個別示例，僅供參考。
升級效果
性能測試報告為我們提供了足夠的性能，以至於我們的團隊花了大約2個月的時間才完成遷移。以下是我們升級後的架構圖。
- 多個計算機引擎滿足我們的各種需求。
- Trino支持DBT，可以直接查詢Iceberg，所以我們不再需要處理數據同步。
- Trino+Iceberg的驚人性能使我們能夠向用戶開放所有黃銅數據（原始數據）。
小結
自2021年8月推出以來，Footprint Analytics團隊在不到一年半的時間內完成了三次架構升級，這要歸功於團隊為加密貨幣用戶帶來最佳數據庫技術優勢的渴望和決心，以及在實施和升級底層基礎設施和架構方面的出色表現。
Footprint Analytics架構3.0升級為用戶帶來了全新的體驗，讓具有不同背景的用戶能夠深入瞭解更多樣化的用途和使用場景：
- Footprint使用Metabase BI工具進行構建，有助於分析師訪問解碼的鏈上數據，完全自由地選擇工具（無需代碼或硬編碼）進行探索，查詢完整的歷史記錄，交叉檢查數據集，及時獲得深入分析。
- 將鏈上和鏈下數據整合到Web2+Web3的分析中。
- 通過在Footprint的業務抽象之上構建/查詢指標，分析師或開發人員可以節省80%的重複數據處理時間，並專注於基於其業務的有意義的指標、研究和產品解決方案。
- 從Footprint Web到REST API調用的無縫體驗，全部基於SQL。
- 提供關鍵信號的實時警報和可操作通知，以支持投資決策。