El desenvolupament d'una instal·lació d'emmagatzematge és una empresa llarga i seriosa.
Gran part de la vida d'un projecte depèn de com estiguin pensats al principi el model d'objecte i l'estructura base.
L'enfocament generalment acceptat ha estat i segueix sent diverses variants de combinar l'esquema estrella amb la tercera forma normal. Com a regla general, segons el principi: dades inicials - 3NF, vitrines - estrella. Aquest enfocament, provat en el temps i recolzat per una gran quantitat d'investigacions, és el primer (i de vegades l'únic) que ve a la ment d'un especialista en DWH experimentat quan pensa com hauria de ser un dipòsit analític.
D'altra banda, el negoci en general i els requisits dels clients en particular tendeixen a canviar ràpidament, i les dades tendeixen a créixer tant "en profunditat" com "en amplitud". I aquí és on apareix el principal desavantatge d'una estrella: limitada flexibilitat.
I si de sobte a la teva vida tranquil·la i acollidora com a desenvolupador de DWH:
- la tasca va sorgir “fer almenys una cosa ràpidament, i després ja veurem”;
- va aparèixer un projecte de ràpid desenvolupament, amb la connexió de noves fonts i la reelaboració del model de negoci almenys un cop per setmana;
- ha aparegut un client que no té ni idea de com hauria de ser el sistema i de quines funcions hauria de realitzar finalment, però està preparat per experimentar i perfeccionar constantment el resultat desitjat mentre s'hi acosta constantment;
- El responsable del projecte va presentar la bona notícia: "I ara tenim àgil!"
O si només esteu interessats a esbrinar com podeu construir instal·lacions d'emmagatzematge, benvingut al tall!
Què vol dir "flexibilitat"?
En primer lloc, anem a definir quines propietats ha de tenir un sistema per ser anomenat "flexible".
Per separat, val la pena esmentar que les propietats descrites s'han de relacionar específicament amb sistema, no a procés el seu desenvolupament. Per tant, si voleu llegir sobre Agile com a metodologia de desenvolupament, és millor llegir altres articles. Per exemple, allà mateix, a Habré, hi ha molts materials interessants (com ara и I ).
Això no vol dir que el procés de desenvolupament i l'estructura del magatzem de dades no estiguin completament relacionats. En general, hauria de ser molt més fàcil desenvolupar un repositori àgil per a una arquitectura àgil. No obstant això, a la pràctica, més sovint hi ha opcions amb el desenvolupament àgil del clàssic DWH segons Kimbal i DataVault, segons Waterfall, que les feliços coincidències de flexibilitat en les seves dues formes en un projecte.
Aleshores, quines capacitats hauria de tenir l'emmagatzematge flexible? Aquí hi ha tres punts:
- Entrega anticipada i lliurament ràpid - això vol dir que, idealment, el primer resultat empresarial (per exemple, els primers informes de treball) s'hauria d'obtenir el més aviat possible, és a dir, fins i tot abans que tot el sistema estigui totalment dissenyat i implementat. A més, cada revisió posterior també hauria de prendre el menor temps possible.
- Refinament iteratiu - això vol dir que, idealment, cada millora posterior no hauria d'afectar la funcionalitat que ja està funcionant. És aquest moment el que sovint es converteix en el malson més gran dels grans projectes: tard o d'hora, els objectes individuals comencen a adquirir tantes connexions que és més fàcil repetir completament la lògica en una còpia propera que afegir un camp a una taula existent. I si us sorprèn que analitzar l'impacte de les millores en els objectes existents pot trigar més temps que les millores en si, és probable que encara no hàgiu treballat amb grans magatzems de dades en banca o telecomunicacions.
- Adaptant-se constantment als canvis requerits del negoci - L'estructura global de l'objecte s'ha de dissenyar no només tenint en compte la possible expansió, sinó amb l'expectativa que la direcció d'aquesta propera expansió ni tan sols es podria somiar en l'etapa de disseny.
I sí, complir tots aquests requisits en un sol sistema és possible (és clar, en determinats casos i amb algunes reserves).
A continuació, consideraré dues de les metodologies de disseny àgil més populars per a magatzems de dades: Model d'àncora и Volta de dades. S'han deixat fora dels parèntesis tècniques tan excel·lents com, per exemple, EAV, 6NF (en la seva forma pura) i tot allò relacionat amb solucions NoSQL, no perquè siguin d'alguna manera pitjors, i ni tan sols perquè en aquest cas l'article amenaçaria d'adquirir. el volum del dissert mitjà. És només que tot això es relaciona amb solucions d'una classe lleugerament diferent, ja sigui amb tècniques que podeu utilitzar en casos específics, independentment de l'arquitectura general del vostre projecte (com EAV), o amb altres paradigmes d'emmagatzematge d'informació globalment (com bases de dades de gràfics). i altres opcions NoSQL).
Problemes de l'enfocament “clàssic” i les seves solucions en metodologies flexibles
Per enfocament "clàssic" em refereixo a la bona estrella (independentment de la implementació específica de les capes subjacents, que els seguidors de Kimball, Inmon i CDM em perdonis).
1. Cardinalitat rígida de les connexions
Aquest model es basa en una clara divisió de dades en Dimensió и fets. I això, carai, és lògic: després de tot, l'anàlisi de dades en la gran majoria dels casos es redueix a l'anàlisi de determinats indicadors numèrics (fets) en determinades seccions (dimensions).
En aquest cas, les connexions entre objectes s'estableixen en forma de relacions entre taules mitjançant una clau estrangera. Això sembla bastant natural, però immediatament condueix a la primera limitació de la flexibilitat: definició estricta de la cardinalitat de les connexions.
Això vol dir que en l'etapa de disseny de la taula, heu de determinar amb precisió per a cada parell d'objectes relacionats si es poden relacionar tants a molts, o només d'1 a molts, i "en quina direcció". Això determina directament quina taula tindrà la clau primària i quina tindrà la clau estrangera. Canviar aquesta actitud quan es rebin nous requisits probablement comportarà una reelaboració de la base.
Per exemple, en dissenyar l'objecte "rebut d'efectiu", vostè, confiant en els juraments del departament de vendes, va establir la possibilitat d'acció una promoció per a diverses posicions de control (però no al revés):
I després d'un temps, els companys van introduir una nova estratègia de màrqueting en la qual poden actuar en la mateixa posició diverses promocions al mateix temps. I ara cal modificar les taules separant la relació en un objecte separat.
(Ara també s'han de millorar tots els objectes derivats en què s'uneix el control de promoció).
Relacions en Data Vault i Anchor Model
Evitar aquesta situació va resultar bastant senzill: no cal confiar en el departament de vendes per fer-ho. totes les connexions s'emmagatzemen inicialment en taules separades i processar-lo tants a molts.
Es va proposar aquest enfocament Dan Linstedt com a part del paradigma Volta de dades i totalment recolzat Lars Rönnbäck в Model d'àncora.
Com a resultat, obtenim la primera característica distintiva de les metodologies flexibles:
Les relacions entre objectes no s'emmagatzemen en atributs de les entitats pares, sinó que són un tipus d'objecte independent.
В Volta de dades aquestes taules d'enllaç s'anomenen Enllaçi en Model d'àncora - llaç. A primera vista, són molt semblants, tot i que les seves diferències no acaben amb el nom (que es comentarà a continuació). En ambdues arquitectures, les taules d'enllaç poden enllaçar qualsevol nombre d'entitats (no necessàriament 2).
Aquesta redundància, a primera vista, proporciona una flexibilitat important per a les modificacions. Aquesta estructura es torna tolerant no només als canvis en la cardinalitat dels enllaços existents, sinó també a l'addició de nous; si ara una posició de xec també té un enllaç amb el caixer que l'ha trencat, l'aparició d'aquest enllaç simplement convertir-se en un complement sobre les taules existents sense afectar cap objecte i procés existent.
2. Duplicació de dades
El segon problema resolt per les arquitectures flexibles és menys evident i és inherent en primer lloc. Mesures tipus SCD2 (dimensions canviants lentament del segon tipus), encara que no només elles.
En un magatzem clàssic, una dimensió és normalment una taula que conté una clau substitutiva (com a PK) i un conjunt de claus i atributs empresarials en columnes separades.
Si una dimensió admet el control de versions, els límits de validesa de la versió s'afegeixen al conjunt estàndard de camps i, per a una fila de la font, apareixen diverses versions al repositori (una per cada canvi en els atributs versionats).
Si una dimensió conté almenys un atribut de versions que canvia sovint, el nombre de versions d'aquesta dimensió serà impressionant (encara que els atributs restants no es versionin o no canviïn mai), i si hi ha diversos d'aquests atributs, el nombre de versions pot ser creixen exponencialment a partir del seu nombre. Aquesta dimensió pot ocupar una quantitat important d'espai en disc, tot i que gran part de les dades que emmagatzema són simplement duplicats de valors d'atributs immutables d'altres files.
Al mateix temps, també s'utilitza molt sovint desnormalització — alguns atributs s'emmagatzemen intencionadament com a valor i no com a enllaç a un llibre de referència o una altra dimensió. Aquest enfocament accelera l'accés a les dades, reduint el nombre d'unions en accedir a una dimensió.
Normalment això condueix a la mateixa informació s'emmagatzema simultàniament en diversos llocs. Per exemple, la informació sobre la regió de residència i la categoria del client es pot emmagatzemar simultàniament a les dimensions "Client" i als fets "Compra", "Lliurament" i "Trucades al centre de trucades", així com a "Client - Gestor de clients". ” taula d'enllaços.
En general, el que s'ha descrit anteriorment s'aplica a dimensions normals (no versionades), però en versions poden tenir una escala diferent: l'aparició d'una nova versió d'un objecte (especialment en retrospectiva) condueix no només a l'actualització de tots els elements relacionats. taules, però a l'aparició en cascada de noves versions d'objectes relacionats, quan la taula 1 s'utilitza per crear la taula 2, i la taula 2 s'utilitza per crear la taula 3, etc. Fins i tot si no hi ha cap atribut de la Taula 1 implicat en la construcció de la Taula 3 (i hi ha altres atributs de la Taula 2 obtinguts d'altres fonts), la versió d'aquesta construcció comportarà com a mínim una sobrecàrrega addicional i com a màxim una sobrecàrrega. versions de la taula 3. que no hi té res a veure, i més avall en la cadena.
3. Complexitat no lineal del retreball
Al mateix temps, cada nova botiga construïda a partir d'una altra augmenta el nombre de llocs on les dades poden "divergir" quan es fan canvis a l'ETL. Això, al seu torn, comporta un augment de la complexitat (i durada) de cada revisió posterior.
Si l'anterior descriu sistemes amb processos ETL rarament modificats, podeu viure en aquest paradigma; només cal que us assegureu que les noves modificacions es fan correctament a tots els objectes relacionats. Si les revisions es produeixen amb freqüència, la probabilitat de "perdre" accidentalment diverses connexions augmenta significativament.
Si, a més, tenim en compte que l'ETL "versionat" és significativament més complicat que un "no versionat", es fa bastant difícil evitar errors en actualitzar amb freqüència tota aquesta instal·lació.
Emmagatzematge d'objectes i atributs a Data Vault i Anchor Model
L'enfocament proposat pels autors d'arquitectures flexibles es pot formular de la següent manera:
Cal separar el que canvia del que segueix sent igual. És a dir, emmagatzemar les claus per separat dels atributs.
Tanmateix, no s'ha de confondre no versionat atribut amb sense canvis: el primer no emmagatzema l'historial dels seus canvis, però pot canviar (per exemple, en corregir un error d'entrada o rebre dades noves); el segon no canvia mai.
Els punts de vista difereixen sobre allò que es pot considerar exactament immutable a Data Vault i Anchor Model.
Des d'un punt de vista arquitectònic Volta de dades, es pot considerar sense canvis conjunt complet de claus - natural (TIN de l'organització, codi de producte en el sistema font, etc.) i substitut. En aquest cas, els atributs restants es poden dividir en grups segons l'origen i/o freqüència dels canvis i Mantenir una taula separada per a cada grup amb un conjunt independent de versions.
En el paradigma Model d'àncora considerat sense canvis només clau substitutiva essència. Tota la resta (incloses les claus naturals) és només un cas especial dels seus atributs. On tots els atributs són independents els uns dels altres per defecte, així que per a cada atribut a taula separada.
В Volta de dades s'anomenen taules que contenen claus d'entitat Hubami. Els concentradors sempre contenen un conjunt fix de camps:
- Claus d'entitats naturals
- Clau substituta
- Enllaç a la font
- Registre el temps d'addició
Publicacions a Hubs mai canvia i no té versions. Externament, els concentradors són molt semblants a les taules de tipus de mapa d'identificació que s'utilitzen en alguns sistemes per generar substituts, però, es recomana utilitzar un hash d'un conjunt de claus empresarials com a substituts a Data Vault. Aquest enfocament simplifica la càrrega de relacions i atributs des de les fonts (no cal unir-se al concentrador per obtenir un substitut, només cal calcular el hash d'una clau natural), però pot causar altres problemes (relacionats, per exemple, amb col·lisions, majúscules i no imprimibles). caràcters en tecles de cadena, etc. .p.), per tant, no s'accepta generalment.
Tots els altres atributs d'entitat s'emmagatzemen en taules especials anomenades Satèl·lits. Un concentrador pot tenir diversos satèl·lits que emmagatzemen diferents conjunts d'atributs.
La distribució d'atributs entre satèl·lits es produeix segons el principi canvi conjunt — en un satèl·lit es poden emmagatzemar atributs sense versions (per exemple, data de naixement i SNILS per a un individu), en un altre, amb versions que rarament canvien (per exemple, cognom i número de passaport), en el tercer, canvis freqüents. (per exemple, adreça de lliurament, categoria, data de la darrera comanda, etc.). En aquest cas, el control de versions es realitza a nivell de satèl·lits individuals, i no de l'entitat en conjunt, per la qual cosa s'aconsella distribuir els atributs de manera que la intersecció de versions dins d'un satèl·lit sigui mínima (la qual cosa redueix el nombre total de versions emmagatzemades). ).
A més, per optimitzar el procés de càrrega de dades, sovint s'inclouen atributs obtinguts de diverses fonts en satèl·lits individuals.
Els satèl·lits es comuniquen amb el concentrador mitjançant clau estrangera (que correspon a la cardinalitat 1-a-molts). Això significa que aquesta arquitectura "predeterminada" admet diversos valors d'atribut (per exemple, diversos números de telèfon de contacte per a un client).
В Model d'àncora s'anomenen taules que emmagatzemen claus Àncores. I mantenen:
- Només claus substitutives
- Enllaç a la font
- Registre el temps d'addició
Es consideren claus naturals des del punt de vista del Model Anchor atributs ordinaris. Aquesta opció pot semblar més difícil d'entendre, però ofereix molt més marge per identificar l'objecte.
Per exemple, si les dades sobre la mateixa entitat poden provenir de sistemes diferents, cadascun dels quals utilitza la seva pròpia clau natural. A Data Vault, això pot provocar estructures força feixugues de diversos concentradors (un per font + una versió mestra unificadora), mentre que en el model Anchor, la clau natural de cada font cau en el seu propi atribut i es pot utilitzar quan es carrega de manera independent de tots els altres.
Però aquí hi ha un punt insidios: si els atributs de diferents sistemes es combinen en una entitat, el més probable és que hi hagi alguns. regles d'"enganxament", pel qual el sistema ha d'entendre que els registres de diferents fonts corresponen a una instància de l'entitat.
В Volta de dades molt probablement aquestes regles determinaran la formació "central substitut" de l'entitat mestra i no influir de cap manera en els concentradors que emmagatzemen claus font naturals i els seus atributs originals. Si en algun moment les regles de fusió canvien (o s'actualitzen els atributs pels quals es realitza), n'hi haurà prou amb reformatar els concentradors substitutius.
В Model d'àncora És molt probable que aquesta entitat s'emmagatzemi l'únic àncora. Això vol dir que tots els atributs, independentment de la font que provinguin, estaran vinculats al mateix substitut. Separar registres fusionats erròniament i, en general, controlar la rellevància de la fusió en aquest sistema pot ser molt més difícil, sobretot si les regles són força complexes i canvien amb freqüència, i el mateix atribut es pot obtenir de diferents fonts (tot i que sens dubte és possible, ja que cada versió de l'atribut conserva un enllaç a la seva font).
En qualsevol cas, si se suposa que el vostre sistema implementa la funcionalitat deduplicació, fusió de registres i altres elements MDM, val la pena prestar especial atenció als aspectes d'emmagatzematge de claus naturals en metodologies àgils. És probable que el disseny més voluminós de Data Vault sigui de sobte més segur en termes d'errors de combinació.
Model d'àncora també proporciona un tipus d'objecte addicional anomenat Nus és essencialment especial tipus degenerat d'àncora, que només pot contenir un atribut. Se suposa que els nodes s'utilitzen per emmagatzemar directoris plans (per exemple, gènere, estat civil, categoria d'atenció al client, etc.). A diferència de l'Àncora, el Nus no té taules d'atributs associades, i el seu únic atribut (nom) s'emmagatzema sempre a la mateixa taula amb la clau. Els nodes es connecten a les àncores mitjançant taules d'enllaç (Tie) de la mateixa manera que les àncores es connecten entre si.
No hi ha una opinió clara sobre l'ús de Nodes. Per exemple, , que promou activament l'ús del model d'àncora a Rússia, creu (de manera no raonable) que per ni un sol llibre de referència es pot afirmar amb certesa que sempre serà estàtic i d'un sol nivell, de manera que és millor utilitzar immediatament un àncora complet per a tots els objectes.
Una altra diferència important entre Data Vault i el model Anchor és la disponibilitat atributs de les connexions:
В Volta de dades Els enllaços són els mateixos objectes de ple dret que els concentradors i poden tenir atributs propis. En Model d'àncora Els enllaços només s'utilitzen per connectar àncores i no poden tenir els seus propis atributs. Aquesta diferència dóna lloc a enfocaments de modelització significativament diferents fets, que es tractarà més endavant.
Emmagatzematge de fets
Abans d'això, vam parlar principalment de modelització de mesures. Els fets són una mica menys clars.
В Volta de dades un objecte típic per emmagatzemar fets és Enllaç, als satèl·lits dels quals s'afegeixen indicadors reals.
Aquest enfocament sembla intuïtiu. Proporciona un fàcil accés als indicadors analitzats i, en general, és similar a una taula de fets tradicional (només els indicadors s'emmagatzemen no a la taula en si, sinó a la "veïna"). Però també hi ha inconvenients: una de les modificacions típiques del model -ampliació de la clau de fet- requereix afegint una nova clau estrangera a Link. I això, al seu torn, "trenca" la modularitat i potencialment provoca la necessitat de modificacions a altres objectes.
В Model d'àncora Una connexió no pot tenir els seus propis atributs, de manera que aquest enfocament no funcionarà; absolutament tots els atributs i indicadors han d'estar vinculats a un àncora específic. La conclusió d'això és senzilla: Cada fet també necessita la seva pròpia àncora. Per a alguns dels que estem acostumats a percebre com a fets, això pot semblar natural; per exemple, el fet d'una compra es pot reduir perfectament a l'objecte "comanda" o "rebut", visitar un lloc a una sessió, etc. Però també hi ha fets pels quals no és tan fàcil trobar un "objecte portador" tan natural, per exemple, les restes de mercaderies als magatzems al començament de cada dia.
En conseqüència, no sorgeixen problemes de modularitat quan s'amplia una clau de fet en el model d'àncora (n'hi ha prou amb afegir una nova relació a l'àncora corresponent), però dissenyar un model per mostrar fets és menys inequívoc; poden aparèixer àncores "artificials" que mostren el model d'objectes de negoci d'una manera poc clara.
Com s'aconsegueix la flexibilitat
La construcció resultant en ambdós casos conté significativament més taulesque la mesura tradicional. Però pot trigar molt menys espai al disc amb el mateix conjunt d'atributs versionats que la dimensió tradicional. Naturalment, aquí no hi ha màgia: es tracta de normalització. Mitjançant la distribució d'atributs entre satèl·lits (a la caixa de dades) o taules individuals (model d'ancoratge), reduïm (o eliminem completament) duplicació de valors d'uns atributs en canviar-ne d'altres.
Per Volta de dades els guanys dependran de la distribució d'atributs entre els Satèl·lits, i per Model d'àncora — és gairebé directament proporcional al nombre mitjà de versions per objecte de mesura.
Tanmateix, l'estalvi d'espai és un avantatge important, però no el principal, d'emmagatzemar els atributs per separat. Juntament amb l'emmagatzematge separat de les relacions, aquest enfocament fa que la botiga disseny modular. Això vol dir que afegir atributs individuals i àrees temàtiques noves completes en un model semblant superestructura sobre un conjunt existent d'objectes sense canviar-los. I això és precisament el que flexibilitza les metodologies descrites.
Això també s'assembla a la transició de la producció de peces a la producció en massa: si en l'enfocament tradicional cada taula del model és única i requereix una atenció especial, en les metodologies flexibles ja és un conjunt de "peces" estàndard. D'una banda, hi ha més taules, i els processos de càrrega i recuperació de dades haurien de semblar més complicats. D'altra banda, esdevenen típic. Això vol dir que hi pot haver automatitzat i basat en metadades. La pregunta "com ho posarem?", la resposta a la qual podria ocupar una part important del treball de disseny de millores, ara simplement no val la pena (així com la pregunta sobre l'impacte del canvi de model en els processos de treball). ).
Això no vol dir que els analistes no siguin necessaris en aquest sistema: algú encara necessita treballar amb el conjunt d'objectes amb atributs i esbrinar on i com carregar-ho tot. Però la quantitat de treball, així com la probabilitat i el cost d'un error, es redueixen significativament. Tant en l'etapa d'anàlisi com durant el desenvolupament de l'ETL, que en una part important es pot reduir a l'edició de metadades.
Costat fosc
Tot l'anterior fa que ambdós enfocaments siguin realment flexibles, tecnològicament avançats i adequats per a la millora iterativa. Per descomptat, també hi ha un “barril a la pomada”, que crec que ja podeu endevinar.
La descomposició de dades, que subjau a la modularitat de les arquitectures flexibles, comporta un augment del nombre de taules i, en conseqüència, per sobre a les unions en el mostreig. Per obtenir simplement tots els atributs d'una dimensió, en una botiga clàssica n'hi ha prou amb una selecció, però una arquitectura flexible requerirà tota una sèrie d'unions. A més, si totes aquestes unions per als informes es poden escriure per endavant, els analistes que estan acostumats a escriure SQL a mà patiran doblement.
Hi ha diversos fets que faciliten aquesta situació:
Quan es treballa amb grans dimensions, gairebé mai tots els seus atributs s'utilitzen simultàniament. Això vol dir que pot haver-hi menys unions del que sembla a primera vista el model. Data Vault també pot tenir en compte la freqüència esperada de compartir quan s'assignen atributs als satèl·lits. Al mateix temps, els propis concentradors o àncores es necessiten principalment per generar i mapejar substituts en l'etapa de càrrega i poques vegades s'utilitzen en les consultes (això és especialment cert per a les àncores).
Totes les unions són per clau. A més, una manera més "comprimida" d'emmagatzemar dades redueix la sobrecàrrega de les taules d'escaneig on es necessita (per exemple, quan es filtra per valor d'atribut). Això pot portar al fet que el mostreig d'una base de dades normalitzada amb un munt d'unions serà encara més ràpid que escanejar una dimensió pesada amb moltes versions per fila.
Per exemple, aquí dins L'article conté una prova comparativa detallada del rendiment del model Anchor amb una mostra d'una taula.
Molt depèn del motor. Moltes plataformes modernes tenen mecanismes interns d'optimització d'unions. Per exemple, MS SQL i Oracle poden "ometre" les unions a les taules si les seves dades no s'utilitzen enlloc excepte per a altres unions i no afecten la selecció final (eliminació de taula/join) i MPP Vertica , ha demostrat ser un excel·lent motor per al model Anchor, donada una mica d'optimització manual del pla de consultes. D'altra banda, emmagatzemar el model d'ancoratge, per exemple, a Click House, que té un suport d'unió limitat, encara no sembla una bona idea.
A més, per ambdues arquitectures n'hi ha moviments especials, facilitant l'accés a les dades (tant des del punt de vista del rendiment de la consulta com per als usuaris finals). Per exemple, Taules puntuals a Data Vault o funcions especials de la taula en el model Anchor.
En total
L'essència principal de les arquitectures flexibles considerades és la modularitat del seu "disseny".
És aquesta propietat la que permet:
- Després d'alguna preparació inicial relacionada amb el desplegament de metadades i l'escriptura d'algorismes ETL bàsics, proporcionar ràpidament al client el primer resultat en forma d'un parell d'informes que contenen dades d'uns quants objectes font. No cal pensar completament (fins i tot al nivell superior) tot el model d'objectes.
- Un model de dades pot començar a funcionar (i ser útil) amb només 2-3 objectes, i després créixer gradualment (sobre el model Anchor Nikolai bona comparació amb el miceli).
- La majoria de les millores, inclosa l'ampliació de l'àrea temàtica i l'addició de noves fonts no afecta la funcionalitat existent i no suposa el risc de trencar alguna cosa que ja funciona.
- Gràcies a la descomposició en elements estàndard, els processos ETL en aquests sistemes tenen el mateix aspecte, la seva escriptura es presta a l'algorisme i, en última instància, automatització.
El preu d'aquesta flexibilitat és rendiment. Això no vol dir que sigui impossible aconseguir un rendiment acceptable en aquests models. Molt sovint, és possible que necessiteu més esforç i atenció als detalls per aconseguir les mètriques que voleu.
Aplicacions
Tipus d'entitats Volta de dades
Més informació sobre Data Vault:
Tipus d'entitats Model d'àncora
Més detalls sobre el model d'àncora:
Taula resum amb característiques comunes i diferències dels enfocaments considerats:
Font: www.habr.com