Pemrosesan data lakehouse mendekati real time

Pencarian Azure AI
Azure Cosmos DB
Azure Data Lake
Azure Event Hubs
Azure Synapse Analytics

Perusahaan berbasis data perlu menjaga sistem back end dan analitik mereka tetap sinkron mendekati real time dengan aplikasi yang berhadapan dengan pelanggan. Dampak transaksi, pembaruan, dan perubahan harus mencerminkan secara akurat melalui proses end-to-end, aplikasi terkait, dan sistem pemrosesan transaksi online (OLTP). Latensi yang dapat ditoleransi untuk perubahan dalam aplikasi OLTP untuk mencerminkan sistem hilir yang menggunakan data mungkin hanya beberapa menit.

Artikel ini menjelaskan solusi end-to-end untuk pemrosesan data mendekati real-time agar data lakehouse tetap sinkron. Solusi ini menggunakan Azure Event Hubs, Azure Synapse Analytics, dan Azure Data Lake Storage untuk pemrosesan dan analitik data.

ApacheĀ® dan Apache Spark adalah merek dagang terdaftar atau merek dagang dari Apache Software Foundation di Amerika Serikat dan/atau negara lain. Tidak ada dukungan oleh The Apache Software Foundation yang tersirat oleh penggunaan tanda ini.

Sistem

Diagram yang memperlihatkan aliran data untuk solusi pemrosesan data end-to-end.

Unduh file Visio arsitektur ini.

Aliran data

  1. Mengubah pengambilan data adalah prasyarat bagi sistem sumber untuk mendengarkan perubahan. Konektor Debezium dapat terhubung ke sistem sumber yang berbeda dan memanfaatkan perubahan saat terjadi. Konektor dapat menangkap perubahan dan menghasilkan peristiwa dari berbagai sistem manajemen database relasional (RDBMS). Menginstal konektor Debezium memerlukan sistem koneksi Kafka.

  2. Konektor mengekstrak data perubahan dan mengirim peristiwa yang diambil ke Azure Event Hubs. Azure Event Hubs dapat menerima sejumlah besar data dari beberapa sumber.

  3. Azure Event Hubs secara langsung mengalirkan data ke kumpulan Azure Synapse Analytics Spark, atau dapat mengirim data ke zona pendaratan Azure Data Lake Storage dalam format mentah.

  4. Sumber data batch lainnya dapat menggunakan alur Azure Synapse untuk menyalin data ke Data Lake Storage dan membuatnya tersedia untuk diproses. Alur kerja ekstrak, transformasi, dan pemuatan (ETL) end-to-end mungkin perlu menautkan langkah yang berbeda atau menambahkan dependensi di antara langkah-langkah. Alur Azure Synapse dapat mengatur dependensi alur kerja dalam kerangka kerja pemrosesan keseluruhan.

  5. Kumpulan Azure Synapse Spark menggunakan API streaming terstruktur Apache Spark yang didukung penuh untuk memproses data dalam kerangka kerja streaming Spark. Langkah pemrosesan data menggabungkan pemeriksaan kualitas data dan validasi aturan bisnis tingkat tinggi.

  6. Data Lake Storage menyimpan data yang divalidasi dalam format Delta Lake terbuka. Delta Lake menyediakan semantik dan transaksi atomitas, konsistensi, isolasi, dan durabilitas (ACID), penanganan metadata yang dapat diskalakan, serta pemrosesan data streaming dan batch terpadu untuk data lake yang ada.

    Menggunakan indeks untuk akselerasi kueri menambah Delta dengan peningkatan performa lebih lanjut. Data dari zona tervalidasi Data Lake Storage juga dapat menjadi sumber untuk analitik dan pembelajaran mesin tingkat lanjut lebih lanjut.

  7. Data dari zona yang divalidasi Data Lake Storage, diubah dan diperkaya dengan lebih banyak aturan ke status pemrosesan terakhirnya, dimuat ke kumpulan SQL khusus untuk menjalankan kueri analitik skala besar.

  8. Power BI menggunakan data yang diekspos melalui kumpulan SQL khusus untuk membangun dasbor dan laporan tingkat perusahaan.

  9. Anda juga dapat menggunakan data mentah yang diambil di zona pendaratan Data Lake Store dan data yang divalidasi dalam format Delta untuk:

    • Analisis ad-hoc dan eksploratif lebih lanjut melalui kumpulan tanpa server Azure Synapse SQL.
    • Pembelajaran mesin melalui Azure Pembelajaran Mesin.
  10. Untuk beberapa antarmuka latensi rendah, data harus dinormalisasi untuk latensi server satu digit. Skenario penggunaan ini terutama untuk respons API. Skenario ini mengkueri dokumen di datastore NoSQL seperti Azure Cosmos DB untuk respons milidetik satu digit.

  11. Strategi partisi Azure Cosmos DB mungkin tidak meminjamkan dirinya ke semua pola kueri. Jika demikian, Anda dapat menambah solusi dengan mengindeks data yang perlu diakses API dengan Azure Cognitive Search. Azure Cosmos DB dan Cognitive Search dapat memenuhi sebagian besar skenario yang memerlukan respons kueri latensi rendah.

Komponen

Solusi ini menggunakan komponen Azure berikut ini:

  • Azure Event Hubs adalah layanan penyerapan terkelola dan terdistribusi yang dapat menskalakan untuk menyerap data dalam jumlah besar. Dengan mekanisme penerbit pelanggan Azure Event Hubs, aplikasi yang berbeda dapat mengirim pesan ke topik di Azure Event Hubs, dan konsumen hilir dapat terhubung ke dan memproses pesan. Fitur Azure Event Hubs Capture dapat menulis pesan ke Data Lake Storage dalam format AVRO saat tiba. Kemampuan ini memungkinkan pemrosesan mikro-batch yang mudah dan skenario retensi jangka panjang. Azure Event Hubs juga menawarkan API yang kompatibel dengan Kafka dan mendukung registri skema.

  • Data Lake Storage membentuk subsistem penyimpanan yang menyimpan semua data dalam format mentah dan tervalidasi. Data Lake Storage dapat menangani transaksi dalam skala besar, dan mendukung format dan ukuran file yang berbeda. Namespace hierarkis membantu mengatur data ke dalam struktur folder yang familier dan mendukung izin Antarmuka Sistem Operasi Portabel untuk UniX (POSIX). Driver Azure Blob Filesystem (ABFS) menawarkan API yang kompatibel dengan Hadoop.

  • Azure Synapse Analytics adalah layanan analitik tak terbatas yang menyatukan integrasi data, pergudangan data perusahaan, dan analitik big data. Solusi ini menggunakan fitur ekosistem Azure Synapse Analytics berikut:

    • Kumpulan Azure Synapse Spark menawarkan runtime Spark sesuai permintaan yang menambahkan peningkatan performa bawaan ke Spark sumber terbuka. Pelanggan dapat mengonfigurasi pengaturan skala otomatis yang fleksibel, mengirimkan pekerjaan dari jarak jauh melalui titik akhir Apache Livy, dan menggunakan antarmuka notebook Synapse Studio untuk pengalaman interaktif.

    • Kumpulan tanpa server Azure Synapse SQL menyediakan antarmuka untuk mengkueri data lakehouse dengan menggunakan sintaks T-SQL yang familier. Tidak ada infrastruktur untuk disiapkan, dan penyebaran ruang kerja Azure Synapse secara otomatis membuat titik akhir. Kumpulan tanpa server Azure Synapse SQL memungkinkan penemuan dasar dan eksplorasi data di tempat, dan merupakan opsi yang baik untuk analisis kueri ad-hoc pengguna.

    • Kumpulan SQL khusus Azure Synapse menyimpan data dalam tabel relasional dengan penyimpanan kolom. Kumpulan SQL khusus menggunakan arsitektur peluasan skala untuk mendistribusikan pemrosesan data di beberapa simpul. Kueri PolyBase membawa data ke dalam tabel kumpulan SQL. Tabel bisa tersambung ke Power BI untuk analisis dan pelaporan.

  • Power BI menyediakan antarmuka visual untuk membuat dan mengakses laporan dan dasbor. Power BI Desktop bisa tersambung ke berbagai sumber data, menggabungkan sumber ke dalam model data, dan membuat laporan atau dasbor. Dengan Power BI, Anda dapat mengubah data berdasarkan persyaratan bisnis, dan berbagi visual dan laporan dengan orang lain melalui layanan Power BI.

  • Azure Cosmos DB adalah database NoSQL multi-modal terkelola yang mendukung API terbuka seperti MongoDB dan Cassandra. Solusi ini menggunakan Azure Cosmos DB untuk aplikasi yang memerlukan waktu respons milidetik satu digit dan ketersediaan tinggi. Azure Cosmos DB menawarkan penulisan multi-wilayah di semua wilayah Azure. Anda dapat menggunakan Azure Synapse Link untuk Azure Cosmos DB untuk mendapatkan wawasan dan menjalankan analitik melalui data secara real time.

  • Azure Cognitive Search adalah layanan pencarian cloud yang dapat mengindeks data yang dibutuhkan aplikasi dan API Anda. Cognitive Search memiliki fitur pengayaan AI opsional yang membantu ekstraksi teks dan menyimpulkan teks dari file non-teks. Cognitive Search terintegrasi dengan layanan seperti Azure Data Lake Storage dan Azure Cosmos DB untuk mengakses dan mengindeks data dengan mudah. Anda dapat mengkueri data terindeks dengan menggunakan REST API atau .NET SDK. Untuk mendapatkan data dari dua indeks terpisah, Anda dapat menggabungkannya ke dalam satu indeks atau menggunakan jenis data yang kompleks.

Detail skenario

Alur kerja end-to-end untuk memproses perubahan mendekati real-time memerlukan:

  • Teknologi change data capture (CDC). Aplikasi OLTP mungkin memiliki penyimpanan data back-end yang berbeda, seperti SQL Server, MySQL, dan Oracle. Langkah pertama adalah mendengarkan perubahan saat terjadi, dan menyebarluaskannya ke depan.
  • Buffer penyerapan untuk menerbitkan peristiwa perubahan dalam skala besar. Layanan ini harus memiliki kemampuan untuk menangani data dalam jumlah besar saat pesan tiba. Pelanggan individual dapat terhubung ke sistem ini dan memproses data.
  • Penyimpanan terdistribusi dan dapat diskalakan untuk data apa adanya dalam format mentah.
  • Sistem pemrosesan aliran terdistribusi dan efisien yang memungkinkan pengguna memulai ulang dan mengelola status.
  • Sistem analitik yang berjalan dalam skala besar untuk mendukung keputusan bisnis.
  • Antarmuka analitik mandiri.
  • Untuk respons API latensi rendah, database NoSQL untuk menyimpan representasi data yang dinormalisasi.
  • Untuk beberapa kasus, sistem untuk mengindeks data, merefresh indeks secara berkala, dan membuat data terbaru tersedia untuk konsumsi hilir.

Semua teknologi sebelumnya harus menggunakan konstruksi keamanan yang relevan untuk keamanan perimeter, autentikasi, otorisasi, dan enkripsi data.

Kemungkinan kasus penggunaan

Solusi ini sangat cocok untuk:

  • Industri yang perlu menyebarluaskan perubahan dari OLTP ke pemrosesan analitik online (OLAP).
  • Aplikasi yang memerlukan transformasi atau pengayaan data.

Skenario pemrosesan data real time sangat penting untuk industri jasa keuangan. Misalnya, jika asuransi, kartu kredit, atau pelanggan bank melakukan pembayaran dan kemudian segera menghubungi layanan pelanggan, agen dukungan pelanggan harus memiliki informasi terbaru.

Skenario serupa berlaku untuk sektor ritel, perdagangan, dan layanan kesehatan. Mengaktifkan skenario ini menyederhanakan operasi, yang mengarah ke produktivitas organisasi yang lebih besar dan peningkatan kepuasan pelanggan.

Pertimbangan

Pertimbangan ini mengimplementasikan pilar Azure Well-Architected Framework, yang merupakan serangkaian tenet panduan yang dapat digunakan untuk meningkatkan kualitas beban kerja. Untuk informasi selengkapnya, lihat Microsoft Azure Well-Architected Framework.

Keandalan

