ความท้าทายสำหรับกองข้อมูล blockchain สมัยใหม่

มีความท้าทายหลายอย่างที่การเริ่มต้นสร้างดัชนี blockchain สมัยใหม่อาจเผชิญ ได้แก่ :

• ข้อมูลจำนวนมหาศาล เมื่อปริมาณข้อมูลในบล็อกเชนเพิ่มขึ้น ดัชนีข้อมูลจะต้องขยายขนาดเพื่อรองรับโหลดที่เพิ่มขึ้นและให้การเข้าถึงข้อมูลอย่างมีประสิทธิภาพ ส่งผลให้ต้นทุนการจัดเก็บสูงขึ้น การคำนวณเมตริกช้าและเพิ่มโหลดบนเซิร์ฟเวอร์ฐานข้อมูล

• ไปป์ไลน์การประมวลผลข้อมูลที่ซับซ้อน เทคโนโลยีบล็อกเชนนั้นซับซ้อน และการสร้างดัชนีข้อมูลที่ครอบคลุมและเชื่อถือได้จำเป็นต้องมีความเข้าใจอย่างลึกซึ้งเกี่ยวกับโครงสร้างข้อมูลและอัลกอริทึมพื้นฐาน มันสืบทอดมาจากความหลากหลายของการใช้งานบล็อกเชน จากตัวอย่างที่เฉพาะเจาะจง NFT ใน Ethereum มักจะถูกสร้างขึ้นภายในสัญญาอัจฉริยะที่เป็นไปตามรูปแบบ ERC721 และ ERC1155 ในขณะที่การใช้งานใน Polkadot เช่น มักจะสร้างโดยตรงภายในรันไทม์บล็อกเชน ในตอนท้ายของวัน สิ่งเหล่านั้นควรได้รับการพิจารณาว่าเป็น NFT และควรบันทึกเป็นสิ่งเหล่านี้

• ความสามารถในการบูรณาการ เพื่อให้คุณค่าสูงสุดแก่ผู้ใช้ โซลูชันการจัดทำดัชนีบล็อกเชนอาจจำเป็นต้องรวมดัชนีข้อมูลเข้ากับระบบอื่นๆ เช่น แพลตฟอร์มการวิเคราะห์หรือ API สิ่งนี้เป็นสิ่งที่ท้าทายและต้องใช้ความพยายามอย่างมากในการออกแบบสถาปัตยกรรม
  เนื่องจากการใช้เทคโนโลยีบล็อกเชนแพร่หลายมากขึ้น จำนวนข้อมูลที่จัดเก็บในบล็อกเชนจึงเพิ่มขึ้น นี่เป็นเพราะผู้คนใช้เทคโนโลยีมากขึ้น และแต่ละธุรกรรมจะเพิ่มข้อมูลใหม่ลงในบล็อกเชน นอกจากนี้ การใช้เทคโนโลยีบล็อกเชนได้พัฒนาจากแอปพลิเคชันการโอนเงินอย่างง่าย เช่น แอปพลิเคชันที่เกี่ยวข้องกับการใช้ Bitcoin ไปจนถึงแอปพลิเคชันที่ซับซ้อนมากขึ้นซึ่งเกี่ยวข้องกับการใช้ตรรกะทางธุรกิจภายในสัญญาอัจฉริยะ สัญญาอัจฉริยะเหล่านี้สามารถสร้างข้อมูลจำนวนมาก ซึ่งมีส่วนทำให้ความซับซ้อนและขนาดของบล็อกเชนเพิ่มขึ้น เมื่อเวลาผ่านไป สิ่งนี้ได้นำไปสู่บล็อกเชนที่ใหญ่ขึ้นและซับซ้อนมากขึ้น

ในบทความนี้ เราจะตรวจสอบวิวัฒนาการของสถาปัตยกรรมเทคโนโลยีของ Footprint Analytics เป็นระยะเพื่อเป็นกรณีศึกษาเพื่อสำรวจว่าเทคโนโลยี Iceberg-Trino จัดการกับความท้าทายของข้อมูลบนเครือข่ายได้อย่างไร

