Pertimbangan desain untuk platform data mandiri
Jala data adalah pendekatan baru yang menarik untuk desain dan pengembangan arsitektur data. Tidak seperti arsitektur data tradisional, jala data memisahkan tanggung jawab antara domain data fungsional yang berfokus pada pembuatan produk data dan tim platform yang berfokus pada kemampuan teknis. Pemisahan tanggung jawab ini harus tercermin dalam platform Anda. Anda harus mencapai keseimbangan antara menyediakan kemampuan agnostik domain dan memungkinkan tim domain Anda memodelkan, memproses, dan mendistribusikan data mereka di seluruh organisasi Anda.
Memilih tingkat granularitas domain dan aturan yang tepat untuk memisahkan menggunakan platform tidaklah mudah. Artikel ini berisi beberapa skenario yang memberi Anda panduan terperinci.
Analitik skala cloud
Saat Anda ingin membangun jala data dengan Azure, kami sarankan Anda mengadopsi analitik skala cloud. Kerangka kerja ini adalah arsitektur referensi yang dapat disebarkan dan dilengkapi dengan templat sumber terbuka dan praktik terbaik. Arsitektur analitik skala cloud memiliki dua blok penyusun utama yang mendasar untuk semua pilihan penyebaran:
- Zona pendaratan manajemen data: Fondasi arsitektur data Anda. Ini berisi semua kemampuan penting untuk manajemen data, seperti katalog data, silsilah data, katalog API, manajemen data master, dan sebagainya.
- Zona pendaratan data: Langganan yang menghosting solusi analitik dan AI Anda. Mereka termasuk kemampuan utama untuk menghosting platform analitik.
Diagram berikut memberikan gambaran umum platform analitik skala cloud dengan zona pendaratan manajemen data dan zona pendaratan data tunggal. Tidak semua layanan Azure dihadirkan dalam diagram. Ini telah disederhanakan untuk menyoroti konsep inti organisasi sumber daya dalam arsitektur ini.
Kerangka kerja analitik berbasis cloud tidak eksplisit tentang jenis arsitektur data yang tepat yang harus Anda provisikan. Anda dapat menggunakannya untuk banyak solusi analitik skala cloud umum, termasuk gudang data (perusahaan), data lake, rumah data lake, dan jala data. Semua contoh solusi dalam artikel ini menggunakan arsitektur jala data.
Pahami bahwa semua arsitektur mematuhi prinsip jala data: kepemilikan domain, data sebagai produk, platform data layanan mandiri, dan tata kelola komputasi federasi. Jalur yang berbeda semuanya dapat menyebabkan jala data. Tidak ada satu jawaban yang benar atau salah. Anda harus melakukan trade-off yang tepat untuk kebutuhan organisasi Anda.
Zona arahan data tunggal
Pola penyebaran paling sederhana untuk membangun arsitektur jala data melibatkan satu zona pendaratan manajemen data dan satu zona pendaratan data. Arsitektur data dalam skenario seperti itu akan terlihat seperti berikut ini:
Dalam model ini, semua domain data fungsi anda berada di zona pendaratan data yang sama. Satu langganan berisi sekumpulan layanan standar. Grup sumber daya memisahkan domain data dan produk data yang berbeda. Layanan data standar, seperti Azure Data Lake Store, Azure Logic Apps, dan Azure Synapse Analytics, berlaku untuk semua domain.
Semua domain data mengikuti prinsip jala data: data mengikuti kepemilikan domain, dan data diperlakukan seperti produk. Platform ini sepenuhnya layanan mandiri, meskipun ada variasi layanan yang terbatas. Semua domain harus sangat mematuhi dan sesuai dengan prinsip manajemen data yang sama.
Opsi penyebaran ini dapat berguna untuk perusahaan yang lebih kecil atau proyek greenfield yang ingin merangkul jala data tetapi tidak terlalu rumit. Penyebaran ini juga dapat menjadi titik awal bagi organisasi yang berencana untuk membangun sesuatu yang lebih kompleks. Dalam hal ini, rencanakan untuk memperluas ke beberapa zona pendaratan di lain waktu.
Sistem sumber selaras dan zona pendaratan selaras konsumen
Dalam model sebelumnya, kami tidak mempertimbangkan langganan lain atau aplikasi lokal. Anda dapat sedikit mengubah model sebelumnya dengan menambahkan zona pendaratan yang selaras dengan sistem sumber untuk mengelola semua data masuk. Onboarding data adalah proses yang sulit, sehingga memiliki dua zona pendaratan data berguna. Onboarding tetap menjadi salah satu bagian yang paling menantang dalam menggunakan data secara besar-besaran. Onboarding juga sering membutuhkan alat tambahan untuk mengatasi integrasi, karena tantangannya berbeda dari integrasi. Ini membantu membedakan antara menyediakan data dan mengkonsumsi data.
Dalam arsitektur di sebelah kiri diagram ini, layanan memfasilitasi semua onboarding data, seperti CDC, layanan untuk menarik API, atau layanan data lake untuk membangun himpunan data secara dinamis. Layanan dalam platform ini dapat menarik data dari lokal, lingkungan cloud, atau vendor SaaS. Jenis platform ini biasanya juga memiliki lebih banyak overhead, karena ada lebih banyak koupling dengan aplikasi operasional yang mendasar. Anda mungkin ingin memperlakukan ini secara berbeda dari penggunaan data apa pun.
Dalam arsitektur di sebelah kanan diagram, organisasi mengoptimalkan konsumsi dan memiliki layanan yang berfokus pada mengubah data menjadi nilai. Layanan ini dapat mencakup pembelajaran mesin, pelaporan, dan sebagainya.
Domain arsitektur ini mengikuti semua prinsip jala data. Domain mengambil kepemilikan data dan diizinkan untuk mendistribusikan data secara langsung ke domain lain.
Zona pendaratan data hub, generik, dan khusus
Opsi penyebaran berikutnya adalah perulangan lain dari desain sebelumnya. Penyebaran ini mengikuti topologi jala yang diatur: data didistribusikan melalui hub pusat, di mana data dipartisi per domain, terisolasi secara logis, dan tidak terintegrasi. Hub model ini menggunakan zona pendaratan data (domain-agnostik) sendiri, dan dapat dimiliki oleh tim tata kelola data pusat yang mengawasi data mana yang didistribusikan ke domain lain. Hub ini juga membawa layanan yang memfasilitasi onboarding data.
Untuk domain yang memerlukan layanan standar untuk mengkonsumsi, menggunakan, menganalisis, dan membuat data baru, gunakan zona pendaratan data generik. Langganan tunggal ini memiliki serangkaian layanan standar. Terapkan juga virtualisasi data, karena sebagian besar produk data Anda sudah bertahan di hub dan Anda tidak memerlukan lebih banyak duplikasi data.
Penyebaran ini memungkinkan 'spesial': zona pendaratan tambahan yang dapat Anda provisikan ketika tidak dimungkinkan untuk mengelompokkan domain secara logis. Mereka dapat diperlukan ketika batas regional atau hukum berlaku, atau ketika domain Anda memiliki persyaratan yang unik dan kontras. Anda mungkin juga membutuhkannya dalam situasi di mana tata kelola anak perusahaan global yang kuat diterapkan dengan pengecualian untuk aktivitas di luar negeri.
Jika organisasi Anda perlu mengontrol data mana yang didistribusikan dan digunakan oleh domain mana, penyebaran hub adalah opsi yang baik. Ini juga merupakan opsi jika Anda mengatasi masalah varian waktu dan non-volatil bagi konsumen data besar. Anda dapat dengan kuat menstandarkan desain produk data, yang memungkinkan domain Anda melakukan perjalanan waktu dan melakukan redeliveries. Model ini sangat umum dalam industri keuangan.
Zona pendaratan data yang fungsional dan selaras secara regional
Menyediakan beberapa zona pendaratan data dapat membantu Anda mengelompokkan domain fungsional berdasarkan kohesi dan efisiensi untuk bekerja dan berbagi data. Semua zona pendaratan data Anda mematuhi audit dan kontrol yang sama, tetapi Anda masih dapat memiliki fleksibilitas dan perubahan desain antara zona pendaratan data yang berbeda.
Beberapa aspek menentukan domain data fungsional mana yang harus Anda kelompokkan secara logis dan membuat kandidat untuk zona pendaratan data bersama. Misalnya, batas regional dapat mengakibatkan Anda menerapkan cetak biru yang sama. Kepemilikan, keamanan, atau batas hukum dapat memaksa Anda untuk memisahkan domain. Fleksibilitas, laju perubahan, dan pemisahan atau penjualan kemampuan Anda juga merupakan faktor penting.
Panduan lebih lanjut dan praktik terbaik dapat ditemukan di domain data.
Zona pendaratan yang berbeda tidak berdiri sendiri. Mereka dapat terhubung ke data lake yang dihosting di zona lain. Ini memungkinkan domain untuk berkolaborasi di seluruh perusahaan Anda. Anda juga dapat menerapkan persistensi poliglot untuk mencampur teknologi penyimpanan data yang berbeda. Persistensi poliglot memungkinkan domain Anda untuk langsung membaca data dari domain lain tanpa menduplikasi data.
Saat menyebarkan beberapa zona pendaratan data, ketahuilah bahwa ada overhead manajemen yang melekat pada setiap zona pendaratan data. Anda harus menerapkan peering VNet di antara semua zona pendaratan data, Anda harus mengelola titik akhir privat tambahan, dan sebagainya.
Menyebarkan beberapa zona pendaratan data adalah opsi yang baik jika arsitektur data Anda besar. Anda dapat menambahkan lebih banyak zona pendaratan ke arsitektur Anda untuk mengatasi kebutuhan umum berbagai domain. Zona pendaratan tambahan ini menggunakan peering jaringan virtual untuk terhubung ke zona pendaratan manajemen data dan semua zona pendaratan lainnya. Peering memungkinkan Anda berbagi himpunan data dan sumber daya di seluruh zona pendaratan Anda. Memisahkan data di seluruh zona terpisah memungkinkan Anda menyebarkan beban kerja di seluruh langganan dan sumber daya Azure Anda. Pendekatan ini membantu mengimplementasikan jala data secara organik.
Perusahaan skala besar yang membutuhkan zona manajemen data yang berbeda
Perusahaan besar yang beroperasi dalam skala global dapat memiliki persyaratan manajemen data yang kontras antara berbagai bagian organisasi mereka. Anda dapat menyebarkan beberapa manajemen data dan zona pendaratan data bersama-sama untuk mengatasi masalah ini. Diagram berikut menunjukkan contoh jenis arsitektur ini:
Beberapa zona pendaratan manajemen data harus membenarkan kompleksitas overhead dan integrasi Anda. Misalnya, zona pendaratan manajemen data lain mungkin masuk akal untuk situasi di mana data (meta) organisasi Anda tidak boleh dilihat oleh siapa pun di luar organisasi Anda.
Kesimpulan
Transisi menuju jala data adalah pergeseran budaya yang melibatkan nuansa, trade off, dan pertimbangan. Anda dapat menggunakan analitik skala cloud untuk mendapatkan praktik terbaik dan sumber daya yang dapat dieksekusi. Arsitektur referensi artikel ini menawarkan titik awal bagi Anda untuk memulai implementasi Anda.