Ngembangkeun fasilitas panyimpen mangrupikeun usaha anu panjang sareng serius.
Seueur dina kahirupan proyek gumantung kana kumaha modél obyék sareng struktur dasarna dipikirkeun dina mimiti.
Pendekatan anu ditarima sacara umum geus sarta tetep rupa-rupa varian ngagabungkeun skéma béntang jeung formulir normal katilu. Sakumaha aturan, nurutkeun prinsip: data awal - 3NF, showcases - béntang. Pendekatan ieu, diuji waktos sareng dirojong ku seueur panilitian, mangrupikeun hal anu munggaran (sarta kadang-kadang hiji-hijina) anu aya dina pikiran spesialis DWH anu ngalaman nalika mikir ngeunaan naon anu kedah katingali ku gudang analitik.
Di sisi anu sanésna, bisnis sacara umum sareng syarat palanggan khususna condong robih gancang, sareng data condong tumbuh "jero" sareng "lebar". Sareng ieu dimana disadvantage utama béntang muncul - kawates kalenturan.
Sareng upami dina kahirupan sepi sareng nyaman anjeun salaku pamekar DWH ujug-ujug:
- tugas timbul "pikeun ngalakukeun sahenteuna hal gancang, lajeng urang bakal ningali";
- proyék ngembang pesat muncul, kalayan sambungan sumber anyar jeung reworking model bisnis sahenteuna saminggu sakali;
- a customer geus mucunghul nu teu boga pamanggih kumaha sistem kudu kasampak kawas jeung naon fungsi eta pamustunganana kudu dipigawé, tapi geus siap ékspérimén jeung konsistén nyaring hasil nu dipikahoyong bari konsistén meunang ngadeukeutan ka eta;
- Manajer proyék sumping kalayan warta anu saé: "Sareng ayeuna urang lincah!"
Atawa lamun anjeun ngan kabetot dina manggihan kumaha sejenna bisa ngawangun fasilitas gudang - wilujeng sumping di cut!
Naon anu dimaksud "fleksibilitas"?
Kahiji, hayu urang ngartikeun sipat naon anu kudu dipiboga ku sistem pikeun disebut "fleksibel".
Kapisah, eta sia mentioning yén sipat dijelaskeun kudu patali husus ka sistem, henteu ka prosés perkembangannya. Janten, upami anjeun hoyong maca ngeunaan Agile salaku metodologi pangembangan, langkung saé maca tulisan anu sanés. Contona, di dinya, dina Habré, aya seueur bahan anu pikaresepeun (sapertos и jeung ).
Ieu henteu hartosna yén prosés pangwangunan sareng struktur gudang data henteu aya hubunganana. Gemblengna, kedah langkung gampang pikeun ngembangkeun gudang Agile pikeun arsitéktur lincah. Nanging, dina prakna, langkung sering aya pilihan sareng pangembangan Agile tina DWH klasik numutkeun Kimbal sareng DataVault - numutkeun Curug, tibatan kabeneran kalenturan dina dua bentukna dina hiji proyék.
Janten, kamampuan naon anu kedah aya dina panyimpenan anu fleksibel? Aya tilu titik di dieu:
- Pangiriman awal sareng turnaround gancang - Ieu ngandung harti yén ideally hasil bisnis munggaran (contona, laporan gawé munggaran) kudu diala salaku awal mungkin, nyaeta, malah saméméh sakabéh sistem pinuh dirancang jeung dilaksanakeun. Leuwih ti éta, unggal révisi salajengna ogé kedah nyandak sakedik waktos.
- Perbaikan iteratif - Ieu ngandung harti yén unggal perbaikan salajengna kedahna henteu mangaruhan fungsionalitas anu parantos jalan. Momen ieu anu sering janten ngimpina pangbadagna dina proyék-proyék ageung - sooner atanapi engké, objék individu ngawitan acquire jadi loba sambungan nu janten gampang pikeun sakabéhna ngulang logika dina salinan caket dieu ti nambahkeun widang ka méja aya. Tur upami Anjeun salah reuwas yén analisa dampak perbaikan dina objék aya tiasa nyandak leuwih waktos ti perbaikan sorangan, anjeun paling dipikaresep teu acan digarap kalawan gudang data badag dina perbankan atawa telecoms.
- Terus-terusan adaptasi kana ngarobih syarat bisnis - struktur obyék sakabéh kudu dirancang teu ngan nyokot kana akun kamungkinan ékspansi, tapi kalawan ekspektasi nu arah ékspansi salajengna ieu malah teu bisa ngimpi dina tahap desain.
Sareng enya, nyumponan sadaya sarat ieu dina hiji sistem tiasa (tangtosna, dina sababaraha kasus sareng sababaraha reservations).
Di handap ieu kuring bakal mertimbangkeun dua metodologi desain tangkas anu pang populerna pikeun gudang data - Modél jangkar и Kolong Data. Ditinggalkeun kaluar tina kurung aya téknik anu saé sapertos, contona, EAV, 6NF (dina bentuk murnina) sareng sadayana anu aya hubunganana sareng solusi NoSQL - sanés sabab kumaha waé parah, sareng sanés kusabab dina hal ieu tulisan éta bakal ngancem pikeun nampi. volume rata disser. Ieu ngan ukur yén sadaya ieu aya hubunganana sareng solusi kelas anu rada béda - boh kana téknik anu anjeun tiasa dianggo dina kasus khusus, henteu paduli arsitektur proyék anjeun (sapertos EAV), atanapi paradigma panyimpen inpormasi anu sanés (sapertos database grafik. jeung pilihan séjén NoSQL).
Masalah pendekatan "klasik" sareng solusina dina metodologi anu fleksibel
Ku pendekatan "klasik" Maksad abdi béntang heubeul alus (paduli palaksanaan husus tina lapisan kaayaan, bisa jadi pengikut Kimball, Inmon na CDM ngahampura kuring).
1. Cardinality kaku tina sambungan
Modél ieu dumasar kana division jelas data kana Diménsi и fakta. Sareng ieu, sial, logis - saatosna, analisa data dina seuseueurna kasus turun kana analisa indikator numeris (fakta) dina bagian-bagian (dimensi) anu tangtu.
Dina hal ieu, sambungan antara objék dijieun dina bentuk hubungan antara tabel ngagunakeun konci asing. Ieu katingalina rada alami, tapi langsung nyababkeun watesan kalenturan munggaran - harti ketat ngeunaan cardinality of sambungan.
Ieu ngandung harti yén dina tahap desain tabel, anjeun kudu akurat nangtukeun pikeun unggal pasangan objék patali naha maranéhna bisa pakaitna saloba-ka-loba, atawa ngan 1-ka-loba, sarta "mana arah". Ieu langsung nangtukeun tabel mana nu bakal boga konci primér jeung nu bakal boga konci asing. Ngarobah sikep ieu nalika sarat anyar narima paling dipikaresep bakal ngakibatkeun hiji reworking tina basa.
Salaku conto, nalika ngarancang objék "kuitansi kas", anjeun, ngandelkeun sumpah jabatan penjualan, netepkeun kamungkinan tindakan. hiji promotion pikeun sababaraha posisi dipariksa (tapi henteu sabalikna):
Sareng saatos sababaraha waktos, kolega ngenalkeun strategi pamasaran énggal dimana aranjeunna tiasa ngalaksanakeun posisi anu sami sababaraha promosi sakaligus. Tur ayeuna anjeun kudu ngarobah tabel ku misahkeun hubungan kana objék misah.
(Sadaya obyék turunan dimana cek promosi dihijikeun ayeuna ogé kedah ningkat).
Hubungan dina Kolong Data sareng Modél Jangkar
Ngahindarkeun kaayaan ieu tétéla cukup saderhana: anjeun teu kedah percanten ka departemen penjualan pikeun ngalakukeun ieu. kabéh sambungan mimitina disimpen dina tabel misah sareng ngolahna saloba-loba-lobana.
Pendekatan ieu diajukeun Dan Linstedt salaku bagian tina paradigma Kolong Data sarta dirojong pinuh Lars Rönnbäck в Modél jangkar.
Hasilna, urang meunang fitur has munggaran tina metodologi fléksibel:
Hubungan antara objék teu disimpen dina atribut entitas indungna, tapi mangrupakeun tipe misah objék.
В Kolong Data tabél linking sapertos disebut link, sareng di Modél jangkar - dasi. Dina glance kahiji, aranjeunna pisan sarupa, sanajan béda maranéhanana teu ditungtungan make ngaran (anu bakal dibahas dihandap). Dina duanana arsitéktur, tabel link bisa numbu sajumlah éntitas (teu kudu 2).
redundansi ieu, dina glance kahiji, nyadiakeun kalenturan signifikan pikeun modifikasi. Struktur sapertos kitu janten toleran henteu ngan ukur kana parobihan dina kardinalitas tautan anu tos aya, tapi ogé kana tambihan anu énggal - upami ayeuna posisi cek ogé ngagaduhan tautan ka kasir anu nembus éta, penampilan tautan sapertos kitu ngan saukur bakal janten tambihan dina tabel anu tos aya tanpa mangaruhan obyék sareng prosés anu aya.
2. Duplikasi data
Masalah kadua direngsekeun ku arsitéktur fléksibel kirang écés sarta alamiah di tempat munggaran. Pangukuran tipe SCD2 (laun ngarobah dimensi tina tipe kadua), sanajan teu ukur aranjeunna.
Dina gudang Palasik, hiji diménsi ilaharna mangrupa méja nu ngandung hiji konci surrogate (sakumaha PK) sarta susunan konci bisnis jeung atribut dina kolom misah.
Lamun diménsi ngarojong versioning, wates validitas versi ditambahkeun kana set standar widang, sarta pikeun hiji baris dina sumberna, sababaraha versi nembongan dina gudang (hiji pikeun tiap parobahan dina atribut versioned).
Upami diménsi ngandung sahenteuna hiji atribut versi anu sering robih, jumlah vérsi diménsi sapertos kitu bakal pikaresepeun (sanaos atribut sésana henteu diversi atanapi henteu kantos robih), sareng upami aya sababaraha atribut sapertos kitu, jumlah vérsi tiasa. tumuwuh éksponénsial tina jumlah maranéhanana. Dimensi ieu tiasa nyandak sajumlah ageung rohangan disk, sanaos seueur data anu disimpenna ngan saukur duplikat nilai atribut anu teu tiasa dirobih tina barisan anu sanés.
Dina waktos anu sami, éta ogé sering dianggo denormalisasi - sababaraha atribut ngahaja disimpen salaku nilai, teu salaku tumbu ka buku rujukan atawa dimensi séjén. Pendekatan ieu nyepetkeun aksés data, ngirangan jumlah gabungan nalika ngaksés diménsi.
Biasana ieu ngakibatkeun inpo nu sarua disimpen sakaligus dina sababaraha tempat. Salaku conto, inpormasi ngeunaan daérah tempat tinggal sareng kategori klien tiasa disimpen sakaligus dina dimensi "Klién" sareng fakta "Beuli", "Pangiriman" sareng "Telepon Pusat Telepon", kitu ogé dina "Klién - Manajer Klién". ” méja link.
Sacara umum, ditétélakeun di luhur manglaku ka biasa (non-versioned) diménsi, tapi dina leuwih versioned maranéhna bisa boga skala béda: penampilan versi anyar tina hiji obyék (utamana di retrospect) ngabalukarkeun teu ukur update sadaya patali. tabél, tapi ka penampilan cascading sahiji versi anyar objék patali - nalika Table 1 dipaké pikeun ngawangun Table 2, sarta Table 2 dipaké pikeun ngawangun Table 3, jsb. Malah lamun teu hiji atribut tunggal Table 1 aub dina pangwangunan Table 3 (jeung atribut sejenna Table 2 dicandak ti sumber sejenna aub), versioning konstruksi ieu bakal di minimum ngakibatkeun overhead tambahan, sarta dina maksimum ka tambahan. versi dina Table 3. nu boga nganggur teu jeung eta pisan, sarta salajengna handap ranté nu.
3. pajeulitna nonlinier of rework
Dina waktos anu sami, unggal toko énggal anu diwangun dina dasar anu sanés ningkatkeun jumlah tempat dimana data tiasa "diverge" nalika parobihan dilakukeun kana ETL. Ieu, kahareupna ngabalukarkeun kanaékan pajeulitna (jeung durasi) unggal révisi saterusna.
Upami di luhur ngajelaskeun sistem sareng prosés ETL anu jarang dirobih, anjeun tiasa hirup dina paradigma sapertos kitu - anjeun ngan ukur kedah mastikeun yén modifikasi énggal leres dilakukeun pikeun sadaya objék anu aya hubunganana. Upami révisi sering kajantenan, kamungkinan ngahaja "leungit" sababaraha sambungan ningkat sacara signifikan.
Upami, salian ti éta, urang tumut kana akun yén "versioned" ETL nyata langkung pajeulit batan "non-versioned", janten rada hese pikeun nyingkahan kasalahan nalika sering ngamutahirkeun sadayana fasilitas ieu.
Nyimpen objék sareng atribut dina Data Kolong sareng Model Jangkar
Pendekatan anu diusulkeun ku pangarang arsitéktur fleksibel tiasa dirumuskeun kieu:
Perlu misahkeun naon anu robih tina anu tetep sami. Hartina, nyimpen konci misah ti atribut.
Sanajan kitu, hiji teu matak bingung teu versioned atribut jeung teu robah: anu kahiji henteu nyimpen sajarah parobahanana, tapi tiasa robih (contona, nalika koréksi kasalahan input atanapi nampi data énggal); anu kadua henteu kantos robih.
Sudut pandang béda dina naon anu tiasa dianggap teu tiasa dirobih dina Kolong Data sareng Modél Jangkar.
Tina sudut pandang arsitéktur Kolong Data, bisa dianggap unchanged sakabeh set konci - alam (TIN organisasi, kode produk dina sistem sumber, jsb) jeung surrogate. Dina hal ieu, atribut sésana bisa dibagi kana grup nurutkeun sumber jeung / atawa frékuénsi parobahan na Ngajaga tabel misah pikeun tiap grup kalawan hiji set bebas versi.
Dina paradigma Modél jangkar dianggap teu robah ngan konci surrogate panggih. Sagalana sejenna (kaasup konci alam) ngan kasus husus tina atribut na. Dimana kabéh atribut anu bebas silih sacara standar, jadi pikeun tiap atribut a méja misah.
В Kolong Data tabél ngandung kenop éntitas disebut Hubami. Hub salawasna ngandung sakumpulan sawah anu tetep:
- Konci Éntitas Alam
- Konci pangganti
- Tumbu ka sumber
- Rékam nambahan waktu
Tulisan di Hubs pernah robah jeung teu boga versi. Externally, hubs pisan sarupa tabel tipe ID-peta dipaké dina sababaraha sistem keur ngahasilkeun surrogates, kumaha oge, eta disarankeun pikeun make Hash tina susunan konci bisnis sakumaha surrogates di Data Kolong. pendekatan ieu simplifies loading hubungan jeung atribut ti sumber (anjeun teu kedah gabung hub pikeun meunangkeun surrogate a, anjeun ngan perlu ngitung Hash sahiji konci alam), tapi bisa ngabalukarkeun masalah séjén (patali, contona, tabrakan). , Kasus jeung karakter non-dicitak dina kenop string, jsb. .p.), Ku sabab eta teu umum ditarima.
Kabéh atribut éntitas séjén disimpen dina tabel husus disebut Satelit. Hiji hub tiasa gaduh sababaraha satelit anu nyimpen set atribut anu béda.
Sebaran atribut diantara satelit lumangsung nurutkeun prinsip parobahan gabungan - dina hiji satelit, atribut non-versi tiasa disimpen (contona, tanggal lahir sareng SNILS pikeun individu), dina anu sanés - jarang ngarobih versi (contona, nami tukang sareng nomer paspor), dina katilu - anu sering robih. (Contona, alamat pangiriman, kategori, tanggal pesenan panungtungan, jsb). Dina hal ieu, vérsi dilaksanakeun dina tingkat satelit individu, sanés éntitas sacara gembleng, ku kituna disarankeun pikeun ngadistribusikaeun atribut supados simpang vérsi dina hiji satelit minimal (anu ngirangan jumlah total versi anu disimpen. ).
Ogé, pikeun ngaoptimalkeun prosés ngamuat data, atribut anu dicandak tina sababaraha sumber sering kalebet dina satelit individu.
Satelit komunikasi sareng Hub via konci asing (anu pakait jeung 1-to-loba cardinality). Ieu ngandung harti yén sababaraha nilai atribut (contona, sababaraha nomer telepon kontak pikeun hiji klien) dirojong ku arsitektur "standar" ieu.
В Modél jangkar tabél nu nyimpen konci disebut Jangkar. Sareng aranjeunna tetep:
- Ngan konci pengganti
- Tumbu ka sumber
- Rékam nambahan waktu
Konci alam tina sudut pandang Model Jangkar dianggap atribut biasa. Pilihan ieu sigana langkung hese ngartos, tapi masihan langkung seueur ruang pikeun ngaidentipikasi obyék.
Salaku conto, upami data ngeunaan éntitas anu sami tiasa asalna tina sistem anu béda, anu masing-masing nganggo konci alami sorangan. Dina Data Kolong, ieu bisa ngakibatkeun struktur rada pajeujeut tina sababaraha hub (hiji per sumber + versi master ngahijikeun Tatar), sedengkeun dina model Anchor, konci alam unggal sumber digolongkeun kana atribut sorangan sarta bisa dipaké nalika loading bebas tina. sakabeh batur.
Tapi aya ogé hiji titik insidious di dieu: lamun atribut ti sistem béda digabungkeun dina hiji éntitas, paling dipikaresep aya sababaraha. aturan "gluing", dimana sistem kedah ngartos yén rékaman tina sumber anu béda pakait sareng hiji conto éntitas.
В Kolong Data aturan ieu paling dipikaresep bakal nangtukeun formasi "surrogate hub" tina éntitas master sareng henteu mangaruhan kana Hub anu nyimpen konci sumber alam sareng atribut aslina. Lamun di sawatara titik aturan merging robah (atawa atribut ku nu eta dipigawé diropéa), bakal cukup pikeun reformat hubs surrogate.
В Modél jangkar éntitas sapertos kitu bakal paling dipikaresep disimpen di hijina jangkar. Ieu ngandung harti yén sakabéh atribut, euweuh urusan naon sumber aranjeunna asalna, bakal kabeungkeut surrogate sarua. Misahkeun rékaman anu dihijikeun sacara salah sareng, sacara umum, ngawaskeun relevansi ngahiji dina sistem sapertos kitu tiasa langkung sesah, khususna upami aturanna rada rumit sareng sering robih, sareng atribut anu sami tiasa didapet tina sumber anu béda (sanaos pastina. mungkin, saprak unggal versi atribut nahan tumbu ka sumber na).
Dina sagala hal, lamun sistem Anjeun sakuduna dituju pikeun nerapkeun pungsionalitasna deduplication, merging rékaman sarta elemen MDM séjén, éta patut nengetan hususna ka aspék nyimpen konci alam dina metodologi lincah. Éta kamungkinan yén desain Data Vault anu langkung ageung ujug-ujug bakal langkung aman dina hal kasalahan gabungan.
Modél jangkar ogé nyadiakeun tipe objék tambahan disebut Knot éta dasarna husus tipe degenerate tina jangkar, nu bisa ngandung ngan hiji atribut. Titik anu sakuduna dipaké pikeun nyimpen diréktori datar (contona, gender, status kakawinan, kategori layanan palanggan, jsb). Beda sareng Jangkar, Knot teu boga tabel atribut pakait, sarta ngan atribut na (nami) salawasna disimpen dina tabel sarua jeung konci. Titik disambungkeun ka Anchors ku tabel dasi (Tie) dina cara nu sarua salaku Anchors disambungkeun ka silih.
Henteu aya pendapat anu jelas ngeunaan panggunaan Nodes. Salaku conto, , anu aktip ngamajukeun pamakean Model Jangkar di Rusia, percaya (teu munasabah) yén pikeun henteu aya buku rujukan tunggal tiasa dinyatakeun kalayan pasti. salawasna bakal statik sareng tingkat tunggal, janten langkung saé langsung nganggo Jangkar anu lengkep pikeun sadaya objék.
Beda penting séjén antara Data Vault sareng model Jangkar nyaéta kasadiaan atribut sambungan:
В Kolong Data Tumbu mangrupakeun objék full-fledged sarua Hubs, sarta bisa mibanda atribut sorangan. The Modél jangkar Tumbu dipaké ngan pikeun nyambungkeun jangkar na teu bisa boga atribut sorangan. Bedana ieu ngakibatkeun pendekatan modeling béda signifikan fakta, nu bakal dibahas salajengna.
Panyimpen kanyataan
Sateuacan ieu, urang ngobrolkeun utamina ngeunaan modél pangukuran. Faktana rada kurang jelas.
В Kolong Data objék has pikeun nyimpen fakta nyaeta Tumbu, dina anu satelit indikator nyata ditambahkeun.
Pendekatan ieu sigana intuitif. Éta nyayogikeun aksés gampang kana indikator anu dianalisis sareng umumna sami sareng tabel kanyataan tradisional (ngan ukur indikator anu disimpen henteu dina méja sorangan, tapi dina méja "tatangga"). Tapi aya ogé pitfalls: salah sahiji modifikasi has model - perluasan konci kanyataan - merlukeun. nambahkeun konci asing anyar pikeun Patalina. Sareng ieu, kahareupna "ngarecah" modularitas sareng berpotensi nyababkeun kabutuhan modifikasi kana objék anu sanés.
В Modél jangkar Sambungan teu tiasa gaduh atribut sorangan, janten pendekatan ieu moal jalan - leres pisan sadayana atribut sareng indikator kedah dihubungkeun sareng hiji jangkar khusus. Kacindekan tina ieu basajan - Unggal kanyataan ogé butuh jangkar sorangan. Kanggo sababaraha naon anu biasa kami perceiving salaku kanyataan, ieu sigana alami - contona, kanyataan ngagaleuh tiasa dikirangan sampurna kana obyék "pesenan" atanapi "kuitansi", ngadatangan situs ka sési, jsb. Tapi aya ogé fakta nu teu jadi gampang pikeun manggihan "obyek pamawa" alam - contona, sésa-sésa barang di gudang di awal unggal poé.
Sasuai, masalah sareng modularitas nalika ngalegaan konci kanyataan dina modél Anchor henteu timbul (cukup ngan ukur nambihan Hubungan énggal ka Jangkar anu saluyu), tapi ngarancang modél pikeun ningalikeun fakta henteu ambigu; Jangkar "jieunan" tiasa muncul. nu mintonkeun model objék bisnis dina cara teu jelas.
Kumaha kalenturan kahontal
Konstruksi anu dihasilkeun dina duanana kasus ngandung nyata leuwih tabeltinimbang pangukuran tradisional. Tapi meureun butuh spasi disk nyata kirang kalawan set sarua atribut versioned sakumaha diménsi tradisional. Alami, teu aya sihir di dieu - éta sadayana ngeunaan normalisasi. Ku ngadistribusikaeun atribut sakuliah Satelit (dina Kolong Data) atawa tabel individu (Model Jangkar), urang ngurangan (atawa sagemblengna ngaleungitkeun) duplikasi nilai sababaraha atribut nalika ngarobah batur.
keur Kolong Data winnings bakal gumantung kana sebaran atribut diantara Satelit, jeung Modél jangkar - ampir sabanding langsung jeung jumlah rata-rata versi per obyék pangukuran.
Sanajan kitu, tabungan spasi mangrupakeun hiji kaunggulan penting, tapi teu utama, pikeun nyimpen atribut misah. Babarengan gudang misah tina hubungan, pendekatan ieu ngajadikeun toko desain modular. Ieu ngandung harti yén nambahkeun duanana atribut individu jeung sakabeh wewengkon subjek anyar dina model kitu Sigana mah superstruktur leuwih hiji set aya objék tanpa ngarobah aranjeunna. Sareng ieu anu ngajadikeun metodologi anu dijelaskeun fléksibel.
Ieu ogé nyarupaan transisi tina produksi sapotong ka produksi masal - lamun dina pendekatan tradisional unggal tabel model unik sarta merlukeun perhatian husus, lajeng dina metodologi fléksibel geus susunan standar "bagian". Di hiji sisi, aya deui tabel, sarta prosés loading na retrieving data kudu kasampak leuwih pajeulit. Di sisi séjén, aranjeunna janten has. Nu hartina meureun aya otomatis tur metadata disetir. Patarosan "kumaha urang bakal iklas eta?", Jawaban nu bisa nyandak up bagian signifikan tina karya dina ngarancang perbaikan, ayeuna ngan saukur teu patut eta (kitu oge patarosan ngeunaan dampak ngarobah model dina prosés gawé. ).
Ieu henteu hartosna yén analis teu diperlukeun dina sistem sapertos - batur masih kudu dianggo ngaliwatan susunan objék kalawan atribut jeung angka kaluar dimana jeung kumaha carana muka eta sadayana. Tapi jumlah pagawéan, ogé kamungkinan sareng biaya kasalahan, dikirangan sacara signifikan. Duanana dina tahap analisa sareng nalika pamekaran ETL, anu dina bagian anu penting tiasa diréduksi pikeun ngédit metadata.
Sisi poek
Kabéh di luhur ngajadikeun duanana pendekatan sabenerna fléksibel, technologically canggih tur cocog pikeun perbaikan iterative. Tangtosna, aya ogé "tong dina salep", anu kuring pikir anjeun parantos tiasa nebak.
Dékomposisi data, anu ngadasarkeun modularitas arsitéktur anu fleksibel, nyababkeun kanaékan jumlah tabel sareng, sasuai, overhead pikeun ngagabung nalika sampling. Dina raraga saukur meunang sagala atribut diménsi a, dina toko Palasik hiji pilih cukup, tapi arsitéktur fléksibel bakal merlukeun sakabeh runtuyan gabung. Sumawona, upami sadayana ngagabung ieu pikeun laporan tiasa ditulis sateuacanna, maka analis anu biasa nyerat SQL ku leungeun bakal sangsara dua kali.
Aya sababaraha fakta anu ngagampangkeun kaayaan ieu:
Nalika damel sareng diménsi ageung, sadaya atributna ampir henteu kantos dianggo sakaligus. Ieu ngandung harti yén meureun aya pangsaeutikna ngagabung ti sigana di glance kahiji dina modél. Data Vault ogé tiasa tumut kana frékuénsi ékspéktasi dibagikeun nalika ngalokasikeun atribut ka satelit. Dina waktu nu sarua, Hubs atanapi Anchors sorangan diperlukeun utamana pikeun generating na pemetaan surrogates dina tahap loading sarta jarang dipaké dina queries (ieu hususna bener keur Anchors).
Kabéh ngagabung téh ku konci. Salaku tambahan, cara anu langkung "dikomprés" pikeun nyimpen data ngirangan overhead tabel scanning dimana diperyogikeun (contona, nalika nyaring ku nilai atribut). Ieu tiasa nyababkeun kanyataan yén sampling tina pangkalan data anu dinormalisasi sareng sakumpulan gabungan bakal langkung gancang tibatan nyeken hiji diménsi beurat sareng seueur versi per baris.
Contona, di dieu Artikel ngandung tés komparatif detil kinerja model Jangkar kalawan sampel tina hiji méja.
Loba gumantung kana mesin. Seueur platform modéren gaduh mékanisme optimasi gabungan internal. Salaku conto, MS SQL sareng Oracle tiasa "skip" ngagabung kana tabel upami datana henteu dianggo dimana waé kecuali pikeun gabung anu sanés sareng henteu mangaruhan seleksi ahir (méja / éliminasi gabung), sareng MPP Vertica , geus kabuktian jadi hiji mesin alus teuing pikeun Modél jangkar, dibéré sababaraha optimasi manual tina rencana query. Di sisi anu sanésna, nyimpen Model Jangkar, contona, dina Click House, anu ngagaduhan dukungan terbatas, henteu acan janten ide anu saé.
Sajaba ti éta, pikeun duanana arsitéktur aya gerakan husus, sangkan aksés data leuwih gampang (duanana tina sudut pandang kinerja query jeung pamaké tungtung). Salaku conto, Point-In-Time tabel dina Data Kolong atawa fungsi tabel husus dina modél Jangkar.
dina total
Hakekat utama arsitéktur fléksibel anu dianggap nyaéta modularitas "desain" na.
Harta ieu ngamungkinkeun:
- Saatos sababaraha persiapan awal anu aya hubunganana sareng panyebaran metadata sareng nyerat algoritma ETL dasar, gancang nyadiakeun konsumén jeung hasil munggaran dina bentuk sababaraha laporan anu ngandung data tina ngan sababaraha objék sumber. Teu perlu sagemblengna mikir ngaliwatan (sanajan di tingkat luhur) sakabéh modél obyék.
- Hiji model data bisa ngamimitian gawé (jeung mangpaat) kalawan ngan 2-3 objék, lajeng tumuwuh laun (ngeunaan modél jangkar Nikolai ngabandingkeun saé sareng miselium).
- Paling perbaikan, kaasup dilegakeun wewengkon subjek jeung nambahkeun sumber anyar henteu mangaruhan fungsionalitas anu tos aya sareng henteu ngabahayakeun pikeun ngalanggar hal anu parantos jalan.
- Hatur nuhun kana dékomposisi kana unsur standar, prosés ETL dina sistem sapertos kitu katingalina sami, tulisanna masihan algoritma sareng, pamustunganana, otomatis.
Harga kalenturan ieu pagelaran. Ieu lain hartosna yén teu mungkin pikeun ngahontal kinerja ditarima dina model kitu. Langkung sering ti henteu, anjeun ngan saukur peryogi langkung usaha sareng perhatian kana detil pikeun ngahontal métrik anu anjeun pikahoyong.
aktip
Jenis éntitas Kolong Data
Inpormasi langkung seueur ngeunaan Data Vault:
Jenis éntitas Modél jangkar
Langkung seueur ngeunaan Modél Jangkar:
Tabel kasimpulan sareng fitur umum sareng bédana pendekatan anu dianggap:
sumber: www.habr.com