Footprint Analytics จัดทำดัชนีข้อมูลบล็อกเชนสาธารณะประมาณ 22 รายการ และตลาด NFT 17 แห่ง โครงการ GameFi 1900 โครงการ และคอลเล็กชัน NFT กว่า 100,000 รายการลงในชั้นข้อมูลนามธรรมเชิงความหมาย เป็นโซลูชันคลังข้อมูลบล็อกเชนที่ครอบคลุมมากที่สุดในโลก

โดยไม่คำนึงถึงข้อมูลบล็อกเชน ซึ่งรวมถึงบันทึกการทำธุรกรรมทางการเงินมากกว่า 2 หมื่นล้านแถว ซึ่งนักวิเคราะห์ข้อมูลมักจะสอบถาม ซึ่งแตกต่างจากบันทึกการเข้าในคลังข้อมูลแบบดั้งเดิม

เรามีประสบการณ์การอัปเกรดครั้งใหญ่ 3 ครั้งในช่วงหลายเดือนที่ผ่านมาเพื่อตอบสนองความต้องการทางธุรกิจที่กำลังเติบโต:

สถาปัตยกรรม 1.0 Bigquery

ในช่วงเริ่มต้นของ Footprint Analytics เราใช้ Google Bigquery เป็นเครื่องมือจัดเก็บและสืบค้น Bigquery เป็นผลิตภัณฑ์ที่ยอดเยี่ยม มันเร็วอย่างเห็นได้ชัด ใช้งานง่าย และให้พลังเลขคณิตแบบไดนามิกและไวยากรณ์ UDF ที่ยืดหยุ่นซึ่งช่วยให้เราทำงานให้เสร็จได้อย่างรวดเร็ว

อย่างไรก็ตาม Bigquery ก็มีปัญหาหลายอย่างเช่นกัน

• ข้อมูลไม่ถูกบีบอัด ส่งผลให้ต้นทุนการจัดเก็บสูง โดยเฉพาะอย่างยิ่งเมื่อต้องจัดเก็บข้อมูลดิบของ Footprint Analytics มากกว่า 22 บล็อกเชน

• การทำงานพร้อมกันไม่เพียงพอ: Bigquery รองรับเพียง 100 ข้อความค้นหาพร้อมกัน ซึ่งไม่เหมาะสำหรับสถานการณ์การทำงานพร้อมกันสูงสำหรับ Footprint Analytics เมื่อให้บริการนักวิเคราะห์และผู้ใช้จำนวนมาก

• ล็อคอินด้วย Google Bigquery ซึ่งเป็นผลิตภัณฑ์แบบปิด。
  ดังนั้นเราจึงตัดสินใจที่จะสำรวจสถาปัตยกรรมทางเลือกอื่นๆ

สถาปัตยกรรม 2.0 OLAP

เราสนใจผลิตภัณฑ์ OLAP บางตัวซึ่งได้รับความนิยมอย่างมาก ข้อได้เปรียบที่น่าสนใจที่สุดของ OLAP คือเวลาตอบสนองการสืบค้นข้อมูล ซึ่งโดยทั่วไปจะใช้เวลาเพียงเสี้ยววินาทีในการส่งคืนผลการสืบค้นสำหรับข้อมูลจำนวนมหาศาล และยังสามารถรองรับการสืบค้นพร้อมกันนับพันรายการได้อีกด้วย

เราเลือก Doris หนึ่งในฐานข้อมูล OLAP ที่ดีที่สุดมาทดลองใช้ เครื่องยนต์นี้ทำงานได้ดี อย่างไรก็ตาม เมื่อถึงจุดหนึ่ง เราก็พบปัญหาอื่นๆ ในไม่ช้า:

• ยังไม่รองรับประเภทข้อมูล เช่น Array หรือ JSON (พ.ย. 2022) อาร์เรย์เป็นประเภทข้อมูลทั่วไปในบล็อกเชนบางประเภท ตัวอย่างเช่น ช่องหัวข้อในบันทึก evm การไม่สามารถคำนวณบน Array ได้ส่งผลโดยตรงต่อความสามารถของเราในการคำนวณเมตริกทางธุรกิจจำนวนมาก

