Membangunkan kemudahan penyimpanan adalah usaha yang panjang dan serius.
Banyak dalam kehidupan projek bergantung pada seberapa baik model objek dan struktur asas difikirkan pada permulaan.
Pendekatan yang diterima umum telah dan kekal sebagai pelbagai varian untuk menggabungkan skema bintang dengan bentuk normal ketiga. Sebagai peraturan, mengikut prinsip: data awal - 3NF, pameran - bintang. Pendekatan ini, yang diuji masa dan disokong oleh sejumlah besar penyelidikan, adalah perkara pertama (dan kadangkala satu-satunya) yang terlintas di fikiran pakar DWH yang berpengalaman apabila memikirkan tentang rupa repositori analisis.
Sebaliknya, perniagaan secara amnya dan keperluan pelanggan khususnya cenderung berubah dengan cepat, dan data cenderung untuk berkembang secara "mendalam" dan "secara luas". Dan di sinilah kelemahan utama bintang muncul - terhad fleksibiliti.
Dan jika dalam kehidupan anda yang tenang dan selesa sebagai pemaju DWH tiba-tiba:
- tugas itu timbul "untuk melakukan sekurang-kurangnya sesuatu dengan cepat, dan kemudian kita akan melihat";
- projek yang berkembang pesat muncul, dengan sambungan sumber baharu dan kerja semula model perniagaan sekurang-kurangnya sekali seminggu;
- pelanggan telah muncul yang tidak tahu bagaimana rupa sistem itu dan apakah fungsi yang sepatutnya dilaksanakan, tetapi bersedia untuk mencuba dan secara konsisten memperhalusi hasil yang diingini sambil secara konsisten mendekatinya;
- Pengurus projek datang dengan berita baik: "Dan kini kami mempunyai tangkas!"
Atau jika anda hanya berminat untuk mengetahui cara lain anda boleh membina kemudahan storan - selamat datang ke pemotongan!
Apakah maksud "fleksibiliti"?
Mula-mula, mari kita tentukan sifat yang mesti ada pada sistem untuk dipanggil "fleksibel".
Secara berasingan, perlu dinyatakan bahawa sifat yang diterangkan harus berkaitan secara khusus sistem, bukan untuk proses perkembangannya. Oleh itu, jika anda ingin membaca tentang Agile sebagai metodologi pembangunan, lebih baik membaca artikel lain. Sebagai contoh, di sana, di HabrΓ©, terdapat banyak bahan menarik (seperti ΠΈ Dan ).
Ini tidak bermakna bahawa proses pembangunan dan struktur gudang data tidak berkaitan sama sekali. Secara keseluruhannya, lebih mudah untuk membangunkan repositori Agile untuk seni bina tangkas. Walau bagaimanapun, dalam amalan, lebih kerap terdapat pilihan dengan pembangunan Agile DWH klasik mengikut Kimbal dan DataVault - menurut Waterfall, daripada kebetulan yang menggembirakan fleksibiliti dalam dua bentuknya pada satu projek.
Jadi, apakah keupayaan yang perlu ada pada storan fleksibel? Terdapat tiga perkara di sini:
- Penghantaran awal dan pemulihan yang cepat - ini bermakna bahawa secara idealnya hasil perniagaan pertama (contohnya, laporan kerja pertama) harus diperolehi seawal mungkin, iaitu, sebelum keseluruhan sistem direka dan dilaksanakan sepenuhnya. Selain itu, setiap semakan seterusnya juga perlu mengambil masa yang sesingkat mungkin.
- Penapisan berulang - ini bermakna setiap penambahbaikan seterusnya sepatutnya tidak menjejaskan fungsi yang sudah berfungsi. Momen inilah yang sering menjadi mimpi ngeri terbesar pada projek besar - lambat laun, objek individu mula memperoleh begitu banyak sambungan sehingga menjadi lebih mudah untuk mengulang logik sepenuhnya dalam salinan berdekatan daripada menambah medan pada jadual sedia ada. Dan jika anda terkejut bahawa menganalisis kesan pengubahsuaian pada objek sedia ada boleh mengambil lebih banyak masa daripada pengubahsuaian itu sendiri, kemungkinan besar anda masih belum bekerja dengan gudang data yang besar dalam perbankan atau telekomunikasi.
- Sentiasa menyesuaikan diri dengan perubahan keperluan perniagaan - struktur objek keseluruhan harus direka bentuk bukan sahaja dengan mengambil kira kemungkinan pengembangan, tetapi dengan jangkaan bahawa arah pengembangan seterusnya ini tidak dapat diimpikan pada peringkat reka bentuk.
Dan ya, memenuhi semua keperluan ini dalam satu sistem adalah mungkin (sudah tentu, dalam kes tertentu dan dengan beberapa tempahan).
Di bawah ini saya akan mempertimbangkan dua metodologi reka bentuk tangkas yang paling popular untuk gudang data - Model sauh ΠΈ Bilik Kebal Data. Ditinggalkan daripada kurungan adalah teknik yang sangat baik seperti, sebagai contoh, EAV, 6NF (dalam bentuk tulennya) dan segala-galanya yang berkaitan dengan penyelesaian NoSQL - bukan kerana ia entah bagaimana lebih teruk, malah bukan kerana dalam kes ini artikel itu akan mengancam untuk memperoleh isipadu disser purata. Cuma semua ini berkaitan dengan penyelesaian kelas yang sedikit berbeza - sama ada dengan teknik yang boleh anda gunakan dalam kes tertentu, tanpa mengira seni bina keseluruhan projek anda (seperti EAV), atau dengan paradigma penyimpanan maklumat lain secara global (seperti pangkalan data graf dan pilihan lain NoSQL).
Masalah pendekatan "klasik" dan penyelesaiannya dalam metodologi yang fleksibel
Dengan pendekatan "klasik" yang saya maksudkan adalah bintang lama yang baik (tidak kira pelaksanaan khusus lapisan asas, semoga pengikut Kimball, Inmon dan CDM memaafkan saya).
1. Kardinaliti sambungan yang tegar
Model ini berdasarkan pembahagian data yang jelas kepada Dimensi ΠΈ fakta. Dan ini, sialnya, adalah logik - lagipun, analisis data dalam kebanyakan kes datang kepada analisis penunjuk berangka (fakta) tertentu dalam bahagian (dimensi) tertentu.
Dalam kes ini, sambungan antara objek diwujudkan dalam bentuk hubungan antara jadual menggunakan kunci asing. Ini kelihatan agak semula jadi, tetapi dengan serta-merta membawa kepada had pertama fleksibiliti - takrifan ketat tentang kardinaliti sambungan.
Ini bermakna bahawa pada peringkat reka bentuk jadual, anda mesti menentukan dengan tepat untuk setiap pasangan objek berkaitan sama ada objek tersebut boleh dikaitkan sebagai banyak-ke-banyak, atau hanya 1-dengan-banyak, dan "ke arah mana". Ini secara langsung menentukan jadual mana yang akan mempunyai kunci utama dan yang akan mempunyai kunci asing. Mengubah sikap ini apabila keperluan baharu diterima kemungkinan besar akan membawa kepada kerja semula pangkalan.
Sebagai contoh, apabila mereka bentuk objek "resit tunai", anda, bergantung pada sumpah jabatan jualan, meletakkan kemungkinan tindakan satu kenaikan pangkat untuk beberapa jawatan cek (tetapi bukan sebaliknya):
Dan selepas beberapa lama, rakan sekerja memperkenalkan strategi pemasaran baharu di mana mereka boleh bertindak pada kedudukan yang sama beberapa promosi pada masa yang sama. Dan kini anda perlu mengubah suai jadual dengan memisahkan hubungan menjadi objek yang berasingan.
(Semua objek terbitan di mana semakan promosi disertai sekarang juga perlu diperbaiki).
Perhubungan dalam Bilik Kebal Data dan Model Sauh
Mengelakkan situasi ini ternyata agak mudah: anda tidak perlu mempercayai jabatan jualan untuk melakukan ini. semua sambungan pada mulanya disimpan dalam jadual berasingan dan memprosesnya sebagai banyak-ke-banyak.
Pendekatan ini dicadangkan Dan Linstedt sebagai sebahagian daripada paradigma Bilik Kebal Data dan disokong sepenuhnya Lars RΓΆnnbΓ€ck Π² Model Sauh.
Hasilnya, kami mendapat ciri tersendiri pertama metodologi fleksibel:
Perhubungan antara objek tidak disimpan dalam atribut entiti induk, tetapi merupakan jenis objek yang berasingan.
Π Bilik Kebal Data jadual penghubung tersebut dipanggil pautan, dan dalam Model Sauh - Tie. Pada pandangan pertama, mereka sangat serupa, walaupun perbezaan mereka tidak berakhir dengan nama (yang akan dibincangkan di bawah). Dalam kedua-dua seni bina, jadual pautan boleh dipautkan sebarang bilangan entiti (tidak semestinya 2).
Lebihan ini, pada pandangan pertama, memberikan fleksibiliti yang ketara untuk pengubahsuaian. Struktur sedemikian menjadi bertolak ansur bukan sahaja kepada perubahan dalam kardinaliti pautan sedia ada, tetapi juga kepada penambahan yang baru - jika kini kedudukan cek juga mempunyai pautan ke juruwang yang menembusinya, penampilan pautan sedemikian hanya akan menjadi alat tambah ke atas jadual sedia ada tanpa menjejaskan sebarang objek dan proses sedia ada.
2. Penduaan data
Masalah kedua yang diselesaikan oleh seni bina fleksibel adalah kurang jelas dan wujud di tempat pertama. Ukuran jenis SCD2 (perlahan mengubah dimensi jenis kedua), walaupun bukan sahaja mereka.
Dalam gudang klasik, dimensi lazimnya ialah jadual yang mengandungi kunci pengganti (sebagai PK) dan satu set kunci perniagaan serta atribut dalam lajur yang berasingan.
Jika dimensi menyokong versi, sempadan kesahan versi ditambahkan pada set medan standard dan beberapa versi muncul dalam repositori untuk satu baris dalam sumber (satu untuk setiap perubahan dalam atribut versi).
Jika dimensi mengandungi sekurang-kurangnya satu atribut versi yang kerap berubah, bilangan versi dimensi sedemikian akan mengagumkan (walaupun atribut yang selebihnya tidak versi atau tidak pernah berubah), dan jika terdapat beberapa atribut sedemikian, bilangan versi boleh berkembang secara eksponen daripada bilangan mereka. Dimensi ini boleh menggunakan sejumlah besar ruang cakera, walaupun kebanyakan data yang disimpannya hanyalah pendua nilai atribut yang tidak boleh diubah daripada baris lain.
Pada masa yang sama, ia juga sangat kerap digunakan penyahnormalan β sesetengah atribut disimpan secara sengaja sebagai nilai, dan bukan sebagai pautan ke buku rujukan atau dimensi lain. Pendekatan ini mempercepatkan akses data, mengurangkan bilangan cantuman apabila mengakses dimensi.
Biasanya ini membawa kepada maklumat yang sama disimpan serentak di beberapa tempat. Sebagai contoh, maklumat tentang wilayah kediaman dan kategori pelanggan boleh disimpan serentak dalam dimensi "Pelanggan" dan fakta "Pembelian", "Penghantaran" dan "Panggilan Pusat Panggilan", serta dalam "Pelanggan - Pengurus Pelanggan". β jadual pautan.
Secara umum, yang diterangkan di atas digunakan untuk dimensi biasa (bukan versi), tetapi dalam versi ia mungkin mempunyai skala yang berbeza: kemunculan versi baharu objek (terutamanya apabila dilihat semula) membawa bukan sahaja kepada kemas kini semua yang berkaitan. jadual, tetapi kepada penampilan melata versi baharu objek berkaitan - apabila Jadual 1 digunakan untuk membina Jadual 2, dan Jadual 2 digunakan untuk membina Jadual 3, dsb. Walaupun tidak ada satu atribut Jadual 1 yang terlibat dalam pembinaan Jadual 3 (dan atribut lain Jadual 2 yang diperoleh daripada sumber lain terlibat), versi pembinaan ini sekurang-kurangnya akan membawa kepada overhed tambahan, dan pada maksimum kepada tambahan. versi dalam Jadual 3. yang tidak ada kena mengena sama sekali, dan seterusnya ke bawah rantaian.
3. Kerumitan bukan linear kerja semula
Pada masa yang sama, setiap etalase baharu yang dibina berdasarkan yang lain meningkatkan bilangan tempat di mana data boleh "mencapah" apabila perubahan dibuat pada ETL. Ini, seterusnya, membawa kepada peningkatan dalam kerumitan (dan tempoh) setiap semakan berikutnya.
Jika di atas menerangkan sistem dengan proses ETL yang jarang diubah suai, anda boleh hidup dalam paradigma sedemikian - anda hanya perlu memastikan bahawa pengubahsuaian baharu dibuat dengan betul pada semua objek berkaitan. Jika semakan kerap berlaku, kemungkinan "hilang" beberapa sambungan secara tidak sengaja meningkat dengan ketara.
Jika, sebagai tambahan, kami mengambil kira bahawa ETL "berversi" adalah jauh lebih rumit daripada yang "tidak versi", menjadi agak sukar untuk mengelakkan kesilapan apabila kerap mengemas kini keseluruhan kemudahan ini.
Menyimpan objek dan atribut dalam Data Vault dan Model Anchor
Pendekatan yang dicadangkan oleh pengarang seni bina fleksibel boleh dirumuskan seperti berikut:
Adalah perlu untuk memisahkan apa yang berubah daripada apa yang tetap sama. Iaitu, simpan kunci secara berasingan daripada atribut.
Walau bagaimanapun, seseorang tidak boleh mengelirukan bukan versi atribut dengan tidak berubah: yang pertama tidak menyimpan sejarah perubahannya, tetapi boleh berubah (contohnya, apabila membetulkan ralat input atau menerima data baharu); yang kedua tidak pernah berubah.
Sudut pandangan berbeza tentang perkara yang boleh dianggap tidak berubah dalam Bilik Kebal Data dan Model Sauh.
Dari sudut seni bina Bilik Kebal Data, boleh dianggap tidak berubah keseluruhan set kunci - semula jadi (TIN organisasi, kod produk dalam sistem sumber, dll.) dan pengganti. Dalam kes ini, atribut yang tinggal boleh dibahagikan kepada kumpulan mengikut sumber dan/atau kekerapan perubahan dan Sediakan meja berasingan untuk setiap kumpulan dengan set versi bebas.
Dalam paradigma Model Sauh dianggap tidak berubah hanya kunci pengganti intipati. Segala-galanya (termasuk kunci semula jadi) hanyalah kes khas atributnya. Di mana semua atribut adalah bebas antara satu sama lain secara lalai, jadi bagi setiap atribut a meja berasingan.
Π Bilik Kebal Data jadual yang mengandungi kunci entiti dipanggil Hubami. Hab sentiasa mengandungi set medan tetap:
- Kunci Entiti Semulajadi
- Kunci pengganti
- Pautan ke sumber
- Rekod masa tambah
Siaran dalam Hab tidak pernah berubah dan tidak mempunyai versi. Secara luaran, hab sangat serupa dengan jadual jenis peta ID yang digunakan dalam sesetengah sistem untuk menjana pengganti, namun, adalah disyorkan untuk menggunakan cincang daripada set kunci perniagaan sebagai pengganti dalam Bilik Kebal Data. Pendekatan ini memudahkan pemuatan perhubungan dan atribut daripada sumber (tidak perlu menyertai hab untuk mendapatkan pengganti, hanya mengira cincang kunci semula jadi), tetapi boleh menyebabkan masalah lain (berkaitan, contohnya, perlanggaran, kes dan tidak boleh dicetak aksara dalam kekunci rentetan, dsb. .p.), oleh itu ia tidak diterima umum.
Semua atribut entiti lain disimpan dalam jadual khas yang dipanggil Satelit. Satu hab boleh mempunyai beberapa satelit yang menyimpan set atribut yang berbeza.
Pengagihan atribut antara satelit berlaku mengikut prinsip perubahan bersama β dalam satu satelit, atribut bukan versi boleh disimpan (contohnya, tarikh lahir dan SNILS untuk individu), dalam yang lain - jarang menukar versi (contohnya, nama keluarga dan nombor pasport), dalam yang ketiga - sering menukar yang (contohnya, alamat penghantaran, kategori, tarikh pesanan terakhir, dsb.). Dalam kes ini, versi dijalankan pada peringkat satelit individu, dan bukan entiti secara keseluruhan, jadi adalah dinasihatkan untuk mengedarkan atribut supaya persilangan versi dalam satu satelit adalah minimum (yang mengurangkan jumlah versi yang disimpan ).
Selain itu, untuk mengoptimumkan proses pemuatan data, atribut yang diperoleh daripada pelbagai sumber selalunya disertakan dalam satelit individu.
Satelit berkomunikasi dengan Hab melalui kunci asing (yang sepadan dengan kardinaliti 1-ke-banyak). Ini bermakna berbilang nilai atribut (contohnya, berbilang nombor telefon kenalan untuk satu pelanggan) disokong oleh seni bina "lalai" ini.
Π Model Sauh jadual yang menyimpan kunci dipanggil sauh. Dan mereka menyimpan:
- Hanya kunci pengganti
- Pautan ke sumber
- Rekod masa tambah
Kunci semula jadi dari sudut pandangan Model Anchor dipertimbangkan sifat-sifat biasa. Pilihan ini mungkin kelihatan lebih sukar untuk difahami, tetapi ia memberikan lebih banyak skop untuk mengenal pasti objek.
Sebagai contoh, jika data tentang entiti yang sama boleh datang daripada sistem yang berbeza, setiap satunya menggunakan kunci semula jadinya sendiri. Dalam Bilik Kebal Data, ini boleh membawa kepada struktur yang agak rumit bagi beberapa hab (satu setiap sumber + versi induk penyatuan), manakala dalam model Anchor, kunci semula jadi setiap sumber jatuh ke dalam atributnya sendiri dan boleh digunakan apabila memuatkan secara bebas daripada semua yang lain.
Tetapi terdapat juga satu perkara berbahaya di sini: jika atribut daripada sistem yang berbeza digabungkan dalam satu entiti, kemungkinan besar terdapat beberapa peraturan "pelekatan", yang mana sistem mesti memahami bahawa rekod daripada sumber yang berbeza sepadan dengan satu kejadian entiti.
Π Bilik Kebal Data peraturan ini kemungkinan besar akan menentukan pembentukan βhab penggantiβ entiti induk dan tidak mempengaruhi Hab yang menyimpan kunci sumber semula jadi dan sifat asalnya. Jika pada satu ketika peraturan penggabungan berubah (atau atribut yang ia dilaksanakan dikemas kini), ia sudah cukup untuk memformat semula hab pengganti.
Π Model sauh entiti sedemikian kemungkinan besar akan disimpan dalam satu-satunya sauh. Ini bermakna semua sifat, tidak kira dari mana sumbernya, akan terikat kepada pengganti yang sama. Mengasingkan rekod gabungan yang tersilap dan, secara amnya, memantau perkaitan penggabungan dalam sistem sedemikian boleh menjadi lebih sukar, terutamanya jika peraturannya agak rumit dan kerap berubah, dan atribut yang sama boleh diperolehi daripada sumber yang berbeza (walaupun sudah tentu mungkin, kerana setiap versi atribut mengekalkan pautan ke sumbernya).
Walau apa pun, jika sistem anda sepatutnya melaksanakan fungsi tersebut penyahduplikasian, penggabungan rekod dan elemen MDM lain, adalah wajar memberi perhatian khusus kepada aspek penyimpanan kunci semula jadi dalam metodologi tangkas. Kemungkinan reka bentuk Bilik Kebal Data yang lebih besar tiba-tiba akan menjadi lebih selamat dari segi ralat penggabungan.
Model sauh juga menyediakan jenis objek tambahan yang dipanggil Simpul ia pada asasnya istimewa jenis sauh yang merosot, yang boleh mengandungi hanya satu atribut. Nod sepatutnya digunakan untuk menyimpan direktori rata (contohnya, jantina, status perkahwinan, kategori perkhidmatan pelanggan, dll.). Berbeza dengan Anchor, the Knot tidak mempunyai jadual atribut yang berkaitan, dan satu-satunya atributnya (nama) sentiasa disimpan dalam jadual yang sama dengan kunci. Nod disambungkan ke Anchor melalui jadual ikatan (Tie) dengan cara yang sama seperti Anchor disambungkan antara satu sama lain.
Tiada pendapat yang jelas mengenai penggunaan Nodes. Sebagai contoh, , yang secara aktif mempromosikan penggunaan Model Anchor di Rusia, percaya (bukan tidak munasabah) bahawa tidak ada satu buku rujukan pun boleh dinyatakan dengan pasti bahawa ia sentiasa akan menjadi statik dan satu peringkat, jadi lebih baik menggunakan Anchor sepenuhnya untuk semua objek dengan segera.
Satu lagi perbezaan penting antara Data Vault dan model Anchor ialah ketersediaan atribut sambungan:
Π Bilik Kebal Data Pautan adalah objek lengkap yang sama seperti Hab dan boleh dimiliki sifat-sifat sendiri. Π Model sauh Pautan hanya digunakan untuk menyambungkan Sauh dan tidak boleh mempunyai sifat sendiri. Perbezaan ini menghasilkan pendekatan pemodelan yang jauh berbeza fakta, yang akan dibincangkan lebih lanjut.
Penyimpanan fakta
Sebelum ini, kami bercakap terutamanya mengenai pemodelan ukuran. Faktanya kurang jelas sedikit.
Π Bilik Kebal Data objek tipikal untuk menyimpan fakta ialah Pautan, di dalam satelitnya penunjuk sebenar ditambah.
Pendekatan ini kelihatan intuitif. Ia menyediakan akses mudah kepada penunjuk yang dianalisis dan secara amnya serupa dengan jadual fakta tradisional (hanya penunjuk disimpan bukan dalam jadual itu sendiri, tetapi dalam jadual "jiran"). Tetapi terdapat juga perangkap: salah satu pengubahsuaian tipikal model - pengembangan kunci fakta - memerlukan menambah kunci asing baharu pada Pautan. Dan ini, seterusnya, "memecahkan" modulariti dan berpotensi menyebabkan keperluan untuk pengubahsuaian pada objek lain.
Π Model sauh Sambungan tidak boleh mempunyai atribut sendiri, jadi pendekatan ini tidak akan berfungsi - benar-benar semua atribut dan penunjuk mesti dikaitkan dengan satu sauh tertentu. Kesimpulan daripada ini adalah mudah - Setiap fakta juga memerlukan sauhnya sendiri. Untuk beberapa perkara yang biasa kita anggap sebagai fakta, ini mungkin kelihatan semula jadi - contohnya, fakta pembelian boleh dikurangkan dengan sempurna kepada objek "pesanan" atau "resit", melawat tapak ke sesi, dsb. Tetapi terdapat juga fakta yang tidak begitu mudah untuk mencari "objek pembawa" semulajadi - contohnya, sisa-sisa barang di gudang pada awal setiap hari.
Sehubungan itu, masalah dengan modulariti apabila mengembangkan kunci fakta dalam model Anchor tidak timbul (cukup sekadar menambah Perhubungan baharu pada Anchor yang sepadan), tetapi mereka bentuk model untuk memaparkan fakta adalah kurang jelas; Anchor "buatan" mungkin muncul. yang memaparkan model objek perniagaan dengan cara yang tidak jelas.
Bagaimana fleksibiliti dicapai
Pembinaan yang terhasil dalam kedua-dua kes mengandungi lebih banyak jadualdaripada pengukuran tradisional. Tetapi ia mungkin mengambil masa kurang ketara ruang cakera dengan set atribut versi yang sama seperti dimensi tradisional. Sememangnya, tiada keajaiban di sini - semuanya mengenai normalisasi. Dengan mengedarkan atribut merentas Satelit (dalam Bilik Kebal Data) atau jadual individu (Model Sauh), kami mengurangkan (atau menghapuskan sepenuhnya) pertindihan nilai beberapa atribut apabila menukar yang lain.
Untuk Bilik Kebal Data kemenangan akan bergantung kepada pengagihan atribut antara Satelit, dan untuk Model sauh β hampir berkadar terus dengan purata bilangan versi bagi setiap objek ukuran.
Walau bagaimanapun, penjimatan ruang adalah penting, tetapi bukan kelebihan utama, untuk menyimpan atribut secara berasingan. Bersama-sama penyimpanan perhubungan yang berasingan, pendekatan ini menjadikan kedai reka bentuk modular. Ini bermakna menambah kedua-dua atribut individu dan keseluruhan kawasan subjek baharu dalam model sedemikian kelihatan seperti suprastruktur atas set objek sedia ada tanpa mengubahnya. Dan inilah yang menjadikan metodologi yang diterangkan fleksibel.
Ini juga menyerupai peralihan daripada pengeluaran sekeping kepada pengeluaran besar-besaran - jika dalam pendekatan tradisional setiap jadual model adalah unik dan memerlukan perhatian khusus, maka dalam metodologi yang fleksibel ia sudah menjadi satu set "bahagian" standard. Di satu pihak, terdapat lebih banyak jadual, dan proses memuatkan dan mendapatkan semula data sepatutnya kelihatan lebih rumit. Sebaliknya, mereka menjadi tipikal. Maknanya mungkin ada automatik dan dipacu metadata. Soalan "bagaimana kita akan meletakkannya?", jawapan yang boleh mengambil bahagian penting dalam kerja mereka bentuk penambahbaikan, kini tidak berbaloi (serta persoalan tentang kesan perubahan model pada proses kerja ).
Ini tidak bermakna penganalisis tidak diperlukan dalam sistem sedemikian sama sekali - seseorang masih perlu bekerja melalui set objek dengan atribut dan memikirkan di mana dan bagaimana untuk memuatkan semuanya. Tetapi jumlah kerja, serta kemungkinan dan kos kesilapan, dikurangkan dengan ketara. Kedua-duanya pada peringkat analisis dan semasa pembangunan ETL, yang sebahagian besarnya boleh dikurangkan untuk menyunting metadata.
Sebelah gelap
Semua perkara di atas menjadikan kedua-dua pendekatan benar-benar fleksibel, maju dari segi teknologi dan sesuai untuk penambahbaikan berulang. Sudah tentu, terdapat juga "tong dalam salap", yang saya fikir anda sudah boleh meneka.
Penguraian data, yang mendasari kemodulatan seni bina yang fleksibel, membawa kepada peningkatan dalam bilangan jadual dan, dengan itu, atas kepala untuk bergabung semasa pensampelan. Untuk mendapatkan semua atribut dimensi, dalam kedai klasik satu pilihan sudah memadai, tetapi seni bina yang fleksibel akan memerlukan keseluruhan siri gabungan. Lebih-lebih lagi, jika semua gabungan ini untuk laporan boleh ditulis lebih awal, maka penganalisis yang biasa menulis SQL dengan tangan akan menderita dua kali ganda.
Terdapat beberapa fakta yang memudahkan keadaan ini:
Apabila bekerja dengan dimensi besar, semua atributnya hampir tidak pernah digunakan secara serentak. Ini bermakna bahawa mungkin terdapat lebih sedikit gabungan daripada yang kelihatan pada pandangan pertama pada model. Bilik Kebal Data juga boleh mengambil kira kekerapan perkongsian yang dijangkakan apabila memperuntukkan atribut kepada satelit. Pada masa yang sama, Hab atau Anchor sendiri diperlukan terutamanya untuk menjana dan memetakan pengganti pada peringkat pemuatan dan jarang digunakan dalam pertanyaan (ini terutama berlaku untuk Anchor).
Semua gabungan adalah dengan kunci. Di samping itu, cara menyimpan data yang lebih "mampat" mengurangkan overhed jadual pengimbasan di mana ia diperlukan (contohnya, apabila menapis mengikut nilai atribut). Ini boleh membawa kepada fakta bahawa pensampelan daripada pangkalan data yang dinormalkan dengan sekumpulan cantuman akan menjadi lebih pantas daripada mengimbas satu dimensi berat dengan banyak versi setiap baris.
Sebagai contoh, di sini Artikel tersebut mengandungi ujian perbandingan terperinci prestasi model Anchor dengan sampel dari satu jadual.
Banyak bergantung pada enjin. Banyak platform moden mempunyai mekanisme pengoptimuman gabungan dalaman. Contohnya, MS SQL dan Oracle boleh "melangkau" cantuman ke jadual jika data mereka tidak digunakan di mana-mana kecuali untuk cantuman lain dan tidak menjejaskan pemilihan akhir (penyingkiran jadual/join), dan MPP Vertica , telah terbukti sebagai enjin yang sangat baik untuk Model Anchor, memandangkan beberapa pengoptimuman manual pelan pertanyaan. Sebaliknya, menyimpan Model Anchor, sebagai contoh, pada Click House, yang mempunyai sokongan penyertaan terhad, masih belum kelihatan seperti idea yang sangat baik.
Di samping itu, untuk kedua-dua seni bina ada gerak khas, menjadikan akses data lebih mudah (kedua-duanya dari sudut prestasi pertanyaan dan untuk pengguna akhir). Sebagai contoh, Jadual Point-In-Time dalam Bilik Kebal Data atau fungsi jadual khas dalam model Anchor.
Dalam jumlah
Intipati utama seni bina fleksibel yang dianggap adalah modulariti "reka bentuk" mereka.
Ia adalah harta ini yang membolehkan:
- Selepas beberapa persediaan awal yang berkaitan dengan penggunaan metadata dan menulis algoritma ETL asas, cepat memberikan pelanggan hasil pertama dalam bentuk beberapa laporan yang mengandungi data daripada hanya beberapa objek sumber. Ia tidak perlu memikirkan sepenuhnya (walaupun di peringkat atas) keseluruhan model objek.
- Model data boleh mula berfungsi (dan berguna) dengan hanya 2-3 objek, dan kemudian berkembang secara beransur-ansur (mengenai model Anchor Nikolai perbandingan yang bagus dengan miselium).
- Kebanyakan penambahbaikan, termasuk meluaskan kawasan subjek dan menambah sumber baharu tidak menjejaskan fungsi sedia ada dan tidak menimbulkan risiko memecahkan sesuatu yang sudah berfungsi.
- Terima kasih kepada penguraian kepada elemen piawai, proses ETL dalam sistem sedemikian kelihatan sama, penulisan mereka sesuai untuk pengalgoritan dan, akhirnya, automasi.
Harga fleksibiliti ini ialah prestasi. Ini tidak bermakna mustahil untuk mencapai prestasi yang boleh diterima pada model sedemikian. Lebih kerap daripada tidak, anda mungkin memerlukan lebih banyak usaha dan perhatian terhadap perincian untuk mencapai metrik yang anda inginkan.
Aplikasi
Jenis entiti Bilik Kebal Data
Maklumat lanjut tentang Data Vault:
Jenis entiti Model Sauh
Butiran lanjut tentang Model Anchor:
Jadual ringkasan dengan ciri umum dan perbezaan pendekatan yang dipertimbangkan:
Sumber: www.habr.com