Arsitektur data besar

Arsitektur big data mengelola penyerapan, pemrosesan, dan analisis data yang terlalu besar atau kompleks untuk sistem database tradisional. Ambang batas untuk memasuki ranah big data bervariasi di antara organisasi, tergantung pada alat dan kemampuan pengguna mereka. Beberapa organisasi mengelola ratusan gigabyte data, dan organisasi lain mengelola ratusan terabyte. Karena alat untuk mengolah dataset besar berevolusi, definisi big data bergeser dari hanya berfokus pada ukuran data untuk menekankan nilai yang diperoleh dari analitik canggih. Meskipun jenis skenario ini cenderung memiliki data dalam jumlah besar.

Dari tahun ke tahun, lanskap data telah berubah. Apa yang dapat Anda lakukan, atau diharapkan untuk dilakukan, dengan data telah berubah. Biaya penyimpanan telah turun secara dramatis, sementara metode untuk pengumpulan data terus meluas. Beberapa data tiba dengan cepat dan memerlukan pengumpulan dan pengamatan berkelanjutan. Data lain tiba lebih lambat, tetapi dalam gugus besar, dan sering dalam bentuk dekade data historis. Anda mungkin mengalami masalah analitik tingkat lanjut atau masalah yang memerlukan pembelajaran mesin untuk diselesaikan. Arsitektur big data berusaha untuk menyelesaikan tantangan ini.

Solusi big data biasanya melibatkan satu atau beberapa jenis beban kerja berikut:

• Pemrosesan batch sumber big data saat tidak aktif
• Pemrosesan data besar dalam gerakan secara real-time
• Eksplorasi interaktif data besar
• Analitik prediktif dan pembelajaran mesin

Pertimbangkan arsitektur big data saat Anda perlu melakukan tugas-tugas berikut:

• Menyimpan dan memproses data dalam volume yang terlalu besar untuk database tradisional
• Mengubah data yang tidak terstruktur untuk analisis dan pelaporan
• Menangkap, memproses, dan menganalisis aliran data yang tidak terbatas secara real time atau dengan latensi rendah

Komponen arsitektur mahadata

Diagram berikut menunjukkan komponen logis arsitektur big data. Solusi individual mungkin tidak berisi setiap item dalam diagram ini.

Proses dimulai pada sumber data. Data masuk ke penyimpanan data dan penerimaan pesan real-time, yang keduanya terhubung. Data dalam penyimpanan data masuk ke pemrosesan batch, kemudian diteruskan ke penyimpanan data analitik sebelum menuju ke analitik dan pelaporan atau langsung ke analitik dan pelaporan. Data penyerapan pesan secara real-time masuk ke dalam pemrosesan streaming. Kemudian masuk ke penyimpanan data analitik, dilanjutkan dengan analitik dan pelaporan, atau langsung ke analitik dan pelaporan. Pembelajaran mesin menunjuk ke pemrosesan batch dan pemrosesan aliran.

Sebagian besar arsitektur big data mencakup beberapa atau semua komponen berikut:

• Sumber data: Semua solusi big data dimulai dengan satu atau beberapa sumber data. Contohnya meliputi:

  • Penyimpanan data aplikasi, seperti database relasional.
  • File statis yang dihasilkan aplikasi, seperti file log server web.
  • Sumber data real time, seperti perangkat Internet of Things (IoT).

• Penyimpanan data: Data untuk operasi pemrosesan batch biasanya disimpan di penyimpanan file terdistribusi yang dapat menyimpan file besar dalam volume tinggi dalam berbagai format. Jenis penyimpanan data semacam ini sering disebut data lake. Opsi untuk menerapkan penyimpanan ini termasuk Azure Data Lake Store, kontainer blob di Azure Storage, atau OneLake di Microsoft Fabric.

• Pemrosesan batch: Himpunan data berukuran besar, sehingga solusi big data sering memproses file data dengan menggunakan pekerjaan batch yang berjalan lama untuk memfilter, mengagregasi, dan menyiapkan data untuk analisis. Biasanya pekerjaan ini melibatkan membaca file sumber, memprosesnya, dan menulis output ke file baru. Anda dapat menggunakan opsi berikut:

  • Jalankan pekerjaan U-SQL di Azure Data Lake Analytics.

  • Gunakan Hive, Pig, atau pekerjaan MapReduce kustom di kluster Hadoop Azure HDInsight.

  • Gunakan program Java, Scala, atau Python dalam kluster HDInsight Spark.

  • Gunakan bahasa Python, Scala, atau SQL di notebook Azure Databricks.

  • Gunakan bahasa Python, Scala, atau SQL di notebook Fabric.