• การสนับสนุนอย่างจำกัดสำหรับ DBT และคำสั่งรวม สิ่งเหล่านี้เป็นข้อกำหนดทั่วไปสำหรับวิศวกรข้อมูลสำหรับสถานการณ์ ETL/ELT ซึ่งเราจำเป็นต้องอัปเดตข้อมูลที่จัดทำดัชนีใหม่บางส่วน
  อย่างที่กล่าวไปแล้ว เราไม่สามารถใช้ Doris สำหรับไปป์ไลน์ข้อมูลทั้งหมดในการผลิตได้ ดังนั้นเราจึงพยายามใช้ Doris เป็นฐานข้อมูล OLAP เพื่อแก้ปัญหาส่วนหนึ่งในไปป์ไลน์การผลิตข้อมูล โดยทำหน้าที่เป็นเครื่องมือคิวรีและให้บริการที่รวดเร็วและสูง ความสามารถในการสืบค้นพร้อมกัน

ขออภัย เราไม่สามารถแทนที่ Bigquery ด้วย Doris ได้ ดังนั้นเราต้องซิงโครไนซ์ข้อมูลจาก Bigquery ไปยัง Doris เป็นระยะโดยใช้เป็นเครื่องมือสืบค้นข้อมูลเท่านั้น กระบวนการซิงโครไนซ์นี้มีปัญหาหลายประการ ซึ่งหนึ่งในนั้นคือการเขียนอัปเดตซ้อนกันอย่างรวดเร็วเมื่อเอ็นจิ้น OLAP ไม่ว่างในการให้บริการการสืบค้นไปยังไคลเอนต์ส่วนหน้า ในเวลาต่อมา ความเร็วของกระบวนการเขียนได้รับผลกระทบ และการซิงโครไนซ์ใช้เวลานานกว่ามาก และบางครั้งก็เป็นไปไม่ได้ที่จะเสร็จสิ้น

เราตระหนักว่า OLAP สามารถแก้ไขปัญหาต่างๆ ที่เรากำลังเผชิญอยู่ และไม่สามารถเป็นโซลูชันแบบครบวงจรของ Footprint Analytics โดยเฉพาะอย่างยิ่งสำหรับไปป์ไลน์การประมวลผลข้อมูล ปัญหาของเราใหญ่กว่าและซับซ้อนกว่า และเราอาจพูดได้ว่า OLAP เป็นเครื่องมือสืบค้นเพียงอย่างเดียวไม่เพียงพอสำหรับเรา

สถาปัตยกรรม 3.0 ภูเขาน้ำแข็ง + Trino

ยินดีต้อนรับสู่สถาปัตยกรรม Footprint Analytics 3.0 ซึ่งเป็นการยกเครื่องสถาปัตยกรรมพื้นฐานทั้งหมด เราได้ออกแบบสถาปัตยกรรมใหม่ทั้งหมดตั้งแต่เริ่มต้น เพื่อแยกการจัดเก็บ การคำนวณ และการสืบค้นข้อมูลออกเป็นสามส่วนที่แตกต่างกัน บทเรียนจากทั้งสองสถาปัตยกรรมก่อนหน้านี้ของ Footprint Analytics และเรียนรู้จากประสบการณ์ของโครงการข้อมูลขนาดใหญ่ที่ประสบความสำเร็จอื่นๆ เช่น Uber, Netflix และ Databricks

การแนะนำของดาต้าเลค

อันดับแรก เราหันมาสนใจที่ Data Lake ซึ่งเป็นที่จัดเก็บข้อมูลประเภทใหม่สำหรับทั้งข้อมูลที่มีโครงสร้างและไม่มีโครงสร้าง Data Lake นั้นสมบูรณ์แบบสำหรับการจัดเก็บข้อมูลแบบ on-chain เนื่องจากรูปแบบของข้อมูลแบบ on-chain มีหลากหลายตั้งแต่ข้อมูลดิบที่ไม่มีโครงสร้างไปจนถึงข้อมูลเชิงนามธรรมที่มีโครงสร้าง Footprint Analytics เป็นที่รู้จักกันดี เราคาดว่าจะใช้ Data Lake เพื่อแก้ปัญหาการจัดเก็บข้อมูล และตามหลักแล้ว มันยังสนับสนุนเครื่องมือประมวลผลหลัก เช่น Spark และ Flink ดังนั้นการรวมเข้ากับเครื่องมือประมวลผลประเภทต่างๆ จึงไม่เป็นเรื่องยุ่งยากเมื่อ Footprint Analytics พัฒนาขึ้น .

