Menggunakan ETL terbalik untuk memuat data dari BigQuery ke Spanner Graph

Dokumen ini menjelaskan cara menggunakan pipeline ekstraksi, transformasi, dan pemuatan (ETL) terbalik untuk memindahkan dan menyinkronkan data grafik secara berkelanjutan dari BigQuery ke Spanner Graph. Panduan ini mencakup aspek-aspek penting berikut:

Untuk menggunakan ETL terbalik guna mengekspor data dari BigQuery ke Spanner, lihat Mengekspor data ke Spanner.

BigQuery melakukan manipulasi data yang kompleks dalam skala besar sebagai platform pemrosesan analitik, sementara Spanner dioptimalkan untuk kasus penggunaan yang memerlukan QPS tinggi dan latensi penayangan rendah. Spanner Graph dan BigQuery terintegrasi secara efektif untuk menyiapkan data grafik di pipeline analisis BigQuery, sehingga Spanner dapat menyajikan penelusuran grafik latensi rendah.

Sebelum memulai

  1. Buat instance Spanner dengan database yang berisi data grafik. Untuk mengetahui informasi selengkapnya, lihat Menyiapkan dan membuat kueri Spanner Graph.

  2. Di BigQuery, buat reservasi slot tingkat Enterprise atau Enterprise Plus. Anda dapat mengurangi biaya komputasi BigQuery saat menjalankan ekspor ke Spanner Graph. Untuk melakukannya, tetapkan kapasitas slot dasar pengukuran ke nol dan aktifkan penskalaan otomatis.

  3. Berikan peran Identity and Access Management (IAM) yang memberi pengguna izin yang diperlukan untuk melakukan setiap tugas dalam dokumen ini.

Peran yang diperlukan

Untuk mendapatkan izin yang Anda perlukan guna mengekspor data grafik BigQuery ke Spanner Graph, minta administrator Anda untuk memberi Anda peran IAM berikut di project Anda:

Untuk mengetahui informasi selengkapnya tentang pemberian peran, lihat Mengelola akses ke project, folder, dan organisasi.

Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui peran khusus atau peran bawaan lainnya.

Kasus penggunaan Reverse ETL

Berikut adalah contoh kasus penggunaan. Setelah menganalisis dan memproses data di BigQuery, Anda dapat memindahkan data ke Spanner Graph menggunakan ETL terbalik.

Penggabungan dan peringkasan data - Gunakan BigQuery untuk menghitung gabungan data terperinci agar lebih sesuai untuk kasus penggunaan operasional.

Transformasi dan pengayaan data - Gunakan BigQuery untuk membersihkan dan menstandardisasi data yang diterima dari berbagai sumber data.

Pemfilteran dan pemilihan data - Gunakan BigQuery untuk memfilter set data besar untuk tujuan analisis. Misalnya, Anda dapat memfilter data yang tidak diperlukan untuk aplikasi real-time.

Prapemrosesan dan rekayasa fitur - Di BigQuery, gunakan fungsi ML.TRANSFORM untuk mengubah data, atau fungsi ML.FEATURE_CROSS untuk membuat persilangan fitur dari fitur input. Kemudian, gunakan reverse ETL untuk memindahkan data yang dihasilkan ke Spanner Graph.

Memahami pipeline ETL terbalik

Data dipindahkan dari BigQuery ke Spanner Graph dalam pipeline ETL terbalik dalam dua langkah:

  1. BigQuery menggunakan slot yang ditetapkan ke tugas pipeline untuk mengekstrak dan mentransformasi data sumber.

  2. Pipeline reverse ETL BigQuery menggunakan API Spanner untuk memuat data ke instance Spanner yang disediakan.

Diagram berikut menunjukkan langkah-langkah dalam pipeline ETL terbalik:

Diagram yang menunjukkan tiga langkah utama saat data dipindahkan dari BigQuery ke Spanner Graph dalam pipeline ETL terbalik.

Gambar 1. Proses pipeline reverse ETL BigQuery

Mengelola perubahan data grafik

