Penyimpanan Data Warehouse menggunakan Redshift

Penyimpanan Data Warehouse menggunakan Redshift

Pertumbuhan data di perusahaan akan semakin cepat seiring dengan perkembangan teknologi. Analis memperkirakan penyimpanan data di perusahaan akan meningkat 50-60% dengan ukuran data yang berlipat ganda setiap 20 bulan. Dengan pertumbuhan data yang terlalu cepat mengakibatkan sebagian besar data adalah “data gelap”, yaitu data yang dikumpulkan tetapi tidak tersentuh dan tidak dianalisa. Untuk mengantisipasi masalah ini, banyak perusahaan menambah sistem pemrosesan database transaksi mereka dengan data warehouse. Salah satu database yang dapat digunakan adalah Amazon Redshift.

Amazon Redshift adalah sistem basis data relational yang dibangun diatas prinsip PostgreSQL. Database ini dioptimalkan untuk melakukan OLAP (Online Analytical Processing) dengan efisiensi kueri lebih dari petabyte data. Efisiensi kueri dicapai melalui kombinasi:

1. Pemrosesan yang sangat paralel;
2. Desain basis data berorientasi kolom;
3. Kompresi data kolom;
4. Pengoptimalan kueri; dan
5. Kueri terkompilasi

Keunggulan Redshift

• Dioptimalkan untuk data warehouse

Amazon Redshift menggunakan teknik yang efisien dan berbagai inovasi untuk memperoleh tingkat kinerja kueri yang sangat tinggi pada kumpulan data dalam jumlah besar, mulai dari ratusan gigabyte hingga lebih dari satu petabyte. Redshift memiliki arsitektur MPP (Massively Parallel Processing) yang digunakan untuk mendistribusikan operasi SQL dan teknik paralelisasi untuk mengambil keuntungan penuh dari semua sumber daya yang tersedia. Hal-hal tersebut tidak dapat dilakukan oleh data warehouse tradisional.

• Scalable

Amazon Redshift dapat dengan mudah ditingkatkan melalui manajemen konsol AWS atau dengan panggilan API sederhana. Setiap perubahan dapat dilakukan dengan menambah atau menghapus sejumlah node di cloud data warehouse. Node DS (Dense Storage) memungkinkan untuk menangani struktur data warehouse yang sangat besar menggunakan HDD (Hard Disk Drive). Sedangkan, perubahan struktur data warehouse tradisional memerlukan properti perhitungan skala yang sangat kompleks.

• Fully Managed

Amazon Redshift menyediakan layanan backup, upgrade, dan patches secara otomatis.

• Keamanan

Amazon Redshift menggunakan teknik enkripsi standar industri untuk menjaga keamanan data. Redshift mendukung koneksi yang mendukung SSL antara aplikasi klien dan data warehouse agar data tetap aman. Selain itu, Amazon Redshift menggunakan AES-256 yang dipercepat perangkat keras untuk mengenkripsi data saat istirahat.

Performance dan Tuning

Performa Amazon Redshift dapat dimonitor menggunakan manajemen konsol, seperti penggunaan CPU dan memori. Untuk mengurangi beban memori dan CPU, perlu dilakukan proses tuning pada database dan kueri. Berikut adalah beberapa cara tuning untuk meningkatkan performa database Redshift:

Encoding kolom

Amazon Redshift adalah basis data berorientasi kolom, yang berarti bahwa data pada disk diatur per baris, disimpan oleh kolom, dan baris diekstraksi dari penyimpanan kolom saat runtime. Arsitektur ini sangat cocok untuk kueri analitik pada tabel dengan jumlah kolom yang besar, dimana sebagian besar kueri hanya mengakses subset dari semua dimensi dan ukuran yang memungkinkan. Data yang disimpan oleh kolom juga harus di-encoding sesuai dengan tipe data dan jumlah bytenya, yang artinya sangat dikompresi untuk menghasilkan kinerja baca yang tinggi. Berikut adalah tipe encoding yang dapat digunakan berdasarkan tipe data kolom:

Untuk menganalisa kesesuaian tipe encoding dari setiap kolom, dapat menggunakan kueri berikut:

analyze compression [nama_tabel];

Berikut adalah contoh output yang akan dihasilkan dari kueri tersebut menggunakan tabel listing:

Table   | Column         | Encoding | Est_reduction_pct

——–+—————-+———-+——————

listing | listid         | delta    | 75.00

listing | sellerid       | delta32k | 38.14

listing | eventid        | delta32k | 5.88

listing | dateid         | zstd     | 31.73

listing | numtickets     | zstd     | 38.41

listing | priceperticket | zstd     | 59.48

listing | totalprice     | zstd     | 37.90

listing | listtime       | zstd     | 13.39

Distribution Style

Saat menjalankan kueri, pengoptimal kueri mendistribusikan ulang baris ke node komputasi yang diperlukan untuk melakukan gabungan dan agregasi. Tujuan dalam memilih gaya distribusi tabel adalah untuk meminimalkan dampak langkah redistribusi dengan menempatkan data di tempat yang diperlukan sebelum kueri dijalankan.

• Distribusikan tabel fakta dan tabel dimensi menggunakan kolom kunci.

Tabel fakta hanya dapat memiliki satu kunci distribusi. Setiap tabel yang bergabung dengan kunci lain tidak digabungkan dengan tabel fakta. Pilih satu dimensi untuk dikolokasi berdasarkan seberapa sering digabungkan dan ukuran baris yang bergabung. Tentukan kunci utama tabel dimensi dan kunci asing yang sesuai tabel fakta sebagai DISTKEY.

