Iceberg + Spark + Trino: مكدس بيانات حديث مفتوح المصدر لـ Blockchain

1. التحدي الذي يواجه مكدس بيانات blockchain الحديث

هناك العديد من التحديات التي قد تواجهها شركة ناشئة حديثة لفهرسة blockchain ، بما في ذلك:

• كميات هائلة من البيانات. مع زيادة كمية البيانات على blockchain ، سيحتاج فهرس البيانات إلى توسيع نطاقه للتعامل مع الحمل المتزايد وتوفير وصول فعال إلى البيانات. وبالتالي ، فإنه يؤدي إلى ارتفاع تكاليف التخزين ؛ بطء حساب المقاييس وزيادة الحمل على خادم قاعدة البيانات.
• خط أنابيب معالجة البيانات المعقدة. تعتبر تقنية Blockchain معقدة ، ويتطلب بناء فهرس بيانات شامل وموثوق فهمًا عميقًا لهياكل البيانات والخوارزميات الأساسية. موروث من خلال تنوع تطبيقات blockchain. بالنظر إلى أمثلة محددة ، يتم عادةً إنشاء NFTs في Ethereum ضمن عقود ذكية تتبع تنسيق ERC721 و ERC1155 ، في حين أن تنفيذ تلك الموجودة على Polkadot ، على سبيل المثال ، عادةً ما يتم إنشاؤه مباشرةً في وقت تشغيل blockchain. في نهاية اليوم ، يجب اعتبار هؤلاء على أنهم NFTs ويجب حفظهم على أنهم.
• قدرات التكامل. من أجل توفير أقصى قيمة للمستخدمين ، قد يحتاج حل فهرسة blockchain إلى دمج فهرس البيانات الخاص به مع أنظمة أخرى ، مثل منصات التحليلات أو واجهات برمجة التطبيقات. هذا يمثل تحديًا ويتطلب بذل جهد كبير في تصميم العمارة.

نظرًا لأن استخدام تقنية blockchain أصبح أكثر انتشارًا ، فقد زادت كمية البيانات المخزنة على blockchain. هذا لأن المزيد من الأشخاص يستخدمون التكنولوجيا ، وتضيف كل معاملة بيانات جديدة إلى blockchain. بالإضافة إلى ذلك ، تطور استخدام تقنية blockchain من تطبيقات تحويل الأموال البسيطة ، مثل تلك التي تتضمن استخدام Bitcoin ، إلى تطبيقات أكثر تعقيدًا تتضمن تنفيذ منطق الأعمال ضمن العقود الذكية. يمكن أن تولد هذه العقود الذكية كميات كبيرة من البيانات ، مما ساهم في زيادة تعقيد وحجم blockchain. بمرور الوقت ، أدى ذلك إلى كتلة سلسلة أكبر وأكثر تعقيدًا.

في هذه المقالة ، نستعرض تطور تحليلات البصمة & # x27 ؛ بنية التكنولوجيا على مراحل كدراسة حالة لاستكشاف كيفية معالجة مكدس تكنولوجيا Iceberg-Trino لتحديات البيانات على السلسلة.

قام Footprint Analytics بفهرسة حوالي 22 من بيانات blockchain العامة ، و 17 سوق NFT ، ومشروع 1900 GameFi ، وأكثر من 100000 مجموعة NFT في طبقة بيانات تجريد دلالية. إنه حل مستودع بيانات blockchain الأكثر شمولاً في العالم.

بغض النظر عن بيانات blockchain ، والتي تتضمن أكثر من 20 مليار صف من سجلات المعاملات المالية ، والتي كثيرًا ما يستفسر عنها محللو البيانات. إنها تختلف عن سجلات الإدخال في مستودعات البيانات التقليدية.

لقد شهدنا 3 ترقيات رئيسية في الأشهر العديدة الماضية لتلبية متطلبات العمل المتنامية:

2. العمارة 1.0 Bigquery

