Get best of the week

Bermigrasi dari Danau Data yang mulus ke Data Mesh yang didistribusikan

Halo, Habr! Saya mempersembahkan kepada Anda terjemahan artikel “Bagaimana Memindahkan Danau Data Monolitik ke Data Terdistribusi” oleh Zhamak Dehghani (Zhamak Degani) (semua gambar diambil dari artikel yang sama).

Semua perusahaan besar sekarang berusaha membangun gudang data besar yang tersentralisasi. Atau bahkan lebih besar cluster Data Lakes (sebagai aturan, pada hdup). Tapi saya tidak tahu satu contoh keberhasilan pembangunan platform data seperti itu. Di mana-mana ada rasa sakit dan penderitaan bagi mereka yang membangun platform data, dan bagi pengguna. Dalam artikel di bawah ini, penulis (Zhamak Degani) menawarkan pendekatan yang sama sekali baru untuk membangun platform data. Ini adalah arsitektur platform data generasi keempat yang disebut Data Mesh. Artikel asli dalam bahasa Inggris sangat tebal dan terus terang sulit dibaca. Terjemahan juga ternyata agak besar dan teksnya tidak terlalu sederhana: kalimat yang panjang, kosakata yang agak kering. Saya tidak merumuskan kembali pemikiran penulis untuk menjaga keakuratan kata-katanya.Tetapi saya sangat menyarankan Anda masih membaca teks yang sulit ini dan membaca artikelnya. Bagi mereka yang berurusan dengan data, itu akan sangat bermanfaat dan sangat menarik.

Evgeny Cherny

Banyak perusahaan berinvestasi dalam generasi Data Lake berikutnya dengan harapan menyederhanakan akses data di seluruh perusahaan dan memberikan wawasan bisnis dan kemampuan untuk membuat keputusan berkualitas tinggi secara otomatis. Namun pendekatan saat ini untuk membangun platform data memiliki masalah serupa yang tidak memungkinkan kami untuk mencapai tujuan kami. Untuk mengatasi masalah ini, kita perlu meninggalkan paradigma Danau Data terpusat (atau pendahulunya, gudang data). Dan beralihlah ke paradigma berdasarkan arsitektur terdistribusi modern: pertimbangkan domain bisnis sebagai prioritas tingkat pertama, terapkan pemikiran platform untuk menciptakan infrastruktur dengan kemampuan swalayan, dan anggap data sebagai produk.

gambar

Kandungan

  • Arsitektur saat ini dari platform data di perusahaan besar
    • Pendekatan arsitektur yang bermasalah
    • domain driven
      • -
      • (data pipelines),
        • (discoverable)
        • (addressable)
        • ,
    • data- -
    • Infrastruktur data terpusat sebagai platform
  • Pergeseran paradigma menuju Data Mesh

Membangun organisasi berbasis data tetap menjadi salah satu tujuan strategis utama dari banyak perusahaan tempat saya bekerja. Klien saya sangat sadar akan keuntungan membuat keputusan berdasarkan data berkualitas tinggi: memastikan kualitas layanan pelanggan yang terbaik, personalisasi yang berlebihan, mengurangi biaya operasi dan waktu karena optimalisasi, menyediakan karyawan dengan alat analisis dan analisis bisnis. Mereka banyak berinvestasi dalam membangun platform data modern. Tetapi terlepas dari upaya dan investasi yang tumbuh dalam membangun platform semacam itu, banyak organisasi melihat hasilnya sebagai biasa-biasa saja.

Organisasi menghadapi banyak kesulitan dalam proses transformasi menjadi perusahaan yang digerakkan oleh data: migrasi dari sistem lama dan sistem pengembangan selama beberapa dekade, perlawanan dari budaya yang ada, dan persaingan yang tinggi antara berbagai prioritas bisnis. Bagaimanapun, saya ingin berbagi dengan Anda pendekatan arsitektur yang memperhitungkan alasan kegagalan banyak inisiatif di bidang membangun platform data. Saya akan menunjukkan bagaimana kita dapat beradaptasi dan menerapkan pelajaran dari dekade terakhir dalam membangun arsitektur terdistribusi di bidang data. Saya telah menyebut pendekatan arsitektur baru ini Data Mesh .

Sebelum membaca lebih lanjut, saya meminta Anda untuk mencoba mengabaikan prasangka yang telah ditetapkan oleh paradigma arsitektur platform data tradisional saat membaca artikel ini. Terbukalah terhadap kemungkinan pindah dari Data Lakes yang terpusat ke arsitektur Data Mesh yang didistribusikan secara sengaja. Terima bahwa data didistribusikan secara inheren dan ada di mana-mana.

Arsitektur saat ini dari platform data di perusahaan besar


Mari kita bicara tentang makna data Danau Data yang terpusat, monolitik, dan mandiri.

