MaxCompute：Membangun arsitektur terintegrasi untuk penyimpanan dan pemrosesan data penuh serta inkremental hampir real-time berbasis tabel Delta

Informasi latar belakang

Dalam skenario bisnis yang kurang sensitif terhadap waktu, jika Anda perlu memproses sejumlah besar data sekaligus, Anda dapat langsung menggunakan MaxCompute untuk memenuhi kebutuhan bisnis. Namun, kebutuhan akan pemrosesan data penuh dan inkremental hampir real-time di MaxCompute meningkat seiring dengan pertumbuhan jumlah data dan cakupan skenario bisnis yang lebih luas. Gambar berikut menunjukkan evolusi kebutuhan tersebut.

Sebagai contoh, proses impor data hampir real-time mengharuskan mesin platform memiliki kemampuan seperti isolasi transaksi dan penggabungan otomatis file kecil. Proses penggabungan data penuh dan inkremental memerlukan kemampuan untuk menyimpan, membaca, dan menulis data inkremental serta menggunakan kunci utama. Sebelum arsitektur terintegrasi diperkenalkan di MaxCompute, tiga solusi dalam gambar berikut digunakan dalam skenario bisnis yang kompleks ini. Solusi-solusi ini memiliki kekurangan masing-masing dalam hal biaya, kemudahan penggunaan, latensi, dan throughput, seperti ditunjukkan dalam gambar berikut.

Dalam ekosistem open source big data, solusi tipikal seperti mesin pemrosesan data open source digunakan untuk menyelesaikan masalah-masalah di atas. Mesin-mesin ini termasuk Spark, Flink, dan Trino, dan mereka terintegrasi mendalam dengan format danau data open source seperti Apache Hudi, Delta Lake, Apache Iceberg, dan Apache Paimon. Mesin-mesin ini dibangun di atas mesin komputasi terbuka dan penyimpanan data yang seragam untuk menyelesaikan masalah dalam arsitektur Lambda.

Arstiektur terintegrasi untuk penyimpanan dan pemrosesan data penuh serta inkremental hampir real-time

Untuk mengatasi masalah-masalah di atas, MaxCompute menyediakan arsitektur terintegrasi untuk penyimpanan dan pemrosesan data penuh serta inkremental hampir real-time. Arsitektur ini mendukung berbagai sumber data dan memungkinkan Anda mengimpor data penuh dan inkremental ke layanan penyimpanan tertentu menggunakan alat pengembangan kustom. Dalam arsitektur ini, layanan manajemen data backend secara otomatis mengoptimalkan dan mengatur struktur penyimpanan data. Mesin komputasi seragam digunakan untuk pemrosesan data inkremental hampir real-time dan pemrosesan data batch. Layanan metadata seragam juga disediakan untuk mengelola metadata transaksi dan file. Gambar berikut menunjukkan arsitektur terintegrasi.

Arsitektur terintegrasi saat ini mendukung kemampuan inti tertentu, termasuk tabel kunci utama, upserts real-time, kueri time travel, kueri inkremental, operasi bahasa manipulasi data SQL (DML), dan tata kelola serta optimasi otomatis data tabel. Untuk informasi lebih lanjut tentang cara kerja arsitektur terintegrasi dan operasi terkait, lihat Konsep Dasar dan Operasi Dasar.

Manfaat Arsitektur

Arsitektur terintegrasi untuk penyimpanan dan pemrosesan data penuh serta inkremental hampir real-time mendukung fitur umum utama dari format danau data open source seperti Apache Hudi dan Apache Iceberg untuk memfasilitasi migrasi antara proses bisnis terkait. Sebagai arsitektur baru yang dikembangkan oleh Alibaba Cloud, arsitektur terintegrasi juga memberikan keunggulan yang berbeda dalam hal fungsi, performa, stabilitas, dan integrasi:

• Menggunakan layanan penyimpanan seragam, layanan metadata, dan mesin komputasi untuk integrasi yang mendalam dan efisien. Arsitektur terintegrasi menyediakan penyimpanan hemat biaya, manajemen file data yang efisien, efisiensi kueri tinggi, dan kueri time travel pada data inkremental.

• Menawarkan sistem sintaks SQL yang lengkap dan serbaguna yang dirancang untuk mendukung semua fitur inti.

• Menyediakan alat yang sangat disesuaikan dan dioptimalkan untuk impor data dalam berbagai skenario bisnis yang kompleks.

• Berintegrasi mulus dengan skenario bisnis yang ada di MaxCompute. Ini membantu mengurangi kompleksitas dan risiko migrasi data serta biaya penyimpanan dan komputasi data.

• Mencapai manajemen file sepenuhnya otomatis untuk memastikan stabilitas dan performa operasi baca-tulis yang lebih tinggi. Arsitektur ini juga secara otomatis mengoptimalkan efisiensi penyimpanan dan mengurangi biaya.

• Menyediakan layanan yang sepenuhnya dikelola berdasarkan MaxCompute. Arsitektur terintegrasi ini dapat digunakan langsung tanpa biaya akses tambahan. Anda hanya perlu membuat tabel Delta untuk membuat arsitektur ini berfungsi.

• Mengadopsi jadwal pengembangan yang otonom dan terkendali.

Skenario Bisnis

Format tabel dan tata kelola data

Pembuatan tabel

Untuk mendukung arsitektur terintegrasi untuk penyimpanan dan pemrosesan data penuh serta inkremental hampir real-time, MaxCompute memperkenalkan tabel Delta dan menggunakan format data tabel yang seragam. Arsitektur terintegrasi mendukung semua fitur dari alur kerja pemrosesan batch yang ada dan alur kerja baru seperti penyimpanan dan pemrosesan data inkremental hampir real-time. Pernyataan sampel berikut menunjukkan sintaks untuk membuat tabel.

CREATE TABLE tt2 (pk BIGINT NOT NULL PRIMARY KEY, val STRING) tblproperties ("transactional"="true");
CREATE TABLE par_tt2 (pk BIGINT NOT NULL PRIMARY KEY, val STRING)  PARTITIONED BY (pt STRING) tblproperties ("transactional"="true");

Ketika Anda mengeksekusi pernyataan CREATE TABLE untuk membuat tabel Delta, Anda hanya perlu menentukan kunci utama dan menambahkan konfigurasi "transactional"="true". Kunci utama digunakan untuk memastikan keunikan baris data, dan properti transaksional digunakan untuk mengkonfigurasi mekanisme transaksi ACID (atomicity, consistency, isolation, durability) untuk isolasi snapshot operasi baca-tulis. Untuk informasi lebih lanjut tentang cara membuat tabel, lihat Operasi Tabel.

Parameter kunci untuk tabel Delta

Untuk informasi lebih lanjut tentang parameter untuk tabel Delta, lihat bagian "Parameter untuk tabel Delta" dalam Operasi Tabel. Parameter kunci untuk tabel Delta:

• write.bucket.num: Nilai default adalah 16. Nilai valid: (0, 4096]. Parameter ini menentukan jumlah bucket untuk setiap tabel partisi atau non-partisi. Parameter ini juga menentukan jumlah node konkuren tempat data ditulis. Anda dapat mengubah nilai parameter ini untuk tabel partisi. Jika partisi ditambahkan ke tabel partisi, konfigurasi parameter ini secara otomatis berlaku untuk partisi baru. Anda tidak dapat mengubah nilai parameter ini untuk tabel non-partisi.

  Catatan

  Anda dapat meningkatkan paralelisme penulisan dan kueri data dengan meningkatkan jumlah bucket. Namun, peningkatan bucket juga memiliki dampak negatif. Setiap file data termasuk dalam satu bucket. Semakin banyak bucket, semakin banyak file kecil. Hal ini lebih lanjut meningkatkan biaya penyimpanan dan beban kerja serta menurunkan efisiensi pembacaan. Kami merekomendasikan Anda mematuhi prinsip-prinsip berikut untuk mengonfigurasi jumlah bucket:

  • Skenario umum mencakup tabel non-partisi dan tabel partisi: jika jumlah data kurang dari 1 GB, kami merekomendasikan menyetel jumlah bucket antara 4 dan 16. Jika jumlah data lebih dari 1 GB, kami merekomendasikan menjaga ukuran data per bucket antara 128 MB dan 256 MB. Jika jumlah data melebihi 1 TB, kami merekomendasikan menyesuaikan rentang data setiap bucket antara 500 MB dan 1 GB.

  • Rekomendasi partisi besar untuk tabel inkremental partisi besar:

    Jika sebuah tabel memiliki sejumlah besar partisi (lebih dari 500) tetapi jumlah data kecil, seperti beberapa puluh megabyte, tersimpan di setiap partisi, kami merekomendasikan Anda mengonfigurasi satu atau dua bucket di setiap partisi untuk mencegah terlalu banyak file kecil yang dihasilkan.

• acid.data.retain.hours: Nilai default adalah 24. Nilai valid: [0, 168]. Parameter ini menentukan rentang waktu data historis yang dapat Anda kueri menggunakan fitur kueri time travel. Unit: jam. Jika Anda tidak perlu menggunakan fitur kueri time travel untuk mengkueri data historis, kami merekomendasikan Anda menyetel parameter ini ke 0. Nilai ini menunjukkan bahwa fitur kueri time travel dinonaktifkan. Ini dapat secara signifikan mengurangi biaya penyimpanan data historis. Jika Anda perlu menggunakan fitur kueri time travel untuk mengkueri data historis lebih tua dari 168 jam (7 hari), Anda dapat menghubungi dukungan teknis MaxCompute.

  Kami merekomendasikan Anda menetapkan periode waktu yang wajar berdasarkan skenario bisnis Anda. Jika Anda menetapkan parameter ini ke nilai besar, sejumlah besar data historis disimpan, biaya penyimpanan tinggi terjadi, dan kueri melambat.

  Catatan

  • Setelah periode waktu yang dikonfigurasi berakhir, sistem secara otomatis memulihkan dan membersihkan data historis. Setelah semua data historis dibersihkan, Anda tidak dapat mengkueri data historis menggunakan fitur kueri time travel. Data yang dipulihkan mencakup log operasi dan file data.

  • Dalam kasus khusus, Anda dapat menjalankan perintah purge untuk memaksa membersihkan data historis.

ALTER TABLE tt2 ADD columns (val2 string);

Format data tabel

Gambar di atas menunjukkan struktur data tabel partisi. File data secara fisik diisolasi berdasarkan partisi, dan data di partisi berbeda disimpan di direktori berbeda. Data di setiap partisi dibagi menjadi bucket berdasarkan jumlah bucket. File data di setiap bucket disimpan secara terpisah. File data diklasifikasikan menjadi file data delta dan file data compacted.

• File data delta: file data inkremental yang dihasilkan setelah data setiap transaksi ditulis atau file kecil digabungkan. Data historis perantara dari semua baris disimpan dalam file data delta untuk memenuhi persyaratan baca-tulis inkremental hampir real-time.

• File data compacted: file data yang dihasilkan setelah file data delta dikompresi. File data compacted tidak berisi data historis perantara dari semua baris. Jika beberapa baris rekaman memiliki kunci utama yang sama, hanya satu baris yang dipertahankan. File data compacted menggunakan penyimpanan berorientasi kolom dan kompresi untuk kueri data yang lebih cepat.

Tata kelola dan optimasi data otomatis

• Masalah yang Ada - Pembengkakan File Kecil

  Tabel Delta mendukung impor data inkremental hampir real-time dalam hitungan menit. Dalam skenario penulisan real-time dengan lalu lintas tinggi, jumlah file kecil untuk data inkremental dapat meningkat, terutama ketika sejumlah besar bucket ada. Hal ini dapat menyebabkan masalah seperti permintaan akses berlebih, biaya tinggi, dan efisiensi I/O rendah untuk pembacaan dan penulisan data. Jika sejumlah besar data terlibat dalam operasi UPDATE dan DELETE, sejumlah besar catatan historis perantara yang berlebihan dihasilkan. Hal ini lebih lanjut meningkatkan biaya penyimpanan dan komputasi serta menurunkan efisiensi kueri.

• Solusi - Tata Kelola dan Optimasi Otomatis

  Mesin penyimpanan MaxCompute mendukung layanan data tabel yang masuk akal dan efisien. Layanan ini secara otomatis mengelola dan mengoptimalkan data yang disimpan, mengurangi biaya penyimpanan dan komputasi, serta meningkatkan performa pemrosesan dan analisis data.

  

  Gambar di atas menunjukkan layanan data tabel Delta. Layanan ini mencakup auto sort, auto merge, auto partial compact, dan auto clean. Anda tidak perlu mengonfigurasi layanan ini secara manual. Layanan mesin penyimpanan cerdas mengidentifikasi dan mengumpulkan data dari setiap dimensi secara otomatis, dan memungkinkan Anda mengonfigurasi kebijakan untuk eksekusi otomatis.

  • Auto sort: Mengonversi file Avro berorientasi baris yang ditulis secara real-time menjadi file AliORC berorientasi kolom. Ini secara signifikan mengurangi biaya penyimpanan dan meningkatkan performa pembacaan data.

  • Auto merge: Secara otomatis menggabungkan file kecil untuk menyelesaikan masalah yang disebabkan oleh peningkatan jumlah file kecil.

    Kebijakan utama adalah melakukan analisis komprehensif secara berkala dari berbagai aspek seperti ukuran, jumlah, dan seri waktu penulisan file, lalu menggabungkan file berdasarkan levelnya. Data historis perantara dari semua rekaman tidak dibersihkan dalam proses ini. Ini memastikan integritas dan jejak audit kueri time travel.

  • Auto partial compact: Secara otomatis menggabungkan file dan membersihkan data historis rekaman. Ini membantu mengurangi biaya penyimpanan tambahan yang disebabkan oleh operasi UPDATE dan DELETE yang berlebihan pada rekaman dan meningkatkan efisiensi pembacaan.

    Kebijakan utama adalah melakukan analisis komprehensif secara berkala dari berbagai aspek seperti ukuran data inkremental, seri waktu penulisan, dan waktu kueri time travel, lalu melakukan operasi compact.

    Catatan

    Operasi ini hanya mengompresi rekaman historis yang waktu pembuatannya berada di luar rentang waktu kueri time travel.

  • Auto clean: Secara otomatis membersihkan file yang tidak valid untuk mengurangi biaya penyimpanan. Setelah operasi auto sort, auto merge, dan auto partial compact dilakukan dan file data baru dihasilkan, file data asli menjadi tidak valid. Sistem mulai secara otomatis menghapus file asli secara real-time. Ini membantu menghemat ruang penyimpanan dan mengurangi biaya penyimpanan secara tepat waktu.

  Dalam skenario yang memerlukan performa kueri tinggi, Anda dapat memicu operasi major compact secara manual untuk data penuh. Untuk informasi lebih lanjut, lihat COMPACTION.

  SET odps.merge.task.mode=service;
  ALTER TABLE tt2 compact major;

  Catatan

  Operasi ini mengonsolidasikan semua informasi di setiap bucket, sepenuhnya membersihkan semua data historis, dan menghasilkan file AliORC berorientasi kolom. Namun, operasi ini menghasilkan overhead eksekusi tambahan dan meningkatkan biaya penyimpanan file baru. Kami merekomendasikan Anda melakukan operasi ini hanya jika diperlukan.

Penulisan data

Upserts hampir real-time dalam hitungan menit

Dalam hal pemrosesan data batch, MaxCompute memungkinkan Anda mengimpor data inkremental ke tabel baru atau partisi dalam hitungan menit atau hari. Kemudian, Anda dapat mengonfigurasi proses ETL offline, dan melakukan operasi join dan merge pada data inkremental dan data tabel yang ada untuk menghasilkan data penuh baru. Proses offline ini memiliki latensi panjang dan mengonsumsi sumber daya dan ruang penyimpanan.

Dalam arsitektur terintegrasi untuk penyimpanan dan pemrosesan data penuh serta inkremental hampir real-time, proses upsert real-time dapat mempertahankan latensi 5 hingga 10 menit dari penulisan data hingga kueri. Ini memenuhi persyaratan untuk pemrosesan data hampir real-time dalam hitungan menit. Selain itu, proses ETL kompleks untuk operasi merge tidak diperlukan. Ini membantu mengurangi biaya komputasi dan penyimpanan. Dalam skenario pemrosesan data bisnis aktual, berbagai sumber data terlibat, seperti database, sistem log, atau sistem antrian pesan. Untuk memfasilitasi penulisan data ke tabel Delta, MaxCompute menyediakan plugin konektor Flink open source yang dapat bekerja dengan DataWorks Data Integration dan alat impor data lainnya untuk menerapkan desain dan pengembangan kustom yang dioptimalkan untuk skenario seperti konkurensi tinggi, toleransi kesalahan, dan pengiriman transaksi. Ini dapat mencapai latensi rendah dan akurasi tinggi.

Sebagaimana ditunjukkan dalam gambar di atas:

• Sebagian besar mesin komputasi dan alat yang kompatibel dengan ekosistem Flink memungkinkan Anda mengonfigurasi penyebaran Flink untuk menggunakan konektor Flink MaxCompute secara efisien menulis data ke tabel Delta secara real-time.

• Anda dapat menyesuaikan parameter write.bucket.num untuk tabel Delta untuk mengonfigurasi paralelisme penulisan secara fleksibel. Ini membantu mempercepat operasi penulisan.

  MaxCompute dioptimalkan secara efisien. Jika Anda menyetel parameter write.bucket.num untuk tabel Delta ke kelipatan integer dari paralelisme sink Flink, MaxCompute memberikan performa penulisan terbaik.

• Anda dapat menggunakan mekanisme checkpoint bawaan Flink untuk menerapkan toleransi kesalahan. Ini memastikan bahwa pemrosesan data mengikuti semantik exactly_once.

• Anda dapat menulis data ke ribuan partisi secara bersamaan. Ini memenuhi persyaratan untuk menulis data secara konkuren ke sejumlah besar partisi.

• Data terlihat dalam hitungan menit dan isolasi snapshot didukung untuk operasi baca-tulis.

• Lingkungan dan konfigurasi yang berbeda dapat memengaruhi throughput lalu lintas secara negatif. Anda dapat memperkirakan throughput lalu lintas maksimum berdasarkan kemampuan pemrosesan (1 MB/s) dari satu bucket. Untuk MaxCompute Tunnel, grup sumber daya Tunnel bersama digunakan secara default. Ini dapat menyebabkan throughput tidak stabil terutama ketika terjadi persaingan sumber daya intens. Batasan juga diberlakukan pada konsumsi sumber daya.

Dalam gambar di atas:

• Alur kerja di sebelah kiri menunjukkan arsitektur pemrosesan data batch di MaxCompute. Dalam kebanyakan kasus, data inkremental diimpor ke tabel baru atau partisi dalam hitungan jam atau hari. Kemudian, proses ETL offline yang ditentukan dipicu untuk melakukan operasi join dan merge pada data inkremental dan data tabel yang ada untuk menghasilkan data penuh baru. Proses offline ini memiliki latensi panjang dan mengonsumsi sumber daya dan ruang penyimpanan.

• Alur kerja di sebelah kanan menunjukkan arsitektur terintegrasi untuk penyimpanan dan pemrosesan data penuh serta inkremental hampir real-time. Dibandingkan dengan arsitektur pemrosesan batch di MaxCompute, ekstraksi data periodik dan penggabungan tidak diperlukan dalam arsitektur terintegrasi, dan catatan baru dibaca dari database dalam hitungan menit. Anda dapat memperbarui data hanya dengan menggunakan tabel Delta. Ini meminimalkan biaya komputasi dan penyimpanan.

Kueri data

Kueri time travel

Mesin komputasi tabel Delta MaxCompute cocok untuk skenario bisnis tipikal di mana fitur kueri time travel diaktifkan. Jika Anda mengaktifkan fitur kueri time travel, Anda dapat mengkueri data versi historis. Fitur ini dapat digunakan untuk melacak balik data bisnis historis atau memulihkan data historis untuk koreksi data ketika terjadi kesalahan data. Anda juga dapat langsung menggunakan operasi pemulihan untuk memulihkan data ke versi historis tertentu. Pernyataan berikut menunjukkan contoh.

// Query data historis dengan timestamp tertentu.
SELECT * FROM tt2 TIMESTAMP AS OF '2024-04-01 01:00:00';
// Query data historis yang dihasilkan 5 menit sebelum waktu kueri.
SELECT * FROM tt2 TIMESTAMP AS OF CURRENT_TIMESTAMP() - 300;
// Query data historis yang ditulis untuk commit kedua terakhir.
SELECT * FROM tt2 TIMESTAMP AS OF GET_LATEST_TIMESTAMP('tt2', 2);

Gambar berikut menunjukkan cara melakukan kueri time travel.

Setelah Anda memasukkan pernyataan kueri time travel, sistem mengurai versi data historis dari layanan metadata, memperoleh file data compacted dan file data delta dari mana Anda ingin membaca data, lalu menggabungkan data untuk output. File data compacted dapat digunakan untuk mempercepat kueri dan meningkatkan efisiensi pembacaan.

Gambar di atas menggunakan tabel transaksional bernama src sebagai contoh.

• Di sebelah kiri gambar menunjukkan proses pembaruan data. t1 hingga t5 mewakili versi waktu dari lima transaksi. Lima transaksi penulisan data dieksekusi, dan lima file data delta dihasilkan. Pada t2 dan t4, operasi COMPACTION dilakukan, dan dua file data compacted bernama c1 dan c2 dihasilkan. Dalam file c1, catatan historis perantara (2,a) dihapus dan catatan terbaru (2,b) dipertahankan.

• Untuk mengkueri data historis pada t1, sistem hanya membaca data dari file data delta d1 dan mengembalikan output. Untuk mengkueri data historis pada t2, sistem hanya membaca data dari file data compacted c1 dan mengembalikan tiga rekaman output. Untuk mengkueri data historis pada t3, sistem mengembalikan data dalam file data compacted c1 dan file data delta d3 dan menggabungkan data untuk output. Anda dapat menerapkan aturan yang sama untuk mendapatkan hasil kueri pada titik waktu lainnya. Jika Anda menggunakan file data compacted, kueri dipercepat tetapi operasi COMPACTION sering dipicu. Anda perlu memilih kebijakan pemicu yang sesuai berdasarkan kebutuhan bisnis Anda.

• Dalam sintaks SQL, Anda dapat secara langsung menentukan konstanta dan fungsi umum. Anda juga dapat menggunakan fungsi TIMESTAMP AS OF expr dan VERSION AS OF expr untuk melakukan kueri yang presisi.

Kueri inkremental

Untuk mengoptimalkan kueri inkremental dan komputasi inkremental untuk tabel Delta, MaxCompute merancang dan mengembangkan sintaks kueri inkremental SQL baru. Untuk informasi lebih lanjut tentang sintaks kueri inkremental, lihat bagian "Parameter dan batasan kueri inkremental" dalam Kueri Time Travel dan Kueri Inkremental. Gambar berikut menunjukkan proses kueri inkremental.

Setelah Anda memasukkan pernyataan SQL, mesin MaxCompute mengurai versi data inkremental historis yang akan dikueri, memperoleh file data compacted yang akan dibaca, menggabungkan data file, dan kemudian mengembalikan hasil output. Gambar di atas menggunakan tabel transaksional bernama src sebagai contoh.

• Di sebelah kiri gambar menunjukkan proses pembaruan data. t1 hingga t5 mewakili versi waktu dari lima transaksi. Lima transaksi penulisan data dieksekusi, dan lima file data compacted dihasilkan. Pada t2 dan t4, operasi COMPACTION dilakukan, dan dua file data compacted bernama c1 dan c2 dihasilkan.

• Sebagai contoh, jika begin adalah t1-1 dan end adalah t1, sistem hanya membaca data dari file data delta d1 pada t1 untuk output. Jika end adalah t2, sistem membaca dua file data delta d1 dan d2. Jika begin adalah t1 dan end adalah t2-1, rentang waktu kueri adalah dari t1 hingga t2. Tidak ada data inkremental yang dimasukkan dalam rentang waktu tersebut. Akibatnya, baris kosong dikembalikan.

• Data dalam file c1 dan c2 yang dihasilkan oleh operasi compaction dan penggabungan tidak dianggap sebagai data baru untuk output.

Pengabaian data berbasis kunci utama yang dioptimalkan

Distribusi data dan indeks tabel Delta pada dasarnya dibangun berdasarkan nilai kolom kunci utama. Saat Anda mengkueri data dari tabel Delta, Anda dapat memfilter data berdasarkan nilai kunci utama tertentu. Ini dapat secara signifikan mengurangi jumlah data yang harus dibaca, mempercepat kueri, dan sangat mengurangi konsumsi sumber daya. Efisiensi kueri dapat ditingkatkan ratusan hingga ribuan kali. Proses pengabaian data berbasis kunci utama yang dioptimalkan mencakup penyaringan tingkat multi-level yang tepat untuk secara efisien menemukan dan membaca data dengan nilai kunci utama tertentu. Sebagai contoh, tabel Delta berisi 100 juta rekaman data. Anda dapat memfilter data tabel berdasarkan nilai kunci utama. Setelah penyaringan, hanya 10.000 rekaman data yang mungkin perlu dibaca dari tabel. Gambar berikut menunjukkan proses kueri data.