في بداية تحليلات البصمة ، استخدمناGoogle Bigqueryكمحرك التخزين والاستعلام لدينا ؛ BigQuery منتج رائع. إنه سريع للغاية وسهل الاستخدام ويوفر قوة حسابية ديناميكية وبنية UDF مرنة تساعدنا في إنجاز المهمة بسرعة.

ومع ذلك ، لدى Bigquery أيضًا عددًا من المشكلات.

• لا يتم ضغط البيانات ، مما يؤدي إلى ارتفاع تكاليف التخزين ، لا سيما عندما يتعلق الأمر بتخزين البيانات الأولية لأكثر من 22 بلوكتشين من تحليلات البصمة.
• التزامن غير الكافي: لا يدعم 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 جبل الجليد + ترينو

مرحبًا بك في Footprint Analytics architecture 3.0 ، إصلاح شامل للبنية الأساسية. لقد أعدنا تصميم الهيكل بأكمله من الألف إلى الياء ، لفصل التخزين والحساب والاستعلام عن البيانات إلى ثلاث قطع مختلفة. أخذ الدروس من البنيتين السابقتين لتحليلات البصمة ، والتعلم من تجربة مشاريع البيانات الضخمة الناجحة الأخرى مثل Uber و Netflix و Databricks.

4.1 مقدمة من بحيرة البيانات

وجهنا انتباهنا أولاً إلى بحيرة البيانات ، وهي نوع جديد من تخزين البيانات لكل من البيانات المهيكلة وغير المهيكلة. تعتبر بحيرة البيانات مثالية لتخزين البيانات على السلسلة حيث أن تنسيقات البيانات على السلسلة تتراوح على نطاق واسع من البيانات الأولية غير المنظمة إلى بيانات التجريد المنظمة. توقعنا استخدام بحيرة البيانات لحل مشكلة تخزين البيانات ، ومن الناحية المثالية سيدعم أيضًا محركات الحوسبة السائدة مثل Spark و Flink ، بحيث لا يكون من الصعب التكامل مع أنواع مختلفة من محركات المعالجة مع تطور Footprint Analytics .

يتكامل Iceberg جيدًا مع محركات Spark و Flink و Trino وغيرها من المحركات الحاسوبية ، ويمكننا اختيار الحساب الأنسب لكل من مقاييسنا. على سبيل المثال:

• بالنسبة لأولئك الذين يحتاجون إلى منطق حسابي معقد ، سيكون Spark هو الخيار.
• Flink للحساب في الوقت الحقيقي.
• بالنسبة لمهام ETL البسيطة التي يمكن إجراؤها باستخدام SQL ، نستخدم Trino.

4.2 محرك الاستعلام

مع حل Iceberg لمشاكل التخزين والحساب ، كان علينا بعد ذلك التفكير في كيفية اختيار محرك استعلام. لا توجد العديد من الخيارات المتاحة ، والبدائل التي اعتبرناها كانت كذلك

• تريون: محرك استعلام SQL
• هكذا: محرك استعلام SQL
• كيوبي: سبارك SQL Serverless

كان أهم شيء أخذناه في الاعتبار قبل التعمق أكثر هو أن محرك الاستعلام المستقبلي يجب أن يكون متوافقًا مع بنيتنا الحالية.

• لدعم BigQuery كمصدر بيانات
• لدعم DBT ، الذي نعتمد عليه في إنتاج العديد من المقاييس
• لدعم قاعدة تعريف أداة BI

بناءً على ما سبق ، اخترنا Trino ، التي تتمتع بدعم جيد للغاية لـ Iceberg وكان الفريق متجاوبًا للغاية لدرجة أننا طرحنا خطأً ، تم إصلاحه في اليوم التالي وتم إصداره إلى أحدث إصدار في الأسبوع التالي. كان هذا بالتأكيد الخيار الأفضل لفريق Footprint ، الذي يتطلب أيضًا استجابة عالية للتنفيذ.

4.3 اختبار أداء