Anda dapat menggunakan ETL terbalik untuk melakukan hal berikut:

  • Memuat set data grafik dari BigQuery ke Spanner Graph.

  • Menyinkronkan data Spanner Graph dengan update berkelanjutan dari set data di BigQuery.

Anda mengonfigurasi pipeline ETL terbalik dengan kueri SQL untuk menentukan data sumber dan transformasi yang akan diterapkan. Pipeline memuat semua data yang memenuhi klausa WHERE dari pernyataan SELECT ke Spanner menggunakan operasi upsert. Operasi upsert setara dengan pernyataan INSERT OR UPDATE. Proses ini menyisipkan baris baru dan memperbarui baris yang ada dalam tabel yang menyimpan data grafik. Pipeline mendasarkan baris baru dan yang diperbarui pada kunci utama tabel Spanner.

Menyisipkan dan memperbarui data untuk tabel dengan dependensi urutan pemuatan

Praktik terbaik desain skema Spanner Graph merekomendasikan penggunaan tabel yang disisipkan dan kunci asing. Jika Anda menggunakan tabel yang disisipkan atau kunci asing yang diterapkan, Anda harus memuat data node dan edge dalam urutan tertentu. Hal ini memastikan baris yang dirujuk ada sebelum Anda membuat baris yang merujuk. Untuk mengetahui informasi selengkapnya, lihat Membuat tabel yang di-interleave.

Skema tabel input grafik contoh berikut menggunakan tabel yang disisipkan dan batasan kunci asing untuk memodelkan hubungan antara seseorang dan akunnya:

CREATE TABLE Person (
  id    INT64 NOT NULL,
  name  STRING(MAX)
) PRIMARY KEY (id);

CREATE TABLE Account (
  id           INT64 NOT NULL,
  create_time  TIMESTAMP,
  is_blocked   BOOL,
  type        STRING(MAX)
) PRIMARY KEY (id);

CREATE TABLE PersonOwnAccount (
  id           INT64 NOT NULL,
  account_id   INT64 NOT NULL,
  create_time  TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id)
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

CREATE PROPERTY GRAPH FinGraph
  NODE TABLES (
    Person,
    Account
  )
  EDGE TABLES (
    PersonOwnAccount
      SOURCE KEY (id) REFERENCES Person
      DESTINATION KEY (account_id) REFERENCES Account
      LABEL Owns
  );

Dalam skema contoh ini, PersonOwnAccount adalah tabel yang disisipkan di Person. Muat elemen dalam tabel Person sebelum elemen dalam tabel PersonOwnAccount. Selain itu, batasan kunci asing pada PersonOwnAccount memastikan baris yang cocok ada di Account, target hubungan edge. Oleh karena itu, muat tabel Account sebelum tabel PersonOwnAccount. Daftar berikut merangkum dependensi urutan pemuatan skema ini:

Ikuti langkah-langkah berikut untuk memuat data:

  1. Muat Person sebelum PersonOwnAccount.
  2. Muat Account sebelum PersonOwnAccount.

Spanner menerapkan batasan integritas referensial dalam skema contoh. Jika pipeline mencoba membuat baris dalam tabel PersonOwnAccount tanpa baris yang cocok dalam tabel Person atau tabel Account, Spanner akan menampilkan error. Kemudian, pipeline akan gagal.

Contoh pipeline reverse ETL ini menggunakan pernyataan EXPORTDATA di BigQuery untuk mengekspor data dari tabel Person, Account, dan PersonOwnAccount dalam set data untuk memenuhi dependensi urutan pemuatan:

