Analisis teks di AWS: implementasi arsitektur data lake menggunakan OpenSearch

Data teks adalah jenis data tidak terstruktur yang umum dijumpai dalam analisis. Data ini seringkali disimpan tanpa menggunakan predefined format serta berpotensi sulit untuk diperoleh dan diproses.

Sebagai contoh, sebuah halaman web memuat data teks yang dikumpulkan oleh data analyst dengan memanfaatkan metode web scraping dan diproses diawal menggunakan pengkonversian ke huruf kecil, stemming, dan lemmatisasi. Setelah proses awal selesai, teks yang telah dibersihkan dianalisis oleh data scientist dan data analyst untuk mendapatkan insights yang relevan.

Posting blog ini mencakup cara mengelola data teks secara efektif menggunakan arsitektur data lake di Amazon Web Services (AWS). Kami menjelaskan bagaimana tim data dapat secara independen mengekstrak insights dari dokumen teks menggunakan OpenSearch sebagai layanan pencarian dan analisis yang terpusat. Kami juga membahas cara mengindeks dan memperbarui data teks dalam OpenSearch serta mengembangkan arsitektur menuju otomatisasi.

Gambaran arsitektur

Arsitektur ini menjelaskan penggunaan layanan AWS untuk menciptakan solusi analisa teks yang lengkap, mulai dari pengumpulan dan penyampaian data hingga pemanfaatan datanya pada OpenSearch (Gambar 1).

Gambar 1. Arsitektur data lake menggunakan OpenSearch

1. Mengumpulkan data dari beragam sumber, misalnya aplikasi SaaS, perangkat edge, log, media streaming, dan media sosial.
2. Menggunakan tools seperti AWS Database Migration Service (AWS DMS), AWS DataSync, Amazon Kinesis, Amazon Managed Streaming for Apache Kafka (Amazon MSK), AWS IoT Core, dan Amazon AppFlow untuk mengirimkan data ke dalam data lake AWS, sesuai dengan jenis sumber datanya.
3. Menyimpan data yang telah dikirimkan ke dalam area mentah (raw zone) pada data lake Amazon Simple Storage Service (Amazon S3) – sebuah area sementara dimana data disimpan dalam bentuk aslinya.
4. Validasi, pembersihan, normalisasi, transformasi, dan pengayaan data melalui serangkaian langkah-langkah pra-pemrosesan menggunakan AWS Glue atau Amazon EMR.
5. Menempatkan data yang telah siap untuk dilakukan pengindeksan di dalam area pengindeksan.
6. Menggunakan AWS Lambda untuk mengindeks dokumen pada OpenSearch dan menyimpannya kembali ke dalam data lake dengan penanda yang unik.
7. Menggunakan area bersih (clean zone) sebagai source of truth bagi seluruh tim untuk kebutuhan pemanfaatan data dan mengkalkulasi metrik-metrik tambahan.
8. Mengembangkan, melatih, dan menghasilkan metrik-metrik baru menggunakan model machine learning (ML) melalui Amazon SageMaker atau layanan kecerdasan buatan (AI) seperti Amazon Comprehend.
9. Menyimpan metrik-metrik baru ke dalam area pengayaan (enriching zone) bersamaan dengan penanda dokumen OpenSearch.
10. Menggunakan penanda kolom yang dihasilkan dari fase pengindeksan awal untuk mengidentifikasi kolom-kolom yang tepat dan memperbaharuinya di OpenSearch menggunakan metrik-metrik baru yang dikalkulasi menggunakan AWS Lambda.
11. Menggunakan OpenSearch untuk pencarian dokumen dan memvisualisasikannya menggunakan metrik-metrik di dalam OpenSearch Dashboards.

Hal yang Perlu Dipertimbangkan

Orkestrasi data lake antar tim

Arsitektur ini memungkinkan tim data untuk bekerja secara independen pada masing-masing dokumen teks pada tahapan yang berbeda-beda di dalam siklus hidup datanya. Tim data engineer akan mengelola area mentah dan pengindeksan, serta bertanggung jawab terhadap penyampaian dan pra-pemrosesan data untuk kebutuhan pengindeksan di OpenSearch.

Data yang telah dibersihkan disimpan di area bersih, di mana data analyst dan data scientist menghasilkan insight dan mengkalkulasi metrik baru. Metrik-metrik ini nantinya disimpan di zona pengayaan dan diindeks sebagai kolom baru dalam dokumen OpenSearch oleh tim data engineer (Gambar 2).

Gambar 2. Orkestrasi data lake antar tim

Mari kita perdalam melalui sebuah contoh. Misalnya ada sebuah perusahaan yang secara periodik mengambil komentar dari sebuah situs blog dan menggunakannya untuk analisa sentimen menggunakan Amazon Comprehend. Maka dalam kasus ini:

1. Komentar akan dimasukkan ke dalam area mentah data lake.
2. Tim data engineer memproses komentar-komentar dan menyimpannya ke dalam area pengindeksan.
3. Sebuah fungsi lambda akan mengindeks komentar-komentar tersebut ke dalam OpenSearch, melakukan pengayaan terhadap komentar dengan menggunakan ID dokumen pada OpenSearch, lalu menyimpannya ke dalam area bersih.
4. Tim data scientist akan menggunakan data komentar dan melakukan analisa sentimen menggunakan Amazon Comprehend.
5. Metrik-metrik analisa sentimen disimpan ke dalam area metrik pada data lake. Kemudian fungsi Lambda kedua akan memperbaharui data komentar di OpenSearch dengan metrik-metrik baru.

Jika data mentah tidak membutuhkan langkah pra-pemrosesan apapun, maka area pengindeksan dan area bersih dapat digabungkan. Anda dapat meninjau lebih jauh contoh spesifik ini, beserta implementasi kodenya, di dalam  AWS samples repository.

Evolusi Skema

Seiring dengan perkembangan data Anda dalam tahapan-tahapan data lake, skema akan turut berubah dan diperkaya. Melanjutkan contoh sebelumnya, Gambar 3 akan menjelaskan bagaimana skema tersebut berevolusi.

Gambar 3. Evolusi skema dalam tahapan-tahapan data lake

1. Di dalam area mentah, terdapat kolom teks mentah yang diperoleh secara langsung dari tahapan penyampaian data. Rekomendasinya adalah tetap menyimpan versi mentah/asli dari data sebagai cadangan, atau semisal ada kebutuhan untuk melakukan pengulangan pemrosesan di kemudian hari.
2. Pada area pengindeksan, kolom data teks yang telah dibersihkan akan menggantikan kolom data mentah setelah pemrosesan dilakukan.
3. Di area bersih, kita menambahkan sebuah kolom ID baru yang dihasilkan dalam pengindeksan dan identifikasi dokumen OpenSearch dari kolom teks terkait.
4. Dalam area pengayaan, kolom ID wajib diperlukan. Sedangkan kolom-kolom lainnya yang mengandung nama metrik bersifat tidak wajib dan melambangkan metrik-metrik baru yang dikalkulasi oleh tim lain yang nantinya akan ditambahkan pada OpenSearch.

Lapisan Pemanfaatan menggunakan OpenSearch

Di OpenSearch, data dikelola dalam indeks-indeks, yang mana dapat dipandang sebagai sebuah tabel seperti pada basis data relasional. Tiap indeks terdiri dari beberapa dokumen – mirip dengan baris pada tabel – dan bermacam-macam kolom, mirip dengan kolom pada tabel. Anda dapat menambahkan dokumen ke dalam sebuah indeks dengan melakukan pengindeksan dan pembaharuan menggunakan beragam API pengguna yang tersedia untuk bahasa-bahasa pemrograman yang populer.

Sekarang, mari kita dalami bagaimana arsitektur ini mengintegrasikan OpenSearch di dalam tahapan pengindeksan dan pembaharuan.

Pengindeksan dan pembaharuan dokumen menggunakan Python

API pengindeksan dokumen akan memungkinkan Anda untuk mengindeks dokumen menggunakan ID kustom, atau membuat ID yang baru jika sebelumnya belum ada. Untuk mempercepat proses pengindeksan, kita dapat menggunakan API pengindeksan massal untuk melakukan pengindeksan terhadap banyak dokumen dalam sekali pemanggilan.

Kita perlu menyimpan kembali ID yang dihasilkan dari operasi pengindeksan untuk kemudian digunakan mengenali dokumen-dokumen mana yang akan diperbaharui menggunakan metrik-metrik baru. Mari kita dalami dua cara untuk melakukan hal ini:

• Menggunakan request library untuk memanggil REST Bulk Index API (disarankan): respon dari API ini akan mengembalikan ID yang dibuat secara otomatis sesuai dengan kebutuhan kita.
• Gunakan Python Low-Level Client for OpenSearch: ID tidak akan diperoleh dari pemanggilan API dan butuh untuk diisi secara mandiri untuk kemudian disimpan. Kita dapat mempergunakan atomic counter yang disediakan Amazon DynamoDB untuk melakukannya. Hal ini memungkinkan beberapa fungsi lambda untuk melakukan pengindeksan secara paralel tanpa khawatir ID yang berbenturan.

Sesuai dengan Gambar 4, fungsi Lambda akan:

1. Menambahkan atomic counter sesuai dengan jumlah dokumen yang akan diindeks ke dalam OpenSearch.
2. Mendapatkan nilai counter dari pemanggilan API.
3. Mengindeks dokumen menggunakan rentang antara [current counter value, current counter value – number of documents].

Figure 4. Menyimpan ID dari operasi pengindeksan massal menggunakan Python Low-Level Client untuk OpenSearch

Otomasi alur data

Seiring dengan berevolusinya arsitektur menuju otomasi, alur data antar tahapan-tahapan data lake akan mengarah pada event-driven. Dengan mengikuti contoh sebelumnya, kita akan mencoba mengotomasi langkah-langkah pemrosesan data ketika bergerak dari area mentah ke area pengindeksan (Gambar 5).

Figure 5. Otomasi berbasis event-driven pada alur data

Dengan Amazon EventBridge dan AWS Step Functions, kita dapat secara otomatis memicu jobs pra-pemrosesan di  AWS Glue sehingga data kita dapat diproses tanpa membutuhkan intervensi manual.

Pendekatan yang sama juga dapat diterapkan kepada tahapan-tahapan data lake lainnya agar dapat mencapai arsitektur otomatis yang lengkap. Anda dapat meninjau lebih jauh dari implementasi ini pada laman automated language use case.

Kesimpulan

Dalam posting blog ini, kami telah membahas tentang desain arsitektur yang secara efektif mampu menangani data teks menggunakan data lake di AWS. Kami juga menjelaskan bagaimana tim data yang berbeda-beda dapat tetap bekerja secara independen untuk mengekstraksi insight dari dokumen teks pada beragam tahapan dengan mempergunakan OpenSearch sebagai layanan pencarian dan analisa.

Artikel ini diterjemahkan dari artikel asli dengan judul “Text analytics on AWS: implementing a data lake architecture with OpenSearch” yang ditulis oleh Francisco Losada, AWS.