Iceberg ทำงานร่วมกับ Spark, Flink, Trino และเครื่องมือคำนวณอื่นๆ ได้เป็นอย่างดี และเราสามารถเลือกการคำนวณที่เหมาะสมที่สุดสำหรับแต่ละเมตริกของเราได้ ตัวอย่างเช่น:

• สำหรับผู้ที่ต้องการตรรกะการคำนวณที่ซับซ้อน Spark จะเป็นตัวเลือก

• Flink สำหรับการคำนวณตามเวลาจริง

• สำหรับงาน ETL อย่างง่ายที่สามารถทำได้โดยใช้ SQL เราใช้ Trino

  เครื่องมือแบบสอบถาม

เมื่อ Iceberg แก้ปัญหาการจัดเก็บและการคำนวณ เราจึงต้องมาคิดถึงวิธีการเลือกเครื่องมือสืบค้นข้อมูล มีตัวเลือกไม่มากนัก ทางเลือกที่เราพิจารณาคือ

• Trino: โปรแกรมสืบค้น SQL

• โอมเพี้ยง: SQL Query Engine

• Kyuubi: Serverless Spark SQL
  สิ่งที่สำคัญที่สุดที่เราพิจารณาก่อนที่จะลงลึกไปกว่านั้นก็คือ เครื่องมือคิวรีในอนาคตจะต้องเข้ากันได้กับสถาปัตยกรรมปัจจุบันของเรา

• เพื่อรองรับ Bigquery เป็นแหล่งข้อมูล

• เพื่อรองรับ DBT ซึ่งเราพึ่งพาเมตริกจำนวนมากที่จะผลิต

• เพื่อรองรับ metabase ของเครื่องมือ BI
  จากข้อมูลข้างต้น เราเลือก Trino ซึ่งรองรับ Iceberg ได้ดีมาก และทีมก็ตอบสนองได้ดีจนพบจุดบกพร่อง ซึ่งได้รับการแก้ไขในวันรุ่งขึ้นและเผยแพร่เป็นเวอร์ชันล่าสุดในสัปดาห์ต่อมา นี่เป็นตัวเลือกที่ดีที่สุดสำหรับทีม Footprint ซึ่งต้องการการตอบสนองในระดับสูงเช่นกัน

การทดสอบประสิทธิภาพ

เมื่อเราตัดสินใจเลือกทิศทางได้แล้ว เราได้ทำการทดสอบประสิทธิภาพของชุดค่าผสม Trino + Iceberg เพื่อดูว่าสามารถตอบสนองความต้องการของเราได้หรือไม่ และที่เราประหลาดใจก็คือข้อความค้นหานั้นรวดเร็วอย่างไม่น่าเชื่อ

เมื่อรู้ว่า Presto + Hive เป็นตัวเปรียบเทียบที่แย่ที่สุดในรอบหลายปีของโฆษณา OLAP การรวมกันของ Trino + Iceberg ทำให้เราทึ่งไปเลย

นี่คือผลการทดสอบของเรา

• กรณีที่ 1 : รวมชุดข้อมูลขนาดใหญ่

  table1 ขนาด 800 GB รวมกับ table2 อีก 50 GB และทำการคำนวณทางธุรกิจที่ซับซ้อน

• กรณีที่ 2: ใช้ตารางเดียวขนาดใหญ่เพื่อทำการค้นหาที่แตกต่างกัน

  ทดสอบ sql : เลือกความแตกต่าง (ที่อยู่) จากกลุ่มตารางตามวัน

Trino+Iceberg รวมกันเร็วกว่า Doris ประมาณ 3 เท่าในการกำหนดค่าเดียวกัน

