lifelong learner — urip iku urup, currently working on accenture.

Membuat Arsitektur Serverless untuk Menampilkan Big Data pada Peta Secara Near Realtime

0
Degananda.com -

system_architecture_thumb

Menampilkan data dengan jumlah besar pada peta dapat menjadi suatu tantangan tersendiri. Apalagi jika data tersebut harus selalu di update setiap sepersekian detik atau menit (near realtime).

Umumnya, kebutuhan untuk menampilkan data dengan jumlah besar secara near realtime digunakan dalam sistem tracking. Contohnya seperti tracking barang, mobil dan lain sebagainya.

Hal ini membutuhkan arsitektur khusus yang mampu menangani pemrosesan data (write) dan pengambilan data secara masif  (read).

Membuat Arsitektur Serverless untuk Menampilkan Big Data pada Peta Secara Near Realtime

arsitektur yang disajikan akan berbasiskan pada komponen azure cloud antive. Meski begitu, arsitektur tersebut uga dapat di implementasikan di cloud provider lain seperti AWS maupun ali cloud.

Kebutuhan bisnis yang diselesaikan

bigdata2.JPG

masalah yang harus diselesaikan

  • Menampilkan big data (>= 20K data) pada peta setiap 1 menit (read)
  • setiap akan akan diupdate setiap 1 menit (write). Sehingga paling tidak pada satu menit akan terdapat 1,2 juta operasi write

Arsitektur 1 – Redis cache sebagai memory storage

pada arsitektur pertama ini, salah satu backbone penting yang dapat menyelesaikan permasalahan diatas adalah redis cache. yakni memory storage yang dapat menyimpan data dengan kemampuan read & write super cepat. Namun, kemampuan ini tentu dibarengi dengan harga mahal yang harus dibayar.

serverless_big_data_ingestor_and_reader.JPG
arsitektur tipe 1 – redis based storage

Ingestion Service & Eventhub

data akan dikirimkan dari ingestion service yang berasal dari berbagai jenis aplikasi. Pada contoh ini, di ibaratkan data-data tersebut dikirimkan melalui

  1. IoT Sensor
  2. ERP (Enterprise resource planning)
  3. ataupun Legacy system yang telah ada sebelumnya.

Seluruh data tersebut akan dikirimkan pada eventhub dengan menggunakan jumlah partisis sebanyak 32 dan 2 konsumer. Ini dikarenakan terdapat 20K key yang akan diupdate setiap menitnya. Sehingga dalam satu jam maka akan terdapat sekitar 1.2 Juta data pada eventhub.

eventhub juga dapat diubah menjadi service bus apabila diperlukan subscription filtering. Pada kasus ini, kami berasumsi tidak ada kebutuhan bisnis untuk filtering.

Serverless Processing dengan azure function

Setelah itu, data akan diproses oleh function app / azure function (serverless) yang berjalan pada app service. Azure function ini memiliki dua buah fungsi yang akan membaca data yang sama dari eventhub namun dengan konsumer yang berbeda.Sehingga, kedua fungsi tersebut akan berjalan secara pararel.

Hopath cache persistor akan menyimpan data dari eventhub pada cache. Sedangkan warmpath persistor akan menyimpan data dari eventhub  pada MSSQL atau cosmos DB (tergantung dari kebutuhan bisnis). Apabila sistem membutuhkan integrasi data ynag kuat maka MSSQL adalah opsi yang lebih cocok.

hotpath persistor function harus dikonfigurasi dengan prefetch lebih tinggi karena, membutuhkan latency yang rendah atas update setiap datannya. Tetapi pada warmpath dapat menggunakan konfigurasi prefetch yang lebih rendah.

proses ETL(Extract, transform load) akan dijalankan oleh azure function ini. Extract data dari eventhub, transform data dari eventhub menjadi format sesuai dan load data yang telah terstruktur ke redis cache ataupun cosmos/mssql.

