Cara menyetel impor data untuk berbagai skenario - AnalyticDB

AnalyticDB for MySQL menyediakan berbagai metode impor data untuk skenario yang berbeda. Namun, kinerja impor data dapat terpengaruh oleh faktor-faktor seperti pemodelan tabel yang tidak tepat sehingga menyebabkan data skew atau penggunaan sumber daya yang tidak efisien akibat konfigurasi impor yang suboptimal. Topik ini menjelaskan cara menyetel kinerja impor data dalam berbagai skenario.

Optimalkan impor tabel eksternal

Periksa distribution key

Distribution key menentukan cara data didistribusikan di antara shard untuk impor secara konkuren. Jika data tidak didistribusikan secara merata, shard yang menerima lebih banyak data dapat menjadi bottleneck, menyebabkan data skew dan memperlambat seluruh pekerjaan impor. Untuk menghindari hal ini, pastikan data Anda didistribusikan secara merata selama impor. Untuk informasi lebih lanjut tentang cara memilih distribution key, lihat Choose a distribution key.

Periksa apakah distribution key sesuai:

Sebelum mengimpor data, evaluasi distribution key yang Anda pilih berdasarkan logika bisnisnya. Misalnya, pada tabel Lineitem, jika Anda memilih kolom l_discount sebagai distribution key, kardinalitas rendahnya (hanya 11 nilai unik) akan menyebabkan data skew yang parah. Semua data dengan nilai diskon yang sama akan dikirim ke shard yang sama, menciptakan bottleneck dan menurunkan kinerja. Pilihan yang lebih baik adalah kolom l_orderkey, karena ID pesanan bersifat unik dan mendistribusikan data lebih merata.
Setelah mengimpor data, jika laporan Data Modeling Diagnostics menunjukkan adanya skew pada field distribusi, distribution key Anda menyebabkan distribusi data yang tidak merata. Untuk informasi lebih lanjut tentang cara melihat diagnostik tersebut, lihat Storage diagnostics.

Periksa partition key

Saat Anda menggunakan INSERT OVERWRITE SELECT, partisi yang diimpor akan menimpa partisi yang sudah ada dengan nama yang sama di tabel target. Di dalam setiap shard, data kemudian diimpor ke partisi masing-masing berdasarkan partition key. Untuk menghindari pemicuan proses sorting eksternal yang menurunkan kinerja, jangan mengimpor terlalu banyak partisi sekaligus. Untuk informasi lebih lanjut tentang cara memilih partition key, lihat Choose a partition key.

Periksa apakah partition key sesuai:

Sebelum mengimpor data, evaluasi partition key Anda berdasarkan kebutuhan bisnis dan distribusi data. Misalnya, jika Anda mempartisi tabel Lineitem berdasarkan kolom l_shipdate selama periode 7 tahun, mempartisi berdasarkan hari akan menghasilkan lebih dari 2.000 partisi, yang tidak efisien. Pendekatan yang lebih cocok adalah mempartisi berdasarkan bulan atau tahun.
Setelah mengimpor data, jika laporan Data Modeling Diagnostics menunjukkan jumlah partisi yang tidak wajar, partition key Anda tidak sesuai. Untuk informasi lebih lanjut tentang cara melihat diagnostik tersebut, lihat Partitioned table diagnostics.

Periksa indeks

Secara default, AnalyticDB for MySQL mengindeks semua kolom saat tabel dibuat. Membangun indeks kolom penuh pada wide table sangat intensif sumber daya. Saat Anda mengimpor data ke wide table, gunakan primary key index. Primary key index digunakan untuk deduplikasi, tetapi penggunaan terlalu banyak kolom dalam primary key dapat memperlambat proses ini. Untuk informasi lebih lanjut tentang cara memilih primary key, lihat Choose a primary key.

Periksa apakah indeks sesuai:

Pada skenario impor offline, primary key index biasanya tidak diperlukan karena pekerjaan komputasi offline telah melakukan deduplikasi data.
Pada tab Monitoring Information > Table Information Statistics, lihat ukuran data tabel, data indeks, dan data primary key index. Jika ukuran data indeks melebihi ukuran data tabel, periksa kolom-kolom yang memiliki nilai string panjang. Pengindeksan kolom-kolom ini memakan waktu dan mengonsumsi storage signifikan. Anda dapat menghapus indeks tersebut. Untuk informasi lebih lanjut, lihat ALTER TABLE.

Catatan
Primary key index tidak dapat dihapus. Anda harus membuat ulang tabel tersebut.

Tambahkan hint untuk mempercepat impor

Anda dapat menambahkan hint direct_batch_load=true ke pernyataan impor Anda untuk mempercepat proses impor.

Catatan

Hint ini hanya didukung untuk kluster elastic Data Warehouse Edition versi V3.1.5 atau lebih baru. Jika Anda tidak melihat peningkatan kinerja yang signifikan, Submit a ticket.

Contoh:

SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM adb_external_table;

Percepat impor dengan elastic import

Catatan

