Thách thức đối với ngăn xếp dữ liệu blockchain hiện đại

Có một số thách thức mà một startup lập chỉ mục blockchain hiện đại có thể gặp phải, bao gồm:

• Số lượng lớn dữ liệu. Khi lượng dữ liệu trên chuỗi khối tăng lên, chỉ mục dữ liệu sẽ cần mở rộng quy mô để xử lý tải trọng tăng lên và cung cấp quyền truy cập dữ liệu hiệu quả. Do đó, nó dẫn đến chi phí lưu trữ cao hơn; tính toán số liệu chậm và tăng tải trên máy chủ cơ sở dữ liệu.

• Đường ống xử lý dữ liệu phức tạp. Công nghệ chuỗi khối rất phức tạp và việc xây dựng một chỉ mục dữ liệu toàn diện và đáng tin cậy đòi hỏi sự hiểu biết sâu sắc về các thuật toán và cấu trúc dữ liệu cơ bản. Nó được kế thừa bởi sự đa dạng của việc triển khai chuỗi khối. Đưa ra các ví dụ cụ thể, các NFT trong Ethereum thường được tạo trong các hợp đồng thông minh tuân theo định dạng ERC721 và ERC1155, trong khi việc triển khai các NFT trên Polkadot, chẳng hạn, thường được xây dựng trực tiếp trong thời gian chạy chuỗi khối. Vào cuối ngày, những thứ đó nên được coi là NFT và nên được lưu dưới dạng đó.

• Khả năng tích hợp. Để cung cấp giá trị tối đa cho người dùng, giải pháp lập chỉ mục chuỗi khối có thể cần tích hợp chỉ mục dữ liệu của nó với các hệ thống khác, chẳng hạn như nền tảng phân tích hoặc API. Đây là một thách thức và đòi hỏi nỗ lực đáng kể đối với việc thiết kế kiến trúc.
  Khi việc sử dụng công nghệ chuỗi khối trở nên phổ biến hơn, lượng dữ liệu được lưu trữ trên chuỗi khối đã tăng lên. Điều này là do nhiều người đang sử dụng công nghệ này và mỗi giao dịch sẽ thêm dữ liệu mới vào chuỗi khối. Ngoài ra, việc sử dụng công nghệ chuỗi khối đã phát triển từ các ứng dụng chuyển tiền đơn giản, chẳng hạn như những ứng dụng liên quan đến việc sử dụng Bitcoin, đến các ứng dụng phức tạp hơn liên quan đến việc triển khai logic kinh doanh trong các hợp đồng thông minh. Các hợp đồng thông minh này có thể tạo ra một lượng lớn dữ liệu, điều này đã góp phần làm tăng độ phức tạp và kích thước của chuỗi khối. Theo thời gian, điều này đã dẫn đến một chuỗi khối lớn hơn và phức tạp hơn.

Trong bài viết này, chúng tôi xem xét sự phát triển của kiến trúc công nghệ của Footprint Analytics theo từng giai đoạn như một nghiên cứu điển hình để khám phá cách ngăn xếp công nghệ Iceberg-Trino giải quyết các thách thức của dữ liệu trên chuỗi.

Footprint Analytics đã lập chỉ mục khoảng 22 dữ liệu chuỗi khối công khai và 17 thị trường NFT, dự án 1900 GameFi và hơn 100.000 bộ sưu tập NFT vào một lớp dữ liệu trừu tượng ngữ nghĩa. Đó là giải pháp kho dữ liệu chuỗi khối toàn diện nhất trên thế giới.

Bất kể dữ liệu chuỗi khối, bao gồm hơn 20 tỷ hàng bản ghi giao dịch tài chính, thường được các nhà phân tích dữ liệu truy vấn. nó khác với nhật ký xâm nhập trong kho dữ liệu truyền thống.

Chúng tôi đã trải qua 3 lần nâng cấp lớn trong vài tháng qua để đáp ứng yêu cầu kinh doanh ngày càng tăng:

Kiến trúc 1.0 Truy vấn lớn