Kekurangan dari arsitektur ini adalah proses ETL dilakukan oleh satu function. Sehingga, ragam data yang di masukan ke eventhub dari ingestion service sangat terbatas.

Serverless presentation service

service ini meliput azure function dengan jenis http trigger yang akan mengambil data dari redis cache. UI (User interface) dan map provider tidak secara langsung berhubungan pada function ini melainkan melalui perantara berupa API manager untuk keperluan kemanan (token auth, ip whitelisting/ jika diperlukan, dsb) dan rate limiting.

Untuk keperluan optimisasi pada UI, sangat disarankan untuk melakukan lazy loading saat mengambil data dari api. Contohnya pada kasus menampilkan 20.000 data pada map dapat dibagi menjadi 4 chunk.

iterasi chunk
1 5000
2 5000
3 5000
4 500

Design Redis cache

cache_design_hashmap_redis.JPG

Sangat disarankan untuk menggunakan jenis keys berupa hash map. Ini diperlukan agar dapat mendapatkan keseluruhan data secara cepat karena proses HSCAN() dapat mengambil keys dan nilainya(value) secara bersamaan (satu operasi).

berikut contoh baris kode (ditulis dengan nodejs/javascript) untuk menampilkan data dari redis cache dengan menggunakan hscan() yang dapat menunjang fungsi lazy load pada UI dan map provider.

async function filterGet(cursor){
  console.log('start fetching');
  console.log(new Date());
  let nextCursor;
  const getAll = await client.hscan('datakeys',cursor,
  'COUNT', '5000').then((res) => {
    console.log(res[1].length/2);
    nextCursor = res[0];
    dataRedis : [] = res[1];
  });
  client.end(true);
  console.log('end fetching ');
  console.log('nextCursor : ' + nextCursor);
  console.log(new Date());
}

hashmap ini memiliki performa yang sangat baik, untuk benchmark menampilkan 21K object data dapat dicapai hanya dengan waktu 2 detik dan 77 milisecond seperti pada gambar dibawah ini.

benchmark_redis_hashmap.JPG

Arsitektur 2 – Redis cache sebagai memory storage dengan ETL production line

berbeda dengan arsitektur pertama yang hanya menggunakan satu service azure function sebagai persistornya, pada arsitektur kedua ini menggunakan lebih banyak komponen untuk mengoptimalkan proses ETL.

databricks_as_persistor_serverless_architecture_ingestor.JPG

arsitektur kedua ini di peruntukan apabila data yang disimpan pada eventhub memiliki ragam data yang cukup banyak dan berbagai business rule(aturan bisnis) sehingga memerlukan proses ETL yang lebih intensif.

Databricks disini berperan untuk melakukan ETL dan sangat mampu untuk memproses data dengan ragam jenis yang banyak. Databricks sendiri data berkomunikasi dengan eventhub dan cache dengan bantuan apache spark. Tentunnya jumlah notebook(s) yang diperlukan akan bergantung pada jumlah skenario ataupun kebutuhan bisnis.

level 2 design pada hotpath notebook databricks dengan konsep bronze,silver,gold bar.

level2_design_databricks_bronze_silver_bar.JPG

terdapat best practice dalam membangun production line untuk melakukan ETL secara real time ataupun near realtime. Yakni dengan memanfaatkan konsep bronze, silver dan gold bar. Konsep ini mirip dengan staging-> master -> reporting.

  • Pada layer bronze, maka seluruh data dari eventhub akan ditampung tetapi telah dikategorisasikan.
  • pada layer silver bar, data akan dilakukan normalisasi dan akan disesuaikan dengan data model yang ada.
  • pada layer gold bar, data telah disesuaikan dengan kebutuhan bisnis. Contohnya data telah diproses dan diambil “insightnya” terkait dengan utilisasi order, utilisasi fuel dan lain sebagainnya. Data pada goldbar ini lah yang nantinnya akan di teruskan ke berbagai komponen lain yang siap mengkonsumsi data tersebut.

(Visited 8 times, 1 visits today)
Please follow and like us:

Leave a Reply