Konsep Partisi, Fitur Dasar Teknologi Big Data

Posted by

Dewasa ini terminologi big data sering kita dengar, khususnya di kalangan praktisi maupun akademisi IT.

Tulisan ini tidak membahas secara umum terkait apa, mengapa, dan bagaimana big data, namun fokus kepada salah satu konsep atau fitur dasar yang ada pada semua teknologi big data saat ini, yaitu partisi. Tulisan ini menjelaskan konsep partisi secara sederhana dengan bantuan analogi yang diharap dapat dikonsumsi oleh praktisi baru atau orang awam dalam ranah big data, sehingga perlu dicatat bahwa pendekatan pada masing-masing teknologi bisa saja berbeda.

Permasalahan

Mengapa harus ada big data? Pertanyaan itu mungkin muncul jika kita lebih dahulu mengenal kata “big data” sebelum memahami atau mengalami masalah yang dapat diselesaikan dengan teknologi big data. Pertama kita coba gambarkan bagaimana dan kapan suatu masalah (yang nantinya dapat diselesaikan dengan teknologi big data) muncul.

Asumsikan kita memiliki suatu toko online (e-commerce) yang mencatat seluruh transaksi pembeli pada suatu basis data (database) misalkan MySQL. Tidak ada yang salah dalam hal ini, semua baik-baik saja, sampai suatu saat query yang dilakukan ke database tadi sudah tidak reliable lagi karena toko semakin berkembang, pelanggan semakin banyak, yang awalnya toko hanya melakukan transaksi dibawah 100 dalam sehari pada ahirnya toko dapat melakukan 1.000.000 transaksi dalam sehari.

Solusi umum yang dilakukan adalah melakukan scale up (meningkatkan kapasitas server, baik meningkatkan kapasitas komputasi, penyimpanan, dan lain-lain) pada server MySQL yang dimiliki. Hal ini wajar, namun perlu diingat scale up memiliki keterbatasan, dalam satu mesin/ instance/ host/ node (kita sebut node kedepannya) jumlah disk yang terpasang memiliki batas maksimal, kapasitas komputasi (core) juga memiliki batasan, bandwith keluar/masuk juga ada batas maksimal, dan lain sebagainya. Sehingga pada suatu titik dalam satu node sudah tidak dapat lagi di-scale up, misal per hari 1.000.000 transaksi tadi jika dikonversi ke penyimpanan data menjadi 20GB per hari, dalam sebulan sudah menjadi 600GB dan terus bertambah.

Apabila hal tersebut terjadi, solusi kedua yang mau tidak mau diambil adalah dengan cara scale out, yaitu menambah jumlah node, sehingga hampir tidak ada lagi batasan terkait kapasitas apapun, karena jumlah node dapat kita tambah secara terus-menerus. Namun permasalahan lain terkait teknologi yang dipakai akan muncul, bagaimana caranya database toko tadi yang menggunakan MySQL dapat kita scale out? Itulah salah satu contoh triggersolusi big data muncul. Dalam tulisan ini kita tidak akan membahas bagaimana men-scale out MySQL, tapi tentang fokus tentang big datakhususnya solusi yang menjawab permasalah pada contoh diatas.

Sebelum ke pendekatan terkait partisi, kita coba menganalogikan kembali terkait permasalahan MySQL tadi, kenapa query bisa berjalan sangat lambat saat data berukuran besar? Hal itu dapat dianalogikan sebagai berikut.

Anggap kita memiliki satu folder yang berisi data-data transaksi tadi, dimana 1 file mewakili 1 transaksi, didalam file tersebut terdapat detail transaksi. Contohnya pada ilustrasi berikut.

/transaction-dir
  |. transaction-1
  |. transaction-2
  |. transaction-3
  ...
  |. transaction-1.000.000.000.000.000.000

Anggap kita adalah MySQL, apabila data hanya berjumlah 100, dan kita disuruh mencari transaksi oleh Pak Agus pada hari Senin minggu ini, file dapat kita temukan dalam directory/ folder tersebut dengan cara membuka satu per satu, cukup lama memang kalau dilakukan oleh manusia, namun sangat cepat apabila dilakukan oleh mesin. Lalu asumsikan jika data sudah sangat banyak seperti contoh, misal kita disuruh mencari transaksi yang dilakukan oleh Pak Imron pada hari Selasa minggu ini, kita pun akan kesusahan, setidaknya akan sangat lama mencarinya, meskipun mesin. Karena lamanya proses pencarian berbanding lurus (linear) dengan jumlah data yang dimiliki. Itulah analogi sederhana terkait masalah pencarian (query) pada database. Ingat, hal ini hanyalah analogi yang mempermudah penjelasan, teknologi dibalik database sekelas MySQL sebenarnya jauh lebih kompleks dan cerdas daripada contoh tersebut.

Dapat disimpulkan masalah yang terjadi pada Big Data adalah:

  1. Data sudah tidak dapat ditampung pada satu host atau scale-up sudah tidak dapat lagi dilakukan.
  2. Proses query sudah tidak realiable dipergunakan.

Setidaknya jika dua masalah tersebut muncul solusi big data dapat dijadikan bahan pertimbangan. Kalau tidak, misal data masih kuat ditampung dalam satu host atau scale up masih memungkinkan, solusi lain seperti optimizing DB schema masih dapat dilakukan, misal memperbaiki dan mengimplementasi index key.

Penjelasan tentang Partisi

Dengan permasalahan yang sudah dicontohkan sebelumnya, asumsikan struktur direktori kita ubah sebagai berikut.

/transaction-dir
  ...
  /user-agus
    ...
    /date-2016-09-19
      /. transaction-1
      /. transaction-2
      /. transaction-3
      ...
    /date-2016-09-20
      /. transaction-1
      /. transaction-2
      /. transaction-3
      ...
    /date-2016-09-21
      /. transaction-1
      /. transaction-2
      /. transaction-3
      ...
    ...
  /user-imron
    ...
    /date-2016-09-19
      /. transaction-1
      /. transaction-2
      /. transaction-3
      ...
    ...
  /user-bayu
    ...
    /date-2016-09-19
      /. transaction-1
      /. transaction-2
      /. transaction-3
      ...
    ...
  ...

Dengan kasus persis seperti sebelumnya kita hendak mencari transaksi oleh Pak Agus pada hari Senin minggu ini (2016–09–19), maka seluruh arsip transaksi dapat kita peroleh pada direktori

/transaction-dir/user-agus/date-2016–09–19/…

Begitu pula kasus yang kedua, saat kita hendak mencari transaksi yang dilakukan oleh Pak Imron pada hari Selasa minggu ini, file dapat secara cepat kita cari pada direktori.

/transaction-dir/user-imron/date-2016–09–20/…

Itulah analogi sederhana terkait partisi. Yaitu data kita kelompokkan secara spesifik sesuai dengan kebutuhan bisnis. Jika kebutuhan bisnis sehari-hari adalah mencari data sesuai dengan pelanggan pada waktu tertentu, maka variabel nama pelanggan (atau ID pelanggan) dan batasan waktu (misal tanggal) dapat kita pakai sebagai partisi untuk mempercepat dalam proses pencarian (query). Sehingga lamanya proses pencarian tidak lagi berbanding lurus dengan banyaknya data yang kita miliki. Kita tidak perlu tahu sudah ada berapa banyak file yang kita miliki, kita tidak perlu mencarinya satu per satu, kita dapat melakukan proses pencarian berdasarkan nama pelanggan dan tanggal langsung ke directory yang dituju secara cepat.

Partisi tersebut adalah salah satu fitur utama dan dasar pada teknologi/ framework/ pustaka (library) big data yang ada saat ini. Dalam teknologi big data, kita/ developer-lah yang menentukan partisi dari data kita akan seperti apa. Sedangkan teknologi yang bersangkutan akan menyimpan data-data dalam partisi-partisi tadi pada node-node yang telah kita siapkan. Hal itu yang menyebabkan proses scaling out dapat dilakukan dengan sangat mudah, karena kita hanya perlu menyipkan sejumlah node sesuai kebutuhan dan data akan terdistribusi ke masing-masing node tadi. Jika kapasitas, misalkan penyimpanan dirasa akan penuh, kita dapat menambahkan satu atau beberapa node lagi dan sisa kapasitas penyimpanan akan bertambah. Hal tersebut yang membedakan antara satu dan lain teknologi big data yang ada. Ada yang berfokus kepada kapasitas penyimpanan, ada yang kapasitas komputasi, dan lain sebagainya.

Contoh Implementasi Big Data