Hampir setiap klien yang bekerja dengan saya sedang merencanakan atau sedang membangun platform data generasi ketiga mereka. Mengakui kesalahan generasi sebelumnya.

  • Generasi pertama: gudang data perusahaan dan platform intelijen bisnis. Ini adalah keputusan untuk sejumlah besar uang yang membuat perusahaan memiliki utang teknis yang sama besarnya. Hutang teknis ada dalam ribuan pekerjaan, tabel, dan laporan ETL yang tidak didukung yang hanya dipahami oleh sekelompok kecil spesialis, yang mengarah pada perkiraan dampak positif fungsi ini pada bisnis yang terlalu rendah.
  • Generasi kedua: Ekosistem Big Data dengan Data Lake sebagai peluru perak. Ekosistem rumit dari data besar dan pekerjaan batch yang berjalan lama didukung oleh tim sentral dari insinyur data yang sangat terspesialisasi. Paling-paling, digunakan untuk analitik R&D.

Platform data generasi ketiga kurang lebih mirip dengan generasi sebelumnya, tetapi dengan bias terhadap

  1. streaming untuk menyediakan ketersediaan data real-time dengan arsitektur seperti Kappa ,
  2. menggabungkan pemrosesan batch dan streaming untuk mengubah data menggunakan kerangka kerja seperti Apache Beam ,
  3. penggunaan layanan cloud untuk penyimpanan dan pemrosesan data dan platform Cloud Machine Learning.

Platform data generasi ketiga menghilangkan beberapa masalah dari generasi sebelumnya, seperti analisis data waktu nyata, dan juga mengurangi biaya pengelolaan infrastruktur data besar. Namun, banyak fitur mendasar yang menyebabkan kegagalan generasi sebelumnya masih dipertahankan.

gambar
Gambar 1: Tiga Generasi Platform Data

Pendekatan arsitektur yang bermasalah


Untuk mengungkap keterbatasan dasar yang dimiliki semua generasi platform data, mari kita lihat arsitektur dan fiturnya. Pada artikel ini, saya akan menggunakan bisnis streaming media Internet (seperti Spotify, SoundCloud, Apple iTunes) sebagai contoh untuk menjelaskan beberapa konsep.

Terpusat dan monolitik


Dari ketinggian 10.000 meter, arsitektur platform data terlihat seperti Gambar 2 di bawah ini.
gambar
Gambar 2: Pemandangan dari ketinggian 10.000 meter pada platform data monolitik Bagian

utama dari arsitektur bertanggung jawab untuk:

  • (to ingest) , , . , , : ; ; ; , ; ( ..).
  • , , , . , , — .
  • (to serve) . machine learning BI . , . , Kafka.

Secara default, perjanjian yang diterima secara umum adalah kenyataan bahwa Platform Data monolitik menyimpan dan memiliki data yang dimiliki oleh domain bisnis yang berbeda. Misalnya, 'mainkan acara', 'KPI penjualan', 'artis', 'album', 'label', 'audio', 'podcast', 'acara musik', dll. - data dari sejumlah besar domain yang berbeda.

Terlepas dari kenyataan bahwa selama dekade terakhir kami telah berhasil menerapkan konsep Desain Berbasis Domain (dan pola Bounded Context key ) untuk desain sistem informasi kami, kami sebagian besar mengabaikan konsep-konsep ini dalam desain platform data. Kami telah beralih dari kepemilikan data di tingkat domain bisnis ke kepemilikan data terlepas dari domain bisnis. Kami banggayang menciptakan monolit terbesar - Platform Big Data.

gambar
Gambar 3: Platform data terpusat tanpa batas yang jelas antara data dari domain bisnis yang berbeda. Dan tanpa kepemilikan data yang relevan oleh domain bisnis,

model terpusat semacam itu dapat bekerja untuk organisasi kecil yang memiliki domain bisnis sederhana dan opsi konsumsi data terbatas. Tetapi itu tidak cocok untuk perusahaan besar dengan domain bisnis besar dan kompleks, sejumlah besar sumber data dan beragam kebutuhan untuk bekerja dengan data dari konsumen.

Ada dua tautan lemah dalam arsitektur dan struktur platform data terpusat, yang sering menyebabkan kegagalan dalam proses membangunnya:

  • Sejumlah besar sumber dan sejumlah besar data. , , . , . . , , , . , data scientists . , ( ) , . , – - .
  • . . , . .

Di sini saya perlu mengklarifikasi bahwa saya tidak mendukung penggunaan data terpecah-pecah dan tersembunyi di kedalaman sistem warisan. Data seperti itu yang sulit dideteksi, dipahami dan digunakan. Saya juga tidak mendukung banyak gudang data yang berbeda dalam organisasi yang sama, yang merupakan hasil dari akumulasi hutang teknis selama bertahun-tahun. Tetapi saya berpendapat bahwa jawaban untuk data terfragmentasi yang tidak dapat diakses seperti itu bukan untuk membuat platform data terpusat dengan tim terpusat yang menyimpan dan memiliki data dari semua domain bisnis.

Pendekatan ini tidak skala dalam organisasi besar, seperti yang ditunjukkan di atas.

Dekomposisi konveyor yang sangat terhubung


gambar
Gambar 4: Dekomposisi arsitektur platform data