Khi bắt đầu Footprint Analytics, chúng tôi đã sử dụng Google Bigquery làm công cụ lưu trữ và truy vấn; Bigquery là một sản phẩm tuyệt vời. Nó cực kỳ nhanh, dễ sử dụng và cung cấp sức mạnh số học động cũng như cú pháp UDF linh hoạt giúp chúng tôi nhanh chóng hoàn thành công việc.

Tuy nhiên, Bigquery cũng có một số vấn đề.

• Dữ liệu không được nén dẫn đến chi phí lưu trữ cao, đặc biệt khi lưu trữ dữ liệu thô của hơn 22 chuỗi khối của Footprint Analytics.

• Đồng thời không đủ: Bigquery chỉ hỗ trợ 100 truy vấn đồng thời, không phù hợp với các tình huống đồng thời cao cho Footprint Analytics, khi phục vụ một số lượng lớn nhà phân tích và người dùng.

• Khóa bằng Google Bigquery, một sản phẩm mã nguồn đóng。
  Vì vậy, chúng tôi quyết định khám phá các kiến trúc thay thế khác.

Kiến trúc 2.0 OLAP

Chúng tôi rất quan tâm đến một số sản phẩm OLAP đã trở nên rất phổ biến. Ưu điểm hấp dẫn nhất của OLAP là thời gian phản hồi truy vấn, thường mất vài giây để trả về kết quả truy vấn cho lượng dữ liệu khổng lồ và nó cũng có thể hỗ trợ hàng nghìn truy vấn đồng thời.

Chúng tôi đã chọn một trong những cơ sở dữ liệu OLAP tốt nhất, Doris, để dùng thử. Động cơ này hoạt động tốt. Tuy nhiên, tại một số điểm, chúng tôi sớm gặp phải một số vấn đề khác:

• Các loại dữ liệu như Mảng hoặc JSON chưa được hỗ trợ (Tháng 11 năm 2022). Mảng là một loại dữ liệu phổ biến trong một số chuỗi khối. Chẳng hạn, trường chủ đề trong nhật ký evm. Không thể tính toán trên Array ảnh hưởng trực tiếp đến khả năng tính toán nhiều chỉ số kinh doanh của chúng tôi.

• Hỗ trợ hạn chế cho DBT và cho các câu lệnh hợp nhất. Đây là những yêu cầu phổ biến đối với kỹ sư dữ liệu đối với các tình huống ETL/ELT, trong đó chúng tôi cần cập nhật một số dữ liệu mới được lập chỉ mục.
  Nói như vậy, chúng tôi không thể sử dụng Doris cho toàn bộ quy trình sản xuất dữ liệu, vì vậy chúng tôi đã cố gắng sử dụng Doris làm cơ sở dữ liệu OLAP để giải quyết một phần vấn đề của chúng tôi trong quy trình sản xuất dữ liệu, hoạt động như một công cụ truy vấn và cung cấp nhanh chóng và hiệu quả cao. khả năng truy vấn đồng thời.

Thật không may, chúng tôi không thể thay thế Bigquery bằng Doris, vì vậy chúng tôi phải đồng bộ hóa dữ liệu từ Bigquery sang Doris theo định kỳ chỉ bằng cách sử dụng nó làm công cụ truy vấn. Quá trình đồng bộ hóa này có một số vấn đề, một trong số đó là quá trình ghi bản cập nhật bị chồng chất nhanh chóng khi công cụ OLAP đang bận phục vụ truy vấn cho các máy khách ngoại vi. Sau đó, tốc độ của quá trình ghi bị ảnh hưởng và quá trình đồng bộ hóa mất nhiều thời gian hơn và thậm chí đôi khi không thể hoàn thành.

Chúng tôi nhận ra rằng OLAP có thể giải quyết một số vấn đề mà chúng tôi đang gặp phải và không thể trở thành giải pháp chìa khóa trao tay của Footprint Analytics, đặc biệt là đối với quy trình xử lý dữ liệu. Vấn đề của chúng tôi lớn hơn và phức tạp hơn, và chúng tôi có thể nói, chỉ riêng OLAP với tư cách là một công cụ truy vấn là không đủ đối với chúng tôi.

Kiến trúc 3.0 Iceberg + Trino

Chào mừng bạn đến với kiến trúc Footprint Analytics 3.0, một bản đại tu toàn bộ kiến trúc cơ bản. Chúng tôi đã thiết kế lại toàn bộ kiến trúc từ đầu để tách việc lưu trữ, tính toán và truy vấn dữ liệu thành ba phần khác nhau. Rút ra bài học từ hai kiến trúc trước đó của Footprint Analytics và học hỏi kinh nghiệm từ các dự án dữ liệu lớn thành công khác như Uber, Netflix và Databricks.

Giới thiệu hồ dữ liệu

Trước tiên, chúng tôi chuyển sự chú ý sang hồ dữ liệu, một loại lưu trữ dữ liệu mới cho cả dữ liệu có cấu trúc và dữ liệu phi cấu trúc. Hồ dữ liệu hoàn hảo cho việc lưu trữ dữ liệu trên chuỗi vì các định dạng của dữ liệu trên chuỗi có phạm vi rộng từ dữ liệu thô phi cấu trúc đến dữ liệu trừu tượng có cấu trúc Footprint Analytics nổi tiếng với. Chúng tôi dự kiến sẽ sử dụng kho dữ liệu để giải quyết vấn đề lưu trữ dữ liệu và lý tưởng nhất là nó cũng sẽ hỗ trợ các công cụ tính toán chính thống như Spark và Flink, để việc tích hợp với các loại công cụ xử lý khác nhau khi Footprint Analytics phát triển sẽ không gây khó khăn .

Iceberg tích hợp rất tốt với Spark, Flink, Trino và các công cụ tính toán khác, đồng thời chúng tôi có thể chọn cách tính toán phù hợp nhất cho từng chỉ số của mình. Ví dụ:

• Đối với những người yêu cầu logic tính toán phức tạp, Spark sẽ là lựa chọn.

• Flink để tính toán thời gian thực.

• Đối với các tác vụ ETL đơn giản có thể được thực hiện bằng SQL, chúng tôi sử dụng Trino.

  Công cụ truy vấn

Với việc Iceberg giải quyết các vấn đề về lưu trữ và tính toán, sau đó chúng tôi phải suy nghĩ về cách chọn một công cụ truy vấn. Không có nhiều tùy chọn có sẵn, các lựa chọn thay thế mà chúng tôi đã xem xét là

• Trino: Công cụ truy vấn SQL

• Presto: Công cụ truy vấn SQL

• Kyuubi: Serverless Spark SQL
  Điều quan trọng nhất mà chúng tôi đã xem xét trước khi tìm hiểu sâu hơn là công cụ truy vấn trong tương lai phải tương thích với kiến trúc hiện tại của chúng tôi.

• Để hỗ trợ Bigquery dưới dạng Nguồn dữ liệu

• Để hỗ trợ DBT, chúng tôi dựa vào đó để tạo ra nhiều chỉ số

• Để hỗ trợ siêu dữ liệu công cụ BI
  Dựa trên những điều trên, chúng tôi đã chọn Trino, công cụ hỗ trợ rất tốt cho Iceberg và nhóm đã phản ứng nhanh đến mức chúng tôi đã đưa ra một lỗi, lỗi này đã được sửa vào ngày hôm sau và phát hành lên phiên bản mới nhất vào tuần sau. Đây chắc chắn là lựa chọn tốt nhất cho nhóm Footprint, những người cũng yêu cầu khả năng đáp ứng triển khai cao.

Kiểm tra năng suất

Khi chúng tôi đã quyết định hướng đi của mình, chúng tôi đã thực hiện kiểm tra hiệu suất trên tổ hợp Trino + Iceberg để xem liệu nó có đáp ứng được nhu cầu của chúng tôi hay không và chúng tôi ngạc nhiên là các truy vấn cực kỳ nhanh.

Biết rằng Presto + Hive là công cụ so sánh tồi tệ nhất trong nhiều năm qua trong tất cả các quảng cáo cường điệu về OLAP, sự kết hợp giữa Trino + Iceberg đã hoàn toàn làm chúng tôi kinh ngạc.