นอกจากนี้ยังมีเซอร์ไพรส์อีกอย่างคือ Iceberg สามารถใช้รูปแบบข้อมูล เช่น Parquet, ORC เป็นต้น ซึ่งจะบีบอัดข้อมูลและจัดเก็บ ที่เก็บข้อมูลตารางของ Iceberg ใช้พื้นที่เพียง 1/5 ของพื้นที่เก็บข้อมูลอื่น ๆ ขนาดที่เก็บข้อมูลของตารางเดียวกันในฐานข้อมูลทั้งสามมีดังนี้:

หมายเหตุ: การทดสอบข้างต้นเป็นตัวอย่างที่เราพบในการผลิตจริงและใช้สำหรับการอ้างอิงเท่านั้น

・ผลการอัพเกรด

รายงานการทดสอบประสิทธิภาพทำให้เราได้รับประสิทธิภาพเพียงพอที่ทีมของเราใช้เวลาประมาณ 2 เดือนในการย้ายข้อมูลให้เสร็จสมบูรณ์ และนี่คือไดอะแกรมของสถาปัตยกรรมของเราหลังการอัปเกรด

• เอ็นจิ้นคอมพิวเตอร์หลายตัวที่ตรงกับความต้องการที่หลากหลายของเรา

• Trino รองรับ DBT สามารถค้นหา Iceberg ได้โดยตรง ดังนั้นเราจึงไม่ต้องจัดการกับการซิงโครไนซ์ข้อมูลอีกต่อไป

• ประสิทธิภาพที่น่าทึ่งของ Trino + Iceberg ทำให้เราสามารถเปิดเผยข้อมูล Bronze (ข้อมูลดิบ) ทั้งหมดแก่ผู้ใช้ของเรา

  สรุป

นับตั้งแต่เปิดตัวในเดือนสิงหาคม 2021 ทีม Footprint Analytics ได้เสร็จสิ้นการอัปเกรดสถาปัตยกรรม 3 รายการภายในเวลาไม่ถึงปีครึ่ง ด้วยความต้องการและความมุ่งมั่นที่จะนำประโยชน์ของเทคโนโลยีฐานข้อมูลที่ดีที่สุดมาสู่ผู้ใช้ crypto และการดำเนินการที่มั่นคงในการนำไปใช้งาน และการอัปเกรดโครงสร้างพื้นฐานและสถาปัตยกรรมพื้นฐาน

การอัปเกรดสถาปัตยกรรม Footprint Analytics 3.0 ได้ซื้อประสบการณ์ใหม่ให้กับผู้ใช้ ทำให้ผู้ใช้จากภูมิหลังที่แตกต่างกันได้รับข้อมูลเชิงลึกในการใช้งานและแอปพลิเคชันที่หลากหลายมากขึ้น:

• สร้างด้วยเครื่องมือ Metabase BI, Footprint ช่วยให้นักวิเคราะห์สามารถเข้าถึงข้อมูลบนเครือข่ายที่ถอดรหัสแล้ว, สำรวจด้วยอิสระอย่างเต็มที่ในการเลือกใช้เครื่องมือ (ไม่ใช้โค้ดหรือฮาร์ดคอร์ด), สืบค้นประวัติทั้งหมด, ตรวจสอบชุดข้อมูลแบบไขว้ เวลา.

• รวมข้อมูลทั้งแบบ on-chain และ off-chain เพื่อการวิเคราะห์ทั่วทั้ง web2 + web3;

• ด้วยการสร้าง / คิวรี่เมตริกที่ด้านบนของสิ่งที่เป็นนามธรรมทางธุรกิจของ Footprint นักวิเคราะห์หรือนักพัฒนาประหยัดเวลา 80% ของงานประมวลผลข้อมูลซ้ำ ๆ และมุ่งเน้นไปที่เมตริกที่มีความหมาย การวิจัยและโซลูชันผลิตภัณฑ์ตามธุรกิจของตน

• ประสบการณ์ที่ราบรื่นตั้งแต่ Footprint Web ไปจนถึงการเรียก REST API ทั้งหมดนี้ใช้ SQL

• การแจ้งเตือนตามเวลาจริงและการแจ้งเตือนที่ดำเนินการได้เกี่ยวกับสัญญาณสำคัญเพื่อสนับสนุนการตัดสินใจลงทุน