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

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

• كميات هائلة من البيانات. ومع زيادة كمية البيانات على بلوكتشين، سيحتاج مؤشر البيانات إلى التوسع للتعامل مع الحمل المتزايد وتوفير وصول فعال إلى البيانات. وبالتالي، يؤدي ذلك إلى ارتفاع تكاليف التخزين؛ وبطء حساب المقاييس وزيادة الحمل على خادم قاعدة البيانات.

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

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

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

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

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

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

استعلام كبير عن الهندسة المعمارية 1.0

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

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

• لا يتم ضغط البيانات، مما يؤدي إلى ارتفاع تكاليف التخزين، خاصة عندما يتعلق الأمر بتخزين البيانات الأولية لأكثر من 22 سلسلة بلوكشين من Footprint Analytics.

• التزامن غير الكافي: لا يدعم Bigquery سوى 100 استعلام متزامن، وهو أمر غير مناسب لسيناريوهات التزامن العالي لـ Footprint Analytics، عند خدمة عدد كبير من المحللين والمستخدمين.

• قم بتأمين الدخول باستخدام Google Bigquery، وهو منتج مغلق المصدر。
  لذلك قررنا استكشاف أبنية بديلة أخرى.

الهندسة المعمارية 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 كمحرك استعلام وحده لم يكن كافيًا بالنسبة لنا.

الهندسة المعمارية 3.0 جبل الجليد + ترينو

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

إدخال بحيرة البيانات

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

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

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

• Flink للحساب في الوقت الفعلي.

• بالنسبة لمهام ETL البسيطة التي يمكن تنفيذها باستخدام SQL، نستخدم Trino.

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

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

• ترينو: محرك استعلام SQL

• قريبا: محرك استعلام SQL

• Kyuubi: Serverless Spark SQL
  أهم شيء أخذناه في الاعتبار قبل التعمق هو أن محرك الاستعلام المستقبلي يجب أن يكون متوافقًا مع بنيتنا الحالية.

• لدعم Bigquery كمصدر بيانات

• لدعم DBT، الذي نعتمد عليه في إنتاج العديد من المقاييس

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

اختبار الأداء

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

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

فيما يلي نتائج اختباراتنا.

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

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

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

  Test sql: حدد (العنوان) المميز من مجموعة الجداول حسب اليوم

تعد تركيبة Trino+Iceberg أسرع بثلاث مرات تقريبًا من Doris في نفس التكوين.

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

ملاحظة: الاختبارات المذكورة أعلاه هي أمثلة فردية واجهناها في الإنتاج الفعلي وهي للإشارة فقط.

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

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

• تتوافق محركات الكمبيوتر المتعددة مع احتياجاتنا المختلفة.

• يدعم Trino DBT، ويمكنه الاستعلام عن Iceberg مباشرة، لذلك لم يعد علينا التعامل مع مزامنة البيانات.

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

  الملخص

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

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

• تم تصميم Footprint باستخدام أداة Metabase BI، مما يسهل على المحللين الوصول إلى البيانات الموجودة على السلسلة التي تم فك تشفيرها، والاستكشاف بحرية كاملة في اختيار الأدوات (بدون رمز أو سلك صلب)، والاستعلام عن السجل بأكمله، وفحص مجموعات البيانات، للحصول على رؤى في أي وقت من الأوقات.

• دمج البيانات داخل السلسلة وخارجها للتحليل عبر web2+web3؛

• من خلال بناء/الاستعلام عن المقاييس بالإضافة إلى ملخص أعمال Footprint، يوفر المحللون أو المطورون الوقت في 80٪ من أعمال معالجة البيانات المتكررة ويركزون على المقاييس الهادفة والأبحاث وحلول المنتجات بناءً على أعمالهم.

• تجربة سلسة من Footprint Web إلى مكالمات REST API، كل ذلك يعتمد على SQL

• تنبيهات في الوقت الفعلي وإشعارات قابلة للتنفيذ بشأن الإشارات الرئيسية لدعم قرارات الاستثمار