بمجرد أن قررنا اتجاهنا ، أجرينا اختبارًا للأداء على تركيبة Trino + Iceberg لمعرفة ما إذا كان يمكن أن يلبي احتياجاتنا ولدهشتنا ، كانت الاستفسارات سريعة بشكل لا يصدق.

مع العلم أن Presto + Hive كان أسوأ مقارنة لسنوات في كل ضجيج OLAP ، فجر مزيج Trino + Iceberg تمامًا عقولنا.

ها هي نتائج اختباراتنا.

الحالة 1: انضم إلى مجموعة بيانات كبيرة

ينضم جدول 1 بسعة 800 غيغابايت إلى جدول 2 آخر بسعة 50 غيغابايت ويقوم بحسابات أعمال معقدة

case2: استخدم جدولًا واحدًا كبيرًا لإجراء استعلام مميز

اختبار sql: حدد (عنوان) مميزًا من مجموعة الجدول حسب اليوم

مزيج Trino + Iceberg أسرع بحوالي 3 مرات من Doris في نفس التكوين.

بالإضافة إلى ذلك ، هناك مفاجأة أخرى ، لأن Iceberg يمكنه استخدام تنسيقات البيانات مثل Parquet و ORC وما إلى ذلك ، والتي ستضغط البيانات وتخزينها. يستغرق تخزين الجدول Iceberg حوالي 1/5 من مساحة مستودعات البيانات الأخرى ، ويكون حجم تخزين نفس الجدول في قواعد البيانات الثلاث كما يلي:

4.4 تأثير الترقية

أعطتنا تقارير اختبار الأداء أداءً كافيًا استغرق فريقنا حوالي شهرين لإكمال الترحيل ، وهذا رسم تخطيطي لبنيتنا بعد الترقية.

• تتناسب محركات الكمبيوتر المتعددة مع احتياجاتنا المختلفة.
• يدعم Trino DBT ، ويمكنه الاستعلام عن Iceberg مباشرة ، لذلك لم نعد مضطرًا للتعامل مع مزامنة البيانات.
• يسمح لنا الأداء المذهل لـ Trino + Iceberg بفتح جميع البيانات البرونزية (البيانات الأولية) لمستخدمينا.

5. ملخص

منذ إطلاقه في أغسطس 2021 ، أكمل فريق Footprint Analytics ثلاث ترقيات معمارية في أقل من عام ونصف ، وذلك بفضل رغبته القوية وتصميمه على جلب فوائد أفضل تكنولوجيا قواعد البيانات لمستخدمي التشفير ، والتنفيذ القوي عند التنفيذ. وتحديث بنيتها التحتية الأساسية وبنيتها.

اشترت ترقية البنية 3.0 لـ Footprint Analytics تجربة جديدة لمستخدميها ، مما يسمح للمستخدمين من خلفيات مختلفة بالحصول على رؤى حول استخدامات وتطبيقات أكثر تنوعًا:

• تم تصميمه باستخدام أداة Metabase BI ، ويسهل Footprint المحللين الوصول إلى البيانات على السلسلة التي تم فك تشفيرها ، والاستكشاف بحرية كاملة في اختيار الأدوات (بدون رمز أو بطاقة ثابتة) ، والاستعلام عن السجل بالكامل ، وفحص مجموعات البيانات ، للحصول على رؤى في no- الوقت.
• دمج كل من البيانات داخل السلسلة وخارجها للتحليل عبر web2 + web3 ؛
• من خلال بناء / مقاييس الاستعلام فوق تجريد الأعمال في Footprint ، يوفر المحللون أو المطورون الوقت في 80٪ من أعمال معالجة البيانات المتكررة والتركيز على المقاييس ذات المغزى والبحث وحلول المنتجات بناءً على أعمالهم.
• تجربة سلسة من Footprint Web إلى مكالمات REST API ، وكلها تستند إلى SQL
• تنبيهات في الوقت الفعلي وإخطارات قابلة للتنفيذ بشأن الإشارات الرئيسية لدعم قرارات الاستثمار