BEGIN
EXPORT DATA OPTIONS (
    uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "Person",
      "priority": "HIGH",
      "tag" : "graph_data_load_person"
    }"""
  ) AS
  SELECT
    id,
    name
  FROM
    DATASET_NAME.Person;

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
  spanner_options="""{
    "table": "Account",
    "priority": "HIGH",
    "tag" : "graph_data_load_account"
  }"""
) AS
SELECT
  id,
  create_time,
  is_blocked,
  type
FROM
  DATASET_NAME.Account;

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
  spanner_options="""{
    "table": "PersonOwnAccount",
    "priority": "HIGH",
    "tag" : "graph_data_load_person_own_account"
  }"""
) AS
SELECT
  id,
  account_id,
  create_time
FROM
  DATASET_NAME.PersonOwnAccount;
END;

Menyinkronkan data

Untuk menyinkronkan BigQuery dengan Spanner Graph, gunakan pipeline ETL terbalik. Anda dapat mengonfigurasi pipeline untuk melakukan salah satu hal berikut:

  • Terapkan penyisipan dan pembaruan apa pun dari sumber BigQuery ke tabel target Spanner Graph. Anda dapat menambahkan elemen skema ke tabel target untuk mengomunikasikan penghapusan secara logis dan menghapus baris tabel target sesuai jadwal.

  • Gunakan fungsi deret waktu yang menerapkan operasi penyisipan dan pembaruan serta mengidentifikasi operasi penghapusan.

Batasan integritas referensial

Tidak seperti Spanner, BigQuery tidak menerapkan batasan kunci primer dan kunci asing. Jika data BigQuery Anda tidak sesuai dengan batasan yang Anda buat pada tabel Spanner, pipeline ETL terbalik mungkin gagal saat memuat data tersebut.

ETL terbalik secara otomatis mengelompokkan data ke dalam batch yang tidak melebihi batas mutasi maksimum per commit dan menerapkan batch ke tabel Spanner secara atomik dalam urutan arbitrer. Jika batch berisi data yang gagal dalam pemeriksaan integritas referensial, Spanner tidak memuat batch tersebut. Contoh kegagalan tersebut mencakup baris turunan yang disisipkan yang tidak memiliki baris induk atau kolom kunci asing yang diterapkan tanpa nilai yang cocok di kolom yang dirujuk. Jika batch gagal dalam pemeriksaan, pipeline akan gagal dengan error, dan pipeline akan berhenti memuat batch.

Memahami error batasan integritas referensial

Contoh berikut menunjukkan error batasan integritas referensial yang mungkin Anda temui:

Mengatasi error batasan kunci asing

  • Error: "Batasan kunci asing FK_Account dilanggar pada tabel PersonOwnAccount. Tidak dapat menemukan nilai yang dirujuk di Account(id)"

  • Penyebab: Penyisipan baris ke dalam tabel PersonOwnAccount gagal karena tidak ada baris yang cocok di tabel Account, yang diperlukan oleh kunci asing FK_Account.

Mengatasi error baris induk tidak ada

  • Error: "Baris induk untuk baris [15,1] dalam tabel PersonOwnAccount tidak ada"

  • Penyebab: Penyisipan baris ke PersonOwnAccount (id: 15 dan account_id: 1) gagal karena baris induk dalam tabel Person (id: 15) tidak ada.

Untuk mengurangi risiko error integritas referensial, pertimbangkan opsi berikut. Setiap opsi memiliki kekurangan.

  • Longgarkan batasan untuk mengizinkan Spanner Graph memuat data.
  • Tambahkan logika ke pipeline Anda untuk menghilangkan baris yang melanggar batasan integritas referensial.

Meringankan integritas referensial

Salah satu opsi untuk menghindari error integritas referensial saat memuat data adalah melonggarkan batasan sehingga Spanner tidak menerapkan integritas referensial.

  • Anda dapat membuat tabel yang disisipkan dengan klausa INTERLEAVE IN untuk menggunakan karakteristik penyisipan baris fisik yang sama. Jika Anda menggunakan INTERLEAVE IN, bukan INTERLEAVE IN PARENT, Spanner tidak menerapkan integritas referensial, meskipun kueri diuntungkan dari kolokasi tabel terkait.

  • Anda dapat membuat kunci asing informasional menggunakan opsi NOT ENFORCED. Opsi NOT ENFORCED memberikan manfaat pengoptimalan kueri. Namun, Spanner tidak menerapkan integritas referensial.

Misalnya, untuk membuat tabel input edge tanpa pemeriksaan integritas referensial, Anda dapat menggunakan DDL ini:

CREATE TABLE PersonOwnAccount (
  id          INT64 NOT NULL,
  account_id  INT64 NOT NULL,
  create_time TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id) NOT ENFORCED
) PRIMARY KEY (id, account_id),
INTERLEAVE IN Person;

Mempertahankan integritas referensial di pipeline ETL terbalik

Untuk memastikan pipeline hanya memuat baris yang memenuhi pemeriksaan integritas referensial, sertakan hanya baris PersonOwnAccount yang memiliki baris yang cocok di tabel Person dan Account. Kemudian, pertahankan urutan pemuatan, sehingga Spanner memuat baris Person dan Account sebelum baris PersonOwnAccount yang merujuk padanya.

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag" : "graph_data_load_person_own_account"
    }"""
  ) AS
  SELECT
    poa.id,
    poa.account_id,
    poa.create_time
  FROM `PROJECT_ID.DATASET_NAME.PersonOwnAccount` poa
    JOIN `PROJECT_ID.DATASET_NAME.Person` p ON (poa.id = p.id)
    JOIN `PROJECT_ID.DATASET_NAME.Account` a ON (poa.account_id = a.id)
  WHERE poa.id = p.id
    AND poa.account_id = a.id;