Masalah kedua dengan arsitektur tradisional platform data adalah bagaimana kita mendekomposisi arsitektur. Jika turun hingga 3.000 meter di atas arsitektur platform data, kita akan menemukan dekomposisi arsitektur di sekitar fungsi pemuatan, pembersihan, pengumpulan, penyajian data, dll. Seperti yang dijelaskan di bagian sebelumnya, kebutuhan untuk menghubungkan sumber baru dan konsumen baru membutuhkan pertumbuhan platform. Arsitek harus menemukan cara untuk skala sistem dengan memecahnya menjadi kuanta arsitektur. Arsitektur kuantum, seperti yang dijelaskan dalam buku " Membangun Arsitektur Evolusi", Merupakan komponen yang dapat digunakan secara independen dengan konektivitas fungsional yang tinggi, yang mencakup semua elemen struktural yang diperlukan untuk pengoperasian sistem yang benar. Motivasi untuk membagi sistem ke dalam kuanta arsitektur terutama terdiri dalam menciptakan tim independen, yang masing-masing menciptakan dan mempertahankan kuantum arsitekturnya sendiri (subsistem fungsional). Ini memungkinkan Anda untuk memparalelkan pekerjaan dan meningkatkan kecepatan dan skalabilitas operasional.

Dipengaruhi oleh platform data generasi sebelumnya, arsitek membagi platform menjadi serangkaian langkah pemrosesan data. Ini adalah saluran pipa yang mengimplementasikan pemrosesan data: memuat, menyiapkan, mengumpulkan, menyediakan akses / pembongkaran, dll.

Meskipun partisi ini memberikan tingkat penskalaan tertentu, namun juga memiliki batasan internal yang memperlambat pengembangan fungsi baru pada platform: ada konektivitas tinggi antara langkah-langkah pipa, yang tidak memungkinkan independensi yang diperlukan dari masing-masing tim.

Mari kita kembali ke contoh media streaming kami. Platform media streaming di Internet memiliki desain domain yang kuat di sekitar jenis media yang mereka tawarkan. Mereka sering memulai layanan mereka dengan "lagu" dan "album", dan kemudian berlaku untuk "acara musik", "podcast", "acara radio", "film", dll. Mengaktifkan satu fitur baru, misalnya, visibilitas untuk "podcast" play rate ”, membutuhkan perubahan dalam semua komponen pipa. Tim perlu mengembangkan layanan baru untuk memuat, membersihkan, dan menyiapkan data (termasuk agregasi) untuk menambah visibilitas "tingkat pemutaran podcast". Ini membutuhkan sinkronisasi antara rilis berbagai tim fungsional. Banyak platform data menggunakan alat unduhan berbasis konfigurasi yang dapat dengan mudah menangani tugas-tugas tersebut.seperti hanya menambahkan sumber baru atau memperluas yang sudah ada. Tetapi ini tidak menghilangkan kebutuhan untuk manajemen rilis end-to-end pada semua tahap dari pipa pemrosesan data. Untuk memberi pengguna akses ke data baru apa pun, unit arsitektur minimum yang perlu diubah adalah keseluruhan pipa. Dan ini secara signifikan membatasi kemampuan kami untuk meningkatkan kecepatan dan skala pengembangan platform data dalam menanggapi munculnya sumber dan pengguna data baru.Dan ini secara signifikan membatasi kemampuan kami untuk meningkatkan kecepatan dan skala pengembangan platform data dalam menanggapi munculnya sumber dan pengguna data baru.Dan ini secara signifikan membatasi kemampuan kami untuk meningkatkan kecepatan dan skala pengembangan platform data dalam menanggapi munculnya sumber dan pengguna data baru.

Tim yang berbeda dan sangat terspesialisasi


Masalah ketiga dengan platform data modern adalah bagaimana kita menyusun tim yang membuat dan memelihara platform. Ketika kita melangkah lebih rendah dari arsitektur platform data tradisional, kita akan melihat sekelompok insinyur data khusus yang terpisah dari unit organisasi di mana data dibuat atau digunakan untuk pengambilan keputusan. Insinyur platform data dipilih dalam tim terpisah hanya berdasarkan kompetensi teknis dan pengalaman mereka dengan teknologi data besar. Pengetahuan bisnis tentang bidang subjek yang sesuai (domain bisnis) tidak ada di tim tersebut.

gambar
Gambar 5: Tim platform data khusus yang tersebar sempit

Secara pribadi, saya tidak iri dengan kehidupan para insinyur platform data. Mereka harus menerima data dari tim yang tidak memiliki insentif untuk memberikan kualitas dan data yang benar. Mereka kurang memahami arti bisnis dari data yang harus Anda unduh. Mereka harus menyiapkan data untuk memenuhi kebutuhan analitis dan operasional, tanpa pemahaman yang jelas tentang penggunaan akhir data ini dan tanpa akses ke para ahli di bidang konsumsi data ini.

Perlu dicatat bahwa kami sebelumnya pernah mengalami masalah yang sama yaitu pemisahan tim. Dan mereka dapat menemukan solusi yang berhasil untuk masalah ini.

gambar

Dalam contoh kami dengan streaming multimedia, kami memiliki perintah "media player", yang memiliki data tentang bagaimana pengguna berinteraksi dengan pemain: lagu yang didengarkan pengguna, pembelian yang dilakukan, kualitas audio dari lagu yang mereka dengarkan, dll. Di sisi lain, ada tim konsumen dari data yang relevan: tim rekomendasi lagu; tim pemantau penjualan; tim pembayaran artis, dll. Dan di antara mereka, tim pengembang platform data yang menyedihkan, yang, dengan biaya usaha keras, menerima data dari satu tim dan menyediakan akses kepada mereka (setelah pemrosesan awal) untuk semua konsumen.

