ترحيل البيانات مباشرة من Apache Cassandra إلى Azure Cosmos DB ل Apache Cassandra باستخدام وكيل الكتابة المزدوجة وApache Spark
أصبحت واجهة برمجة التطبيقات ل Cassandra في Azure Cosmos DB خيارا رائعا لأحمال عمل المؤسسات التي تعمل على Apache Cassandra لعدة أسباب مثل:
عدم وجود نفقات إضافية للإدارة والمراقبة: فهي تقضي على الحمل الزائد لإدارة ومراقبة عدد لا يحصى من الإعدادات عبر ملفات OS وJVM وyaml وتفاعلاتها.
توفير كبير في التكلفة: يمكنك توفير التكلفة باستخدام Azure Cosmos DB، والتي تتضمن تكلفة الأجهزة الظاهرية والنطاق الترددي وأي تراخيص سارية. بالإضافة إلى ذلك، لا يتعين عليك إدارة مركز البيانات والخوادم وتخزين SSD والشبكات وتكاليف الكهرباء.
القدرة على استخدام التعليمات البرمجية والأدوات الموجودة: توفر خدمة Azure Cosmos DB توافق مستوى بروتوكول سلكي مع حزمة أدوات تطوير برمجيات Cassandra وأدواته الموجودة. يضمن هذا التوافق أنه يمكنك استخدام قاعدة التعليمات البرمجية الموجودة مع Azure Cosmos DB ل Apache Cassandra مع تغييرات بسيطة.
لا يدعم Azure Cosmos DB بروتوكول Apache Cassandra gossip الأصلي للنسخ المتماثل. لذلك، عندما يكون عدم التوقف عن العمل شرطاً للترحيل، فمن الضروري اتباع نهج مختلفة. يصف هذا البرنامج التعليمي كيفية ترحيل البيانات مباشرة إلى Azure Cosmos DB ل Apache Cassandra من مجموعة Apache Cassandra الأصلية باستخدام وكيل الكتابة المزدوجة وApache Spark.
الصورة التالية توضح النمط. يتم استخدام وكيل dual-write لالتقاط التغييرات الحية، بينما يتم نسخ البيانات التاريخية بكميات كبيرة باستخدام Apache Spark. يمكن أن يقبل الوكيل الاتصالات من التعليمات البرمجية للتطبيق الخاص بك مع تغييرات تكوين قليلة أو معدومة. سيقوم بتوجيه جميع الطلبات إلى قاعدة البيانات المصدر الخاصة بك وتوجيه عمليات الكتابة بشكل غير متزامن إلى واجهة برمجة التطبيقات ل Cassandra أثناء حدوث النسخة المجمعة.
المتطلبات الأساسية
توفير Azure Cosmos DB لحساب Apache Cassandra.
راجع الميزات المدعومة في Azure Cosmos DB ل Apache Cassandra لضمان التوافق.
تأكد من أن لديك اتصال شبكة بين نظام المجموعة المصدر وواجهة برمجة التطبيقات الهدف لنقطة نهاية Cassandra.
تأكد من أنك قمت بالفعل بترحيل مخطط مساحة المفاتيح/الجدول من قاعدة بيانات Cassandra المصدر إلى واجهة برمجة التطبيقات الهدف لحساب Cassandra.
هام
إذا كان لديك متطلب للحفاظ على Apache Cassandra
writetimeأثناء الترحيل، فيجب تعيين العلامات التالية عند إنشاء الجداول:with cosmosdb_cell_level_timestamp=true and cosmosdb_cell_level_timestamp_tombstones=true and cosmosdb_cell_level_timetolive=trueعلى سبيل المثال:
CREATE KEYSPACE IF NOT EXISTS migrationkeyspace WITH REPLICATION= {'class': 'org.apache.> cassandra.locator.SimpleStrategy', 'replication_factor' : '1'};CREATE TABLE IF NOT EXISTS migrationkeyspace.users ( name text, userID int, address text, phone int, PRIMARY KEY ((name), userID)) with cosmosdb_cell_level_timestamp=true and > cosmosdb_cell_level_timestamp_tombstones=true and cosmosdb_cell_level_timetolive=true;
تكوين إعدادات تشغيل الخدمة بنظام مجموعة Spark
نوصي باستخدام Azure Databricks. استخدم وقت تشغيل يدعم Spark 3.0 أو أعلى.
هام
تحتاج إلى التأكد من أن حساب Azure Databricks الخاص بك لديه اتصال شبكة بمصدر مجموعة Apache Cassandra. قد يتطلب ذلك ضخ شبكة ظاهرية. راجع المقالة هنا لمزيد من المعلومات.
إضافة تبعيات Spark
تحتاج إلى إضافة مكتبة Apache Spark Cassandra Connector إلى نظام مجموعتك للاتصال بنقاط النهاية الأصلية وAzure Cosmos DB Cassandra. في نظام المجموعة، حدد Libraries>Install New>Maven ثم أضف com.datastax.spark:spark-cassandra-connector-assembly_2.12:3.0.0 إحداثيات Maven.
هام
إذا كان لديك متطلب للاحتفاظ بـ Apache Cassandra writetime لكل صف أثناء الترحيل، فإننا نوصي باستخدام هذه العينة. يحتوي ملف jar الخاص بالتبعية في هذا النموذج أيضاً على موصل Spark، لذا يجب عليك تثبيته بدلاً من مجموعة الموصل أعلاه. هذه العينة مفيدة أيضاً إذا كنت تريد إجراء تحقق من مقارنة الصفوف بين المصدر والهدف بعد اكتمال تحميل البيانات التاريخية. راجع القسمين "تشغيل تحميل البيانات التاريخية" و"التحقق من صحة المصدر والهدف" أدناه لمزيد من التفاصيل.
حدد Install، ثم أعد تشغيل نظام المجموعة عند اكتمال التثبيت.
إشعار
تأكد من إعادة تشغيل نظام مجموعة Azure Databricks بعد تثبيت مكتبة موصل Cassandra.
تثبيت وكيل الكتابة المزدوجة
للحصول على الأداء الأمثل في أثناء الكتابة المزدوجة، نوصي بتثبيت الوكيل على كافة العقد في نظام مجموعة Cassandra المصدر.
#assuming you do not have git already installed
sudo apt-get install git
#assuming you do not have maven already installed
sudo apt install maven
#clone repo for dual-write proxy
git clone https://github.com/Azure-Samples/cassandra-proxy.git
#change directory
cd cassandra-proxy
#compile the proxy
mvn package
بدء تشغيل وكيل الكتابة المزدوجة
نوصي بتثبيت الوكيل على كافة العقد في نظام مجموعة Cassandra المصدر لديك. على الأقل، قم بتشغيل الأمر التالي لبدء تشغيل الوكيل على كل عقدة. استبدل <target-server> بعنوان IP أو عنوان ملقم من إحدى العقد في نظام المجموعة الهدف. استبدل <path to JKS file> بمسار إلى ملف .jks المحلي واستبدل <keystore password> بكلمة المرور المطابقة.
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> --proxy-jks-file <path to JKS file> --proxy-jks-password <keystore password>
يفترض من خلال بدء تشغيل الوكيل بهذه الطريقة بأن ما يلي صحيح:
- تحتوي نقاط النهاية المصدر والهدف على نفس اسم المستخدم وكلمة المرور.
- تنفذ نقاط النهاية المصدر والهدف طبقة مآخذ التوصيل الآمنة (SSL).
إذا لم تتمكن نقاط النهاية المصدر والهدف لديك من استيفاء هذه المعايير، فقم بقراءة المزيد من خيارات التكوين.
تكوين SSL
بالنسبة إلى طبقة مأخذ التوصيل الآمنة، يمكنك إما تنفيذ مخزن مفاتيح موجود (على سبيل المثال، الذي يستخدمه نظام المجموعة المصدر) أو إنشاء شهادة موقعة ذاتيًا باستخدام keytool:
keytool -genkey -keyalg RSA -alias selfsigned -keystore keystore.jks -storepass password -validity 360 -keysize 2048
يمكنك أيضًا تعطيل طبقة مأخذ التوصيل الآمنة لنقاط النهاية المصدر أو الهدف إذا لم يتم تطبيق طبقة مأخذ التوصيل الآمنة. استخدم العلامات --disable-source-tls أو --disable-target-tls:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> --source-port 9042 --target-port 10350 --proxy-jks-file <path to JKS file> --proxy-jks-password <keystore password> --target-username <username> --target-password <password> --disable-source-tls true --disable-target-tls true
إشعار
تأكد من أن تطبيق العميل يستخدم نفس مخزن المفاتيح وكلمة المرور مثل تلك المستخدمة لوكيل الكتابة المزدوجة عند إنشاء اتصالات طبقة مأخذ التوصيل الآمنة إلى قاعدة البيانات عبر الوكيل.
تكوين بيانات الاعتماد والمنفذ
بشكل افتراضي، سيتم تمرير بيانات اعتماد المصدر من تطبيق العميل. سيستخدم الوكيل بيانات الاعتماد لإجراء اتصالات إلى نظام مجموعات المصدر والهدف. كما ذكر سابقًا، تفترض هذه العملية أن بيانات اعتماد المصدر والهدف هي نفسها. سيكون من الضروري تحديد اسم مستخدم وكلمة مرور مختلفين لواجهة برمجة التطبيقات الهدف لنقطة نهاية Cassandra بشكل منفصل عند بدء تشغيل الوكيل:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> --proxy-jks-file <path to JKS file> --proxy-jks-password <keystore password> --target-username <username> --target-password <password>
سيكون المصدر الافتراضي والمنافذ الهدف، عند عدم تحديد، 9042. في هذه الحالة، يتم تشغيل واجهة برمجة التطبيقات ل Cassandra على المنفذ 10350، لذلك تحتاج إلى استخدام --source-port أو --target-port لتحديد أرقام المنافذ:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar localhost <target-server> --source-port 9042 --target-port 10350 --proxy-jks-file <path to JKS file> --proxy-jks-password <keystore password> --target-username <username> --target-password <password>
نشر الوكيل عن بُعد
قد تكون هناك ظروف لا تريد فيها تثبيت الوكيل على عقد نظام المجموعة نفسها، وتفضل تثبيته على جهاز منفصل. في هذا السيناريو، تحتاج إلى تحديد عنوان IP الخاص بـ <source-server>:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar <source-server> <destination-server>
تحذير
سيؤثر تثبيت الوكيل وتشغيله عن بُعد على جهاز منفصل (بدلاً من تشغيله على جميع العقد في مجموعة Apache Cassandra المصدر) على الأداء أثناء حدوث الترحيل المباشر. بينما سيعمل بشكل وظيفي، لن يتمكن برنامج تشغيل العميل من فتح الاتصالات لجميع العقد داخل نظام المجموعة، وسيعتمد على عقدة المنسق الفردية (حيث يتم تثبيت الوكيل) لإجراء الاتصالات.
السماح بتغييرات رمز التطبيق صفر
بشكل افتراضي، يستمع الوكيل على المنفذ 29042. يجب تغيير رمز التطبيق للإشارة إلى هذا المنفذ. ومع ذلك، يمكنك تغيير المنفذ الذي يستمع الوكيل عليه. قد تفعل ذلك إذا كنت ترغب في إزالة تغييرات الرموز على مستوى التطبيق بواسطة:
- وجود خادم Cassandra المصدر مشغل على منفذ مختلف.
- وجود وكيل مشغل على منفذ Cassandra القياسي 9042.
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042
إشعار
لا يتطلب تثبيت الوكيل على عقد نظام المجموعة، إعادة تشغيل العقد. ومع ذلك، إذا كان لديك العديد من عملاء التطبيق ويفضل أن يكون الوكيل قيد التشغيل على منفذ Cassandra القياسي 9042 من أجل إزالة أي تغييرات للرموز على مستوى التطبيق تحتاج إلى تغيير منفذ Apache Cassandra الافتراضي. ثم تحتاج إلى إعادة تشغيل العقد في نظام المجموعة الخاص بك وتكوين المنفذ المصدر ليكون المنفذ الجديد الذي قمت بتعريفه من أجل نظام المجموعة Cassandra المصدر.
في المثال التالي، نقوم بتغيير نظام المجموعة Cassandra المصدر للتشغيل على المنفذ 3074 ثم نبدأ نظام المجموعة على المنفذ 9042:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --proxy-port 9042 --source-port 3074
فرض البروتوكولات
لدى الوكيل وظائف لفرض البروتوكولات، والتي قد تكون ضرورية إذا كانت نقطة النهاية المصدر أكثر تقدمًا من الهدف أو غير معتمدة. في هذه الحالة، يمكنك تحديد --protocol-version و--cql-version لفرض البروتوكول للامتثال للهدف:
java -jar target/cassandra-proxy-1.0-SNAPSHOT-fat.jar source-server destination-server --protocol-version 4 --cql-version 3.11
بعد تشغيل وكيل الكتابة المزدوجة، ستحتاج إلى تغيير المنفذ على عميل التطبيق لديك وإعادة التشغيل. (أو تغيير منفذ Cassandra وإعادة تشغيل نظام المجموعة إذا اخترت هذا النهج.) سيبدأ الوكيل بعد ذلك في إعادة توجيه عمليات الكتابة إلى نقطة النهاية الهدف. يمكنك التعرف على المراقبة والمقاييسالمتوفرة في أداة الوكيل.
تشغيل تحميل البيانات التاريخية
لتحميل البيانات، قم بإنشاء دفتر ملاحظات Scala في حساب Azure Databricks. استبدل المصدر والهدف تكوينات Cassandra ببيانات الاعتماد المقابلة، واستبدل مسافات المفاتيح والجداول المصدر والهدف. أضف المزيد من المتغيرات لكل جدول كما هو مطلوب إلى النموذج التالي ثم قم بالتشغيل. بعد أن يبدأ التطبيق الخاص بك بإرسال الطلبات إلى وكيل الكتابة المزدوجة، ستكون على استعداد لترحيل البيانات التاريخية.
هام
قبل ترحيل البيانات، يمكنك زيادة معدل نقل الحاوية إلى المقدار المطلوب لترحيل تطبيقك بسرعة. سيساعدك قياس معدل النقل قبل بدء الترحيل على ترحيل بياناتك في وقت أقل. للمساعدة في الحماية من تحديد المعدل أثناء تحميل البيانات التاريخية، قد ترغب في تمكين عمليات إعادة المحاولة من جانب الخادم (SSR) في واجهة برمجة التطبيقات ل Cassandra. راجع مقالتنا هنا لمزيد من المعلومات والإرشادات حول كيفية تمكين SSR.
import com.datastax.spark.connector._
import com.datastax.spark.connector.cql._
import org.apache.spark.SparkContext
// source cassandra configs
val sourceCassandra = Map(
"spark.cassandra.connection.host" -> "<Source Cassandra Host>",
"spark.cassandra.connection.port" -> "9042",
"spark.cassandra.auth.username" -> "<USERNAME>",
"spark.cassandra.auth.password" -> "<PASSWORD>",
"spark.cassandra.connection.ssl.enabled" -> "true",
"keyspace" -> "<KEYSPACE>",
"table" -> "<TABLE>"
)
//target cassandra configs
val targetCassandra = Map(
"spark.cassandra.connection.host" -> "<Source Cassandra Host>",
"spark.cassandra.connection.port" -> "10350",
"spark.cassandra.auth.username" -> "<USERNAME>",
"spark.cassandra.auth.password" -> "<PASSWORD>",
"spark.cassandra.connection.ssl.enabled" -> "true",
"keyspace" -> "<KEYSPACE>",
"table" -> "<TABLE>",
//throughput related settings below - tweak these depending on data volumes.
"spark.cassandra.output.batch.size.rows"-> "1",
"spark.cassandra.output.concurrent.writes" -> "1000",
"spark.cassandra.connection.remoteConnectionsPerExecutor" -> "1",
"spark.cassandra.concurrent.reads" -> "512",
"spark.cassandra.output.batch.grouping.buffer.size" -> "1000",
"spark.cassandra.connection.keep_alive_ms" -> "600000000"
)
//set timestamp to ensure it is before read job starts
val timestamp: Long = System.currentTimeMillis / 1000
//Read from source Cassandra
val DFfromSourceCassandra = sqlContext
.read
.format("org.apache.spark.sql.cassandra")
.options(sourceCassandra)
.load
//Write to target Cassandra
DFfromSourceCassandra
.write
.format("org.apache.spark.sql.cassandra")
.options(targetCassandra)
.option("writetime", timestamp)
.mode(SaveMode.Append)
.save
إشعار
في نموذج Scala السابق، ستلاحظ أن timestamp يتم تعيينه إلى الوقت الحالي قبل قراءة كافة البيانات في الجدول المصدر. ثم، يتم تعيين writetime إلى هذا الطابع الزمني القديم. وهذا يضمن أن السجلات التي تتم كتابتها من تحميل البيانات التاريخية إلى نقطة النهاية الهدف لا يمكن الكتابة على التحديثات التي تأتي في طابع زمني لاحق من وكيل الكتابة المزدوجة في أثناء قراءة البيانات التاريخية.
هام
إذا كنت بحاجة إلى الاحتفاظ بطوابع زمنية دقيقة لأي سبب من الأسباب، يجب اتباع نهج ترحيل البيانات التاريخية التي تحافظ على الطوابع الزمنية، مثل هذه العينة. يحتوي ملف jar الخاص بالتبعية الموجودة في العينة أيضاً على موصل Spark، لذلك لا تحتاج إلى تثبيت مجموعة موصل Spark المذكورة في المتطلبات المسبقة الماضية - سيؤدي تثبيت كليهما في مجموعة Spark إلى حدوث تعارضات.
تحقق من المصدر والهدف
بعد اكتمال تحميل البيانات التاريخية، يجب أن تكون قواعد البيانات الخاصة بك متزامنة وجاهزة للتنفيذ. ومع ذلك، نوصيك بالتحقق من صحة المصدر والهدف للتأكد من تطابقهما قبل القطع في النهاية.
إشعار
إذا استخدمت عينة مرحل cassandra المذكورة أعلاه للاحتفاظ writetime، فإن هذا يتضمن القدرة على التحقق من صحة الترحيل عن طريق مقارنة الصفوف في المصدر والهدف بناءً على بعض التحمل.