Keandalan memastikan aplikasi Anda dapat mencapai komitmen yang Anda buat kepada pelanggan Anda. Untuk informasi selengkapnya, lihat Gambaran Umum pilar keandalan.

  • Azure Event Hubs menawarkan retensi data 90 hari pada tingkat premium dan khusus. Untuk skenario failover, Anda dapat menyiapkan namespace sekunder di wilayah yang dipasangkan dan mengaktifkannya selama failover.

  • Pekerjaan kumpulan Azure Synapse Spark didaur ulang setiap tujuh hari karena simpul diturunkan untuk pemeliharaan. Pertimbangkan aktivitas ini saat Anda bekerja melalui perjanjian tingkat layanan (SLA) yang terkait dengan sistem. Batasan ini bukan masalah untuk banyak skenario di mana tujuan waktu pemulihan (RTO) sekitar 15 menit.

Pengoptimalan biaya

Optimalisasi biaya adalah tentang mencari cara untuk mengurangi pengeluaran yang tidak perlu dan meningkatkan efisiensi operasional. Untuk informasi selengkapnya, lihat Gambaran umum pilar pengoptimalan biaya.

  • Anda dapat memilih dari berbagai tingkatan Azure Event Hubs berdasarkan karakteristik beban kerja. Azure Event Hubs menagih penyimpanan Capture secara terpisah, berdasarkan jumlah data yang disimpan di Data Lake Storage.

  • Pertimbangkan manajemen siklus hidup objek melalui tingkatan di Azure Data Lake Storage. Seiring bertambahnya usia data, Anda dapat memindahkan data dari tingkat panas, di mana Anda perlu mengakses data terbaru untuk analitik, ke tingkat penyimpanan dingin yang harganya jauh lebih rendah. Tingkat penyimpanan dingin adalah opsi hemat biaya untuk retensi jangka panjang.

  • Anda dapat menjeda kumpulan SQL khusus saat Anda tidak menggunakannya di lingkungan pengembangan atau pengujian Anda. Anda dapat menjadwalkan skrip untuk menjeda kumpulan sesuai kebutuhan, atau Anda dapat menjeda kumpulan secara manual melalui portal.

  • Azure Cosmos DB menawarkan model provisi yang berbeda, seperti throughput tanpa server, throughput yang disediakan manual, dan skala otomatis. Pertimbangkan untuk menggunakan provisi tanpa server untuk beban kerja pengembangan dan pengujian Anda. Anda juga dapat menggunakan skala otomatis, di mana Anda dapat mengatur unit permintaan maksimum per detik (RU/s) pada kontainer. Throughput pada kontainer menskalakan secara otomatis antara 10% DARI RU/dtk maksimum sebagai ambang batas bawah dan RU/dtk maksimum yang dikonfigurasi.

Efisiensi kinerja

Efisiensi performa adalah kemampuan beban kerja Anda untuk diskalakan agar memenuhi permintaan yang diberikan oleh pengguna dengan cara yang efisien. Untuk informasi selengkapnya, lihat Gambaran umum pilar efisiensi performa.

  • Anda dapat menskalakan Azure Event Hubs melalui partisi. Pertimbangkan untuk mempartisi data Anda untuk mempertahankan urutan peristiwa melalui log penerapan. Pemartisian memungkinkan Anda membuat beberapa log paralel dengan memaksimalkan kapasitas throughput yang tersedia.

  • Anda dapat menyiapkan kumpulan Azure Synapse Spark dengan SKU komputer virtual (VM) kecil, sedang, atau besar, berdasarkan beban kerja. Anda juga dapat mengonfigurasi skala otomatis di kumpulan Azure Synapse Spark untuk memperhitungkan beban kerja yang melonjak. Jika Anda membutuhkan lebih banyak sumber daya komputasi, kluster secara otomatis meningkatkan skala untuk memenuhi permintaan, dan menurunkan skala setelah pemrosesan selesai.

  • Gunakan praktik terbaik untuk merancang tabel di kumpulan SQL khusus. Batas performa dan skalabilitas terkait berlaku, berdasarkan tingkat yang dijalankan kumpulan SQL.

  • Azure Cosmos DB menggunakan partisi untuk menskalakan kontainer, berdasarkan kunci partisi. Semua data berdasarkan kunci partisi membentuk partisi logis. Pastikan untuk memilih strategi partisi yang benar berdasarkan persyaratan beban kerja. Anda juga dapat menggunakan indeks untuk pengambilan data yang lebih cepat.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Kontributor lainnya:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya