Arsitektur data besar dirancang untuk menangani penyerapan, pemrosesan, dan analisis data yang terlalu besar atau kompleks untuk sistem database tradisional. Ambang batas di mana organisasi masuk ke ranah mahadata berbeda-beda, tergantung dari kemampuan pengguna dan alat mereka. Bagi sebagian orang, itu bisa berarti ratusan gigabyte data, sementara untuk yang lain itu berarti ratusan terabyte. Seiring alat yang digunakan untuk mengerjakan himpunan data yang besar mengalami perubahan, begitu juga arti mahadata. Semakin banyak, istilah ini berkaitan dengan nilai yang dapat Anda ekstrak dari himpunan data Anda melalui analitik tingkat lanjut, daripada hanya merujuk pada ukuran data saja, meskipun dalam kasus ini ukurannya cenderung cukup 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 cara pengumpulan data terus mengalami pertumbuhan. Beberapa data datang dengan cepat, senantiasa menuntut untuk dikumpulkan dan diamati. Data lain tiba lebih lambat, tetapi dalam gugus yang sangat besar, seringkali dalam bentuk data historis selama beberapa dekade. Anda mungkin menghadapi masalah analitik tingkat lanjut, atau masalah yang membutuhkan pembelajaran mesin. Ini adalah tantangan yang ingin dipecahkan oleh arsitektur mahadata.
Solusi mahadata biasanya melibatkan satu atau beberapa jenis beban kerja berikut:
- Pemrosesan batch atas sumber mahadata yang tidak aktif.
- Pemrosesan real time data besar yang bergerak.
- Eksplorasi interaktif mahadata.
- Analisis prediktif dan pembelajaran mesin.
Pertimbangkan arsitektur mahadata ketika Anda perlu untuk:
- Menyimpan dan memproses data dalam volume yang terlalu besar untuk database tradisional.
- Mengubah data yang tidak terstruktur untuk analisis dan pelaporan.
- Mengambil, memproses, dan menganalisis aliran data yang tidak terbatas secara real time, atau dengan latensi rendah.
Komponen arsitektur mahadata
Diagram berikut menunjukkan komponen logis yang sesuai dengan arsitektur mahadata. Tiap-tiap solusi mungkin tidak mencakuo setiap item dalam diagram ini.
Sebagian besar arsitektur data besar mencakup beberapa atau semua komponen berikut:
Sumber data. Semua solusi mahadata dimulai dengan satu atau beberapa sumber data. Contohnya meliputi:
- Penyimpanan data aplikasi, seperti database relasional.
- File statik yang dihasilkan oleh aplikasi, seperti file log server web.
- Sumber data real-time, seperti perangkat IoT.
Penyimpanan data. Data untuk operasi pemrosesan batch biasanya disimpan dalam penyimpanan file terdistribusi yang dapat menyimpan file dalam jumlah besar dengan berbagai format. Penyimpanan semacam ini sering disebut data lake. Opsi untuk menerapkan penyimpanan ini termasuk Azure Data Lake Store atau kontainer blob di Azure Storage.
Pemrosesan batch. Karena himpunan datanya sangat besar, solusi data besar sering kali harus memproses file data 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. Opsinya meliputi menjalankan pekerjaan U-SQL di Azure Data Lake Analytics, menggunakan Apache Hive, Pig, atau custom Map/Reduce jobs dalam kluster HDInsight Hadoop, atau menggunakan program Java, Scala, atau Python dalam kluster HDInsight Spark.
Penyerapan pesan secara real-time. Jika solusinya mencakup sumber data real time, arsitektur harus menyertakan cara untuk mengambil dan menyimpan pesan real time untuk pemrosesan aliran. Ini mungkin berupa penyimpanan data sederhana, tempat pesan masuk diletakkan ke folder untuk diproses. Namun, banyak solusi yang membutuhkan penyimpanan penyerapan pesan untuk bertindak sebagai buffer pesan, dan mendukung pemrosesan peluasan skala, pengiriman yang andal, dan semantik antrean pesan lainnya. Bagian dari arsitektur streaming ini sering disebut sebagai stream buffering. Opsinya termasuk Azure Event Hubs, Azure IoT Hub, dan Kafka.
Pemrosesan aliran. Setelah menangkap pesan real-time, solusi harus memprosesnya dengan memfilter, menggabungkan, dan menyiapkan data untuk dianalisis. Data aliran yang diproses kemudian ditulis ke sink output. Azure Stream Analytics dilengkapi dengan layanan pemrosesan aliran terkelola berdasarkan kueri SQL yang terus berjalan yang beroperasi di aliran tak terbatas. Anda juga dapat menggunakan teknologi streaming apache sumber terbuka seperti Spark Streaming dalam kluster HDInsight.
Pembelajaran mesin. Membaca data yang disiapkan untuk analisis (dari pemrosesan batch atau aliran), algoritma pembelajaran mesin dapat digunakan untuk membangun model yang dapat memprediksi hasil atau mengklasifikasikan data. Model-model ini dapat dilatih pada himpunan data besar, dan model yang dihasilkan dapat digunakan untuk menganalisis data baru dan membuat prediksi. Ini dapat dilakukan menggunakan Azure Pembelajaran Mesin
Penyimpanan data analitis. Banyak solusi mahadata dirancang untuk menyiapkan data untuk analisis dan kemudian menyajikan data yang diproses dalam format terstruktur yang dapat dikueri menggunakan alat analisis. Penyimpanan data analitis yang digunakan untuk melayani kueri ini bisa menjadi gudang data relasional bergaya Kimball, seperti yang terlihat di sebagian besar solusi inteligensi bisnis tradisional (BI). Sebagai alternatif, data dapat disajikan melalui teknologi NoSQL latensi rendah seperti HBase, atau database Interactive Hive yang menyediakan abstraksi metadata melalui file data di penyimpanan data terdistribusi. Azure Synapse Analytics menyediakan layanan terkelola untuk pergudangan data berbasis cloud dengan skala besar. HDInsight mendukung Interactive Hive, HBase, dan Spark SQL, yang juga dapat digunakan untuk menyajikan data untuk analisis.
Analisis dan pelaporan. Tujuan dari sebagian besar solusi mahadata adalah untuk memberikan wawasan tentang data dan pelaporan. Untuk memberdayakan pengguna dalam menganalisis data, arsitektur dapat mencakup lapisan pemodelan data, seperti kubus OLAP multidimensi atau model data berbentuk tabel di Azure Analysis Services. Ini mungkin juga mendukung BI layanan mandiri, menggunakan teknologi pemodelan dan visualisasi yang ada di Microsoft Power BI atau Microsoft Excel. Analisis dan pelaporan juga dapat berbentuk eksplorasi data interaktif oleh ilmuwan data atau analis data. Untuk skenario ini, banyak layanan Azure yang mendukung notebook analitis, seperti Jupyter, memungkinkan pengguna ini memanfaatkan keterampilannya dengan Python atau R. Untuk eksplorasi data skala besar, Anda dapat menggunakan Microsoft R Server, baik secara mandiri atau dengan Spark.
Orkestrasi. Sebagian besar solusi mahadata terdiri dari operasi pemrosesan data yang berulang-ulang, dikemas dalam alur kerja, yang mengubah data sumber, memindahkan data antara beberapa sumber dan sink, memuat data yang diproses ke penyimpanan data analitis, atau menampilkan hasilnya langsung ke laporan atau dasbor. Untuk mengotomatiskan alur kerja ini, Anda dapat menggunakan teknologi orkestrasi seperti Azure Data Factory atau Apache Oozie dan Sqoop.
arsitektur lambda
Ketika bekerja dengan himpunan data yang sangat besar, diperlukan waktu lama untuk menjalankan jenis kueri yang dibutuhkan klien. Kueri ini tidak dapat dilakukan secara waktu nyata, dan sering kali memerlukan algoritme seperti MapReduce yang beroperasi secara paralel di seluruh kumpulan data. Hasilnya kemudian disimpan secara terpisah dari data mentah dan digunakan untuk kueri.
Salah satu kelemahan dari pendekatan ini adalah bahwa ia membawa latensi - jika pemrosesan memakan waktu beberapa jam, kueri dapat mengembalikan hasil yang berusia beberapa jam. Idealnya, Anda ingin mendapatkan beberapa hasil secara real time (mungkin dengan beberapa kehilangan akurasi), dan menggabungkan hasil ini dengan hasil dari analitik batch.
Arsitektur lambda, pertama diusulkan oleh Nathan Marz, mengatasi masalah ini dengan membuat dua jalur untuk aliran data. Semua data yang masuk ke sistem melewati dua jalur ini:
Lapisan batch (jalur dingin) menyimpan semua data yang masuk dalam bentuk mentahnya dan melakukan pemrosesan batch pada data. Hasil dari 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 melayani dengan pembaruan tambahan berdasarkan data terbaru.
Data yang mengalir ke jalur panas dibatasi oleh persyaratan latensi yang diberlakukan oleh lapisan kecepatan, sehingga dapat diproses secepat mungkin. Seringkali, ini membutuhkan kompromi dari segi tingkat akurasi demi data yang siap secepat mungkin. Misalnya, pertimbangkan skenario IoT di mana sejumlah besar sensor suhu mengirim data telemetri. Lapisan kecepatan dapat digunakan untuk memproses jangka waktu yang bergerak dari data yang masuk.
Di sisi lain, data yang mengalir ke jalur dingin, tidak menuruti persyaratan latensi rendah yang sama. Hal ini memungkinkan perhitungan akurasi tinggi di seluruh himpunan data besar, yang bisa sangat memakan waktu.
Akhirnya, jalur panas dan dingin bertemu di aplikasi klien analitik. Jika klien perlu menampilkan data yang tepat waktu, namun berpotensi kurang akurat secara real time, ia akan memperoleh hasilnya dari jalur panas. Jika tidak, ia akan memilih hasil dari jalur dingin untuk menampilkan data yang tidak begitu 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 pada lapisan batch tidak berubah. Data yang masuk selalu ditambahkan ke data yang ada, dan data sebelumnya tidak pernah ditimpa. Setiap perubahan nilai datum tertentu disimpan sebagai rekaman peristiwa stempel waktu baru. Hal ini memungkinkan untuk melakukan rekomputasi pada setiap titik waktu di seluruh riwayat data yang dikumpulkan. Kemampuan untuk melakukan rekomputasi tampilan batch dari data mentah yang asli adalah hal yang penting, karena memungkinkan tampilan yang baru untuk dibuat saat sistem berkembang.
Arsitektur Kappa
Kelemahan arsitektur lambda ada pada kompleksitasnya. Logika pemrosesan muncul di dua tempat yang berbeda - jalur dingin dan panas - menggunakan kerangka kerja yang berbeda. Hal ini berujung pada dua logika perhitungan dan tingginya kompleksitas dalam mengelola arsitektur untuk kedua jalur.
Arsitektur kappa diusulkan oleh Jay Kreps sebagai alternatif dari arsitektur lambda. Itu memiliki tujuan dasar yang sama dengan arsitektur lambda, tetapi dengan perbedaan penting: Semua data mengalir melalui satu jalur, menggunakan sistem pemrosesan aliran.
Ada beberapa kesamaan dengan lapisan batch arsitektur lambda, karena data peristiwa tidak berubah dan semuanya dikumpulkan, bukan merupakan subset. Data diserap sebagai aliran peristiwa ke dalam log terpadu yang 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 menyusun ulang seluruh kumpulan data (setara dengan apa yang dilakukan lapisan batch di lambda), Anda cukup memutar ulang aliran, biasanya menggunakan paralelisme untuk menyelesaikan perhitungan secara tepat waktu.
Internet of Things (IoT)
Dari sudut pandang praktis, Internet of Things (IoT) mewakili perangkat apa pun yang terhubung ke Internet. Ini termasuk PC Anda, ponsel, jam tangan pintar, termostat pintar, kulkas pintar, mobil yang terhubung, implan pemantauan jantung, dan apa pun yang terhubung ke Internet dan mengirim atau menerima data. Jumlah perangkat yang terhubung terus bertambah setiap harinya, seperti halnya jumlah data yang dikumpulkan dari perangkat-perangkat tersebut. Seringkali data ini dikumpulkan dalam lingkungan yang sangat terbatas, terkadang dengan latensi tinggi. Dalam kasus lain, data dikirim dari lingkungan latensi rendah oleh ribuan atau jutaan perangkat, membutuhkan kemampuan untuk dengan cepat menyerap data dan memprosesnya. Oleh karena itu, perencanaan yang tepat diperlukan untuk menangani kendala dan persyaratan unik ini.
Arsitektur berbasis peristiwa adalah bagian utama dari solusi IoT. Diagram berikut menunjukkan kemungkinan arsitektur logis untuk IoT. Diagram ini menekankan komponen streaming peristiwa arsitektur.
Gateway cloud menyerap peristiwa perangkat di batas cloud, menggunakan sistem pesan latensi rendah yang andal.
Perangkat dapat mengirim peristiwa secara langsung ke gateway cloud, atau melalui gateway bidang. Gateway bidang adalah perangkat atau perangkat lunak khusus, yang biasanya dikolokasikan dengan perangkat, yang menerima peristiwa dan meneruskannya ke gateway cloud. Gateway bidang juga dapat memproses peristiwa perangkat mentah, melakukan fungsi seperti pemfilteran, agregasi, atau transformasi protokol.
Setelah penyerapan, peristiwa melalui satu atau lebih pemroses aliran yang dapat merutekan data (misalnya, ke penyimpanan) atau melakukan analitik dan pemrosesan lainnya.
Berikut beberapa jenis pemrosesan yang umum. (Tentu saja tidak semuanya tercantum dalam daftar ini.)
Menulis data peristiwa ke penyimpanan dingin, untuk pengarsipan atau analitik batch.
Analisis jalur panas, menganalisis aliran peristiwa secara (mendekati) real time, untuk mendeteksi anomali, mengenali pola selama periode peluncuran, atau memicu peringatan saat kondisi tertentu terjadi di aliran.
Menangani jenis pesan non-telemetri khusus dari perangkat, seperti pemberitahuan dan alarm.
Pembelajaran mesin.
Kotak yang diarsir abu-abu menunjukkan komponen sistem IoT yang tidak terkait langsung dengan streaming peristiwa, tetapi disertakan di sini sebagai pelengkap.
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 pesan perintah dan kontrol dikirim ke perangkat.
Kontributor
Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.
Penulis utama:
- Zoiner Tejada | CEO dan Arsitek
Langkah berikutnya
Lihat layanan Azure yang relevan berikut ini: