معالجة الدفق باستخدام Azure Databricks

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

يتوفر تنفيذ مرجعي لهذه البنية على GitHub.

بناء الأنظمة

قم بتنزيل ملف Visio لهذه البنية.

‏‏سير العمل‬

تتكون البنية من المكونات التالية:

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

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

Azure Databricks. Azure Databricks هي عبارة عن نظام أساسي للتحليلات قائم على Apache Spark تم تحسينه للنظام الأساسي لخدمات سحابة Microsoft Azure. يتم استخدام Databricks لربط بيانات ركوب سيارة الأجرة وأجرتها، وأيضاً لإثراء البيانات المرتبطة ببيانات الحي المخزنة في نظام ملفات Databricks.

قاعدة بيانات Azure Cosmos. إخراج وظيفة Azure Databricks هو سلسلة من السجلات، والتي تتم كتابتها إلى Azure Cosmos DB ل Apache Cassandra. يتم استخدام Azure Cosmos DB ل Apache Cassandra لأنه يدعم نمذجة بيانات السلسلة الزمنية.

• يتيح لك ارتباط Azure Synapse لـ Azure Cosmos DB تشغيل تحليلات في الوقت الحقيقي تقريباً على البيانات التشغيلية في Azure Cosmos DB، دون أي تأثير على الأداء أو التكلفة على أحمال العمل الخاصة بالعمليات، باستخدام يتوفر محركان للتحليل من مساحة عمل Azure Synapse: SQL Serverless وSpark Pools.

Azure Log Analytics. يتم تخزين بيانات سجل التطبيقات التي تم جمعها بواسطة مراقبة Azure في مساحة عمل Log Analytics. يمكن استخدام استعلامات Log Analytics لتحليل المقاييس وتصورها وفحص رسائل السجل لتحديد المشكلات داخل التطبيق.

البدائل

• Synapse Link هو الحل المفضل من Microsoft للتحليليات أعلى بيانات Azure Cosmos DB.

تفاصيل السيناريو

السيناريو: تجمع شركة سيارات الأجرة بيانات حول كل رحلة تاكسي. بالنسبة لهذا السيناريو، نفترض وجود جهازين منفصلين يرسلان البيانات. يوجد في سيارة الأجرة عداد يرسل معلومات حول كل رحلة - المدة، والمسافة، ومواقع الالتقاء والتوصيل. يقبل جهاز منفصل المدفوعات من العملاء ويرسل بيانات حول الأسعار. لاكتشاف اتجاهات ركوب الدراجات، تريد شركة سيارات الأجرة حساب متوسط البقشيش لكل ميل مدفوع، في الوقت الحقيقي، لكل حي.

حالات الاستخدام المحتملة

تم تحسين هذا الحل لصناعة البيع بالتجزئة.

احتواء البيانات

لمحاكاة مصدر بيانات، تستخدم هذه البنية المرجعية مجموعة بيانات سيارات الأجرة في مدينة نيويورك رقم ^[1]. تحتوي مجموعة البيانات هذه على بيانات حول رحلات سيارات الأجرة في مدينة نيويورك على مدار أربع سنوات (2010-2013). يحتوي على نوعين من السجلات: بيانات الركوب وبيانات الأجرة. تتضمن بيانات الرحلة مدة الرحلة، ومسافة الرحلة، وموقع الالتقاء والتوصيل. تتضمن بيانات الأجرة مبالغ الأجرة والضرائب والإكرامية. تتضمن الحقول الشائعة في كلا نوعي السجلات رقم لوحة السيارة ورخصة القيادة وبطاقة هوية المورد. تحدد هذه الحقول الثلاثة معاً بشكل فريد سيارة الأجرة بالإضافة إلى السائق. يتم تخزين البيانات بتنسيق CSV.

[1] دونوفان، بريان؛ العمل، دان (2016): بيانات رحلة تاكسي مدينة نيويورك (2010-2013). جامعة إلينوي في أوربانا شامبين. https://doi.org/10.13012/J8PN93H8

منشئ البيانات هو تطبيق ‎.NET Core يقرأ السجلات ويرسلها إلى مراكز الأحداث. يرسل المنشئ بيانات الركوب بتنسيق JSON وبيانات الأجرة بتنسيق CSV.

تستخدم مراكز الأحداث أقسامًا لتقسيم البيانات. تسمح الأقسام للمستهلك بقراءة كل قسم على التوازي. عند إرسال البيانات إلى مراكز الأحداث (مراكز الأحداث)، يمكنك تحديد مفتاح القسم بشكل صريح. وبخلاف ذلك، يتم تعيين السجلات إلى أقسام بأسلوب round-robin.

في هذا السيناريو، يجب أن تنتهي بيانات الركوب وبيانات الأجرة بنفس معرف القسم لكابينة تاكسي معينة. وهذا يمكن Databricks من تطبيق درجة من التوازي عندما تربط بين الدفقين. سيتطابق السجل الموجود في القسم و من بيانات الرحلة مع السجل الموجود في القسم و بيانات الأجرة.

قم بتنزيل ملف Visio لهذه البنية.

في منشئ البيانات، يحتوي نموذج البيانات المشترك لكلا نوعي السجلات على خاصية PartitionKey وهي عبارة عن تسلسل Medallion وHackLicense وVendorId.

public abstract class TaxiData
{
    public TaxiData()
    {
    }

    [JsonProperty]
    public long Medallion { get; set; }

    [JsonProperty]
    public long HackLicense { get; set; }

    [JsonProperty]
    public string VendorId { get; set; }

    [JsonProperty]
    public DateTimeOffset PickupTime { get; set; }

    [JsonIgnore]
    public string PartitionKey
    {
        get => $"{Medallion}_{HackLicense}_{VendorId}";
    }

تُستخدم هذه الخاصية لتوفير مفتاح قسم صريح عند الإرسال إلى مراكز الأحداث:

using (var client = pool.GetObject())
{
    return client.Value.SendAsync(new EventData(Encoding.UTF8.GetBytes(
        t.GetData(dataFormat))), t.PartitionKey);
}

مراكز الأحداث

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

المعالجة المتدفقة

في Azure Databricks، يتم تنفيذ معالجة البيانات بواسطة وظيفة. يتم تعيين المهمة إلى وتشغيلها على نظام مجموعة. يمكن أن تكون المهمة إما تعليمة برمجية مخصصة مكتوبة بلغة Java، أو دفتر ملاحظات Spark.

في هذه البنية المرجعية، تعد الوظيفة أرشيف Java مع فئات مكتوبة بلغتي Java وScala. عند تحديد أرشيف Java لوظيفة Databricks، يتم تحديد الفئة للتنفيذ بواسطة مجموعة Databricks. هنا، main يحتوي أسلوب com.microsoft.pnp.TaxiCabReader الفئة على منطق معالجة البيانات.

قراءة الدفق من مثيلي مركز الأحداث

يستخدم منطق معالجة البيانات دفق Spark المنظم للقراءة من مثيلي مركز أحداث Azure:

// Create a token credential using Managed Identity
val credential = new DefaultAzureCredentialBuilder().build()

val rideEventHubOptions = EventHubsConf(rideEventHubEntraIdAuthConnectionString)
  .setTokenProvider(EventHubsUtils.buildTokenProvider(..., credential))
  .setConsumerGroup(conf.taxiRideConsumerGroup())
  .setStartingPosition(EventPosition.fromStartOfStream)
val rideEvents = spark.readStream
  .format("eventhubs")
  .options(rideEventHubOptions.toMap)
  .load

val fareEventHubOptions = EventHubsConf(fareEventHubEntraIdAuthConnectionString)
  .setTokenProvider(EventHubsUtils.buildTokenProvider(..., credential))
  .setConsumerGroup(conf.taxiFareConsumerGroup())
  .setStartingPosition(EventPosition.fromStartOfStream)
val fareEvents = spark.readStream
  .format("eventhubs")
  .options(fareEventHubOptions.toMap)
  .load

إثراء البيانات بمعلومات الحي

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

يعد تنسيق الملف الشكلي ثنائيًا، ولا يتم تحليله بسهولة، ولكن توفر مكتبة GeoTools أدوات للموضع الجيوفضائي التي تستخدم تنسيق الملف الشكلي. تستخدم هذه المكتبة com.microsoft.pnp.GeoFinder في الفئة لتحديد اسم الحي استنادا إلى إحداثيات الاستلام والإفلات.

val neighborhoodFinder = (lon: Double, lat: Double) => {
      NeighborhoodFinder.getNeighborhood(lon, lat).get()
    }

الانضمام إلى بيانات الرحلات والأجور

أولاً، يتم تحويل بيانات الركوب والأجرة:

val rides = transformedRides
  .filter(r => {
    if (r.isNullAt(r.fieldIndex("errorMessage"))) {
      true
    }
    else {
      malformedRides.add(1)
      false
    }
  })
  .select(
    $"ride.*",
    to_neighborhood($"ride.pickupLon", $"ride.pickupLat")
      .as("pickupNeighborhood"),
    to_neighborhood($"ride.dropoffLon", $"ride.dropoffLat")
      .as("dropoffNeighborhood")
  )
  .withWatermark("pickupTime", conf.taxiRideWatermarkInterval())

val fares = transformedFares
  .filter(r => {
    if (r.isNullAt(r.fieldIndex("errorMessage"))) {
      true
    }
    else {
      malformedFares.add(1)
      false
    }
  })
  .select(
    $"fare.*",
    $"pickupTime"
  )
  .withWatermark("pickupTime", conf.taxiFareWatermarkInterval())

ثم يتم ربط بيانات الركوب ببيانات الأجرة:

val mergedTaxiTrip = rides.join(fares, Seq("medallion", "hackLicense", "vendorId", "pickupTime"))

معالجة البيانات وإدراجها في Azure Cosmos DB

يتم حساب متوسط مبلغ الأجرة لكل حي لفترة زمنية معينة:

val maxAvgFarePerNeighborhood = mergedTaxiTrip.selectExpr("medallion", "hackLicense", "vendorId", "pickupTime", "rateCode", "storeAndForwardFlag", "dropoffTime", "passengerCount", "tripTimeInSeconds", "tripDistanceInMiles", "pickupLon", "pickupLat", "dropoffLon", "dropoffLat", "paymentType", "fareAmount", "surcharge", "mtaTax", "tipAmount", "tollsAmount", "totalAmount", "pickupNeighborhood", "dropoffNeighborhood")
      .groupBy(window($"pickupTime", conf.windowInterval()), $"pickupNeighborhood")
      .agg(
        count("*").as("rideCount"),
        sum($"fareAmount").as("totalFareAmount"),
        sum($"tipAmount").as("totalTipAmount"),
        (sum($"fareAmount")/count("*")).as("averageFareAmount"),
        (sum($"tipAmount")/count("*")).as("averageTipAmount")
      )
      .select($"window.start", $"window.end", $"pickupNeighborhood", $"rideCount", $"totalFareAmount", $"totalTipAmount", $"averageFareAmount", $"averageTipAmount")

الذي يتم إدراجه بعد ذلك في Azure Cosmos DB:

maxAvgFarePerNeighborhood
      .writeStream
      .queryName("maxAvgFarePerNeighborhood_cassandra_insert")
      .outputMode(OutputMode.Append())
      .foreach(new CassandraSinkForeach(connector))
      .start()
      .awaitTermination()

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

الأمان

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

يتم التحكم في الوصول إلى مساحة عمل Azure Databricks باستخدام وحدة تحكم المسؤول. تتضمن وحدة تحكم المسؤول وظائف لإضافة مستخدمين وإدارة أذونات المستخدم وإعداد تسجيل الدخول الأحادي. يمكن أيضاً تعيين التحكم في الوصول لمساحات العمل، والمجموعات، والمهام، والجداول من خلال وحدة تحكم المسؤول.

إدارة البيانات السرية

يتضمن Azure Databricks مخزنا سريا يستخدم لتخزين بيانات الاعتماد والإشارة إليها في دفاتر الملاحظات والوظائف. يتم تقسيم البيانات السرية داخل مخزن البيانات السرية لـ Azure Databricks حسب النطاقات:

databricks secrets create-scope --scope "azure-databricks-job"

تتم إضافة البيانات السرية على مستوى النطاق:

databricks secrets put --scope "azure-databricks-job" --key "taxi-ride"

في التعليمات البرمجية، يتم الوصول إلى البيانات السرية عبر الأدوات المساعدة للبيانات السرية لـ Azure Databricks.

مراقبة‬

يستند Azure Databricks إلى Apache Spark، ويستخدم كلاهما log4j كمكتبة قياسية للتسجيل. بالإضافة إلى التسجيل الافتراضي الذي يوفره Apache Spark، يمكنك تنفيذ التسجيل إلى Azure Log Analytics باتباع المقالة مراقبة Azure Databricks.

نظرا لأن com.microsoft.pnp.TaxiCabReader الفئة تعالج رسائل الركوب والأي أجرة، فمن الممكن أن يكون أي منهما مشوه وبالتالي غير صالح. في بيئة التشغيل، من المهم تحليل هذه الرسائل التي تم تكوينها بشكل غير صحيح لتحديد مشكلة في مصادر البيانات حتى يمكن إصلاحها بسرعة لمنع فقدان البيانات. تسجل com.microsoft.pnp.TaxiCabReader الفئة Apache Spark Accumulator الذي يتعقب عدد سجلات الأجرة والركوب التي تم تكوينها بشكل غير صحيح:

@transient val appMetrics = new AppMetrics(spark.sparkContext)
appMetrics.registerGauge("metrics.malformedrides", AppAccumulators.getRideInstance(spark.sparkContext))
appMetrics.registerGauge("metrics.malformedfares", AppAccumulators.getFareInstance(spark.sparkContext))
SparkEnv.get.metricsSystem.registerSource(appMetrics)

يستخدم Apache Spark مكتبة Dropwizard لإرسال المقاييس، وبعض حقول مقاييس Dropwizard الأصلية غير متوافقة مع Azure Log Analytics. لذلك، تتضمن هذه البنية المرجعية متلقي Dropwizard مخصصًا ومراسلاً. يقوم بتنسيق المقاييس بالتنسيق المتوقع من Azure Log Analytics. عندما يقوم Apache Spark بالإبلاغ عن المقاييس، يتم أيضاً إرسال المقاييس المخصصة لبيانات الرحلة والأجرة التي تم تكوينها بشكل غير جيد.

فيما يلي أمثلة على الاستعلامات التي يمكنك استخدامها في مساحة عمل Azure Log Analytics لمراقبة تنفيذ مهمة الدفق. سترجع الوسيطة ago(1d) في كل استعلام كافة السجلات التي تم إنشاؤها في اليوم الأخير، ويمكن تعديلها لعرض فترة زمنية مختلفة.

الاستثناءات التي تم تسجيلها أثناء تنفيذ استعلام الدفق

SparkLoggingEvent_CL
| where TimeGenerated > ago(1d)
| where Level == "ERROR"

تراكم بيانات الأجرة والركوب غير المنسقة بشكل جيد

SparkMetric_CL
| where TimeGenerated > ago(1d)
| where name_s contains "metrics.malformedrides"
| project value_d, TimeGenerated, applicationId_s
| render timechart

SparkMetric_CL
| where TimeGenerated > ago(1d)
| where name_s contains "metrics.malformedfares"
| project value_d, TimeGenerated, applicationId_s
| render timechart

تنفيذ المهمة بمرور الوقت

SparkMetric_CL
| where TimeGenerated > ago(1d)
| where name_s contains "driver.DAGScheduler.job.allJobs"
| project value_d, TimeGenerated, applicationId_s
| render timechart

لمزيد من المعلومات، راجع مراقبة Azure Databricks.

DevOps

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

• استخدم قالب Azure Resource Manager لتوزيع موارد Azure باتباع عملية البنية الأساسية كتعليمة برمجية (IaC). باستخدام القوالب، تكون أتمتة عمليات التوزيع باستخدام خدمات Azure DevOpsأو حلول CI / CD الأخرى أسهل.

• ضع كل حمل عمل في قالب توزيع منفصل، وقم بتخزين الموارد في أنظمة التحكم بالمصادر. يمكنك توزيع القوالب معاً أو بشكل فردي كجزء من عملية CI/CD، مما يجعل عملية الأتمتة أسهل.

  في هذه البنية، يتم تحديد Azure Event Hubs وLog Analytics وAzure Cosmos DB على أنها حمل عمل واحد. يتم تضمين هذه الموارد في قالب ARM واحد.

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

  في هذه البنية هناك مراحل توزيع متعددة. ضع في اعتبارك إنشاء Azure DevOps Pipeline وإضافة هذه المراحل. فيما يلي بعض الأمثلة على المراحل التي يمكنك أتمتتها:

  • بدء نظام مجموعة Databricks
  • تكوين Databricks CLI
  • تثبيت Scala Tools
  • إضافة بيانات Databricks السرية

  أيضاً، ضع في اعتبارك كتابة اختبارات التكامل التلقائي لتحسين جودة وموثوقية التعليمات البرمجية لـ Databricks ودورة حياتها.

• ضع في اعتبارك استخدام Azure Monitor لتحليل أداء مسار معالجة التدفق. لمزيد من المعلومات، راجع مراقبة Azure Databricks.

لمزيد من المعلومات، راجع قسم DevOps في Microsoft Azure Well-Architected Framework.

تحسين التكلفة

يركز تحسين التكلفة على البحث عن طرق للحد من النفقات غير الضرورية وتحسين الكفاءة التشغيلية. لمزيد من المعلومات، راجع نظرة عامة على ركيزة تحسين التكلفة.

استخدم حاسبة تسعير Azure لتقدير التكاليف. فيما يلي بعض الاعتبارات للخدمات المستخدمة في هذه البنية المرجعية.

مراكز الأحداث

تنشر هذه البنية المرجعية مراكز الأحداث في المستوى القياسي. يستند نموذج الأسعار إلى وحدات معدل النقل وأحداث الدخول وتسجيل الأحداث. حدث الدخول هو وحدة بيانات 64 كيلوبايت أو أقل. تتم فوترة الرسائل الأكبر بمضاعفات 64 كيلوبايت. يمكنك تحديد وحدات معدل النقل إما من خلال مدخل Microsoft Azure أو واجهات برمجة تطبيقات إدارة مراكز الأحداث.

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

تتم أيضا فوترة المستوى القياسي استناداً إلى أحداث الدخول ووحدات معدل النقل.

للحصول على معلومات حول أسعار مراكز الأحداث، راجع أسعار مراكز الأحداث.

Azure Databricks

يوفر Azure Databricks مستويين Standard وPremium، يدعم كل منهما ثلاثة أحمال عمل. توزع هذه البنية المرجعية مساحة عمل Azure Databricks في المستوى Premium.

أحمال عمل هندسة البيانات ووهندسة البيانات الخفيفة مخصصة لمهندسي البيانات لإنشاء المهام وتنفيذها. تم تصميم حمل عمل تحليلات البيانات لعلماء البيانات لاستكشاف البيانات والرؤى وتصورها ومعالجتها ومشاركتها بشكل تفاعلي.

تقدم Azure Databricks العديد من نماذج الأسعار.

• خطة الدفع حسب الاستخدام

  تتم محاسبتك على الأجهزة الظاهرية المتوفرة في أنظمة المجموعات ووحدات Databricks (DBUs) استناداً إلى مثيل الجهاز الظاهري المحدد. وحدات Databricks هي وحدة من قدرات المعالجة، تتم فوترتها بالاستخدام في الثانية. يعتمد استهلاك وحدات Databricks على حجم ونوع المثيل الذي يقوم بتشغيل Azure Databricks. تعتمد الأسعار على حمل العمل المحدد والمستوى المحدد.

• خطة ما قبل الشراء

  يمكنك الالتزام بوحدات Azure Databricks (DBU) كوحدات تثبيت Databricks (DBCU) لمدة عام أو ثلاث سنوات. بالمقارنة مع نموذج الدفع أولاً بأول، يمكنك توفير ما يصل إلى 37%.

لمزيد من المعلومات، راجع ⁧⁩أسعار Azure Databricks⁩.

Azure Cosmos DB

في هذه البنية، تتم كتابة سلسلة من السجلات إلى Azure Cosmos DB بواسطة مهمة Azure Databricks. يتم تحصيل رسوم منك مقابل السعة التي تحتفظ بها، والتي يتم التعبير عنها في وحدات الطلب في الثانية (RU/s)، المستخدمة لتنفيذ عمليات الإدراج. وحدة الفوترة هي 100 وحدة طلب / في الثانية لكل ساعة. على سبيل المثال، تكلفة كتابة عناصر 100 كيلوبايت هي 50 وحدة طلب/ثانية.

بالنسبة لعمليات الكتابة، قم بتوفير سعة كافية لدعم عدد عمليات الكتابة المطلوبة في الثانية. يمكنك زيادة معدل النقل المقدم باستخدام المدخل أو Azure CLI قبل تنفيذ عمليات الكتابة، ثم تقليل معدل النقل بعد اكتمال هذه العمليات. معدل النقل لفترة الكتابة يشير إلى الحد الأدنى لمعدل النقل المطلوب للبيانات المحددة، بالإضافة إلى معدل النقل المطلوب لعملية الإدراج بافتراض عدم تشغيل أي حمل عمل آخر.

مثال لتحليل التكلفة

لنفترض أنك قمت بتكوين قيمة معدل نقل تبلغ 1000 وحدة طلب/ثانية على حاوية. يتم توزيعها لمدة 24 ساعة ولمدة 30 يوماً، بإجمالي 720 ساعة.

تتم فوترة الحاوية بـ 10 وحدات من إجمالي 100 وحدة طلب/ثانية في الساعة لكل ساعة. يتم دفع 0.08 دولار في الساعة على 10 وحدات بسعر 0.008 دولار (لكل 100 وحدة طلب/ثانية في الساعة).

لمدة 720 ساعة أو 7200 وحدة (من 100 وحدة طلب)، تتم محاسبتك على 57.60 دولار للشهر.

يتم أيضًا احتساب مساحة التخزين لكل غيغابايت مستخدمة لبياناتك وفهرسك المخزنين. لمزيد من المعلومات، راجع نموذج تسعير Azure Cosmos DB.

استخدم حاسبة سعة Azure Cosmos DB للحصول على تقدير سريع لتكلفة حمل العمل.

لمزيد من المعلومات، راجع قسم التكلفة في Microsoft Azure Well-Architected Framework.

نشر هذا السيناريو

لنشر وتشغيل التطبيق المرجعي، اتبع الخطوات في الملف التمهيدي GitHub.

الخطوة التالية

• معالجة الدفق باستخدام Azure Stream Analytics