نقل البيانات من Cassandra إلى Bigtable باستخدام خادم وكيل لميزة Dual-Write

الدقائق المتبقية: 8

لمحة عن هذا الدرس التطبيقي حول الترميز

تاريخ التعديل الأخير: أبريل 15, 2025

تأليف: Louis Cheynel

1. مقدمة

‫Bigtable هي خدمة قاعدة بيانات NoSQL مُدارة بالكامل وعالية الأداء ومصمّمة لمعالجة مهام العمل التحليلية والتشغيلية الكبيرة. غالبًا ما يتطلّب نقل البيانات من قواعد البيانات الحالية، مثل Apache Cassandra، إلى Bigtable تخطيطًا دقيقًا للحدّ من وقت الاستراحة وتأثير التطبيق.

يوضّح هذا الدرس التطبيقي حول الترميز استراتيجية نقل البيانات من Cassandra إلى Bigtable باستخدام مجموعة من أدوات الخادم الوكيل:

Cassandra-Bigtable Proxy: يسمح هذا العنصر لعملاء Cassandra وأدواتها (مثل cqlsh أو برامج التشغيل) بالتفاعل مع Bigtable باستخدام بروتوكول لغة الاستعلامات في Cassandra (CQL) من خلال ترجمة الاستعلامات.
خادم وكيل نقل البيانات بدون انقطاع (ZDM) من Datastax: خادم وكيل مفتوح المصدر يقع بين تطبيقك وخدمات قاعدة البيانات (Cassandra المصدر وBigtable الهدف من خلال خادم وكيل Cassandra-Bigtable). وتعمل هذه الأداة على تنسيق عمليات الكتابة المزدوجة وإدارة توجيه الزيارات، ما يتيح نقل البيانات بأقل قدر من التغييرات في التطبيق ووقت الاستراحة.
أداة نقل بيانات Cassandra (CDM): أداة مفتوحة المصدر تُستخدَم لنقل البيانات السابقة بشكل مجمّع من مجموعة Cassandra المصدر إلى مثيل Bigtable المستهدَف.

المُعطيات

كيفية إعداد مجموعة Cassandra أساسية على Compute Engine
كيفية إنشاء مثيل Bigtable
كيفية نشر خادم وكيل Cassandra-Bigtable وضبطه لربط مخطّط Cassandra بـ Bigtable
كيفية نشر خادم وكيل Datastax ZDM وضبطه لعمليات الكتابة المزدوجة
كيفية استخدام أداة Cassandra Data Migrator لنقل البيانات الحالية بشكل مجمّع
سير العمل العام لنقل البيانات من Cassandra إلى Bigtable باستخدام وكيل

المتطلبات

مشروع على Google Cloud تم تفعيل الفوترة فيه يكون المستخدمون الجدد مؤهّلين للاستفادة من فترة تجريبية مجانية.
معرفة أساسية بمفاهيم Google Cloud، مثل المشاريع وCompute Engine وشبكات VPC وقواعد جدار الحماية معرفة أساسية بأدوات سطر الأوامر في Linux
الوصول إلى جهاز تم تثبيت gcloud CLI عليه وضبطه، أو استخدام Google Cloud Shell

في هذا الدليل التعليمي حول رموز البرامج، سنستخدم بشكل أساسي الأجهزة الافتراضية على Compute Engine ضمن شبكة ومنطقة VPC نفسها لتبسيط عملية الاتصال بالشبكة. ننصح باستخدام عناوين IP الداخلية.

2. إعداد البيئة

1. اختيار مشروع على Google Cloud أو إنشاؤه

انتقِل إلى Google Cloud Console واختَر مشروعًا حاليًا أو أنشئ مشروعًا جديدًا. دوِّن رقم تعريف المشروع.

2. تفعيل واجهات برمجة التطبيقات المطلوبة

تأكَّد من تفعيل Compute Engine API وBigtable API لمشروعك.

gcloud services enable compute.googleapis.com bigtable.googleapis.com bigtableadmin.googleapis.com --project=<your-project-id>