Đây là kết quả của các bài kiểm tra của chúng tôi.

• trường hợp 1: tham gia tập dữ liệu lớn

  Một bảng1 800 GB kết hợp với một bảng2 50 GB khác và thực hiện các phép tính kinh doanh phức tạp

• case2: sử dụng một bảng lớn để thực hiện một truy vấn riêng biệt

  Kiểm tra sql: chọn phân biệt (địa chỉ) từ nhóm bảng theo ngày

Sự kết hợp Trino+Iceberg nhanh hơn khoảng 3 lần so với Doris trong cùng một cấu hình.

Ngoài điều này, còn có một bất ngờ khác, đó là Iceberg có thể sử dụng các định dạng dữ liệu như Parquet, ORC, v.v., các định dạng này sẽ nén và lưu trữ dữ liệu. Lưu trữ bảng của Iceberg chỉ chiếm khoảng 1/5 không gian của các kho dữ liệu khác Kích thước lưu trữ của cùng một bảng trong ba cơ sở dữ liệu như sau:

Lưu ý: Các thử nghiệm trên là các ví dụ riêng lẻ mà chúng tôi đã gặp trong quá trình sản xuất thực tế và chỉ mang tính chất tham khảo.

・Hiệu ứng nâng cấp

Các báo cáo thử nghiệm hiệu suất đã cung cấp cho chúng tôi đủ hiệu suất để nhóm của chúng tôi mất khoảng 2 tháng để hoàn thành quá trình di chuyển và đây là sơ đồ về kiến trúc của chúng tôi sau khi nâng cấp.

• Nhiều công cụ máy tính phù hợp với nhu cầu khác nhau của chúng tôi.

• Trino hỗ trợ DBT, có thể truy vấn Iceberg trực tiếp nên chúng ta không còn phải xử lý đồng bộ dữ liệu nữa.

• Hiệu suất tuyệt vời của Trino + Iceberg cho phép chúng tôi mở tất cả dữ liệu Đồng (dữ liệu thô) cho người dùng của mình.

  Tóm tắt

Kể từ khi ra mắt vào tháng 8 năm 2021, nhóm Footprint Analytics đã hoàn thành ba lần nâng cấp kiến trúc trong vòng chưa đầy một năm rưỡi, nhờ vào mong muốn kéo dài và quyết tâm mang lại lợi ích của công nghệ cơ sở dữ liệu tốt nhất cho người dùng tiền điện tử của mình cũng như việc thực thi vững chắc việc triển khai và nâng cấp cơ sở hạ tầng và kiến trúc cơ bản của nó.

Bản nâng cấp kiến trúc Footprint Analytics 3.0 đã mang lại trải nghiệm mới cho người dùng, cho phép người dùng từ các nền tảng khác nhau có được thông tin chi tiết về cách sử dụng và ứng dụng đa dạng hơn:

• Được xây dựng bằng công cụ Metabase BI, Footprint tạo điều kiện cho các nhà phân tích có quyền truy cập vào dữ liệu trên chuỗi được giải mã, khám phá hoàn toàn tự do lựa chọn các công cụ (không có mã hoặc hardcord), truy vấn toàn bộ lịch sử, kiểm tra chéo bộ dữ liệu, để có được thông tin chi tiết mà không- thời gian.

• Tích hợp cả dữ liệu trên chuỗi và ngoài chuỗi để phân tích trên web2 + web3;

• Bằng cách xây dựng/truy vấn các chỉ số trên cơ sở trừu tượng kinh doanh của Footprint, các nhà phân tích hoặc nhà phát triển tiết kiệm thời gian cho 80% công việc xử lý dữ liệu lặp đi lặp lại và tập trung vào các chỉ số, nghiên cứu và giải pháp sản phẩm có ý nghĩa dựa trên hoạt động kinh doanh của họ.

• Trải nghiệm liền mạch từ Footprint Web đến lệnh gọi API REST, tất cả đều dựa trên SQL

• Cảnh báo theo thời gian thực và thông báo có thể thực hiện được về các tín hiệu chính để hỗ trợ các quyết định đầu tư