• Pilih dimensi terbesar berdasarkan ukuran dataset yang difilter.

Hanya baris yang digunakan dalam gabungan yang perlu didistribusikan, jadi pertimbangkan ukuran dataset setelah pemfilteran, bukan ukuran tabel.

• Pilih kolom dengan kardinalitas tinggi pada hasil kueri filter.

Misalnya, jika ingin mendistribusikan tabel penjualan pada kolom tanggal, mungkin harus mendapatkan distribusi data yang adil, kecuali jika sebagian besar penjualan musiman. Namun, jika biasanya menggunakan predikat terbatas rentang untuk memfilter periode tanggal yang sempit, sebagian besar baris yang difilter terjadi pada kumpulan irisan terbatas dan beban kerja kueri.

• Ubah beberapa tabel dimensi untuk menggunakan distribusi ALL.

Jika tabel dimensi tidak dapat dikelompokkan dengan tabel fakta atau tabel gabungan penting lainnya, kinerja kueri dapat ditingkatkan secara signifikan dengan mendistribusikan seluruh tabel ke semua node. Distribusi ALL dapat mengalikan persyaratan penyimpanan, menambah waktu proses dan operasi pemeliharaan.

Sort Keys

Sort keys berfungsi untuk mempercepat operasi kueri join, group by, dan order by. Kolom yang menggunakan sort key adalah kolom yang biasanya digunakan sebagai key dalam join, order by, dan group by.

Vacuum

Amazon Redshift menyimpan semua data yang terdapat di database, termasuk data yang telah di hapus dari database. Oleh karena itu, tabel dengan metode SCD (Slowly Changing Dimension) tipe 1 perlu di vacuum secara rutin untuk menghapus data yang telah dihapus dari tabel agar performanya tetap baik. Untuk mengetahui tabel yang perlu di vacuum, dapat menjalankan kueri dibawah ini:

SELECT t.schema AS SCHEMA,

trim(s.perm_table_name) AS TABLE,

(sum(abs(datediff(seconds, coalesce(b.starttime,d.starttime,s.starttime), CASE WHEN coalesce(b.endtime,d.endtime,s.endtime) > coalesce(b.starttime,d.starttime,s.starttime) THEN coalesce(b.endtime,d.endtime,s.endtime) ELSE coalesce(b.starttime,d.starttime,s.starttime) END)))/60)::numeric(24,0) AS minutes,

sum(coalesce(b.rows,d.rows,s.rows)) AS ROWS,

trim(split_part(l.event,’:’,1)) AS event,

substring(trim(l.solution),1,60) AS solution,

max(l.query) AS sample_query,

count(DISTINCT l.query),

q.text AS query_text

FROM stl_alert_event_log AS l

LEFT JOIN stl_scan AS s ON s.query = l.query

AND s.slice = l.slice

AND s.segment = l.segment

LEFT JOIN stl_dist AS d ON d.query = l.query

AND d.slice = l.slice

AND d.segment = l.segment

LEFT JOIN stl_bcast AS b ON b.query = l.query

AND b.slice = l.slice

AND b.segment = l.segment

LEFT JOIN

(SELECT query,

LISTAGG(text) WITHIN

GROUP (

ORDER BY sequence) AS text

FROM stl_querytext

WHERE sequence < 100

GROUP BY query) AS q ON q.query = l.query

LEFT JOIN svv_table_info AS t ON t.table_id = s.tbl

WHERE l.userid > 1

AND l.event_time >= dateadd(DAY, -7, CURRENT_DATE)

AND s.perm_table_name NOT LIKE ‘volt_tt%’

AND SCHEMA IS NOT NULL

GROUP BY 1, 2, 5, 6, query_text

ORDER BY 3 DESC, 7 DESC;

Lebar Kolom

Selama pemrosesan kueri kompleks, hasil kueri perantara mungkin perlu disimpan dalam blok sementara. Tabel sementara ini tidak dikompresi, jadi lebar kolom yang tidak perlu akan mengkonsumsi memori berlebihan dan ruang disk sementara, yang dapat mempengaruhi kinerja kueri. Oleh karena itu, saat membuat tabel, lebar kolom setiap tabel lebih baik menggunakan ukuran yang paling kecil selama memungkinkan.

Referensi

Gupta, A., Agarwal, D., Tan, D., Kulesza, J., Pathak, R., Stefani, S., & Srinivasan, V. (2015, May). Amazon redshift and the case for simpler data warehouses. In Proceedings of the 2015 ACM SIGMOD international conference on management of data (pp. 1917-1923). ACM.

Lars Kamp. (2017, November 15). Amazon Redshift: Data Warehousing for the Masses. Retrieved from https://medium.com/the-rig/amazon-redshift-data-warehousing-for-the-masses-ea1642dc63ea

Ian Meyers. (2015, Desember 10). Top 10 Performance Tuning Techniques for Amazon Redshift. Retrieved from https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-techniques-for-amazon-redshift/

Team Post. (2019, February 28). Amazon Redshift vs RDS: What’s the Difference?. Retrieved from https://www.yurbi.com/blog/amazon-redshift-vs-rds-whats-the-difference/

Disajikan oleh anditika Maulida Purnamasari

Dikirim oleh Antoni Wibowo