استبدِل برقم تعريف مشروعك الفعلي.

3- اختيار منطقة ومنطقة

اختَر منطقة ومنطقة لمواردك. سنستخدم us-central1 وus-central1-c كمثالَين. حدِّد هذه المتغيرات كمتغيّرات بيئة للتيسير:

export PROJECT_ID="<your-project-id>"
export REGION="us-central1"
export ZONE="us-central1-c"

gcloud config set project $PROJECT_ID
gcloud config set compute/region $REGION
gcloud config set compute/zone $ZONE

4. ضبط قواعد جدار الحماية

يجب السماح بالاتصال بين أجهزة الكمبيوتر الافتراضية ضمن شبكة VPC التلقائية على عدة منافذ:

منفذ CQL في Cassandra/Proxies: 9042
منفذ التحقّق من صحة خادم ZDM الوكيل: 14001
بروتوكول النقل الآمن (SSH): 22

أنشئ قاعدة جدار حماية للسماح بالزيارات الداخلية على هذه المنافذ. سنستخدم العلامة cassandra-migration لتطبيق هذه القاعدة بسهولة على الأجهزة الافتراضية ذات الصلة.

gcloud compute firewall-rules create allow-migration-internal \
--network=default \
--action=ALLOW \
--rules=tcp:22,tcp:9042,tcp:14001 \
--source-ranges=10.128.0.0/9 # Adjust if using a custom VPC/IP range \
--target-tags=cassandra-migration

3. نشر مجموعة Cassandra (الإصدار الأصلي)

في هذا الدرسّ البرمجي، سننشئ مجموعة بسيطة من عقدة واحدة من Cassandra على Compute Engine. في سيناريو واقعي، ستتصل بالمجموعة الحالية.

1. إنشاء جهاز افتراضي على Google Compute Engine لنظام Cassandra

gcloud compute instances create cassandra-origin \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

2. تثبيت Cassandra

# Install Java (Cassandra dependency)
sudo apt-get update
sudo apt-get install -y openjdk-11-jre-headless