Pada kenyataannya, kami memiliki tim sumber data yang tidak terlibat dan tim konsumen data yang frustrasi yang harus berjuang untuk mendapat tempat di bagian atas tumpukan tim pengembangan platform data.

Kami telah menciptakan arsitektur dan struktur organisasi yang tidak memberikan skalabilitas yang diperlukan dan tidak mampu mencapai tujuan membangun organisasi yang didorong data.

Arsitektur Platform Data Generasi Selanjutnya


Dan apa solusi untuk masalah yang kita bahas di atas? Menurut pendapat saya, perubahan paradigma diperlukan. Pergeseran paradigma di persimpangan metode yang telah memainkan peran penting dalam membangun arsitektur terdistribusi scalable modern dan yang industri teknologi secara keseluruhan telah dilaksanakan pada kecepatan yang dipercepat. Metode yang menghasilkan hasil yang sukses.

Saya percaya bahwa arsitektur platform data perusahaan berikutnya adalah mengintegrasikan Arsitektur Didorong Domain Terdistribusi, merancang platform layanan mandiri, dan pemikiran produk untuk data.

gambar
Gambar 6: Mengubah pergeseran paradigma platform data generasi berikutnya.

Saya mengerti bahwa ini mungkin terdengar seperti banyak kata kunci dalam satu kalimat, tetapi masing-masing komponen ini memiliki dampak yang sangat positif pada perubahan fondasi teknis sistem informasi kami. Mari kita lihat bagaimana kita dapat menerapkan masing-masing disiplin ilmu ini ke dunia data untuk menjauh dari paradigma saat ini yang telah ditransfer dari bertahun-tahun membangun gudang data generasi sebelumnya.

Data dan arsitektur berbasis domain terdistribusi


Dekomposisi dan kepemilikan data berdasarkan orientasi domain bisnis


Buku Eric Evans, Domain-Driven Design , telah memiliki dampak besar pada pemikiran arsitektur kontemporer dan, oleh karena itu, pemodelan organisasi. Arsitektur microservice baru menguraikan sistem informasi menjadi layanan terdistribusi yang dibangun dalam batas-batas domain bisnis tertentu. Ini secara mendasar mengubah cara tim dibentuk: mulai sekarang, sebuah tim dapat secara mandiri dan mandiri memiliki layanan-layanan mikronya.

Menariknya, kami mengabaikan konsep domain bisnis di bidang data. Datang Aplikasi Desain Didorong Domain dalam Arsitektur Platform Data: Ini adalah Munculnya Acara Domain Bisnisdalam sistem informasi dan memuatnya ke dalam platform data monolitik. Namun, setelah data diunggah ke penyimpanan terpusat, konsep kepemilikan data dari domain bisnis yang berbeda oleh tim yang berbeda hilang.

Untuk mendesentralisasi platform data monolitik, Anda perlu mengubah cara Anda berpikir tentang data, lokasi, dan kepemilikannya. Alih-alih mentransfer data ke Data Lake atau platform, domain harus menyimpan dan memelihara set data mereka dengan cara yang ramah pengguna.

Dalam contoh kami, alih-alih memuat data dari pemutar media ke repositori terpusat untuk diproses lebih lanjut oleh tim dukungan repositori, mengapa tidak menyimpan dan memproses kumpulan data ini dalam domain dan tidak memberikan akses tim lain kepada mereka? Tempat di mana kumpulan data ini akan disimpan secara fisik dapat diimplementasikan secara teknis di dalam domain sesuai keinginan. Tentu saja, Anda dapat menggunakan arsitektur terpusat, tetapi data dari pemutar media itu sendiri akan tetap berada di bawah kepemilikan dan dukungan tim dari domain yang sesuai di mana data ini dihasilkan. Demikian pula, dalam contoh kami, domain pengembangan rekomendasi lagu dapat membuat kumpulan data dalam format yang paling cocok untuk digunakan (misalnya, dalam bentuk struktur grafik) berdasarkan data dari pemutar media. Jika ada tim lain,yang menganggap format ini nyaman dan bermanfaat, mereka juga dapat mengaksesnya.

Ini, tentu saja, menyiratkan bahwa kami dapat menggandakan data dalam domain yang berbeda ketika kami mengubah formatnya menjadi yang sesuai dengan konsumen tertentu.

Semua ini membutuhkan perubahan dalam pemikiran kami dari mengunduh data (melalui ETL atau streaming) untuk meningkatkan skala proses ini ke semua domain. Kuantum arsitektur dalam platform data berorientasi domain adalah domain bisnis, bukan tahap memuat dan mengubah data.

gambar
Gambar 7: Dekomposisi arsitektur berdasarkan domain bisnis dan tim pemilik data.

Set data domain sumber


Beberapa domain bisnis selaras dengan sumber data (sistem informasi). Dalam kasus yang ideal, sistem informasi dan tim yang menyertainya tidak hanya bertanggung jawab untuk menambah dan mendukung fungsi bisnis, tetapi juga menyediakan kumpulan data yang menggambarkan fakta dan realitas dari domain bisnis yang sesuai. Namun, pada skala organisasi besar, sebagai suatu peraturan, tidak ada korespondensi yang jelas antara domain bisnis dan sistem informasi. Sebagai aturan, untuk setiap domain ada beberapa sistem informasi yang mengotomatiskan proses bisnis yang berbeda dari domain yang diberikan dan, karenanya, menyimpan data yang terkait dengannya. Untuk domain seperti itu, ada kebutuhan untuk mengintegrasikan dan mengagregasi data yang berbeda untuk mendapatkan set data yang konsisten dan selaras di seluruh domain bisnis.

Format terbaik untuk menyimpan fakta yang menggambarkan domain bisnis adalah Acara Domain . Mereka dapat disimpan sebagai log peristiwa didistribusikan dengan cap waktu. Log ini dapat diberikan akses ke konsumen yang berwenang.

Selain log ini, sumber data juga harus menyediakan akses ke snapshot berkala dari set data utama di domain mereka. Agregat gambar tersebut untuk interval waktu yang lebih baik mencerminkan interval perubahan untuk domain Anda (biasanya sehari / minggu / bulan / kuartal, dll.).

Harap perhatikan bahwa set data domain bisnis yang disiapkan untuk konsumen harus dipisahkan dari set sumber data internal (yang digunakan sistem informasi untuk pekerjaan mereka). Mereka harus disimpan di tempat yang berbeda secara fisik yang cocok untuk bekerja dengan data besar. Selanjutnya, akan dijelaskan cara membuat data warehouse dan infrastruktur layanan untuk itu.

Kumpulan data khusus domain yang disiapkan untuk konsumen adalah elemen paling dasar dari keseluruhan arsitektur. Mereka tidak bertransformasi dan tidak dirancang untuk konsumen tertentu, tetapi merupakan data mentah dan tidak diolah.

Kumpulan data domain konsumen


Domain lain terkait erat dengan data konsumen. Set data domain semacam itu dibuat sedemikian rupa sehingga, ketika digunakan, mereka cocok dengan set skenario pengguna yang terkait. Kumpulan data ini berbeda dari kumpulan data domain sumber. Ini bukan data mentah, tetapi data melewati beberapa tahap transformasi. Struktur set data ini dan penyajiannya disesuaikan dengan kasus spesifik penggunaannya. Itu Ini adalah analog dari data mart khusus dalam repositori terpusat. Untuk set data seperti domain konsumen (dataset domain konsumen) harus disediakan kemungkinan pemulihan cepat dari data mentah.

Jalur pipa data terdistribusi diimplementasikan dalam domain mereka


Kepemilikan data dalam arsitektur baru kami didelegasikan dari platform pusat ke tim dalam domain bisnis, tetapi kebutuhan untuk pembersihan, persiapan, dan agregasi data (menggunakan jalur pipa data) tidak hilang. Oleh karena itu, implementasi pipeline datanya sendiri menjadi tugas internal tim domain bisnis. Akibatnya, kami mendapatkan jaringan pipa data domain kami sendiri yang didistribusikan di semua domain.

Misalnya, domain sumber harus mencakup pembersihan data, penghapusan duplikat, pengayaan data, dll., Sehingga domain lain dapat menggunakan data ini tanpa pemrosesan awal. Setiap kumpulan data tersebut harus memenuhi Tujuan Tingkat Layanannya dalam hal kualitas data.

Demikian pula, tahap-tahap membangun showcases terspesialisasi dari pipeline terpusat untuk memproses data masuk ke jalur pipa data sendiri dari domain konsumen yang membangun dataset domain konsumen.

gambar
Gambar 8: Jalur pipa pemrosesan data terdistribusi yang diimplementasikan di dalam domainnya

Tampaknya model seperti itu akan mengarah pada duplikasi besar upaya di setiap domain untuk membuat implementasi sendiri dari jalur pipa pemrosesan data. Kami akan membicarakan masalah ini di bagian "infrastruktur data terpusat sebagai platform".

Data dan Pemikiran Produk


Pemindahan kepemilikan data dan tanggung jawab untuk pengembangan dan pemeliharaan pipa pemrosesan data ke sisi domain bisnis dapat menimbulkan kekhawatiran serius tentang ketersediaan yang berkelanjutan dan kemudahan penggunaan set data yang didistribusikan tersebut. Oleh karena itu, di sini kita menemukan pemikiran produk yang berguna terkait dengan data.

Data Domain sebagai Produk


Selama sepuluh tahun terakhir, pemikiran produk telah sangat menembus pengembangan sistem informasi organisasi dan telah secara serius mengubah pendekatan untuk pengembangan ini. Tim domain untuk pengembangan sistem informasi memberikan kemampuan baru dalam bentuk API yang digunakan pengembang dalam organisasi sebagai blok bangunan untuk menciptakan fungsionalitas urutan yang lebih tinggi dan nilai yang lebih tinggi. Tim berusaha keras untuk menciptakan pengalaman terbaik bagi pengguna API mereka melalui dokumentasi yang jelas dan terperinci yang mudah diakses oleh pengguna; lingkungan pengujian indikator kualitas yang dilacak dengan cermat.

Agar platform data terdistribusi menjadi sukses, tim data dari domain bisnis harus menerapkan pemikiran produk dalam kaitannya dengan menyediakan kumpulan data: memahami data yang mereka siapkan sebagai produk, dan konsumen (analis, ilmuwan data, insinyur data, spesialis ML dll) sebagai pelanggan Anda.

gambar
Gambar 9: Karakteristik Kumpulan Data Domain sebagai Produk

Pertimbangkan contoh kami - streaming konten media melalui Internet. Domain bisnis yang paling penting adalah kisah reproduksi: oleh siapa, di mana, kapan, dan lagu mana yang didengarkan. Domain ini memiliki berbagai data konsumen utama dalam organisasi. Seseorang membutuhkan data dalam mode waktu dekat untuk mempelajari pengalaman pengguna dan deteksi tepat waktu dari masalah dan kesalahan pemutaran. Yang lain tertarik pada snapshot historis yang dikumpulkan berdasarkan hari atau bulan. Oleh karena itu, domain kami menyediakan data dalam dua format: peristiwa pemutaran dalam bentuk streaming (streaming, topik dalam kafka atau sesuatu seperti itu) dan peristiwa pemutaran teragregasi dalam format batch (file, tabel dalam sarang, dll.).

Untuk memberikan pengalaman pengguna terbaik bagi konsumen, produk data domain bisnis harus memiliki fitur utama berikut.

Kenyamanan dan kemudahan deteksi (dapat ditemukan)


Penting untuk memastikan kondisi di mana produk-data dapat dengan mudah ditemukan. Implementasi yang paling umum dari persyaratan ini adalah keberadaan registri - katalog semua produk data yang tersedia dengan informasi meta yang diperlukan (seperti pemilik, sumber asal, sampel kumpulan data, frekuensi pembaruan, struktur set data, dll.). Layanan terpusat semacam itu memungkinkan konsumen data untuk dengan mudah menemukan kumpulan data yang mereka minati. Setiap produk data dari domain bisnis apa pun harus didaftarkan dalam direktori data terpusat.

Harap perhatikan bahwa ada pergeseran dari platform terpusat tunggal yang memiliki semua data ke produk data terdistribusi dari berbagai domain bisnis yang terdaftar di direktori data tunggal.

Alamat unik (dapat dialamatkan)


Setiap produk-data harus memiliki alamat unik (sesuai dengan perjanjian global), yang akan memungkinkan konsumennya mendapatkan akses terprogram ke sana. Organisasi dapat mengadopsi berbagai perjanjian tentang nama produk data dan lokasinya, tergantung pada metode penyimpanan data yang tersedia dan format data itu sendiri. Untuk arsitektur terdesentralisasi terdistribusi, konvensi umum seperti itu diperlukan. Standar alamat dataset akan menghilangkan gesekan saat mencari dan mengakses produk data.

Kualitas data


Tidak seorang pun akan menggunakan produk yang tidak kredibel. Di platform data generasi saat ini, mengunduh dan menerbitkan data yang mengandung kesalahan dan tidak mencerminkan seluruh kebenaran bisnis tersebar luas, yaitu. data yang tidak bisa dipercaya. Di bagian inilah sejumlah besar pekerjaan ETL terkonsentrasi, yang menghapus data setelah pemuatan.

Arsitektur baru mengharuskan pemilik produk data untuk mengadopsi SLO (Service Level Objective) dalam hal akurasi, keandalan, dan relevansi data. Untuk memastikan kualitas yang dapat diterima, perlu menggunakan metode seperti pembersihan data dan pengujian integritas data otomatis pada tahap pembuatan produk data. Informasi tentang garis keturunan data dalam metadata setiap produk data memberi konsumen kepercayaan tambahan pada produk itu sendiri dan kesesuaiannya untuk kebutuhan spesifik.

Nilai target indikator kualitas data (atau rentang yang dapat diterima) bervariasi tergantung pada produk data dari domain bisnis tertentu. Misalnya, domain "acara ulangan" dapat menyediakan dua produk berbeda: satu dalam mode waktu nyata dekat dengan tingkat akurasi yang lebih rendah (termasuk peristiwa yang terlewat atau berulang); dan yang kedua dengan penundaan yang lebih lama dan tingkat kualitas data yang lebih tinggi. Setiap data-produk mendefinisikan dan mempertahankan tingkat target integritas dan keandalan data dalam bentuk seperangkat SLO (Service Level Objective).

Deskripsi yang jelas tentang sintaksis semantik dan data


Produk yang berkualitas harus mudah digunakan. Menciptakan produk data sesederhana mungkin untuk digunakan oleh analis, insinyur, dan ilmuwan data membutuhkan keberadaan semantik dan sintaksis data yang dijelaskan dengan baik. Idealnya, dataset sampel disediakan sebagai contoh.

Integritas Data dan Standar Seluruh Organisasi


Salah satu masalah utama dalam arsitektur data driven domain terdistribusi adalah kebutuhan untuk mengintegrasikan data dari domain yang berbeda. Kunci untuk integrasi data yang mudah dan efisien antara domain adalah dengan menetapkan dan mengikuti aturan dan standar. Standar semacam itu harus didefinisikan di tingkat organisasi. Dibutuhkan standardisasi di bidang penentuan jenis data dan aturan yang dapat diterima untuk aplikasi mereka, konvensi tentang nama dan alamat produk data, format metadata, dll.