Fitur elastic import hanya tersedia untuk kluster dengan versi kernel 3.1.10.0 atau lebih baru.
Fitur ini didukung pada kluster Enterprise Edition, Basic Edition, dan Data Lakehouse Edition yang memiliki job resource group.
Elastic import hanya mendukung data dari MaxCompute dan data CSV, Parquet, atau ORC dari Object Storage Service (OSS).
Saat menggunakan elastic import, pastikan job resource group memiliki sumber daya yang cukup untuk mencegah antrian panjang, eksekusi lambat, dan kegagalan pekerjaan.

Fitur elastic import memungkinkan Anda menjalankan beberapa pekerjaan impor secara konkuren. Anda juga dapat mempercepat satu pekerjaan impor tunggal dengan mengalokasikan lebih banyak sumber daya kepadanya. Untuk informasi lebih lanjut, lihat Data import methods.

Contoh:

/*+ elastic_load=true, elastic_load_configs=[adb.load.resource.group.name=resource_group]*/
submit job insert overwrite adb_table select * from adb_external_table;

Untuk informasi tentang parameter, lihat Hint parameters.

Optimalkan impor data DataWorks

Optimalkan konfigurasi pekerjaan

Optimalkan Data Records Per Write

Parameter ini menentukan ukuran batch untuk setiap impor. Dalam kebanyakan kasus, kami merekomendasikan mempertahankan nilai default 2048.

Namun, jika satu record berukuran besar, misalnya 512 KB, pertimbangkan untuk mengatur parameter ini menjadi 16. Hal ini menjaga ukuran batch di bawah 8 MB dan mencegah penggunaan memori tinggi pada node frontend.
Optimalkan channel control
- Kinerja sinkronisasi data berbanding lurus dengan nilai parameter Expected Maximum Concurrency. Kami merekomendasikan agar Anda meningkatkan nilai Expected Maximum Concurrency sebanyak mungkin.
  
  Penting
  Nilai Expected Maximum Concurrency yang lebih tinggi mengonsumsi lebih banyak sumber daya DataWorks. Pilih nilai yang sesuai dengan kebutuhan Anda.
- Untuk kinerja sinkronisasi yang lebih baik, aktifkan Distributed Execution.

Masalah umum dan solusi

Jika client mengirim data terlalu lambat, utilisasi CPU kluster, I/O disk, dan waktu respons penulisan juga akan rendah. Meskipun server database dapat memproses data yang dikirim dari client, volume inbound yang rendah mengakibatkan write TPS yang lebih rendah dari yang diharapkan.

Solusi: Tingkatkan nilai Data Records Per Write dan Expected Maximum Concurrency. Kinerja impor data meningkat secara linear seiring dengan meningkatnya tekanan impor.
Jika terjadi data skew pada tabel target, beberapa node kluster menjadi kelebihan beban, sehingga menurunkan kinerja impor. Dalam kasus ini, utilisasi CPU dan I/O disk rendah, tetapi waktu respons penulisan tinggi. Anda dapat mengidentifikasi tabel yang skew pada halaman Diagnostics and Optimization > Data Modeling Diagnostics.

Solusi: Rancang ulang skema tabel, lalu impor ulang data tersebut. Untuk informasi lebih lanjut, lihat table schema design.

Optimalkan impor data JDBC

Optimasi sisi client

Batching data di aplikasi Anda
- Saat mengimpor data menggunakan program JDBC, gunakan impor batch untuk mengurangi overhead jaringan dan koneksi. Hindari impor baris tunggal kecuali Anda memiliki persyaratan khusus.
- Ukuran batch 2048 record direkomendasikan. Jika satu record berukuran besar, pastikan ukuran total batch tetap di bawah 8 MB. Anda dapat menghitung jumlah record per batch dengan membagi 8 MB dengan ukuran satu record. Batch yang terlalu besar dapat mengonsumsi terlalu banyak memori pada node frontend dan menurunkan kinerja impor.
Konfigurasikan konkurensi aplikasi
- Saat mengimpor data dari aplikasi, gunakan beberapa thread konkuren. Satu thread tidak dapat memanfaatkan sepenuhnya sumber daya client dan sering kali tidak mampu mengimbangi kecepatan impor database karena pemrosesan dan batching data di sisi client. Impor konkuren dapat meningkatkan kecepatan secara signifikan.
- Tingkat konkurensi optimal bergantung pada faktor-faktor seperti batching, sumber data, dan beban mesin client. Tidak ada nilai terbaik tunggal. Lakukan pengujian untuk menemukan tingkat konkurensi optimal untuk workload Anda. Jika kecepatan impor di bawah ekspektasi, coba gandakan konkurensinya. Jika kecepatan kemudian menurun, kurangi secara bertahap hingga menemukan pengaturan optimal.

Masalah umum dan solusi

Jika Anda mengalami kinerja buruk saat mengimpor data ke AnalyticDB for MySQL dari program kustom, pertama-tama periksa adanya bottleneck kinerja di sisi client.

Pastikan sumber data Anda dapat menyediakan data dengan laju yang cukup. Jika data berasal dari sistem atau file lain, periksa client untuk kemungkinan bottleneck output.
Pastikan kecepatan pemrosesan data, verifikasi bahwa produksi dan konsumsi data tersinkronisasi, serta pastikan data yang cukup sedang menunggu untuk diimpor ke AnalyticDB for MySQL.
Periksa beban mesin client untuk memastikan tersedia sumber daya sistem yang cukup, seperti CPU dan I/O disk.