Agar lebih jelas, pada tulisan ini akan dibahas implementasi konsep partisi yang telah dijelaskan pada beberapa teknologi big data yang cukup populer dipergunakan.

  • Hadoop (HDFS), partisi pada HDFS kurang lebih sama dengan ilustrasi pada contoh di atas karena pada dasarnya HDFS “hanya” distributed file system. Masing-masing file diubah dalam bentuk block file, masing-masing block tadi disimpan pada suatu node dengan mekanisme distribusi tertentu. Sehingga kita akan mendapati seolah-olah kita memiliki suatu directory yang sangat besar dengan sub-sub directory (partisi) dengan jumlah yang sangat banyak pada satu interface. Namun sebenarnya di belakang layar, Hadoop mendistribusikan block file tadi ke semua node yang telah di-assign [1].
  • Hive, Apache Hive yang merupakan data warehouse dapat menggunakan HDFS maupun AWS S3 sebagai media penyimpanan data. Partisi pada Hive ditentukan oleh struktur direktori mirip dengan contoh di atas. Berikut contoh struktur direktori dan script untuk membuat tabel pada Hive.
# directory structure
/transaction-dir
  ...
  /user=agus
    ...
    /date=2016-09-19
      /. transaction-1
      /. transaction-2
      /. transaction-3
      ...
    ...
  ...
# hive script
CREATE TABLE `user_transaction`(
  `some_value` bigint,
  `other_column` string,
  `other_column2` string)
PARTITIONED BY ( 
  `user` string, 
  `date` string)
  • Cassandra, partisi pada Cassandra direpresentasikan oleh primary-keyyang kita set pada saat pembuatan tabel. Primary-key pada Cassandra sendiri terdiri dari group/ partition key dan clustering key. Untuk contoh di atas misalkan, kita dapat create table pada Cassandra sebagai berikut. Perhatikan bahwa “user” dan “date_string” merupakan suatu composable-key yang berfungsi sebagai partition key. Sehingga proses query akan sangat cepat (sesuai ekspektasi) jika “user” dan “date_string” telah diketahui, apabila tidak, proses query dapat sangat lambat (tidak sesuai ekspektasi) karena bisa jadi proses query dilakukan secara full scan table(melakukan pencarian pada seluruh file yang dimiliki) [3].
CREATE TABLE group_join_dates (
    user text,
    date_string text,
    timestamp timeuuid,
    details text,
    ...
    PRIMARY KEY ((user, date_string), timestamp)
  • HBase, pada HBase partisi direpresentasikan oleh row key yang kita berikan pada saat menciptakan suatu record (write). Mengingat HBase yang merupakan columnar NoSQL dan tidak perlu adanya skema yang dibutuhkan saat menciptakan tabel selain column family. Untuk menciptakan partisi sesuai dengan contoh kasus di atas, desain dari tabel dapat kita lakukan seperti contoh berikut. Perlu diperhatikan bahkan row key pada HBase berfungsi sebagai partition sekaligus ordering key (sama halnya dengan Cassandra dengan pendekatan yang berbeda) [4].
row key             | items         | total
...
agus_2016–09–19_1   | popok, baju   | 40000
agus_2016–09–19_2   | celana        | 10000
...
imron_2016–09–20_1  | rokok         | 15000
...
  • Spark, lain halnya dengan beberapa contoh di atas, Spark merupakan framework big data untuk melakukan komputasi (bukan database maupun file system), namun selayaknya framework big data lain yang berjalan pada lingkungan sistem terdistribusi (distributed system), Spark memiliki fitur partisi untuk “memecah” data yang hendak dikomputasi. Partisi pada Spark secara teknis disebut RDD (Resilient Distributed Dataset). Data yang dikomputasi menggunakan Spark terdapat “didalam” RDD, dan RDD ini yang didistribusikan oleh Spark ke node-node yang telah kita tentukan sebelumnya [5].

Kesimpulan

Partisi adalah salah satu fitur dasar dan ada pada setiap* teknologi/ framework big data, karena partisi tersebut yang merepresentasikan secara fisik pada sistem terdistribusi (distributed system) lokasi data yang dimiliki diolah, disimpan, atau apapun sesuai dengan fungsi dari masing-masing teknologi big data yang bersangkutan.


*bisa jadi dikemudian hari konsep partisi sudah tidak relevan apabila telah ditemukan metode lain yang lebih baik untuk menggantikannya, namun setidaknya untuk saat ini semua teknologi big data pasti memiliki konsep tersebut.

Referensi

[1] HDFS Architecture Guide

[2] Hive Language Manual

[3] Basic Rules of Cassandra Data Modeling, DataStax

[4] Guidelines for HBase Schema Design, MapR

[5] Spark Programming Guide

Leave a Reply

Your email address will not be published. Required fields are marked *