สแต็กข้อมูลโอเพ่นซอร์สที่ทันสมัยสำหรับบล็อกเชน

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

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

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

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

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

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

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

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

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

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

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

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

ดังนั้นเราจึงตัดสินใจที่จะสำรวจสถาปัตยกรรมทางเลือกอื่นๆ

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

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

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

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

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

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

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

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

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

4.1. บทนำของทะเลสาบข้อมูล

อันดับแรก เราหันมาสนใจที่ 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

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

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

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

• เพื่อรองรับ Bigquery เป็นแหล่งข้อมูล
• เพื่อรองรับ DBT ซึ่งเราพึ่งพาเมตริกจำนวนมากที่จะผลิต
• เพื่อรองรับ metabase ของเครื่องมือ BI

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

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

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

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

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

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

table800 ขนาด 1 GB รวมกับ table50 อีก 2 GB และทำการคำนวณทางธุรกิจที่ซับซ้อน

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

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

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

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

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

4.4. อัพเกรดเอฟเฟกต์

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

• เอ็นจิ้นคอมพิวเตอร์หลายตัวที่ตรงกับความต้องการที่หลากหลายของเรา
• Trino รองรับ DBT และสามารถค้นหา Iceberg ได้โดยตรง ดังนั้นเราจึงไม่ต้องจัดการกับการซิงโครไนซ์ข้อมูลอีกต่อไป
• ประสิทธิภาพที่น่าทึ่งของ Trino + Iceberg ช่วยให้เราสามารถเปิดข้อมูล Bronze (ข้อมูลดิบ) ทั้งหมดให้กับผู้ใช้ของเราได้

5 สรุป

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

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

• Footprint สร้างขึ้นด้วยเครื่องมือ Metabase BI ช่วยให้นักวิเคราะห์สามารถเข้าถึงข้อมูลบนเครือข่ายที่ถอดรหัสแล้ว สำรวจด้วยอิสระอย่างเต็มที่ในการเลือกใช้เครื่องมือ (ไม่มีโค้ดหรือฮาร์ดคอร์ด) สอบถามประวัติทั้งหมด และตรวจสอบชุดข้อมูลเพื่อรับข้อมูลเชิงลึก ไม่มีเวลา.
• รวมข้อมูลทั้งแบบ on-chain และ off-chain เพื่อการวิเคราะห์ทั่วทั้ง web2 + web3;
• ด้วยการสร้าง / คิวรี่เมตริกที่ด้านบนของสิ่งที่เป็นนามธรรมทางธุรกิจของ Footprint นักวิเคราะห์หรือนักพัฒนาประหยัดเวลา 80% ของงานประมวลผลข้อมูลซ้ำ ๆ และมุ่งเน้นไปที่เมตริกที่มีความหมาย การวิจัย และโซลูชันผลิตภัณฑ์ตามธุรกิจของตน
• ประสบการณ์ที่ราบรื่นตั้งแต่ Footprint Web ไปจนถึงการเรียก REST API ทั้งหมดนี้ใช้ SQL
• การแจ้งเตือนตามเวลาจริงและการแจ้งเตือนที่ดำเนินการได้เกี่ยวกับสัญญาณสำคัญเพื่อสนับสนุนการตัดสินใจลงทุน