Mengembangkan fasilitas penyimpanan merupakan pekerjaan yang panjang dan serius.
Banyak hal dalam kehidupan suatu proyek bergantung pada seberapa baik model objek dan struktur dasar dipikirkan pada awalnya.
Pendekatan yang diterima secara umum telah dan masih merupakan berbagai varian penggabungan skema bintang dengan bentuk normal ketiga. Biasanya, menurut prinsip: data awal - 3NF, etalase - bintang. Pendekatan ini, yang telah teruji oleh waktu dan didukung oleh sejumlah besar penelitian, adalah hal pertama (dan terkadang satu-satunya) yang terlintas di benak spesialis DWH berpengalaman ketika memikirkan seperti apa seharusnya repositori analitik itu.
Di sisi lain, kebutuhan bisnis secara umum dan kebutuhan pelanggan pada khususnya cenderung berubah dengan cepat, dan data cenderung berkembang baik “secara mendalam” maupun “luasnya”. Dan di sinilah kelemahan utama sebuah bintang muncul - terbatas keluwesan.
Dan jika dalam kehidupan Anda yang tenang dan nyaman sebagai pengembang DWH tiba-tiba:
- muncul tugas “untuk melakukan setidaknya sesuatu dengan cepat, dan kemudian kita lihat saja”;
- sebuah proyek yang berkembang pesat muncul, dengan koneksi sumber-sumber baru dan pengerjaan ulang model bisnis setidaknya sekali seminggu;
- muncul pelanggan yang tidak tahu seperti apa sistem itu seharusnya dan fungsi apa yang pada akhirnya harus dijalankan, tetapi siap untuk bereksperimen dan secara konsisten menyempurnakan hasil yang diinginkan sambil secara konsisten semakin mendekatinya;
- Manajer proyek datang membawa kabar baik: “Dan sekarang kami memiliki agile!”
Atau jika Anda hanya tertarik untuk mencari tahu bagaimana lagi Anda dapat membangun fasilitas penyimpanan - selamat datang di sini!
Apa yang dimaksud dengan "fleksibilitas"?
Pertama, mari kita tentukan properti apa yang harus dimiliki suatu sistem agar bisa disebut “fleksibel”.
Secara terpisah, perlu disebutkan bahwa properti yang dijelaskan harus berhubungan secara khusus sistem, tidak untuk proses perkembangannya. Oleh karena itu, jika Anda ingin membaca tentang Agile sebagai metodologi pengembangan, ada baiknya membaca artikel lainnya. Misalnya saja di Habré, ada banyak materi menarik (seperti и Dan ).
Ini tidak berarti bahwa proses pengembangan dan struktur data warehouse sama sekali tidak berhubungan. Secara keseluruhan, akan jauh lebih mudah untuk mengembangkan repositori Agile untuk arsitektur tangkas. Namun, dalam praktiknya, lebih sering ada opsi dengan pengembangan Agile dari DWH klasik menurut Kimbal dan DataVault - menurut Waterfall, daripada kebetulan fleksibilitas dalam dua bentuknya pada satu proyek.
Jadi, kemampuan apa yang seharusnya dimiliki oleh penyimpanan fleksibel? Ada tiga poin di sini:
- Pengiriman awal dan penyelesaian cepat - ini berarti idealnya hasil bisnis pertama (misalnya, laporan kerja pertama) harus diperoleh sedini mungkin, bahkan sebelum seluruh sistem dirancang dan diimplementasikan sepenuhnya. Selain itu, setiap revisi selanjutnya juga harus memakan waktu sesingkat mungkin.
- Penyempurnaan berulang - ini berarti bahwa setiap peningkatan selanjutnya idealnya tidak mempengaruhi fungsionalitas yang sudah berfungsi. Momen inilah yang sering menjadi mimpi buruk terbesar dalam proyek besar - cepat atau lambat, objek individual mulai memperoleh begitu banyak koneksi sehingga menjadi lebih mudah untuk mengulangi logika dalam salinan di dekatnya daripada menambahkan bidang ke tabel yang ada. Dan jika Anda terkejut bahwa menganalisis dampak perbaikan pada objek yang ada bisa memakan waktu lebih lama daripada perbaikan itu sendiri, kemungkinan besar Anda belum bekerja dengan gudang data besar di perbankan atau telekomunikasi.
- Terus beradaptasi dengan perubahan kebutuhan bisnis - struktur objek secara keseluruhan harus dirancang tidak hanya dengan mempertimbangkan kemungkinan perluasan, tetapi dengan harapan bahwa arah perluasan berikutnya bahkan tidak dapat diimpikan pada tahap desain.
Dan ya, memenuhi semua persyaratan ini dalam satu sistem adalah mungkin (tentu saja, dalam kasus tertentu dan dengan beberapa syarat).
Di bawah ini saya akan mempertimbangkan dua metodologi desain tangkas yang paling populer untuk gudang data - Model jangkar и Gudang Data. Yang tidak diikutsertakan adalah teknik luar biasa seperti, misalnya, EAV, 6NF (dalam bentuk murni) dan segala sesuatu yang berhubungan dengan solusi NoSQL - bukan karena teknik tersebut lebih buruk, dan bahkan bukan karena dalam kasus ini artikel tersebut akan mengancam untuk memperoleh volume rata-rata disser. Hanya saja semua ini berkaitan dengan solusi dari kelas yang sedikit berbeda - baik dengan teknik yang dapat Anda gunakan dalam kasus tertentu, terlepas dari keseluruhan arsitektur proyek Anda (seperti EAV), atau dengan paradigma penyimpanan informasi lainnya secara global (seperti database grafik). dan opsi lain NoSQL).
Masalah pendekatan “klasik” dan solusinya dalam metodologi yang fleksibel
Yang saya maksud dengan pendekatan “klasik” adalah bintang lama yang baik (terlepas dari penerapan spesifik lapisan yang mendasarinya, semoga pengikut Kimball, Inmon, dan CDM memaafkan saya).
1. Kardinalitas koneksi yang kaku
Model ini didasarkan pada pembagian data yang jelas menjadi Dimensi и fakta. Dan ini, sialnya, logis - lagipula, analisis data di sebagian besar kasus bermuara pada analisis indikator numerik (fakta) tertentu di bagian (dimensi) tertentu.
Dalam hal ini, hubungan antar objek dibuat dalam bentuk hubungan antar tabel dengan menggunakan kunci asing. Ini terlihat cukup alami, tetapi langsung mengarah pada batasan pertama dalam fleksibilitas - definisi ketat tentang kardinalitas koneksi.
Ini berarti bahwa pada tahap desain tabel, Anda harus secara akurat menentukan untuk setiap pasangan objek terkait apakah objek tersebut dapat berhubungan banyak-ke-banyak, atau hanya 1-ke-banyak, dan “ke arah mana”. Ini secara langsung menentukan tabel mana yang akan memiliki kunci utama dan mana yang akan memiliki kunci asing. Mengubah sikap ini ketika persyaratan baru diterima kemungkinan besar akan mengarah pada pengerjaan ulang pangkalan.
Misalnya, ketika merancang objek "tanda terima tunai", Anda, dengan mengandalkan sumpah departemen penjualan, menetapkan kemungkinan tindakan satu promosi untuk beberapa posisi cek (tetapi tidak sebaliknya):
Dan setelah beberapa waktu, rekan kerja memperkenalkan strategi pemasaran baru di mana mereka dapat mengambil posisi yang sama beberapa promosi sekaligus. Dan sekarang Anda perlu memodifikasi tabel dengan memisahkan hubungan menjadi objek terpisah.
(Semua objek turunan yang digabungkan dengan pemeriksaan promosi sekarang juga perlu ditingkatkan).
Hubungan dalam Data Vault dan Model Anchor
Menghindari situasi ini ternyata cukup sederhana: Anda tidak harus mempercayai departemen penjualan untuk melakukan hal ini. semua koneksi awalnya disimpan dalam tabel terpisah dan memprosesnya sebagai banyak-ke-banyak.
Pendekatan ini diusulkan Dan Linstedt sebagai bagian dari paradigma Gudang Data dan didukung penuh Lars Ronnback в Model Jangkar.
Hasilnya, kami mendapatkan ciri khas pertama dari metodologi fleksibel:
Hubungan antar objek tidak disimpan dalam atribut entitas induk, tetapi merupakan tipe objek yang terpisah.
В Gudang Data tabel penghubung seperti itu disebut Link, dan dalam Model Jangkar - Dasi. Sekilas keduanya sangat mirip, meski perbedaannya tidak berhenti pada namanya (yang akan dibahas di bawah). Di kedua arsitektur, tabel tautan dapat ditautkan sejumlah entitas (belum tentu 2).
Sekilas, redundansi ini memberikan fleksibilitas yang signifikan untuk modifikasi. Struktur seperti itu menjadi toleran tidak hanya terhadap perubahan kardinalitas tautan yang ada, tetapi juga terhadap penambahan tautan baru - jika sekarang posisi cek juga memiliki tautan ke kasir yang menerobosnya, kemunculan tautan tersebut hanya akan terjadi. menjadi tambahan pada tabel yang ada tanpa mempengaruhi objek dan proses yang ada.
2. Duplikasi data
Masalah kedua yang diselesaikan dengan arsitektur fleksibel kurang jelas dan merupakan masalah yang melekat. Pengukuran tipe SCD2 (perlahan-lahan mengubah dimensi tipe kedua), meski tidak hanya mereka.
Di gudang klasik, dimensi biasanya berupa tabel yang berisi kunci pengganti (sebagai PK) dan sekumpulan kunci bisnis serta atribut di kolom terpisah.
Jika dimensi mendukung pembuatan versi, batas validitas versi ditambahkan ke kumpulan kolom standar, dan beberapa versi muncul di repositori untuk satu baris di sumber (satu untuk setiap perubahan dalam atribut berversi).
Jika suatu dimensi berisi setidaknya satu atribut berversi yang sering berubah, jumlah versi dari dimensi tersebut akan sangat banyak (meskipun atribut lainnya tidak berversi atau tidak pernah berubah), dan jika ada beberapa atribut seperti itu, jumlah versinya bisa tumbuh secara eksponensial dari jumlah mereka. Dimensi ini dapat memakan banyak ruang disk, meskipun sebagian besar data yang disimpannya hanyalah duplikat dari nilai atribut yang tidak dapat diubah dari baris lain.
Pada saat yang sama, ini juga sangat sering digunakan denormalisasi — beberapa atribut sengaja disimpan sebagai nilai, dan bukan sebagai tautan ke buku referensi atau dimensi lain. Pendekatan ini mempercepat akses data, mengurangi jumlah gabungan saat mengakses suatu dimensi.
Biasanya hal ini mengarah pada informasi yang sama disimpan secara bersamaan di beberapa tempat. Misalnya, informasi tentang wilayah tempat tinggal dan kategori klien dapat disimpan secara bersamaan dalam dimensi "Klien" dan fakta "Pembelian", "Pengiriman" dan "Panggilan Pusat Panggilan", serta di "Klien - Manajer Klien ” tabel tautan.
Secara umum, hal di atas berlaku untuk dimensi biasa (tidak berversi), tetapi dalam dimensi berversi, dimensi tersebut mungkin memiliki skala yang berbeda: kemunculan versi baru suatu objek (terutama dalam retrospeksi) tidak hanya mengarah pada pembaruan semua yang terkait. tabel, tetapi untuk tampilan berjenjang dari versi baru objek terkait - ketika Tabel 1 digunakan untuk membuat Tabel 2, dan Tabel 2 digunakan untuk membuat Tabel 3, dll. Bahkan jika tidak ada satu pun atribut Tabel 1 yang dilibatkan dalam pembuatan Tabel 3 (dan atribut lain dari Tabel 2 yang diperoleh dari sumber lain juga terlibat), membuat versi konstruksi ini minimal akan menyebabkan tambahan overhead, dan maksimal menyebabkan tambahan versi pada Tabel 3. yang tidak ada hubungannya sama sekali, dan lebih jauh lagi rantainya.
3. Kompleksitas pengerjaan ulang nonlinier
Pada saat yang sama, setiap etalase baru yang dibangun berdasarkan etalase lain meningkatkan jumlah tempat di mana data dapat “menyimpang” ketika perubahan dilakukan pada ETL. Hal ini, pada gilirannya, menyebabkan peningkatan kompleksitas (dan durasi) setiap revisi berikutnya.
Jika penjelasan di atas menjelaskan sistem dengan proses ETL yang jarang dimodifikasi, Anda dapat hidup dalam paradigma seperti itu - Anda hanya perlu memastikan bahwa modifikasi baru telah dilakukan dengan benar pada semua objek terkait. Jika revisi sering terjadi, kemungkinan “hilangnya” beberapa koneksi secara tidak sengaja meningkat secara signifikan.
Selain itu, jika kita memperhitungkan bahwa ETL “berversi” jauh lebih rumit daripada ETL “tidak berversi”, maka akan sangat sulit untuk menghindari kesalahan ketika sering memperbarui seluruh fasilitas ini.
Menyimpan objek dan atribut di Data Vault dan Anchor Model
Pendekatan yang dikemukakan oleh penulis arsitektur fleksibel dapat dirumuskan sebagai berikut:
Penting untuk memisahkan apa yang berubah dari apa yang tetap sama. Artinya, simpan kunci secara terpisah dari atribut.
Namun, jangan bingung tidak berversi atribut dengan tidak berubah: yang pertama tidak menyimpan riwayat perubahannya, tetapi dapat berubah (misalnya, ketika memperbaiki kesalahan input atau menerima data baru); yang kedua tidak pernah berubah.
Sudut pandang berbeda mengenai apa yang sebenarnya dianggap tidak dapat diubah dalam Data Vault dan Model Anchor.
Dari sudut pandang arsitektur Gudang Data, dapat dianggap tidak berubah seluruh rangkaian kunci - alami (NPWP organisasi, kode produk di sistem sumber, dll.) dan pengganti. Dalam hal ini, atribut yang tersisa dapat dibagi menjadi beberapa kelompok menurut sumber dan/atau frekuensi perubahan dan Sediakan meja terpisah untuk setiap kelompok dengan serangkaian versi independen.
Dalam paradigma Model Jangkar dianggap tidak berubah hanya kunci pengganti esensi. Segala sesuatu yang lain (termasuk kunci alami) hanyalah kasus khusus dari atributnya. Di mana semua atribut independen satu sama lain secara default, jadi untuk setiap atribut a meja terpisah.
В Gudang Data tabel yang berisi kunci entitas dipanggil Hubami. Hub selalu berisi sekumpulan bidang tetap:
- Kunci Entitas Alami
- Kunci pengganti
- Tautan ke sumber
- Catat waktu penambahan
Posting di Hub tidak pernah berubah dan tidak memiliki versi. Secara eksternal, hub sangat mirip dengan tabel tipe peta ID yang digunakan di beberapa sistem untuk menghasilkan pengganti, namun, disarankan untuk menggunakan hash dari sekumpulan kunci bisnis sebagai pengganti di Data Vault. Pendekatan ini menyederhanakan pemuatan hubungan dan atribut dari sumber (tidak perlu bergabung dengan hub untuk mendapatkan pengganti, cukup menghitung hash dari kunci alami), tetapi dapat menyebabkan masalah lain (terkait, misalnya, dengan tabrakan, kasus, dan non-cetak karakter dalam kunci string, dll. .p.), oleh karena itu tidak diterima secara umum.
Semua atribut entitas lainnya disimpan dalam tabel khusus yang disebut Satelit. Satu hub dapat memiliki beberapa satelit yang menyimpan kumpulan atribut berbeda.
Distribusi atribut antar satelit terjadi sesuai dengan prinsip perubahan bersama — di satu satelit atribut non-versi dapat disimpan (misalnya, tanggal lahir dan SNILS untuk individu), di satelit lain - jarang mengubah atribut berversi (misalnya, nama belakang dan nomor paspor), di satelit ketiga - yang sering berubah (misalnya, alamat pengiriman, kategori, tanggal pemesanan terakhir, dll.). Dalam hal ini, pembuatan versi dilakukan pada tingkat masing-masing satelit, dan bukan pada entitas secara keseluruhan, sehingga disarankan untuk mendistribusikan atribut sehingga perpotongan versi dalam satu satelit menjadi minimal (yang mengurangi jumlah total versi yang disimpan ).
Selain itu, untuk mengoptimalkan proses pemuatan data, atribut yang diperoleh dari berbagai sumber sering kali disertakan dalam masing-masing satelit.
Satelit berkomunikasi dengan Hub melalui kunci asing (yang sesuai dengan kardinalitas 1-ke-banyak). Ini berarti beberapa nilai atribut (misalnya, beberapa nomor telepon kontak untuk satu klien) didukung oleh arsitektur “default” ini.
В Model Jangkar tabel yang menyimpan kunci dipanggil Jangkar. Dan mereka menyimpan:
- Hanya kunci pengganti
- Tautan ke sumber
- Catat waktu penambahan
Kunci alami dari sudut pandang Model Jangkar dipertimbangkan atribut biasa. Opsi ini mungkin tampak lebih sulit untuk dipahami, namun memberikan lebih banyak ruang untuk mengidentifikasi objek.
Misalnya, jika data tentang entitas yang sama dapat berasal dari sistem yang berbeda, masing-masing sistem menggunakan kunci alaminya sendiri. Di Data Vault, hal ini dapat menyebabkan struktur beberapa hub yang agak rumit (satu per sumber + versi master pemersatu), sedangkan dalam model Anchor, kunci alami setiap sumber termasuk dalam atributnya sendiri dan dapat digunakan saat memuat secara independen. semua yang lain.
Namun ada juga satu hal yang berbahaya di sini: jika atribut dari sistem yang berbeda digabungkan dalam satu entitas, kemungkinan besar ada beberapa aturan “menempelkan”, dimana sistem harus memahami bahwa catatan dari sumber yang berbeda sesuai dengan satu contoh entitas.
В Gudang Data aturan-aturan ini kemungkinan besar akan menentukan pembentukannya “pusat pengganti” dari entitas utama dan tidak mempengaruhi Hub yang menyimpan kunci sumber alami dan atribut aslinya dengan cara apa pun. Jika suatu saat aturan penggabungan berubah (atau atribut yang digunakan untuk melakukan hal tersebut diperbarui), maka cukup memformat ulang hub pengganti.
В Model jangkar entitas seperti itu kemungkinan besar akan disimpan satu-satunya jangkar. Artinya, semua atribut, apa pun sumbernya, akan terikat pada pengganti yang sama. Memisahkan catatan yang digabungkan secara keliru dan, secara umum, memantau relevansi penggabungan dalam sistem seperti itu bisa menjadi jauh lebih sulit, terutama jika aturannya cukup rumit dan sering berubah, dan atribut yang sama dapat diperoleh dari sumber yang berbeda (walaupun tentu saja hal ini mungkin, karena setiap versi atribut menyimpan tautan ke sumbernya).
Bagaimanapun, jika sistem Anda seharusnya mengimplementasikan fungsionalitas tersebut deduplikasi, menggabungkan catatan dan elemen MDM lainnya, ada baiknya memberikan perhatian khusus pada aspek penyimpanan kunci alami dalam metodologi agile. Kemungkinan besar desain Data Vault yang lebih besar akan tiba-tiba menjadi lebih aman dalam hal kesalahan penggabungan.
Model jangkar juga menyediakan tipe objek tambahan yang disebut Simpul itu pada dasarnya istimewa jenis jangkar yang merosot, yang hanya dapat berisi satu atribut. Node seharusnya digunakan untuk menyimpan direktori datar (misalnya, jenis kelamin, status perkawinan, kategori layanan pelanggan, dll.). Berbeda dengan Jangkar, Simpul tidak memiliki tabel atribut terkait, dan satu-satunya atributnya (nama) selalu disimpan dalam tabel yang sama dengan kuncinya. Node dihubungkan ke Jangkar dengan tabel pengikat (Tie) dengan cara yang sama seperti Jangkar dihubungkan satu sama lain.
Belum ada pendapat yang jelas mengenai penggunaan Nodes. Misalnya, , yang secara aktif mempromosikan penggunaan Model Jangkar di Rusia, percaya (bukannya tidak masuk akal) bahwa tidak ada satu pun buku referensi yang dapat dinyatakan dengan pasti bahwa itu selalu akan statis dan satu tingkat, jadi lebih baik segera menggunakan Jangkar lengkap untuk semua objek.
Perbedaan penting lainnya antara Data Vault dan model Anchor adalah ketersediaannya atribut koneksi:
В Gudang Data Tautan adalah objek lengkap yang sama dengan Hub, dan dapat dimiliki atribut sendiri. Di Model jangkar Tautan hanya digunakan untuk menghubungkan Jangkar dan tidak dapat memiliki atributnya sendiri. Perbedaan ini menghasilkan pendekatan pemodelan yang berbeda secara signifikan fakta, yang akan dibahas lebih lanjut.
Penyimpanan fakta
Sebelumnya, kita terutama membahas tentang pemodelan pengukuran. Faktanya kurang jelas.
В Gudang Data objek khas untuk menyimpan fakta adalah Tautan, yang satelitnya ditambahkan indikator nyata.
Pendekatan ini tampaknya intuitif. Ini memberikan akses mudah ke indikator yang dianalisis dan umumnya mirip dengan tabel fakta tradisional (hanya indikator yang disimpan bukan di tabel itu sendiri, tetapi di tabel “tetangga”). Namun ada juga kendala: salah satu modifikasi khas model - perluasan kunci fakta - memerlukan menambahkan kunci asing baru ke Link. Dan hal ini, pada gilirannya, “merusak” modularitas dan berpotensi menyebabkan perlunya modifikasi pada objek lain.
В Model jangkar Koneksi tidak dapat memiliki atributnya sendiri, jadi pendekatan ini tidak akan berhasil - semua atribut dan indikator harus ditautkan ke satu jangkar tertentu. Kesimpulannya sederhana - Setiap fakta juga memerlukan jangkarnya sendiri. Untuk beberapa hal yang biasa kita anggap sebagai fakta, ini mungkin terlihat wajar - misalnya, fakta pembelian dapat direduksi menjadi objek "pesanan" atau "tanda terima", mengunjungi situs untuk suatu sesi, dll. Namun ada juga fakta yang membuat tidak mudah untuk menemukan “benda pembawa” yang alami - misalnya, sisa-sisa barang di gudang pada awal setiap hari.
Oleh karena itu, masalah dengan modularitas ketika memperluas kunci fakta dalam model Anchor tidak muncul (cukup menambahkan Hubungan baru ke Anchor yang sesuai), tetapi merancang model untuk menampilkan fakta tidak terlalu ambigu; Anchor “buatan” mungkin muncul yang menampilkan model objek bisnis dengan cara yang tidak jelas.
Bagaimana fleksibilitas dicapai
Konstruksi yang dihasilkan dalam kedua kasus tersebut mengandung lebih banyak tabel secara signifikandibandingkan pengukuran tradisional. Tapi itu mungkin diperlukan ruang disk secara signifikan lebih sedikit dengan kumpulan atribut berversi yang sama dengan dimensi tradisional. Tentu saja, tidak ada keajaiban di sini - ini semua tentang normalisasi. Dengan mendistribusikan atribut di seluruh Satelit (di Data Vault) atau tabel individual (Model Jangkar), kami mengurangi (atau menghilangkan sepenuhnya) duplikasi nilai beberapa atribut ketika mengubah yang lain.
Untuk Gudang Data kemenangan akan bergantung pada distribusi atribut di antara Satelit, dan untuk Model jangkar — hampir berbanding lurus dengan jumlah rata-rata versi per objek pengukuran.
Namun, penghematan ruang merupakan keuntungan penting, namun bukan yang utama, dari menyimpan atribut secara terpisah. Bersama dengan penyimpanan hubungan yang terpisah, pendekatan ini menjadikan penyimpanan desain modular. Ini berarti menambahkan atribut individual dan keseluruhan area subjek baru dalam model seperti itu suprastruktur atas sekumpulan objek yang ada tanpa mengubahnya. Dan inilah yang membuat metodologi yang dijelaskan menjadi fleksibel.
Hal ini juga menyerupai transisi dari produksi potongan ke produksi massal - jika dalam pendekatan tradisional setiap tabel model adalah unik dan memerlukan perhatian khusus, maka dalam metodologi yang fleksibel ini sudah merupakan seperangkat “bagian” standar. Di satu sisi, terdapat lebih banyak tabel, dan proses memuat dan mengambil data akan terlihat lebih rumit. Di sisi lain, mereka menjadi khas. Artinya mungkin ada otomatis dan didorong oleh metadata. Pertanyaan “bagaimana kita akan menerapkannya?”, yang jawabannya dapat menghabiskan banyak waktu dalam merancang perbaikan, kini sudah tidak ada gunanya lagi (begitu juga dengan pertanyaan tentang dampak perubahan model terhadap proses kerja. ).
Ini tidak berarti bahwa analis tidak diperlukan dalam sistem seperti itu sama sekali - seseorang masih perlu mengerjakan sekumpulan objek dengan atribut dan mencari tahu di mana dan bagaimana memuat semuanya. Namun jumlah pekerjaan, serta kemungkinan dan biaya kesalahan, berkurang secara signifikan. Baik pada tahap analisis maupun selama pengembangan ETL, yang sebagian besar dapat direduksi menjadi pengeditan metadata.
Sisi gelap
Semua hal di atas menjadikan kedua pendekatan ini benar-benar fleksibel, berteknologi maju, dan cocok untuk perbaikan berulang. Tentu saja, ada juga “tong dalam salep”, yang menurut saya sudah bisa Anda tebak.
Dekomposisi data, yang mendasari modularitas arsitektur fleksibel, menyebabkan peningkatan jumlah tabel dan, karenanya, atas untuk bergabung saat pengambilan sampel. Untuk mendapatkan semua atribut suatu dimensi, di toko klasik, satu pilihan saja sudah cukup, namun arsitektur yang fleksibel akan memerlukan serangkaian gabungan. Terlebih lagi, jika semua gabungan laporan ini dapat ditulis terlebih dahulu, maka analis yang terbiasa menulis SQL dengan tangan akan menderita dua kali lipat.
Ada beberapa fakta yang membuat situasi ini lebih mudah:
Saat bekerja dengan dimensi besar, semua atributnya hampir tidak pernah digunakan secara bersamaan. Ini berarti bahwa jumlah gabungan mungkin lebih sedikit daripada yang terlihat pada model pada pandangan pertama. Data Vault juga dapat memperhitungkan frekuensi pembagian yang diharapkan saat mengalokasikan atribut ke satelit. Pada saat yang sama, Hub atau Anchor sendiri diperlukan terutama untuk menghasilkan dan memetakan pengganti pada tahap pemuatan dan jarang digunakan dalam kueri (ini terutama berlaku untuk Anchors).
Semua gabungan dilakukan berdasarkan kunci. Selain itu, cara penyimpanan data yang lebih “terkompresi” mengurangi overhead pemindaian tabel jika diperlukan (misalnya, saat memfilter berdasarkan nilai atribut). Hal ini dapat mengarah pada fakta bahwa pengambilan sampel dari database yang dinormalisasi dengan banyak gabungan akan lebih cepat daripada memindai satu dimensi berat dengan banyak versi per baris.
Misalnya saja di sini Artikel ini berisi uji komparatif mendetail tentang performa model Anchor dengan sampel dari satu tabel.
Banyak hal tergantung pada mesinnya. Banyak platform modern memiliki mekanisme optimasi gabungan internal. Misalnya, MS SQL dan Oracle dapat “melewati” gabungan ke tabel jika datanya tidak digunakan di mana pun kecuali untuk gabungan lainnya dan tidak memengaruhi pilihan akhir (eliminasi tabel/gabungan), dan MPP Vertica , telah terbukti menjadi mesin yang sangat baik untuk Model Jangkar, mengingat beberapa optimasi manual pada rencana kueri. Di sisi lain, menyimpan Model Anchor, misalnya, di Click House, yang memiliki dukungan join terbatas, sepertinya belum merupakan ide yang bagus.
Selain itu, untuk kedua arsitektur tersebut ada gerakan khusus, membuat akses data lebih mudah (baik dari sudut pandang kinerja kueri dan pengguna akhir). Misalnya, Tabel Point-In-Time di Gudang Data atau fungsi tabel khusus dalam model Jangkar.
Total
Esensi utama dari arsitektur fleksibel adalah modularitas “desain” mereka.
Properti inilah yang memungkinkan:
- Setelah beberapa persiapan awal terkait penerapan metadata dan penulisan algoritma ETL dasar, dengan cepat memberikan hasil pertama kepada pelanggan dalam bentuk beberapa laporan yang berisi data dari beberapa objek sumber saja. Tidak perlu memikirkan sepenuhnya (bahkan pada tingkat atas) keseluruhan model objek.
- Model data dapat mulai berfungsi (dan berguna) hanya dengan 2-3 objek, lalu tumbuh secara bertahap (tentang model Jangkar Nikolai perbandingan yang bagus dengan miselium).
- Sebagian besar perbaikan, termasuk perluasan area subjek dan penambahan sumber baru tidak mempengaruhi fungsionalitas yang ada dan tidak menimbulkan risiko merusak sesuatu yang sudah berfungsi.
- Berkat dekomposisi menjadi elemen standar, proses ETL dalam sistem tersebut terlihat sama, penulisannya dapat dilakukan algoritma dan, pada akhirnya, otomatisasi.
Harga dari fleksibilitas ini adalah kinerja. Ini tidak berarti bahwa tidak mungkin mencapai kinerja yang dapat diterima pada model tersebut. Seringkali, Anda mungkin memerlukan lebih banyak usaha dan perhatian terhadap detail untuk mencapai metrik yang Anda inginkan.
Aplikasi
Tipe entitas Gudang Data
Informasi selengkapnya tentang Gudang Data:
Tipe entitas Model Jangkar
Detail lebih lanjut tentang Model Jangkar:
Tabel ringkasan dengan ciri-ciri umum dan perbedaan dari pendekatan yang dipertimbangkan:
Sumber: www.habr.com