Untuk entitas yang dapat disimpan dalam bentuk yang berbeda dan dengan sekumpulan atribut yang berbeda di domain yang berbeda, perlu untuk menerapkan praktik Manajemen Data Master. Tetapkan mereka sebagai pengidentifikasi global dan sejajarkan set dan, yang paling penting, nilai atribut di antara semua domain.

Memastikan interoperabilitas data untuk integrasi efektifnya, serta menentukan standar untuk menyimpan dan menyajikan produk data di tingkat organisasi, adalah salah satu prinsip dasar untuk membangun sistem terdistribusi tersebut.

Keamanan Data dan Kontrol Akses


Memastikan akses yang aman ke data adalah suatu keharusan, terlepas dari apakah arsitekturnya terpusat atau tidak. Dalam dunia produk data berorientasi bisnis yang terdesentralisasi, kontrol akses dimungkinkan (dan harus diterapkan) dengan tingkat granularitas yang lebih tinggi untuk setiap set data. Kebijakan kontrol akses data dapat didefinisikan secara terpusat, tetapi diterapkan secara terpisah untuk setiap produk data. Sebagai cara mudah untuk menerapkan kontrol akses ke kumpulan data, Anda dapat menggunakan sistem Manajemen Identitas Perusahaan dan kontrol akses berbasis peran .

Selanjutnya, satu infrastruktur akan dijelaskan, yang memungkinkan Anda untuk dengan mudah dan otomatis mengimplementasikan fitur-fitur di atas untuk setiap produk data.

Perintah data domain bisnis lintas-fungsional


Peran berikut harus diwakili dalam tim yang menyediakan data dalam bentuk produk data: pemilik produk data dan insinyur data.

Pemilik produk data bertanggung jawab atas konsep dan peta jalan, siklus hidup produknya. Mengukur kepuasan pelanggan dan secara konstan mengukur dan meningkatkan kualitas data domain bisnisnya. Ini mengisi dan menyeimbangkan simpanan produk datanya dengan persyaratan data konsumen.

Juga, pemilik produk data harus menetapkan metrik kunci dan indikator kinerja (KPI) untuk produk mereka. Misalnya, waktu yang diperlukan untuk membiasakan diri dan mulai menggunakan produk data oleh pengguna mungkin merupakan salah satu dari metrik ini.

Untuk membuat dan memelihara jalur pipa data mereka sendiri di dalam domain bisnis, tim harus menyertakan insinyur data. Efek samping yang baik dari ini adalah penyebaran keterampilan yang relevan dalam domain bisnis. Menurut pengamatan saya, saat ini beberapa insinyur data, walaupun kompeten dalam menggunakan alat dan teknologinya, tidak memiliki pengetahuan tentang praktik pengembangan perangkat lunak standar dalam hal menciptakan produk data. Pertama-tama, praktik DevOps seperti pengiriman terus menerus dan pengujian otomatis. Di sisi lain, pengembang perangkat lunak yang mengembangkan sistem informasi sering tidak memiliki pengalaman dan pengetahuan yang cukup di bidang teknologi dan alat untuk bekerja dengan data sebagai produk.Menggabungkan mereka ke dalam tim multifungsi dalam domain bisnis akan mengarah pada munculnya spesialis dari profil yang lebih luas. Kami mengamati sesuatu yang serupa selama pengembangan DevOps ketika tipe baru insinyur muncul, sepertiSRE .

gambar
Gambar 10: Perintah data domain lintas fungsional

Infrastruktur data terpusat sebagai platform


Salah satu aspek sensitif dari arsitektur yang didorong domain terdistribusi dari platform data adalah perlunya duplikasi di setiap domain dari upaya dan keterampilan yang diperlukan untuk mengoperasikan infrastruktur dan tumpukan teknologi yang digunakan dalam jalur pipa data. Untungnya, penciptaan infrastruktur bersama sebagai platform adalah tugas yang dipelajari dengan baik untuk dipecahkan dalam TI (tetapi tidak di bidang bekerja dengan data).

Tim infrastruktur data harus memiliki dan menyediakan sebagai alat layanan yang diperlukan untuk domain bisnis untuk mengumpulkan, memproses, dan menyimpan produk data mereka.

gambar
Gambar 11: Infrastruktur Data sebagai Platform

Infrastruktur data sebagai platform harus bebas dari konsep khusus domain atau logika bisnis. Selain itu, platform harus menyembunyikan kerumitan implementasinya dari pengguna dan memberikan fungsionalitas dalam jumlah maksimum untuk digunakan dalam mode swalayan. Berikut adalah daftar beberapa fitur yang harus disediakan oleh infrastruktur data terpusat seperti platform:

  • Penyimpanan data scalable dalam berbagai format
  • Enkripsi data (di sini hashing, depersonalisasi, dll.)
  • Versi produk data
  • Menyimpan data skema data produk
  • Kontrol akses data
  • Penebangan
  • Orkestrasi thread / proses pengolahan data
  • Caching dalam memori
  • Menyimpan metadata dan garis keturunan data
  • Pemantauan, peringatan, pencatatan
  • Perhitungan metrik kualitas untuk produk data
  • Pemeliharaan Katalog Data
  • Standardisasi dan kebijakan, kemampuan untuk mengendalikan kepatuhan
  • Mengatasi produk data
  • Jalur pipa CI / CD untuk produk data