• Penyerapan pesan real time: Jika solusi mencakup sumber real-time, arsitektur harus menangkap dan menyimpan pesan real-time untuk pemrosesan streaming. Misalnya, Anda dapat memiliki penyimpanan data sederhana yang mengumpulkan pesan masuk untuk diproses. Namun, banyak solusi membutuhkan penyimpanan penyerapan pesan untuk berfungsi sebagai buffer untuk pesan, dan untuk mendukung pemrosesan peluasan skala, pengiriman yang andal, dan semantik antrean pesan lainnya. Bagian arsitektur streaming ini sering disebut sebagai buffering streaming. Opsinya termasuk Azure Event Hubs, Azure IoT Hub, dan Kafka.

• Pemrosesan aliran: Setelah solusi menangkap pesan real-time, solusi harus memprosesnya dengan memfilter, menggabungkan, dan menyiapkan data untuk analisis. Data aliran yang diproses kemudian ditulis ke sink output.

  • Azure Stream Analytics adalah layanan pemrosesan aliran terkelola yang menggunakan kueri SQL yang terus berjalan yang beroperasi pada aliran yang tidak terbatas.

  • Anda dapat menggunakan teknologi streaming Apache sumber terbuka, seperti Spark Streaming, di kluster HDInsight atau Azure Databricks.

  • Azure Functions adalah layanan komputasi tanpa server yang dapat menjalankan kode berbasis peristiwa, yang ideal untuk tugas pemrosesan aliran ringan.

  • Fabric mendukung pemrosesan data real time dengan menggunakan aliran peristiwa dan pemrosesan Spark.

• Pembelajaran mesin: Untuk menganalisis data yang disiapkan dari pemrosesan batch atau streaming, Anda dapat menggunakan algoritma pembelajaran mesin untuk membangun model yang memprediksi hasil atau mengklasifikasikan data. Model-model ini dapat dilatih pada himpunan data besar. Anda dapat menggunakan model yang dihasilkan untuk menganalisis data baru dan membuat prediksi.

  Gunakan Azure Machine Learning untuk melakukan tugas-tugas ini. Pembelajaran Mesin menyediakan alat untuk membangun, melatih, dan menyebarkan model. Atau, Anda dapat menggunakan API bawaan dari layanan Azure AI untuk tugas pembelajaran mesin umum, seperti tugas visi, ucapan, bahasa, dan pengambilan keputusan.

• Penyimpanan data analitis: Banyak solusi big data menyiapkan data untuk analisis dan kemudian melayani data yang diproses dalam format terstruktur yang dapat dikueri alat analitik. Penyimpanan data analitis yang melayani kueri ini dapat menjadi gudang data relasional bergaya Kimball. Sebagian besar solusi kecerdasan bisnis tradisional (BI) menggunakan jenis gudang data ini. Atau, Anda dapat menyajikan data melalui teknologi NoSQL latensi rendah, seperti HBase, atau database Apache Hive interaktif yang menyediakan abstraksi metadata atas file data di penyimpanan data terdistribusi.

  • Azure Synapse Analytics adalah layanan terkelola untuk pergudangan data berbasis cloud skala besar.

  • HDInsight mendukung Interactive Hive, HBase, dan Spark SQL. Alat-alat ini dapat melayani data untuk analisis.

  • Fabric menyediakan berbagai penyimpanan data, termasuk database SQL, gudang data, lakehouse, dan eventhouse. Alat-alat ini dapat melayani data untuk analisis.

  • Azure menyediakan penyimpanan data analitik lainnya, seperti Azure Databricks, Azure Data Explorer, Azure SQL Database, dan Azure Cosmos DB.

