Menskalakan analitik skala cloud di Azure
Platform data yang dapat diskalakan sangat penting untuk mengakomodasi pertumbuhan data yang cepat. Sejumlah besar data dihasilkan setiap detik di seluruh dunia. Jumlah data yang tersedia diperkirakan akan terus tumbuh secara eksponensial selama beberapa tahun ke depan. Seiring meningkatnya laju pembuatan data, kecepatan pergerakan data juga meningkat.
Tidak peduli berapa banyak data yang Anda miliki, pengguna Anda menuntut respons kueri yang cepat. Mereka berharap untuk menunggu menit, bukan jam, untuk hasil. Artikel ini menjelaskan bagaimana Anda dapat menskalakan solusi analitik skala cloud Azure dan terus memenuhi permintaan pengguna untuk kecepatan.
Pendahuluan
Banyak perusahaan memiliki monolit platform data besar. Monolit ini dibangun di sekitar satu akun Azure Data Lake Gen2, dan terkadang satu kontainer penyimpanan. Satu langganan Azure sering digunakan untuk semua tugas terkait platform data. Penskalaan tingkat langganan tidak ada di sebagian besar platform arsitektur, yang dapat menghambat adopsi Azure berkelanjutan jika pengguna mengalami salah satu batasan langganan Azure atau tingkat layanan. Meskipun beberapa batasan adalah batas lunak, memukulnya masih dapat memiliki efek negatif yang signifikan pada platform data Anda.
Saat Anda menyusun platform data, pertimbangkan struktur organisasi Anda. Perhatikan kepemilikan data dan tanggung jawab fungsi dari tim Anda. Jika organisasi Anda memberi tim tingkat otonomi besar dan kepemilikan terdistribusi, arsitektur jala data adalah pilihan terbaik Anda.
Hindari situasi yang memiliki tim yang berbeda yang bertanggung jawab atas berbagai tugas solusi—tugas seperti penyerapan, pembersihan, agregasi, dan penyajian. Tergantung pada beberapa tim dapat menyebabkan hilangnya kecepatan yang dramatis. Misalnya, jika konsumen data Anda pada lapisan penyajian perlu melakukan onboarding aset data baru atau menerapkan perubahan fungsional untuk aset data tertentu, mereka harus melalui proses multi-langkah. Untuk contoh ini, langkah-langkahnya adalah:
- Konsumen data mengirimkan tiket ke setiap tim yang bertanggung jawab atas tahap alur data.
- Tim harus bekerja sama secara sinkron karena lapisan saling terhubung. Layanan baru memerlukan perubahan pada lapisan pembersihan data, yang menyebabkan perubahan pada lapisan agregasi data, yang menyebabkan perubahan pada lapisan penyajian. Perubahan dapat memengaruhi setiap tahap alur.
- Sulit bagi tim untuk melihat efek potensial dari perubahan pemrosesan, karena mereka tidak memiliki gambaran umum tentang seluruh siklus hidup end-to-end. Mereka harus bekerja sama untuk merancang rencana rilis yang terdefinisi dengan baik yang meminimalkan efek pada konsumen dan alur yang ada. Manajemen dependensi ini meningkatkan overhead manajemen.
- Sebagai aturan, tim bukan ahli subjek penting pada aset data yang diminta konsumen data. Untuk memahami fitur himpunan data atau nilai parameter baru, mereka harus berkonsultasi dengan pakar.
- Setelah semua perubahan diterapkan, konsumen data diberi tahu bahwa aset data baru siap digunakan.
Setiap organisasi besar memiliki ribuan konsumen data. Proses yang rumit seperti yang dijelaskan sangat mengurangi kecepatan dalam arsitektur besar, karena tim terpusat menjadi hambatan untuk unit bisnis. Hasilnya kurang inovasi dan efektivitas terbatas. Berpotensi, unit bisnis dapat memutuskan untuk meninggalkan layanan dan membangun platform data mereka sendiri sebagai gantinya.
Metode untuk penskalaan
Analitik skala cloud mengatasi tantangan penskalakan dengan menggunakan dua konsep inti:
- Menggunakan zona pendaratan data untuk penskalaan
- Menggunakan produk data atau integrasi data untuk penskalaan, untuk memungkinkan kepemilikan data terdistribusi dan terdesentralisasi
Anda dapat menyebarkan satu zona pendaratan data, atau beberapa zona pendaratan. Zona pendaratan data memungkinkan Anda menemukan dan mengelola data dengan menyambungkan ke zona pendaratan manajemen data. Setiap zona pendaratan manajemen data berada dalam satu langganan Azure.
Langganan adalah unit manajemen, penagihan, dan skala Azure. Mereka memainkan peran penting dalam rencana adopsi Azure skala besar Anda.
Menskalakan dengan zona pendaratan data
Konsep pusat analitik skala cloud adalah zona pendaratan manajemen data dan zona pendaratan data. Anda harus menempatkan masing-masing dalam langganan Azure-nya sendiri. Memisahkannya memungkinkan Anda memisahkan tugas dengan jelas, mengikuti prinsip hak istimewa paling sedikit, dan secara parsial mengatasi masalah skala langganan yang disebutkan sebelumnya. Penyiapan analitik skala cloud minimal mencakup satu zona pendaratan data dan satu zona pendaratan manajemen data.
Namun, pengaturan minimal tidak cukup untuk penyebaran platform data skala besar. Perusahaan membangun platform skala besar dan melakukan investasi untuk menskalakan upaya data dan analitik mereka secara konsisten dan efisien dari waktu ke waktu. Untuk mengatasi batasan tingkat langganan, analitik skala cloud menggunakan langganan sebagai unit penskalaan, seperti yang dibahas di zona pendaratan Azure. Teknik ini memungkinkan untuk meningkatkan jejak platform data dengan menambahkan lebih banyak zona pendaratan data ke arsitektur. Mengadopsi teknik ini juga mengatasi masalah satu Azure Data Lake Gen2 yang digunakan untuk seluruh organisasi, karena setiap zona pendaratan data mencakup tiga data lake. Proyek dan aktivitas dari beberapa domain dapat didistribusikan di lebih dari satu langganan Azure, sehingga memberikan skalabilitas yang lebih besar.
Tentukan berapa banyak zona pendaratan data yang diperlukan organisasi Anda sebelum Anda menerapkan arsitektur analitik skala cloud. Membuat keputusan yang tepat meletakkan fondasi untuk platform data yang efektif dan efisien.
Jumlah zona pendaratan data yang diperlukan tergantung pada banyak faktor, terutama:
- Penyelarasan organisasi, seperti berapa banyak unit bisnis yang membutuhkan zona pendaratan data mereka sendiri
- Pertimbangan operasional, seperti bagaimana organisasi Anda menyelaraskan sumber daya operasi dan sumber daya yang khusus untuk unit bisnis.
Menggunakan model zona pendaratan data yang tepat meminimalkan upaya di masa mendatang untuk memindahkan produk data dan aset data dari satu zona pendaratan ke zona pendaratan lainnya. Ini juga membantu Anda secara efektif dan konsisten menskalakan big data dan upaya analitik di masa depan.
Pertimbangkan faktor-faktor berikut saat Anda memutuskan jumlah zona pendaratan data yang akan disebarkan.
| Faktor | Deskripsi |
|---|---|
| Struktur organisasi dan kepemilikan data | Pertimbangkan bagaimana organisasi Anda disusun dan bagaimana data dimiliki di organisasi Anda. |
| Wilayah dan lokasi | Jika Anda menyebarkan di beberapa wilayah, putuskan wilayah atau wilayah mana yang harus menghosting zona data. Pastikan untuk mematuhi semua persyaratan residensi data. |
| Kuota | Kuota langganan bukan jaminan kapasitas dan diterapkan berdasarkan per wilayah. |
| Kedaulatan data | Karena peraturan kedaulatan data, data harus disimpan di wilayah tertentu dan mengikuti kebijakan khusus wilayah. |
| Kebijakan Azure | Zona pendaratan data harus mengikuti persyaratan berbagai kebijakan Azure. |
| Batas manajemen | Langganan menyediakan batas manajemen untuk tata kelola dan isolasi yang memisahkan kekhawatiran dengan jelas. |
| Jaringan | Setiap zona pendaratan memiliki jaringan virtual. Karena jaringan virtual berada di satu wilayah, setiap wilayah baru memerlukan zona pendaratan baru. Jaringan virtual harus menjadi jaringan virtual serekan untuk mengaktifkan komunikasi lintas domain. |
| Batas | Langganan memiliki batasan. Dengan memiliki beberapa langganan, Anda dapat mengurangi bahaya mencapai batas ini. |
| Alokasi biaya | Pertimbangkan apakah layanan bersama seperti akun penyimpanan yang dibayar secara terpusat harus dibagi berdasarkan unit bisnis atau domain. Menggunakan langganan terpisah membuat batas untuk alokasi biaya. Anda dapat mencapai fungsionalitas yang sama dengan menggunakan tag. |
| Klasifikasi data dan data yang sangat rahasia | Mekanisme keamanan dapat memengaruhi pengembangan produk data dan kegunaan platform data. Pertimbangkan klasifikasi data dan putuskan apakah himpunan data yang sangat rahasia memerlukan perlakuan khusus, seperti akses just-in-time, kunci yang dikelola pelanggan (CMK), kontrol jaringan terperintah halus, atau lebih banyak enkripsi. |
| Implikasi hukum atau keamanan lainnya | Pertimbangkan apakah ada persyaratan hukum atau keamanan lain yang memerlukan pemisahan data logis atau fisik. |
Jika Anda menerapkan arsitektur jala data, pertimbangkan faktor-faktor berikut saat Anda memutuskan cara mendistribusikan zona pendaratan data dan domain data Anda.
| Faktor | Deskripsi |
|---|---|
| Domain data | Pertimbangkan domain data yang digunakan organisasi Anda, dan putuskan mana yang akan ada di platform data Anda. Pertimbangkan ukuran domain data individual Anda. Untuk informasi selengkapnya, lihat Apa itu domain data? |
| Latensi | Domain yang berkolaborasi pada data dalam jumlah besar dapat mentransfer sejumlah besar data di seluruh zona pendaratan. Pertimbangkan untuk mengalokasikan domain Anda di zona atau wilayah pendaratan yang sama. Memisahkannya meningkatkan latensi dan dapat meningkatkan biaya di domain lintas wilayah. |
| Keamanan | Beberapa penyebaran atau konfigurasi layanan memerlukan hak istimewa yang ditingkatkan dalam langganan. Memberikan hak istimewa ini kepada pengguna dalam satu domain secara implisit memberi pengguna hak istimewa yang sama di domain lain dalam langganan yang sama. |
Anda dapat menemukan pertimbangan lebih lanjut dalam panduan kerangka kerja adopsi cloud untuk langganan.
Banyak organisasi menginginkan penskalaan platform data perusahaan yang efisien. Unit bisnis harus dapat membangun solusi dan aplikasi data mereka sendiri untuk memenuhi persyaratan unik mereka. Menyediakan kemampuan ini dapat menjadi tantangan, karena banyak platform data yang ada tidak dibangun di sekitar konsep skalabilitas dan kepemilikan terdesentralisasi. Kekurangan ini jelas terlihat dalam arsitektur, struktur tim, dan model ops platform data ini.
Zona pendaratan data tidak membuat silo data dalam organisasi Anda. Penyiapan jaringan yang direkomendasikan untuk analitik skala cloud memungkinkan berbagi data yang aman dan di tempat di seluruh zona pendaratan, yang pada gilirannya memungkinkan inovasi di seluruh domain data dan unit bisnis. Untuk mempelajari selengkapnya, lihat Pertimbangan arsitektur jaringan.
Hal yang sama berlaku untuk lapisan identitas. Saat Anda menggunakan satu penyewa Microsoft Entra, Anda dapat memberikan akses identitas ke aset data di beberapa zona pendaratan data. Untuk mempelajari selengkapnya tentang proses otorisasi pengguna dan identitas, lihat Manajemen akses data.
Catatan
Jika Anda memiliki beberapa zona pendaratan data, setiap zona dapat terhubung ke data yang dihosting di zona lain. Ini memungkinkan grup untuk berkolaborasi di seluruh bisnis Anda.
Analitik skala cloud menggunakan arsitektur umum untuk menganjurkan tata kelola yang konsisten. Arsitektur Anda mendefinisikan kemampuan dan kebijakan garis besar. Semua zona pendaratan data mematuhi audit dan kontrol yang sama. Tim Anda dapat membuat alur data, menyerap sumber, dan membuat produk data seperti laporan dan dasbor. Teams juga dapat melakukan analisis Spark/SQL sesuai kebutuhan. Anda dapat menambah kemampuan zona arahan data dengan menambahkan layanan ke kemampuan dalam kebijakan. Misalnya, tim dapat menambahkan mesin grafik pihak ketiga untuk memenuhi persyaratan bisnis.
Analitik skala cloud menempatkan penekanan yang kuat pada katalog dan klasifikasi pusat untuk melindungi data dan memungkinkan berbagai grup untuk menemukan produk data.
Perhatian
Sebaiknya jangan mengkueri data di seluruh wilayah. Sebagai gantinya, pastikan bahwa data dekat dengan komputasi yang menggunakannya, sambil menghormati batas regional.
Arsitektur analitik skala cloud dan konsep zona pendaratan data memungkinkan organisasi Anda untuk dengan mudah meningkatkan ukuran platform data Anda dari waktu ke waktu. Anda dapat menambahkan lebih banyak zona pendaratan data dalam pendekatan bertahas. Pelanggan Anda tidak perlu memiliki beberapa zona pendaratan pada awalnya. Saat Anda mengadopsi arsitektur ini, prioritaskan beberapa zona pendaratan data dan produk data yang dikandungnya. Prioritas yang tepat membantu memastikan keberhasilan penyebaran analitik skala cloud Anda.
Menskalakan dengan produk data atau integrasi data
Dalam setiap zona pendaratan, organisasi Anda dapat menskalakan dengan menggunakan aplikasi data. Aplikasi data adalah unit atau komponen arsitektur data Anda yang merangkum fungsionalitas yang menyediakan produk data yang dioptimalkan baca untuk dikonsumsi oleh aplikasi data lainnya. Di Azure, aplikasi data adalah lingkungan dalam bentuk grup sumber daya yang memungkinkan tim lintas fungsi menerapkan solusi data dan beban kerja. Tim terkait mengurus siklus hidup end-to-end solusi data, yang mencakup tugas penyerapan, pembersihan, agregasi, dan penyajian.
Analitik skala cloud membahas masalah integrasi dan tanggung jawab data yang dibahas sebelumnya. Alih-alih tanggung jawab fungsi monolitik untuk penyerapan tabel dan integrasi sistem sumber, desain referensi menyediakan arsitektur terdistribusi yang didorong oleh domain data. Tim lintas fungsi mengambil alih tanggung jawab fungsi dan kepemilikan fungsi menyeluruh untuk cakupan data.
Alih-alih memiliki tumpukan teknis terpusat, dan tim yang bertanggung jawab atas semua tugas alur kerja pemrosesan data Anda, Anda dapat mendistribusikan tanggung jawab end-to-end di beberapa tim integrasi data lintas fungsional otonom. Setiap tim memiliki kemampuan domain atau subdomain dan didorong untuk melayani himpunan data sesuai kebutuhan konsumen data.
Perbedaan arsitektur ini menyebabkan peningkatan kecepatan pada platform data Anda. Konsumen data Anda tidak lagi harus mengandalkan sekumpulan tim terpusat atau berjuang agar perubahan yang diminta diprioritaskan. Karena tim yang lebih kecil mengambil kepemilikan dari alur kerja integrasi end-to-end Anda, perulangan umpan balik antara penyedia data dan konsumen data jauh lebih pendek. Pendekatan ini menghasilkan prioritas yang lebih cepat, siklus pengembangan yang lebih cepat, dan proses pengembangan yang lebih gesit. Tim Anda tidak perlu lagi menyinkronkan proses dan rencana rilis di antara mereka sendiri, karena tim integrasi data lintas fungsi memiliki kesadaran penuh tentang tumpukan teknis end-to-end dan implikasi perubahan. Ini dapat menggunakan praktik rekayasa perangkat lunak untuk menjalankan pengujian unit dan integrasi untuk meminimalkan efek keseluruhan pada konsumen.
Idealnya, tim yang memiliki sistem integrasi data juga memiliki sistem sumber. Tim ini harus terdiri dari teknisi data yang bekerja pada sistem sumber, pakar subjek (UKM) untuk himpunan data, teknisi cloud, dan pemilik produk data. Membangun tim lintas fungsi ini mengurangi jumlah komunikasi yang diperlukan dengan tim luar, dan sangat penting sekaligus mengembangkan tumpukan lengkap Anda dari infrastruktur ke alur data aktual.
Fondasi platform data Anda adalah himpunan data yang terintegrasi dari sistem sumber. Himpunan data ini memungkinkan tim produk data Anda berinovasi pada tabel fakta bisnis dan untuk meningkatkan pengambilan keputusan dan proses bisnis. Tim integrasi data dan tim produk data Anda harus menawarkan SLA kepada konsumen dan memastikan bahwa semua perjanjian terpenuhi. SLA yang ditawarkan dapat terkait dengan kualitas data, ketepatan waktu, tingkat kesalahan, waktu aktif, dan tugas lainnya.
Ringkasan
Dengan menggunakan mekanisme penskalaan arsitektur analitik skala cloud Anda, organisasi Anda menumbuhkan data estate Anda dalam Azure dari waktu ke waktu sambil menghindari batasan teknis yang terkenal. Kedua metode penskalaan yang dijelaskan dalam artikel ini membantu Anda mengatasi kompleksitas teknis yang berbeda, dan dapat digunakan dengan cara yang sederhana dan efisien.