Menghapus elemen grafik

Pipeline Reverse ETL menggunakan operasi upsert. Karena operasi upsert setara dengan pernyataan INSERT OR UPDATE, pipeline hanya dapat menyinkronkan baris yang ada dalam data sumber saat runtime. Artinya, pipeline mengecualikan baris yang dihapus. Jika Anda menghapus data dari BigQuery, pipeline ETL terbalik tidak dapat menghapus data yang sama secara langsung dari Spanner Graph.

Anda dapat menggunakan salah satu opsi berikut untuk menangani penghapusan dari tabel sumber BigQuery:

Melakukan penghapusan logis atau sementara di sumber

Untuk menandai baris secara logis untuk dihapus, gunakan flag yang dihapus di BigQuery. Kemudian, buat kolom di tabel Spanner target tempat Anda dapat menyebarkan tanda. Saat ETL terbalik menerapkan update pipeline, hapus baris yang memiliki tanda ini di Spanner. Anda dapat menemukan dan menghapus baris tersebut secara eksplisit menggunakan DML yang dipartisi. Atau, hapus baris secara implisit dengan mengonfigurasi kolom TTL (time to live) dengan tanggal yang bergantung pada kolom tanda hapus. Tulis kueri Spanner untuk mengecualikan baris yang dihapus secara logis ini. Hal ini memastikan bahwa Spanner mengecualikan baris ini dari hasil sebelum penghapusan terjadwal. Setelah pipeline ETL terbalik berjalan hingga selesai, Spanner mencerminkan penghapusan logis di barisnya. Kemudian, Anda dapat menghapus baris dari BigQuery.

Contoh ini menambahkan kolom is_deleted ke tabel PersonOwnAccount di Spanner. Kemudian, menambahkan kolom expired_ts_generated yang bergantung pada nilai is_deleted. Kebijakan TTL menjadwalkan penghapusan baris yang terpengaruh karena tanggal di kolom yang dihasilkan lebih awal daripada nilai minimum DELETION POLICY.

ALTER TABLE PersonOwnAccount
  ADD COLUMN is_deleted BOOL DEFAULT (FALSE);

ALTER TABLE PersonOwnAccount ADD COLUMN
  expired_ts_generated TIMESTAMP AS (IF(is_deleted,
    TIMESTAMP("1970-01-01 00:00:00+00"),
    TIMESTAMP("9999-01-01 00:00:00+00"))) STORED HIDDEN;

ALTER TABLE PersonOwnAccount
  ADD ROW DELETION POLICY (OLDER_THAN(expired_ts_generated, INTERVAL 0 DAY));

Menggunakan histori perubahan BigQuery untuk INSERT, UPDATE, dan penghapusan logis

Anda dapat melacak perubahan pada tabel BigQuery menggunakan histori perubahannya. Gunakan fungsi CHANGES GoogleSQL untuk menemukan baris yang berubah dalam interval waktu tertentu. Kemudian, gunakan informasi baris yang dihapus dengan pipeline reverse ETL. Anda dapat menyiapkan pipeline untuk menetapkan indikator, seperti tanda dihapus atau tanggal habis masa berlaku, di tabel Spanner. Indikator ini menandai baris untuk dihapus dalam tabel Spanner.

Gunakan hasil dari fungsi deret waktu CHANGES untuk memutuskan baris mana dari tabel sumber yang akan disertakan dalam pemuatan pipeline reverse ETL Anda.

Pipeline menyertakan baris dengan _CHANGE_TYPE sebagai INSERT atau UPDATE sebagai upsert jika baris ada dalam tabel sumber. Baris saat ini dari tabel sumber memberikan data terbaru.

Gunakan baris dengan _CHANGE_TYPE sebagai DELETE yang tidak memiliki baris yang ada di tabel sumber untuk menetapkan indikator dalam tabel Spanner, seperti flag yang dihapus atau tanggal habis masa berlaku baris.

Kueri ekspor Anda harus memperhitungkan urutan penyisipan dan penghapusan di BigQuery. Misalnya, pertimbangkan baris yang dihapus pada waktu T1 dan baris baru yang disisipkan pada waktu T2. Jika keduanya dipetakan ke baris tabel Spanner yang sama, ekspor harus mempertahankan efek peristiwa ini dalam urutan aslinya.

Jika disetel, indikator delete menandai baris untuk dihapus di tabel Spanner.

Misalnya, Anda dapat menambahkan kolom ke tabel input Spanner untuk menyimpan tanggal habis masa berlaku setiap baris. Kemudian, buat kebijakan penghapusan yang menggunakan tanggal habis masa berlaku ini.

Contoh berikut menunjukkan cara menambahkan kolom untuk menyimpan tanggal habis masa berlaku baris tabel.

ALTER TABLE PersonOwnAccount ADD COLUMN expired_ts TIMESTAMP;

ALTER TABLE PersonOwnAccount
  ADD ROW DELETION POLICY (OLDER_THAN(expired_ts, INTERVAL 1 DAY));

Untuk menggunakan fungsi CHANGES pada tabel di BigQuery, tetapkan opsi enable_change_history tabel ke TRUE:

ALTER TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`
  SET OPTIONS (enable_change_history=TRUE);

Contoh berikut menunjukkan cara menggunakan reverse ETL untuk memperbarui baris baru atau yang berubah dan menetapkan tanggal habis masa berlaku untuk baris yang ditandai untuk dihapus. Gabungan kiri dengan tabel PersonOwnAccount memberikan informasi kueri tentang status saat ini setiap baris.

EXPORT DATA OPTIONS (
  uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    format='CLOUD_SPANNER',
    spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag" : "graph_data_delete_via_reverse_etl"
    }"""
  ) AS
SELECT
  DISTINCT
   IF (changes._CHANGE_TYPE = 'DELETE', changes.id, poa.id) AS id,
   IF (changes._CHANGE_TYPE = 'DELETE', changes.account_id, poa.account_id) AS account_id,
   IF (changes._CHANGE_TYPE = 'DELETE', changes.create_time, poa.create_time) AS create_time,
   IF (changes._CHANGE_TYPE = 'DELETE', changes._CHANGE_TIMESTAMP, NULL) AS expired_ts
FROM
  CHANGES(TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`,
    TIMESTAMP_TRUNC(TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY), DAY),
    TIMESTAMP_TRUNC(CURRENT_TIMESTAMP(), DAY)) changes
LEFT JOIN `PROJECT_ID.DATASET_NAME.PersonOwnAccount` poa
  ON (poa.id = changes.id
  AND poa.account_id = changes.account_id)
WHERE (changes._CHANGE_TYPE = 'DELETE'
   AND poa.id IS NULL)
   OR (changes._CHANGE_TYPE IN ( 'UPDATE', 'INSERT')
   AND poa.id IS NOT NULL );

Contoh kueri menggunakan LEFT JOIN dengan tabel sumber untuk mempertahankan urutan. Penggabungan ini memastikan bahwa catatan perubahan DELETE diabaikan untuk baris yang dihapus dan kemudian dibuat ulang dalam interval histori perubahan kueri. Pipeline mempertahankan baris baru yang valid.

Saat Anda menghapus baris, pipeline akan mengisi kolom expired_ts di baris Spanner Graph yang sesuai menggunakan stempel waktu DELETE dari kolom _CHANGE_TIMESTAMP. Kebijakan penghapusan baris (kebijakan TTL) di Spanner menghapus baris apa pun yang nilai expired_ts-nya lebih dari satu hari yang lalu.

Untuk memastikan keandalan sistem, koordinasikan jadwal pipeline, jangka waktu lihat kembali perubahan, dan kebijakan TTL Spanner. Jadwalkan pipeline agar berjalan setiap hari. Kebijakan TTL Spanner harus memiliki durasi yang lebih lama daripada interval proses ini. Hal ini mencegah pipeline memproses ulang peristiwa DELETE sebelumnya untuk baris yang telah dihapus oleh kebijakan TTL Spanner.

Contoh ini menunjukkan interval start_timestamp dan end_timestamp untuk kueri harian yang mencatat semua perubahan tabel BigQuery dari hari UTC sebelumnya. Karena ini adalah kueri batch dan fungsi CHANGES memiliki batasan, end_timestamp harus setidaknya 10 menit sebelum waktu saat ini. Oleh karena itu, jadwalkan kueri ini untuk dijalankan setidaknya 10 menit setelah tengah malam UTC. Untuk mengetahui detail selengkapnya, lihat dokumentasi CHANGES.

Menggunakan kolom TTL dengan stempel waktu terakhir terlihat

Pipeline ETL terbalik menetapkan kolom last_seen_ts ke stempel waktu saat ini untuk setiap baris dalam tabel Spanner. Saat Anda menghapus baris BigQuery, Spanner tidak memperbarui baris yang sesuai, dan kolom last_seen_ts tidak berubah. Kemudian, Spanner menghapus baris dengan last_seen_ts yang sudah tidak berlaku menggunakan kebijakan TTL atau DML yang dipartisi, berdasarkan nilai minimum yang ditentukan. Sebelum penghapusan terjadwal, kueri Spanner dapat memfilter baris dengan last_seen_ts yang lebih lama dari nilai minimum ini. Pendekatan ini berfungsi secara efektif saat data grafik diperbarui secara rutin, dan pembaruan yang tidak ada menunjukkan data usang yang harus dihapus.

Melakukan refresh penuh

Sebelum memuat dari BigQuery, Anda dapat menghapus tabel Spanner untuk mencerminkan penghapusan di tabel sumber. Tindakan ini mencegah pipeline memuat baris yang dihapus dari tabel BigQuery sumber ke Spanner selama eksekusi pipeline berikutnya. Ini mungkin opsi yang paling mudah diterapkan. Namun, pertimbangkan waktu yang diperlukan untuk memuat ulang data grafik Anda sepenuhnya.

Mempertahankan pipeline batch reverse ETL terjadwal

Setelah menjalankan pipeline reverse ETL awal yang memuat data secara massal dari BigQuery ke Spanner Graph, data dunia nyata akan terus berubah. Set data berubah, dan pipeline menambahkan atau menghapus elemen grafik dari waktu ke waktu. Pipeline menemukan node baru dan menambahkan hubungan edge baru, atau inferensi AI membuatnya.

Untuk memastikan database Spanner Graph tetap terbaru, jadwalkan dan urutkan orkestrasi pipeline BigQuery menggunakan salah satu opsi berikut:

BigQuery Pipelines memungkinkan Anda mengembangkan, menguji, mengontrol versi, dan men-deploy alur kerja transformasi data SQL yang kompleks di BigQuery. Secara native, fitur ini menangani dependensi pesanan dengan memungkinkan Anda menentukan hubungan antara kueri dalam pipeline. Dataform membuat hierarki dependensi dan menjalankan kueri Anda dalam urutan yang benar. Hal ini memastikan bahwa dependensi upstream selesai sebelum tugas downstream dimulai.

Workflows yang dipanggil oleh Cloud Scheduler memberikan solusi yang berguna dan fleksibel untuk mengatur urutan Google Cloud layanan, termasuk kueri BigQuery. Tentukan alur kerja sebagai serangkaian langkah yang masing-masing menjalankan tugas BigQuery. Anda dapat menggunakan Cloud Scheduler untuk memanggil alur kerja ini sesuai jadwal yang ditentukan. Kelola dependensi menggunakan definisi alur kerja untuk menentukan urutan eksekusi, menerapkan logika kondisional, menangani error, dan meneruskan output dari satu kueri ke kueri lainnya.

Kueri terjadwal, yang juga dikenal sebagai tugas transfer BigQuery, di BigQuery memungkinkan Anda menjalankan pernyataan SQL secara berulang. Kueri terjadwal tidak menawarkan penanganan error yang andal atau pengelolaan dependensi dinamis.

Reverse ETL dengan kueri berkelanjutan BigQuery

Fitur kueri berkelanjutan BigQuery memungkinkan Anda menjalankan operasi BigQuery yang mendekati real time. Menggabungkan EXPORT DATA dengan kueri berkelanjutan memberikan metode alternatif untuk menjalankan pipeline reverse ETL yang menghindari tugas batch terjadwal.

Kueri berkelanjutan adalah kueri yang berjalan lama yang memantau tabel BigQuery sumber untuk baris baru. Saat mendeteksi baris baru yang ditambahkan ke tabel, BigQuery akan mengalirkan hasil kueri ke operasi EXPORT DATA.

Pendekatan ini memberikan keuntungan sebagai berikut.

  • Sinkronisasi data mendekati real-time: Baris baru di BigQuery ditampilkan di Spanner dengan penundaan minimal.

  • Mengurangi overhead pemrosesan batch: Kueri berkelanjutan menghilangkan kebutuhan akan tugas batch berkala, yang mengurangi overhead komputasi.

  • Pembaruan yang didorong peristiwa: Pembaruan data Spanner sebagai respons terhadap perubahan aktual di BigQuery.

Pipeline kueri berkelanjutan memerlukan penetapan reservasi slot dengan job_type CONTINUOUS. Tetapkan peran ini di tingkat project atau folder atau di tingkat organisasi.

Membuat kueri berkelanjutan dengan ETL terbalik dari BigQuery ke Spanner

Konfigurasi parameter start_timestamp dari fungsi APPENDS untuk mulai memproses data di tempat pemuatan batch dihentikan. Fungsi ini mengambil semua baris yang dibuat dalam jangka waktu tertentu. Pada contoh berikut, pipeline secara arbitrer menetapkan titik awal 10 menit sebelum CURRENT_TIME. Stempel waktu ini harus berada dalam periode perjalanan waktu BigQuery.

Ada beberapa metode untuk memulai pipeline kueri berkelanjutan, termasuk yang berikut:

  1. Di BigQuery Studio, dengan memilih Lainnya dan memilih Kueri berkelanjutan di bagian Pilih mode kueri.

  2. Gunakan CLI bq dan berikan opsi --continuous=true.

EXPORT DATA OPTIONS ( uri="https://spanner.googleapis.com/projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
  format="CLOUD_SPANNER",
  spanner_options="""{
      "table": "PersonOwnAccount",
      "priority": "HIGH",
      "tag": "reverse-etl-continuous",
      "change_timestamp_column": "create_time"
   }"""
)
AS SELECT id, account_id, _CHANGE_TIMESTAMP as create_time
  FROM