• Analitik dan pelaporan: Sebagian besar solusi big data berusaha untuk memberikan wawasan tentang data melalui analisis dan pelaporan. Untuk memberdayakan pengguna untuk menganalisis data, arsitektur mungkin menyertakan lapisan pemodelan data, seperti kubus pemrosesan analitik online multidansa atau model data tabular di Azure Analysis Services. Ini mungkin juga mendukung BI layanan mandiri dengan menggunakan teknologi pemodelan dan visualisasi di Power BI atau Excel.

  Ilmuwan data atau analis data juga dapat menganalisis dan melaporkan melalui eksplorasi data interaktif. Untuk skenario ini, banyak layanan Azure mendukung notebook analitik, seperti Jupyter, untuk memungkinkan pengguna ini menggunakan keterampilan yang ada dengan Python atau Microsoft R. Untuk eksplorasi data skala besar, Anda dapat menggunakan Microsoft R Server, baik mandiri atau dengan Spark. Anda juga dapat menggunakan Fabric untuk mengedit model data, yang memberikan fleksibilitas dan efisiensi untuk pemodelan dan analisis data.

• Orkestrasi: Sebagian besar solusi big data terdiri dari operasi pemrosesan data berulang yang dienkapsulasi dalam alur kerja. Operasi melakukan tugas-tugas berikut:

  • Mengubah data sumber
  • Memindahkan data antara beberapa sumber dan sink
  • Memuat data yang diproses ke dalam penyimpanan data analitik
  • Mendorong hasil langsung ke laporan atau dasbor

  Untuk mengotomatiskan alur kerja ini, gunakan teknologi orkestrasi seperti Azure Data Factory, Fabric, atau Apache Oozie dan Apache Sqoop.

arsitektur lambda

Saat Anda bekerja dengan himpunan data besar, dibutuhkan waktu lama untuk menjalankan jenis kueri yang dibutuhkan klien. Kueri ini tidak dapat dilakukan secara real time. Dan mereka sering memerlukan algoritma seperti MapReduce yang beroperasi secara paralel di seluruh himpunan data. Hasil kueri disimpan secara terpisah dari data mentah dan digunakan untuk kueri lebih lanjut.

Salah satu kelemahan dari pendekatan ini adalah memperkenalkan latensi. Jika pemrosesan memakan waktu beberapa jam, kueri mungkin mengembalikan hasil yang berusia beberapa jam. Idealnya, Anda harus mendapatkan beberapa hasil secara real time, berpotensi dengan hilangnya akurasi, dan menggabungkan hasil ini dengan hasil dari analitik batch.

Arsitektur Lambda mengatasi masalah ini dengan membuat dua jalur untuk aliran data. Semua data yang masuk ke sistem melewati dua jalur berikut:

• Lapisan batch (jalur dingin) menyimpan semua data masuk dalam bentuk mentahnya dan melakukan pemrosesan batch pada data. Hasil pemrosesan ini disimpan sebagai tampilan batch.

• Lapisan kecepatan (jalur panas) menganalisis data secara real time. Lapisan ini dirancang untuk latensi rendah, dengan mengorbankan akurasi.

Lapisan batch mengumpan ke dalam lapisan melayani yang mengindeks tampilan batch demi kueri yang efisien. Lapisan kecepatan memperbarui lapisan penyajian dengan pembaruan bertahap berdasarkan data terbaru.

Sumber aliran data adalah log data peristiwa terpadu. Data masuk ke lapisan cepat atau lapisan batch. Dari lapisan kecepatan, garis tegas menunjuk ke klien analitik dan garis terputus menunjuk ke lapisan penyajian. Dari lapisan batch, data masuk ke lapisan penyajian dan kemudian klien analitik. Lapisan kecepatan diberi label sebagai jalur panas. Lapisan batch dan lapisan penyajian diberi label sebagai jalur dingin.

Data yang mengalir ke jalur panas harus diproses dengan cepat karena persyaratan latensi yang diberlakukan lapisan kecepatan. Pemrosesan cepat memastikan bahwa data siap untuk digunakan segera tetapi dapat memperkenalkan ketidakakuratan. Misalnya, pertimbangkan skenario IoT di mana banyak sensor suhu mengirim data telemetri. Lapisan kecepatan mungkin memproses jendela waktu geser data masuk.

Data yang mengalir ke jalur dingin tidak tunduk pada persyaratan latensi rendah yang sama. Jalur dingin menyediakan komputasi akurasi tinggi di seluruh himpunan data besar tetapi dapat memakan waktu lama.