# Add Cassandra repository
echo "deb [https://debian.cassandra.apache.org](https://debian.cassandra.apache.org) 41x main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
curl [https://downloads.apache.org/cassandra/KEYS](https://downloads.apache.org/cassandra/KEYS) | sudo apt-key add -

# Install Cassandra
sudo apt-get update
sudo apt-get install -y cassandra

3- إنشاء مساحة مفاتيح وجدول

سنستخدم مثالاً لجدول موظفي وسننشئ مساحة مفاتيح تُسمى "zdmbigtable".

cd ~/apache-cassandra
bin/cqlsh <your-localhost-ip? 9042  #starts the cql shell

في cqlsh:

-- Create keyspace (adjust replication for production)
CREATE KEYSPACE zdmbigtable WITH replication = {'class':'SimpleStrategy', 'replication_factor':1};

-- Use the keyspace
USE zdmbigtable;

-- Create the employee table
CREATE TABLE employee (
    name text PRIMARY KEY,
    age bigint,
    code int,
    credited double,
    balance float,
    is_active boolean,
    birth_date timestamp
);

-- Exit cqlsh
EXIT;

اترك جلسة SSH مفتوحة أو سجِّل عنوان IP لوحدة VM هذه (hostname -I).

4. إعداد Bigtable (الهدف)

المدة 0:01

أنشئ مثيلًا على Bigtable. سنستخدم zdmbigtable كمعرّف للمثيل.

gcloud bigtable instances create zdmbigtable \ 
--display-name="ZDM Bigtable Target" \ 
--cluster=bigtable-c1 \ 
--cluster-zone=$ZONE \ 
--cluster-num-nodes=1 # Use 1 node for dev/testing; scale as needed

سيتم إنشاء جدول Bigtable نفسه لاحقًا بواسطة النص البرمجي لإعداد وكيل Cassandra-Bigtable.

5. إعداد خادم وكيل Cassandra-Bigtable

1. إنشاء جهاز افتراضي على Compute Engine لخادم وكيل Cassandra-Bigtable

gcloud compute instances create bigtable-proxy-vm \ 
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

يمكنك استخدام بروتوكول النقل الآمن (SSH) للوصول إلى bigtable-proxy-vm:

gcloud compute ssh bigtable-proxy-vm

داخل الجهاز الظاهري:

# Install Git and Go
sudo apt-get update
sudo apt-get install -y git golang-go

# Clone the proxy repository
# Replace with the actual repository URL if different
git clone https://github.com/GoogleCloudPlatform/cloud-bigtable-ecosystem.git
cd cassandra-to-bigtable-proxy/

# Set Go environment variables
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin

2. ضبط الخادم الوكيل

nano config.yaml

عدِّل المتغيّرات التالية. للحصول على إعدادات أكثر تقدمًا، استخدِم هذا المثال المتوفّر على GitHub.

#!/bin/bash
cassandraToBigtableConfigs:
  # Global default GCP Project ID
  projectId: <your-project-id>

listeners:
- name: cluster1
  port: 9042
  bigtable:
    #If you want to use multiple instances then pass the instance names by comma seperated
    #Instance name should not contain any special characters except underscore(_)
    instanceIds: zdmbigtable

    # Number of grpc channels to be used for Bigtable session.
    Session:
      grpcChannels: 4

otel:
  # Set enabled to true or false for OTEL metrics/traces/logs.
  enabled: False

  # Name of the collector service to be setup as a sidecar
  serviceName: cassandra-to-bigtable-otel-service

  healthcheck:
    # Enable the health check in this proxy application config only if the
    # "health_check" extension is added to the OTEL collector service configuration.
    #
    # Recommendation:
    # Enable the OTEL health check if you need to verify the collector's availability
    # at the start of the application. For development or testing environments, it can
    # be safely disabled to reduce complexity.

    # Enable/Disable Health Check for OTEL, Default 'False'.
    enabled: False
    # Health check endpoint for the OTEL collector service
    endpoint: localhost:13133
  metrics:
    # Collector service endpoint
    endpoint: localhost:4317

  traces:
    # Collector service endpoint
    endpoint: localhost:4317
    #Sampling ratio should be between 0 and 1. Here 0.05 means 5/100 Sampling ratio.
    samplingRatio: 1

loggerConfig:
  # Specifies the type of output, here it is set to 'file' indicating logs will be written to a file.
  # Value of `outputType` should be `file` for file type or `stdout` for standard output.
  # Default value is `stdout`.
  outputType: stdout
  # Set this only if the outputType is set to `file`.
  # The path and name of the log file where logs will be stored. For example, output.log, Required Key.
  # Default `/var/log/cassandra-to-spanner-proxy/output.log`.
  fileName: output/output.log
  # Set this only if the outputType is set to `file`.
  # The maximum size of the log file in megabytes before it is rotated. For example, 500 for 500 MB.
  maxSize: 10
  # Set this only if the outputType is set to `file`.
  # The maximum number of backup log files to keep. Once this limit is reached, the oldest log file will be deleted.
  maxBackups: 2
  # Set this only if the outputType is set to `file`.
  # The maximum age in days for a log file to be retained. Logs older than this will be deleted. Required Key.
  # Default 3 days
  maxAge: 1

  # Set this only if the outputType is set to `file`.
  # Default value is set to 'False'. Change the value to 'True', if log files are required to be compressed.
  compress: True

احفظ الملف وأغلقه (ctrl+X، ثم Y، ثم Enter في nano).

3- بدء خادم وكيل Cassandra-Bigtable

ابدأ تشغيل الخادم الوكيل.

# At the root of the cassandra-to-bigtable-proxy directory
go run proxy.go

سيتم بدء الخادم الوكيل والاستماع إلى المنفذ 9042 لاتصالات CQL الواردة. يجب إبقاء جلسة الوحدة الطرفية هذه قيد التشغيل. دوِّن عنوان IP الخاص بجهاز الكمبيوتر الظاهري هذا (hostname -I).

4. إنشاء جدول باستخدام CQL

اربط cqlsh بعنوان IP الخاص بجهاز Cassandra-Bigtable Proxy VM.

في cqlsh، نفِّذ الأمر التالي:

-- Create the employee table
CREATE TABLE zdmbigtable.employee (
    name text PRIMARY KEY,
    age bigint,
    code int,
    credited double,
    balance float,
    is_active boolean,
    birth_date timestamp
);

تأكَّد في Google Cloud Console من توفّر جدول الموظفين وجدول البيانات الوصفية في مثيل Bigtable.

6. إعداد خادم ZDM الوكيل

يتطلّب "خادم وكيل ZDM" جهازَين على الأقل: عقدة وكيل واحدة أو أكثر تعالج الزيارات، و"Jumphost" المستخدَم للنشر والإدارة من خلال Ansible.

1. إنشاء أجهزة افتراضية في Compute Engine لخادم وكيل ZDM

نحتاج إلى جهازَي VM: zdm-proxy-jumphost وzdm-proxy-node-1.

# Jumphost VM 
gcloud compute instances create zdm-jumphost \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

# Proxy Node VM 
gcloud compute instances create zdm-proxy-node-1 \
--machine-type=e2-standard-8 \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=20GB

دوِّن عناوين IP لكلتا الجهازَين الافتراضيَين.

2. تجهيز مضيف القفزة

استخدام بروتوكول النقل الآمن (SSH) للوصول إلى مضيف القفزة zdm-jumphost

gcloud compute ssh zdm-jumphost

# Install Git and Ansible

sudo apt-get update
sudo apt-get install -y git ansible

داخل مضيف القفزة

git clone https:\/\/github.com/datastax/zdm-proxy-automation.git 

cd zdm-proxy-automation/ansible/

عدِّل ملف الضبط الرئيسي vars/zdm_proxy_cluster_config.yml:

عدِّل origin_contact_points وtarget_contact_points باستخدام عناوين IP الداخلية لوحدة Cassandra الافتراضية ووحدة Cassandra-Bigtable Proxy الافتراضية، على التوالي. اترك المصادقة معلّقة لأنّنا لم نضبطها.

##############################
#### ORIGIN CONFIGURATION ####
##############################
## Origin credentials (leave commented if no auth)
# origin_username: ...
# origin_password: ...

## Set the following two parameters only if Origin is a self-managed, non-Astra cluster
origin_contact_points: <Your-Cassandra-VM-Internal-IP> # Replace!
origin_port: 9042

##############################
#### TARGET CONFIGURATION ####
##############################
## Target credentials (leave commented if no auth)
# target_username: ...
# target_password: ...

## Set the following two parameters only if Target is a self-managed, non-Astra cluster
target_contact_points: <Your-Bigtable-Proxy-VM-Internal-IP> # Replace!
target_port: 9042

# --- Other ZDM Proxy settings can be configured below ---
# ... (keep defaults for this codelab)

احفظ هذا الملف وأغلقه.

3- نشر خادم ZDM الوكيل باستخدام Ansible

يمكنك تنفيذ الدليل الإرشادي Ansible من دليل ansible على مضيف القفزة:

ansible-playbook deploy_zdm_proxy.yml -i zdm_ansible_inventory

سيؤدي هذا الأمر إلى تثبيت البرامج اللازمة (مثل Docker) على عقدة الخادم الوكيل (zdm-proxy-node-1)، وسحب صورة Docker الخاصة بخادم ZDM الوكيل، وبدء حاوية الخادم الوكيل باستخدام الإعدادات التي قدّمتها.

4. التحقّق من صحة خادم ZDM الوكيل

تحقَّق من نقطة نهاية مدى الجاهزية لخادم ZDM الوكيل الذي يعمل على zdm-proxy-node-1 (المنفذ 14001) من مضيف القفزة:

# Replace <zdm-proxy-node-1-internal-ip> with the actual internal IP.
curl -G http://<zdm-proxy-node-1-internal-ip>:14001/health/readiness

من المفترض أن يظهر لك ناتج مشابه لما يلي، ما يشير إلى أنّ كلاً من المصدر (Cassandra) والهدف (Cassandra-Bigtable Proxy) قيد التشغيل:

{
  "OriginStatus": {
    "Addr": "<Your-Cassandra-VM-Internal-IP>:9042",
    "CurrentFailureCount": 0,
    "FailureCountThreshold": 1,
    "Status": "UP"
  },
  "TargetStatus": {
    "Addr": "<Your-Bigtable-Proxy-VM-Internal-IP>:9042",
    "CurrentFailureCount": 0,
    "FailureCountThreshold": 1,
    "Status": "UP"
  },
  "Status": "UP"
}

7. ضبط التطبيق وبدء عمليات الكتابة المزدوجة

المدة 0:05

في هذه المرحلة من عملية نقل البيانات الفعلية، عليك إعادة ضبط تطبيقاتك للإشارة إلى عنوان IP الخاص بعقدة ZDM Proxy (مثل :9042) بدلاً من الاتصال مباشرةً بخادم Cassandra.

بعد أن يتصل التطبيق بخادم ZDM الوكيل: يتم عرض عمليات القراءة من المصدر (Cassandra) تلقائيًا. يتم إرسال عمليات الكتابة إلى كلّ من المصدر (Cassandra) والهدف (Bigtable، من خلال وكيل Cassandra-Bigtable). يتيح ذلك لتطبيقك مواصلة العمل بشكلٍ طبيعي مع ضمان كتابة البيانات الجديدة في كلتا قاعدتَي البيانات في الوقت نفسه. يمكنك اختبار الاتصال باستخدام cqlsh المُوجَّه إلى خادم ZDM الوكيل من مضيف القفزة أو جهاز افتراضي آخر في الشبكة:

Cqlsh <zdm-proxy-node-1-ip-address> 9042

حاوِل إدخال بعض البيانات:

INSERT INTO zdmbigtable.employee (name, age, is_active) VALUES ('Alice', 30, true); 
SELECT * FROM employee WHERE name = 'Alice';

يجب كتابة هذه البيانات في كلّ من Cassandra وBigtable. يمكنك تأكيد ذلك في Bigtable من خلال الانتقال إلى Google Cloud Console وفتح "محرر طلبات البحث في Bigtable" لمثيلك. نفِّذ طلب بحث "SELECT * FROM employee"، ومن المفترض أن تظهر البيانات التي تم إدراجها مؤخرًا.

8. نقل البيانات السابقة باستخدام أداة نقل بيانات Cassandra

بعد تفعيل ميزة "الكتابة المزدوجة" للبيانات الجديدة، استخدِم أداة "محوِّل بيانات Cassandra" (CDM) لنسخ البيانات السابقة الحالية من Cassandra إلى Bigtable.

1. إنشاء جهاز افتراضي على Compute Engine لخدمة إدارة البيانات

تحتاج هذه الآلة الافتراضية إلى ذاكرة كافية لتشغيل Spark.

gcloud compute instances create cdm-migrator-vm \
--machine-type=e2-medium \
--image-family=ubuntu-2004-lts \
--image-project=ubuntu-os-cloud \
--tags=cassandra-migration \
--boot-disk-size=40GB

2. تثبيت المتطلبات الأساسية (Java 11 وSpark)

اتصل بجهاز cdm-migrator-vm باستخدام بروتوكول النقل الآمن (SSH):

gcloud compute ssh cdm-migrator-vm

داخل الجهاز الظاهري:

# Install Java 11 
sudo apt-get update 
sudo apt-get install -y openjdk-11-jdk
 
# Verify Java installation 
java -version 

# Download and Extract Spark (Using version 3.5.3 as requested) 
# Check the Apache Spark archives for the correct URL if needed

wget  [https://archive.apache.org/dist/spark/spark-3.5.3/spark-3.5.3-bin-hadoop3-scala2.13.tgz](https://archive.apache.org/dist/spark/spark-3.5.3/spark-3.5.3-bin-hadoop3-scala2.13.tgz) tar -xvzf spark-3.5.3-bin-hadoop3-scala2.13.tgz
 
export SPARK_HOME=$PWD/spark-3.5.3-bin-hadoop3-scala2.13 
export PATH=$PATH:$SPARK_HOME/bin

3- تنزيل أداة نقل بيانات Cassandra

نزِّل ملف jar الخاص بأداة CDM. راجِع صفحة إصدار Cassandra Data Migrator على GitHub للحصول على عنوان URL الصحيح للإصدار المطلوب.

# Example using version 5.2.2 - replace URL if needed
wget https://github.com/datastax/cassandra-data-migrator/releases/download/v5.2.2/cassandra-data-migrator-5.2.2.jar)

4. ضبط منصّة إدارة البيانات

أنشئ ملف خصائص باسم cdm.properties.

Nano cdm.properties

الصِق الإعدادات التالية، مع استبدال عناوين IP وإيقاف ميزتَي TTL/Writetime لأنّهما غير متوافقتَين مباشرةً مع Bigtable بالطريقة نفسها. اترك المصادقة معلّقة.

# Origin Cassandra Connection 
spark.cdm.connect.origin.host <Your-Cassandra-VM-IP-Address> # Replace!
spark.cdm.connect.origin.port 9042
spark.cdm.connect.origin.username cassandra # Leave default, or set if auth is enabled # 
spark.cdm.connect.origin.password cassandra # Leave default, or set if auth is enabled #

# Target Bigtable (via Cassandra-Bigtable Proxy)
Connection spark.cdm.connect.target.host <Your-Bigtable-Proxy-VM-IP-Address> # Replace! 
spark.cdm.connect.target.port 9042
spark.cdm.connect.target.username cassandra # Leave default, or set if auth is enabled #
spark.cdm.connect.target.password cassandra # Leave default, or set if auth is enabled #

# Disable TTL/Writetime features (Important for Bigtable compatibility via Proxy)
spark.cdm.feature.origin.ttl.automatic false 
spark.cdm.feature.origin.writetime.automatic false 
spark.cdm.feature.target.ttl.automatic false 
spark.cdm.feature.target.writetime.automatic false

احفظ الملف وأغلقه.

5- تشغيل مهمة نقل البيانات

نفِّذ عملية نقل البيانات باستخدام spark-submit. يطلب هذا الأمر من Spark تشغيل حزمة CDM باستخدام ملف الخصائص وتحديد مساحة المفاتيح والجدول المطلوب نقله. عدِّل إعدادات الذاكرة (–driver-memory و–executor-memory) استنادًا إلى حجم جهازك الظاهري وحجم البيانات.

تأكَّد من أنّك في الدليل الذي يحتوي على حزمة CDM وملف الخصائص. استبدِل "cassandra-data-migrator-5.2.2.jar" إذا نزّلت إصدارًا مختلفًا.

./spark-3.5.3-bin-hadoop3-scala2.13/bin/spark-submit \ --properties-file cdm.properties \ --master "local[*]" \ --driver-memory 4G \ --executor-memory 4G \ --class com.datastax.cdm.job.Migrate \ cassandra-data-migrator-5.2.2.jar &> cdm_migration_$(date +%Y%m%d_%H%M).log

سيتم نقل البيانات في الخلفية، وسيتم تسجيل السجلّات في cdm_migration_‎... ‎.log. راقِب ملف السجلّ لمعرفة مستوى التقدّم وأي أخطاء:

tail -f cdm_migration_*.log

6. التحقّق من نقل البيانات

بعد اكتمال مهمة "إدارة البيانات الوصفية" بنجاح، تأكَّد من توفّر البيانات السابقة في Bigtable. بما أنّ خادم Cassandra-Bigtable Proxy يسمح بعمليات القراءة باستخدام CQL، يمكنك مرة أخرى استخدام cqlsh المرتبط بخادم ZDM Proxy (الذي يوجّه عمليات القراءة إلى الهدف بعد نقل البيانات، أو يمكن ضبطه على ذلك) أو مباشرةً إلى خادم Cassandra-Bigtable Proxy لطلب البحث عن البيانات. الاتصال عبر خادم وكيل ZDM:

cqlsh <zdm-proxy-node-1-ip-address> 9042

في cqlsh:

SELECT COUNT(*) FROM zdmbigtable.employee; -- Check row count matches origin 
SELECT * FROM employee LIMIT 10; -- Check some sample data

بدلاً من ذلك، يمكنك استخدام أداة cbt (إذا كانت مثبّتة على آلة افتراضية لإدارة بيانات العملاء أو Cloud Shell) للبحث عن البيانات مباشرةً في Bigtable:

# First, install cbt if needed
# gcloud components update
# gcloud components install cbt

# Then lookup a specific row (replace 'some_employee_name' with an actual primary key)
cbt -project $PROJECT_ID -instance zdmbigtable lookup employee some_employee_name

9. عملية النقل (مبدأ)

بعد التحقّق بدقة من اتساق البيانات بين Cassandra وBigtable، يمكنك المتابعة لإجراء عملية النقل النهائية.

باستخدام "خادم ZDM الوكيل"، يتضمن نقل البيانات إعادة ضبطه للقراءة بشكل أساسي من الهدف (Bigtable) بدلاً من المصدر (Cassandra). يتم ذلك عادةً من خلال ضبط إعدادات ZDM Proxy، ما يؤدي إلى نقل عدد زيارات القراءة في تطبيقك إلى Bigtable بشكل فعّال.

بعد التأكّد من أنّ Bigtable يعرض كل الزيارات بشكل صحيح، يمكنك في النهاية إجراء ما يلي:

أوقِف عمليات الكتابة المزدوجة من خلال إعادة ضبط خادم ZDM الوكيل.
أوقِف مجموعة Cassandra الأصلية.
أزِل خادم ZDM الوكيل واطلب من التطبيق الاتصال مباشرةً بخادم وكيل Cassandra-Bigtable أو استخدِم برنامج Bigtable CQL Client الأصلي لنظام التشغيل Java.

إنّ تفاصيل إعادة ضبط ZDM Proxy لعملية النقل لا تقع ضمن نطاق هذا الدرس التطبيقي الأساسي حول الترميز، ولكن يمكن الاطّلاع عليها بالتفصيل في مستندات Datastax ZDM.

10. تَنظيم

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

1. حذف الأجهزة الافتراضية في Compute Engine

gcloud compute instances delete cassandra-origin-vm zdm-proxy-jumphost zdm-proxy-node-1 bigtable-proxy-vm cdm-migrator-vm --zone=$ZONE --quiet

2. حذف مثيل Bigtable

gcloud bigtable instances delete zdmbigtable

3- حذف قواعد جدار الحماية

gcloud compute firewall-rules delete allow-migration-internal

4. حذف قاعدة بيانات Cassandra (إذا كانت مثبَّتة محليًا أو دائمة)

إذا ثبّتْت Cassandra خارج جهاز Compute Engine افتراضي تم إنشاؤه هنا، اتّبِع الخطوات المناسبة لإزالة البيانات أو إلغاء تثبيت Cassandra.

11. تهانينا!

لقد أكملت بنجاح عملية إعداد مسار نقل بيانات يستند إلى الخادم الوكيل من Apache Cassandra إلى Bigtable.

لقد تعلّمت كيفية:

يمكنك نشر Cassandra وBigtable.

ضبط خادم وكيل Cassandra-Bigtable لتوافق CQL
يمكنك نشر وكيل Datastax ZDM لإدارة عمليات الكتابة المزدوجة والزيارات.
استخدِم أداة نقل بيانات Cassandra لنقل البيانات السابقة.

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

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

استكشاف مستندات Bigtable
راجِع مستندات Datastax ZDM Proxy للتعرّف على الإعدادات المتقدّمة وإجراءات النقل.
راجِع مستودع Cassandra-Bigtable Proxy للحصول على مزيد من التفاصيل.
اطّلِع على مستودع Cassandra Data Migrator للاستخدام المتقدّم.
تجربة دروس Google Cloud Codelabs الأخرى

الإبلاغ عن خطأ