APPENDS(TABLE `PROJECT_ID.DATASET_NAME.PersonOwnAccount`,
  CURRENT_TIMESTAMP() - INTERVAL 10 MINUTE )

Urutan pemuatan tidak dijamin

Data Spanner Graph terdiri dari beberapa tabel input. Anda harus mematuhi urutan pemuatan yang ketat saat tabel memiliki batasan integritas referensial. Namun, kueri berkelanjutan serentak tidak dapat mengontrol urutan penambahan baris oleh Spanner. Akibatnya, pemuatan data Spanner Graph menggunakan kueri berkelanjutan hanya untuk skema grafik dengan batasan integritas referensial yang lebih longgar.

Terintegrasi dengan pipeline yang ada

Kueri berkelanjutan melengkapi tugas batch terjadwal yang ada. Misalnya, gunakan kueri berkelanjutan untuk pembaruan hampir real-time dan tugas terjadwal untuk sinkronisasi atau rekonsiliasi data lengkap.

Gunakan kueri berkelanjutan BigQuery untuk membangun pipeline reverse ETL yang responsif dan terbaru untuk menyinkronkan data antara BigQuery dan Spanner Graph.

Pertimbangan kueri berkelanjutan

  • Biaya: Kueri berkelanjutan menimbulkan biaya untuk eksekusi kueri dan streaming data yang sedang berlangsung.

  • Penanganan error: Pipeline kueri berkelanjutan dibatalkan jika mengalami error database, seperti kunci utama duplikat atau pelanggaran integritas referensial. Jika pipeline gagal, Anda harus memperbaiki data secara manual di tabel BigQuery sumber sebelum memulai ulang kueri.

  • Penghapusan dan update tidak ditangani: Fungsi APPENDS hanya mencatat penyisipan. Tidak mencatat penghapusan atau pembaruan.

Mengikuti praktik terbaik reverse ETL

Untuk hasil terbaik, lakukan hal berikut.

  • Pilih strategi untuk mencegah error integritas referensial saat Anda memuat data edge.

  • Rancang pipeline data keseluruhan Anda untuk mencegah ujung yang tidak terhubung. Edge yang tidak terhubung dapat mengganggu efisiensi kueri Spanner Graph dan integritas struktur grafik. Untuk mengetahui informasi selengkapnya, lihat mencegah ujung yang menggantung.

  • Ikuti rekomendasi pengoptimalan ekspor Spanner.

  • Jika Anda memuat data dalam jumlah besar, pertimbangkan untuk membagi pipeline menjadi beberapa pipeline yang lebih kecil untuk menghindari batas waktu eksekusi kueri BigQuery default selama enam jam. Untuk mengetahui informasi selengkapnya, lihat Batas tugas kueri BigQuery.

  • Untuk pemuatan data besar, tambahkan indeks dan batasan kunci asing setelah pemuatan data massal awal selesai. Praktik ini meningkatkan performa pemuatan data karena batasan kunci asing memerlukan pembacaan tambahan untuk validasi dan indeks memerlukan penulisan tambahan. Operasi ini meningkatkan jumlah peserta transaksi, yang dapat memperlambat proses pemuatan data.

  • Aktifkan penskalaan otomatis di Spanner untuk mempercepat waktu pemuatan data ke dalam instance. Kemudian, konfigurasikan parameter priority Spanner di bagian spanner_options perintah BigQuery EXPORT DATA ke HIGH. Untuk mengetahui informasi selengkapnya, lihat Ringkasan penskalaan otomatis Spanner, Mengonfigurasi ekspor dengan opsi spanner_options, dan RequestOptions.priority.

  • Untuk pemuatan data besar, buat titik pemisahan untuk memisahkan database Anda terlebih dahulu. Langkah ini menyiapkan Spanner untuk peningkatan throughput.

  • Konfigurasi prioritas permintaan Spanner untuk pemuatan data dalam definisi pipeline.

Langkah berikutnya