Saat membuat infrastruktur data terpusat, perlu dipastikan bahwa pembuatan produk data pada infrastruktur seperti itu membutuhkan waktu sesingkat mungkin. Oleh karena itu, otomatisasi maksimum fungsionalitas utama sangat penting, seperti: kemampuan untuk mengunduh data menggunakan konfigurasi sederhana, registrasi otomatis produk data dalam direktori data, dll. Menggunakan infrastruktur cloud dapat mengurangi biaya pengoperasian dan meningkatkan kecepatan penyediaan akses ke infrastruktur data sesuai permintaan.

Pergeseran paradigma menuju Data Mesh


Itu sudah lama dibaca! Mari kita singkatkan semua yang tertulis di atas. Kami memeriksa beberapa karakteristik utama dari platform data modern: jaringan pipa data yang terpusat, monolitik, dan kompleks (dengan ratusan dan ribuan pekerjaan yang saling terkait erat satu sama lain), tim-tim khusus yang berbeda. Setelah kami berbicara tentang pendekatan data mesh baru, yang mencakup produk data terdistribusi yang berfokus pada domain bisnis yang dikelola oleh tim lintas fungsi (dengan pemilik produk data dan insinyur data), menggunakan infrastruktur data umum sebagai platform untuk hosting.

Data Mesh adalah arsitektur terdistribusi, dengan manajemen terpusat dan standar yang dikembangkan yang memastikan integritas data, dan dengan infrastruktur terpusat yang memungkinkan penggunaan swalayan. Saya harap pembaca cukup jelas bahwa arsitektur seperti itu sangat jauh dari satu set penyimpanan data yang tidak dapat diakses secara longgar, dikembangkan secara independen di berbagai departemen.

gambar
Gambar 12: Arsitektur Data Mesh dari 10.000 Meter

Anda mungkin bertanya: bagaimana Data Lake atau Data Warehouse masuk ke dalam arsitektur ini? Mereka hanya memisahkan node (domain) dalam arsitektur terdistribusi ini. Ada kemungkinan besar bahwa dalam arsitektur seperti itu kita tidak lagi membutuhkan Data Lake. Bagaimanapun, kita akan memiliki akses untuk meneliti data asli dari berbagai domain bisnis, yang dirancang dalam bentuk produk-data.

Dengan demikian, Danau Data tidak lagi menjadi elemen sentral dari keseluruhan arsitektur. Tetapi kami akan terus menggunakan teknologi dan alat yang digunakan untuk membangun Danau Data, baik untuk membuat infrastruktur data umum, atau untuk implementasi internal produk-data kami.

Ini benar-benar membawa kita kembali ke tempat semuanya dimulai. James dicksonpada 2010 ia bermaksud menggunakan Data Lake untuk satu domain bisnis, dan beberapa domain data akan membentuk Water Garden.

Pergeseran paradigma utama adalah untuk mempertimbangkan produk data domain bisnis sebagai tugas prioritas pertama, dan alat dan teknologi sebagai tugas prioritas kedua (sebagai detail implementasi). Ini untuk mengalihkan model mental dari Danau Data yang terpusat ke dalam ekosistem produk data yang terintegrasi secara mulus dan efisien satu sama lain.

Beberapa kata tentang pelaporan dan visualisasi (menggunakan alat BI, dll.). Prinsip yang sama berlaku untuk mereka: dalam arsitektur ini mereka adalah node yang terpisah. Itu mereka adalah produk-data independen dalam domain bisnis, fokus utamanya pada konsumen, dan bukan pada sumber data.

Saya akui bahwa meskipun saya melihat aplikasi yang sukses dari prinsip-prinsip Data Mesh oleh klien saya, meningkatkan prinsip-prinsip ini dalam organisasi besar masih jauh. Tetapi teknologi jelas bukan batasan di sini. Semua alat yang kami gunakan saat ini dapat digunakan untuk distribusi dan kepemilikan produk data oleh tim yang berbeda. Secara khusus, transisi ke standardisasi pekerjaan pemrosesan data paket dan aliran, serta penggunaan alat-alat seperti Apache Beam atau Google Cloud DataFlow , membuatnya mudah untuk memproses beragam set data dengan alamat unik.

Platform katalog data seperti Katalog Google Cloud Data, memberikan kemudahan penemuan, kontrol akses, dan pengelolaan terpusat set data domain bisnis terdistribusi. Sejumlah besar platform cloud memungkinkan domain bisnis untuk memilih yang cocok untuk penyimpanan produk data yang ditargetkan.

Kebutuhan akan perubahan paradigma sudah jelas. Ada semua teknologi dan alat yang diperlukan untuk ini. Eksekutif bisnis dan profesional pemrosesan data harus mengakui bahwa paradigma dan pendekatan Big Data saat ini dengan satu platform Big Data Lake hanya akan mengulangi kegagalan di masa lalu, menggunakan teknologi dan alat cloud baru.

Mari kita beralih dari platform data monolitik terpusat ke ekosistem produk data.

gambar

Tautan ke sumber utama dan bahan tambahan tentang topik ini


More articles:


All Articles