Strategi Mengoptimalkan Pengeluaran Biaya BigQuery untuk Data Warehouse
Untuk cerita kali ini saya ingin berbagi pengalaman saya terkait bagaimana kita dapat mengatur dan mengoptimalkan biaya data yang telah tersimpan di dalam bigquery. Sebelumnya, jika teman-teman belum pernah mendengar tentang BigQuery, beberapa referensi berikut dapat membantu teman-teman https://cloud.google.com/bigquery/docs/introduction dan https://www.youtube.com/watch?v=d3MDxC_iuaw
Untuk yang ingin hands-on BigQuery secara gratis, ada fitur bernama BigQuery Sandbox https://cloud.google.com/bigquery/docs/sandbox
Sekarang kita tahu bahwa BigQuery dapat kita gunakan untuk keperluan data warehouse. Lalu, semakin lama data kita tentunya akan semakin bertambah dan jumlah data yang kita simpan akan semakin besar. Itulah kenapa historical data sangatlah berharga jika kita ingin melakukan analisa dengan waktu tertentu. Oleh karena semakin banyaknya data yang kita proses maka sebagai data engineer tentunya akan muncul sebuah pertanyaan bagaimana kita bisa mengoptimalkan pengeluaran kita ketika menggunakan tools data warehouse terutama di kasus kali ini kita menggunakan BigQuery.
Berikut beberapa strategi yang dapat kita aplikasikan:
dari segi storage
- billing pricing strategy
- table expiration
- streaming or batching
dari segi processing
- partition table
- cluster table
- query what you need only!
- byte billing control
- dry run
Billing pricing strategy
Dalam BigQuery kita bisa memilih kita ingin di bill dari logical atau physical. Maksudnya apa physical bill? artinya adalah total yang harus dibayar ditentukan dari total physical storage yang digunakan untuk menyimpan data tersebut. Data yang ditaruh di physical akan di compressed. Berikut contohnya
Kita bisa melihat bahwa total logical 231MB dan total physical 212MB. Namun tidak sedikit juga jika logical bytes lebih kecil dibandingkan physical byte. Hal ini dipengaruhi oleh
- cardinality data
- correct data types
Perlu menjadi catatan bahwa physical billing hanya dapat diaktifkan pada dataset level. Sehingga perlu diperhatikan jika kalian ingin merubah billing status dataset, karena bisa saja physical storage lebih besar dibanding logical.
Table Expiration
Gunakan tabel sesuai kebutuhan waktunya. Jika kalian memiliki beberapa environment data untuk melakukan development, selalu pastikan jika data yang sudah tidak digunakan untuk dihapus. Pada BigQuery kita dapat menggunakan table expiration. Kita juga bisa mengaplikasikan ini pada partition level https://cloud.google.com/bigquery/docs/updating-datasets.
Streaming or Batching
Apakah tim kalian membutuhkan data yang real-time dari upstream tabel? jika memang tidak, pastikan kebutuhan streaming data sesuai kebutuhan dan gunakan batch loading data. Karena streaming data akan dikenakan biaya streaming insert.
Partition Table
Mungkin ini sudah menjadi strategi yang sering dijumpai oleh teman-teman. Namun di sini saya ingin mengingatkan bahwa kita dapat memaksa user untuk selalu menggunakan required_partition_filter. Hal ini dapat mengurangi user error ketika melakukan select development data.
CREATE TABLE
mydataset.newtable (transaction_id INT64)
PARTITION BY
_PARTITIONDATE
OPTIONS (
partition_expiration_days = 3,
require_partition_filter = TRUE);Cluster Table
Jika kita sudah menggunakan partition table, kita bisa menggabungkan dengan cluster table. Cluster table akan melakukan sort data pada specific kolom yang kita pilih. Dengan begitu ketika kita ingin melakukan filter dari data tersebut, maka BigQuery akan hanya mencari pada block yang sudah di sort tersebut. Hal ini dapat membantu kita sehingga kita tidak perlu melakukan scan seluruh data.
Query What You Need!
Selalu hindari menggunakan SELECT * saat melakukan query. Hal ini sangat berpengaruh ke dalam bagaimana BigQuery melakukan scan. Selalu hindari dan selalu pilih kolom yang ingin kalian akses. Pada penggunaan sehari-hari kita bisa menggunakan CTE untuk melakukan filtering kolom. Sehingga data yang ingin diproses sudah melalui filtering where yang cukup.
Byte Billing Control
Merupakan fitur yang dapat digunakan untuk bisa membatasi cost dalam melakukan query. Kalian bisa menggunakan ini agar kita selalu bisa membatasi jika kita tidak dengan sengaja melakukan running sebuah tabel yang besar https://cloud.google.com/bigquery/docs/best-practices-costs#console. Untuk admin project, kita dapat melakukan setup ini pada user level dan akan membantu kita melakukan governance user usage https://cloud.google.com/bigquery/docs/custom-quotas. Perlu menjadi catatan, jika kita mencancel job yang sudah running cost akan tetap ada. Namun dengan billing control job tersebut akan gagal di depan.
Dry Run
Untuk kalian yang banyak melakukan development BQ dan eksperimen menggunakan client libraries, fitur dry run dapat membantu untuk memastikan estimasi data yang akan di run sudah sesuai. Dari pengalaman saya, dry run membantu user dalam melihat data yang akan di run. Ketika data yang di plan tidak sesuai, maka kita dapat meng cancel pipeline tersebut dan melakukan submit ulang. Hal ini meningkatkan awereness dan tentunya mencegah data yang salah di run.
Berikut beberapa strategi yang dapat kita gunakan untuk mengoptimalkan cost BigQuery. Jika teman-teman ada cerita yang ingin dibagikan, mari berbagi bersama dan stay connected! Terima kasih