Akhirnya, jalur panas dan dingin bertemu di aplikasi klien analitik. Jika klien perlu menampilkan data yang tepat waktu namun mungkin kurang akurat secara real-time, klien memperoleh hasilnya dari jalur cepat. Jika tidak, klien memilih hasil dari jalur dingin untuk menampilkan data yang kurang tepat waktu tetapi lebih akurat. Dengan kata lain, jalur panas memegang data dalam jangka waktu yang relatif kecil, setelah itu hasilnya dapat diperbarui dengan data yang lebih akurat dari jalur dingin.

Data mentah yang disimpan di lapisan batch tidak dapat diubah. Data masuk ditambahkan ke data yang ada, dan data sebelumnya tidak ditimpa. Perubahan pada nilai datum tertentu disimpan sebagai rekaman peristiwa bertanda waktu baru. Rekaman peristiwa bertanda waktu memungkinkan komputasi ulang kapan saja di seluruh riwayat data yang dikumpulkan. Kemampuan untuk mengolah ulang tampilan batch dari data mentah asli penting karena memungkinkan pembuatan tampilan baru saat sistem berkembang.

Arsitektur Kappa

Kelemahan arsitektur Lambda adalah kompleksitasnya. Logika pemrosesan muncul di dua tempat yang berbeda, jalur dingin dan panas, melalui kerangka kerja yang berbeda. Proses ini mengarah pada logika komputasi duplikat dan manajemen arsitektur yang kompleks untuk kedua jalur.

Arsitektur Kappa adalah alternatif untuk arsitektur Lambda. Ini memiliki tujuan dasar yang sama dengan arsitektur Lambda, tetapi semua data mengalir melalui satu jalur melalui sistem pemrosesan aliran.

Sumber aliran data adalah log data peristiwa terpadu. Data masuk ke lapisan kecepatan atau penyimpanan jangka panjang. Baris dari data sumber ke penyimpanan jangka panjang menyatakan "cerminkan kejadian ke penyimpanan jangka panjang." Penyimpanan jangka panjang menunjuk ke lapisan kecepatan. Baris ini berbunyi "hitung ulang kejadian log dari penyimpanan jika diperlukan." Lapisan kecepatan menunjuk ke klien analitik dan diuraikan dalam warna hijau.

Mirip dengan lapisan batch arsitektur Lambda, data peristiwa tidak dapat diubah dan semuanya dikumpulkan, bukan subset data. Data diserap sebagai aliran peristiwa ke dalam log terpadu terdistribusi dan toleran terhadap kesalahan. Peristiwa-peristiwa tersebut diurutkan, dan keadaan peristiwa saat ini diubah hanya oleh acara baru yang ditambahkan. Mirip dengan lapisan kecepatan arsitektur Lambda, semua pemrosesan peristiwa dilakukan pada aliran input dan bertahan sebagai tampilan real-time.

Jika Anda perlu mengolah ulang seluruh himpunan data (setara dengan apa yang dilakukan lapisan batch dalam arsitektur Lambda), Anda dapat memutar ulang aliran. Proses ini biasanya menggunakan paralelisme untuk menyelesaikan komputasi secara tepat waktu.

Arsitektur dari Lakehouse

Data lake adalah repositori data terpusat yang menyimpan data terstruktur (tabel database), data semi terstruktur (file XML), dan data yang tidak terstruktur (file gambar dan audio). Data ini dalam format mentah dan asli dan tidak memerlukan skema yang telah ditentukan sebelumnya. Data lake dapat menangani data dalam volume besar, sehingga cocok untuk pemrosesan dan analitik big data. Data lake menggunakan solusi penyimpanan berbayar rendah, yang menyediakan cara hemat biaya untuk menyimpan data dalam jumlah besar.

Gudang data adalah repositori terpusat yang menyimpan data terstruktur dan semi terstruktur untuk tujuan pelaporan, analisis, dan BI. Gudang data dapat membantu Anda membuat keputusan berdasarkan informasi dengan memberikan tampilan data Anda yang konsisten dan komprehensif.

Arsitektur Lakehouse menggabungkan elemen data lake dan gudang data terbaik. Pola ini bertujuan untuk menyediakan platform terpadu yang mendukung data terstruktur dan tidak terstruktur, yang memungkinkan manajemen dan analitik data yang efisien. Sistem ini biasanya menggunakan penyimpanan cloud berbayar rendah dalam format terbuka, seperti Parquet atau Optimized Row Columnar, untuk menyimpan data mentah dan yang diproses.

Kasus penggunaan umum untuk arsitektur lakehouse meliputi:

• Analitik terpadu: Ideal untuk organisasi yang membutuhkan satu platform untuk analisis data historis dan real time

• Pembelajaran mesin: Mendukung beban kerja analitik dan pembelajaran mesin tingkat lanjut dengan mengintegrasikan kemampuan manajemen data

• Tata kelola data: Memastikan kepatuhan dan kualitas data di seluruh himpunan data besar

IoT

IoT mewakili perangkat apa pun yang terhubung ke internet dan mengirim atau menerima data. Perangkat IoT termasuk PC, ponsel, jam tangan pintar, termostat pintar, kulkas pintar, mobil yang terhubung, dan implan pemantauan jantung.

Jumlah perangkat yang terhubung tumbuh setiap hari, dan begitu juga jumlah data yang mereka hasilkan. Data ini sering dikumpulkan di lingkungan yang memiliki kendala signifikan dan terkadang latensi tinggi. Dalam kasus lain, ribuan atau jutaan perangkat mengirim data dari lingkungan latensi rendah, yang membutuhkan penyerapan dan pemrosesan yang cepat. Anda harus merencanakan dengan benar untuk menangani batasan dan persyaratan unik ini.

Arsitektur berbasis peristiwa adalah bagian utama dari solusi IoT. Diagram berikut menunjukkan arsitektur logis untuk IoT. Diagram menekankan komponen arsitektur yang melakukan streaming peristiwa.

Aliran data dimulai dengan perangkat pada sisi kiri, tersambung ke gateway lapangan, yang kemudian tersambung ke gateway cloud. Gateway cloud tersambung ke berbagai tugas melalui pemrosesan aliran. Tugas-tugas tersebut termasuk penyimpanan dingin, analitik jalur panas, pemberitahuan, dan pembelajaran mesin. Analisis batch mengarah ke penyimpanan dingin. Pemrosesan streaming mengarah ke bagian belakang aplikasi, yang mengarah ke perintah dan pengendalian, API penyediaan, dan registri perangkat. API provisi menunjuk ke registri perangkat. Perintah dan kontrol menunjuk ke gateway bidang asli dan ke perangkat lain, bukan perangkat asli dalam aliran data.

Gerbang cloud menyerap event perangkat di batas cloud melalui sistem olahpesan latensi rendah yang andal.

Perangkat mungkin mengirim peristiwa langsung ke gateway cloud atau melalui gateway lapangan. Gateway bidang adalah perangkat atau perangkat lunak khusus yang biasanya terpasang bersama perangkat, dan menerima kegiatan serta meneruskannya ke gateway cloud. Gateway lapangan mungkin juga memproses lebih awal kejadian perangkat mentah, yang mencakup melakukan fungsi penyaringan, agregasi, atau transformasi protokol.

Setelah penyerapan, peristiwa melalui satu atau beberapa prosesor streaming yang dapat merutekan data ke tujuan, seperti penyimpanan, atau melakukan analitik dan pemrosesan lainnya.

Jenis pemrosesan umum meliputi:

• Mencatat data kejadian ke penyimpanan dingin untuk pengarsipan atau analitik batch.

• Analitik jalur panas. Menganalisis aliran peristiwa secara hampir real-time untuk mendeteksi anomali, mengenali pola dalam jendela waktu yang bergulir, atau mengaktifkan peringatan saat kondisi tertentu terjadi dalam aliran.

• Menangani jenis pesan non-telemetri khusus dari perangkat, seperti pemberitahuan dan alarm.

• Pembelajaran mesin.

Dalam diagram sebelumnya, kotak abu-abu adalah komponen dari sistem IoT yang tidak terkait langsung dengan streaming peristiwa. Mereka disertakan dalam diagram untuk kelengkapan.

• registri perangkat adalah database perangkat yang disediakan, termasuk ID perangkat dan biasanya metadata perangkat, seperti lokasi.

• API provisi adalah antarmuka eksternal umum untuk menyediakan dan mendaftarkan perangkat baru.

• Beberapa solusi IoT memungkinkan perintah dan mengontrol pesan dikirim ke perangkat.

Langkah selanjutnya

• Pusat IoT
• Event Hubs
• Analisis Streaming
• Azure Data Explorer
• Fabric
• Azure Databricks

Sumber daya terkait

• arsitektur IoT
• Gaya arsitektur data besar
• Arsitektur analitik modern dengan Azure Databricks
• Arsitektur big data dengan Fabric