Come condividere i dati all'interno di un'organizzazione

Question

Quali sono alcuni modi efficaci con cui un'organizzazione può condividere i dati chiave tra più dipartimenti e applicazioni?

Per fare un esempio, supponiamo che esista un'applicazione principale e un database per gestire i dati dei clienti.Nell'organizzazione sono presenti altre dieci applicazioni e database che leggono tali dati e li collegano ai propri dati.Attualmente questa condivisione dei dati avviene attraverso una combinazione di collegamenti a database (DB), viste materializzate, trigger, tabelle di staging, informazioni sulla ricodifica delle chiavi, servizi web, ecc.

Esistono altri approcci validi per la condivisione dei dati?E come si confrontano i tuoi approcci con quelli di cui sopra rispetto a preoccupazioni come:

dati duplicati

processi di sincronizzazione dei dati soggetti a errori

stretto controaccoppiamento lento (riduzione delle dipendenze/fragilità/coordinamento dei test)

semplificazione architettonica

sicurezza

prestazione

interfacce ben definite

altre preoccupazioni rilevanti?

Tieni presente che i dati condivisi dei clienti vengono utilizzati in molti modi, da semplici query a record singolo a unioni complesse, multi-predicato e multi-ordinamento con altri dati dell'organizzazione archiviati in database diversi.

Grazie per i vostri suggerimenti e consigli...

Answer 1

Sono sicuro che l'avevi previsto, "Dipende".

Dipende da tutto.E la soluzione per condividere i dati del cliente per il dipartimento A potrebbe essere completamente diversa per condividere i dati del cliente con il dipartimento B.

Il mio concetto preferito che è emerso nel corso degli anni è il concetto di "Coerenza Eventuale".Il termine deriva da Amazon che parla di sistemi distribuiti.

La premessa è che, anche se lo stato dei dati in un'azienda distribuita potrebbe non essere perfettamente coerente ora, "prima o poi" lo sarà.

Ad esempio, quando il record di un cliente viene aggiornato sul sistema A, i dati del cliente del sistema B ora sono obsoleti e non corrispondono.Ma, "alla fine", il record di A verrà inviato a B attraverso qualche processo.Quindi, alla fine, le due istanze corrisponderanno.

Quando lavori con un singolo sistema, non hai "EC", ma hai aggiornamenti istantanei, un'unica "fonte di verità" e, in genere, un meccanismo di blocco per gestire condizioni di competizione e conflitti.

Quanto più le vostre operazioni sono in grado di lavorare con i dati "CE", tanto più facile sarà separare questi sistemi.Un semplice esempio è un Data Warehouse utilizzato dalle vendite.Usano il DW per eseguire i loro report giornalieri, ma non li eseguono fino al mattino presto e guardano sempre i dati di "ieri" (o precedenti).Quindi non è necessario che il DW sia perfettamente coerente in tempo reale con il sistema operativo quotidiano.È perfettamente accettabile che un processo venga eseguito, ad esempio, alla chiusura dell'attività e sposti nel corso dei giorni transazioni e attività in massa in un'unica operazione di aggiornamento di grandi dimensioni.

Puoi vedere come questo requisito può risolvere molti problemi.Non vi è alcuna contesa per i dati transazionali, nessuna preoccupazione che i dati di alcuni report cambino nel corso dell'accumulo delle statistiche perché il report ha effettuato due query separate al database attivo.Non è necessario che le chiacchiere ad alto dettaglio risucchino l'elaborazione della rete e della CPU, ecc.durante il giorno.

Ora, questo è un esempio estremo, semplificato e molto grossolano di EC.

Ma considera un sistema grande come Google.Come consumatori della ricerca, non abbiamo idea di quando o quanto tempo impiega un risultato di ricerca raccolto da Google a comparire in una pagina di ricerca.1ms?1 secondo?10 secondi?10 ore?È facile immaginare come se colpisci i server di Google della costa occidentale, potresti benissimo ottenere un risultato di ricerca diverso rispetto a quello che otterresti se colpisci i loro server della costa orientale.In nessun momento questi due casi sono completamente coerenti.Ma in larga misura, sono per lo più coerenti.E per quanto riguarda il loro caso d'uso, i consumatori non sono realmente colpiti dal ritardo.

Considera l'e-mail.A vuole inviare un messaggio a B, ma nel processo il messaggio viene instradato attraverso i sistemi C, D ed E.Ogni sistema accetta il messaggio, se ne assume la completa responsabilità e poi lo trasmette a un altro.Il mittente vede l'e-mail andare avanti.Il ricevente non se ne accorge davvero perché non necessariamente sa che sta arrivando.Quindi, c'è una grande finestra di tempo necessaria affinché il messaggio si muova attraverso il sistema senza che nessuno sappia o si preoccupi di quanto velocemente sia.

D’altronde A avrebbe potuto essere al telefono con B."L'ho appena inviato, l'hai già ricevuto?Ora?Ora?Scaricalo ora?"

Pertanto, esiste una sorta di livello implicito e sottostante di prestazione e risposta.Alla fine, "alla fine", la posta in uscita di A corrisponde alla posta in arrivo di B.

Questi ritardi, l'accettazione di dati obsoleti, vecchi di un giorno o di 1-5 secondi, sono ciò che controlla l'accoppiamento finale dei tuoi sistemi.Quanto più allentato è questo requisito, tanto più allentato è l'accoppiamento e maggiore è la flessibilità a disposizione in termini di progettazione.

Questo è vero fino ai core della tua CPU.Le applicazioni moderne, multi core e multi thread in esecuzione sullo stesso sistema possono avere visualizzazioni diverse degli "stessi" dati, obsolete solo di microsecondi.Se il tuo codice può funzionare correttamente con dati potenzialmente incoerenti tra loro, allora buon giorno, tutto procede.In caso contrario, è necessario prestare particolare attenzione per garantire che i dati siano completamente coerenti, utilizzando tecniche come qualificazione della memoria volatile o costrutti di blocco, ecc.Tutto ciò, a modo suo, costa le prestazioni.

Quindi questa è la considerazione di base.Tutte le altre decisioni iniziano da qui.Rispondere a questa domanda può dirti come partizionare le applicazioni tra macchine, quali risorse sono condivise e come sono condivise.Quali protocolli e tecniche sono disponibili per spostare i dati e quanto costerà in termini di elaborazione per eseguire il trasferimento.Replica, bilanciamento del carico, condivisione dei dati, ecc.eccetera.Tutto basato su questo concetto.

Modifica, in risposta al primo commento.

Esatto, esatto.Nel gioco qui, ad esempio, se B non può modificare i dati del cliente, qual è il danno con i dati del cliente modificati?Puoi "rischiare" che non sia aggiornato per un breve periodo?Forse i dati dei tuoi clienti arrivano abbastanza lentamente da poterli replicare immediatamente da A a B.Supponiamo che la modifica venga messa in coda che, a causa del volume basso, viene ritirata prontamente (< 1 s), ma anche in questo caso sarebbe "fuori transazione" con la modifica originale, e quindi c'è una piccola finestra in cui A avrebbe dati che B non conosce.

Ora la mente inizia davvero a girare.Cosa succede durante quegli 1 secondo di "lag", qual è lo scenario peggiore possibile.E puoi ingegnerizzarlo?Se riesci a progettare con un ritardo di 1 secondo, potresti essere in grado di progettare con un ritardo di 5 secondi, 1 metro o anche più lungo.Quanti dati dei clienti utilizzi effettivamente su B?Forse B è un sistema progettato per facilitare il prelievo degli ordini dall'inventario.Difficile immaginare che sia necessario qualcosa di più del semplice ID cliente e forse un nome.Solo qualcosa per identificare grossolanamente a chi è destinato l'ordine mentre viene assemblato.

Il sistema di prelievo non ha necessariamente bisogno di stampare tutte le informazioni del cliente fino alla fine del processo di prelievo, e a quel punto l'ordine potrebbe essere passato a un altro sistema che forse è più aggiornato, in particolare, con le informazioni di spedizione, quindi alla fine il sistema di picking non ha quasi bisogno dei dati del cliente.In effetti, potresti INcorporare e denormalizzare le informazioni del cliente all'interno dell'ordine di prelievo, quindi non c'è necessità o aspettativa di sincronizzazione in un secondo momento.Finché l'ID cliente è corretto (che comunque non cambierà mai) e il nome (che cambia così raramente che non vale la pena discuterne), questo è l'unico riferimento reale di cui hai bisogno e tutti i tuoi fogli di prelievo sono perfettamente accurati al momento del creazione.

Il trucco sta nella mentalità di scomporre i sistemi e concentrarsi sui dati essenziali necessari per l'attività.I dati che non ti servono non devono essere replicati o sincronizzati.Le persone si irritano per cose come la denormalizzazione e la riduzione dei dati, soprattutto quando provengono dal mondo della modellazione relazionale dei dati.E con buona ragione, dovrebbe essere considerato con cautela.Ma una volta distribuito, sei implicitamente denormalizzato.Cavolo, lo stai copiando all'ingrosso adesso.Quindi potresti anche essere più intelligente al riguardo.

Tutto ciò può essere mitigato attraverso procedure solide e una conoscenza approfondita del flusso di lavoro.Identificare i rischi ed elaborare politiche e procedure per gestirli.

Ma la parte difficile è spezzare la catena del DB centrale all'inizio e istruire le persone che non possono "avere tutto" come potrebbero aspettarsi quando si dispone di un unico archivio di informazioni centrale e perfetto.

Answer 2

Questa non è sicuramente una risposta esauriente. Siamo spiacenti, per il mio lungo post e spero che aggiunge a pensieri che sarebbero presentati qui.

Ho un paio di osservazioni su alcuni degli aspetti che lei ha citato.

duplicate data

E 'stata la mia esperienza che questo è di solito un effetto collaterale di dipartimentalizzazione o di specializzazione. Una collezione reparto pionieri di alcuni dati che è visto come utile da altri gruppi specializzati. Dal momento che non hanno accesso esclusivo a questi dati in quanto è mescolata con altri la raccolta dei dati, al fine di utilizzarlo, anche loro si avvia la raccolta / archiviazione dei dati, il che rende intrinsecamente duplicato. Questo problema non passa mai e proprio come ci sia uno sforzo continuo di refactoring del codice e la rimozione di duplicazione, v'è la necessità di portare continuamente i dati duplicati per l'accesso centralizzato, lo stoccaggio e la modifica.

well-defined interfaces

La maggior parte delle interfacce sono definite con buona intenzione mantenere altri vincoli in mente. Tuttavia, abbiamo semplicemente l'abitudine di crescente delle limitazioni poste dalle interfacce definite in precedenza. Ancora una volta un caso di continuo il refactoring.

tight coupling vs loose coupling

Se una qualsiasi cosa, la maggior parte del software è afflitto da questo problema. L'accoppiamento stretto è di solito un risultato di soluzione utile dato il vincolo di tempo ci troviamo di fronte. accoppiamento lasco comporta un certo grado di complessità, che non ci piace quando vogliamo fare le cose. I servizi Web mantra è andata giri per un certo numero di anni e devo ancora vedere un buon esempio di soluzione che allevia completamente il punto

architectural simplification

Per me questa è la chiave per la lotta contro tutti i problemi che hai menzionato nella sua interrogazione. SIP vs storia VoIP H.323 viene in mente. SIP è molto semplificato, facile da costruire, mentre H.323 come un tipico standard di telecomunicazioni ha cercato di prevedere ogni questione sul pianeta sul VoIP e di fornire una soluzione per esso. Risultato finale, SIP è cresciuto molto più rapidamente. E 'un dolore per essere H.323 soluzione compatibile. In realtà, H.323 la conformità è un settore mega dollaro.

On a few architectural fads that I have grown up to.

Nel corso degli anni, ho iniziato a come l'architettura REST per la sua semplicità. Esso fornisce un semplice accesso unico ai dati e alle applicazioni di facile costruire intorno ad esso. Ho visto soluzione aziendale soffrire di più dalla duplicazione, l'isolamento e l'accesso dei dati rispetto a qualsiasi altra questione come prestazioni ecc resto a me fornisce una panacea per alcuni di questi mali.

Answer 3

Per risolvere un certo numero di questi problemi, mi piace il concetto di centro "Data Hub". Un Data Hub rappresenta una "singola fonte di verità" per una particolare entità, ma solo memorizza gli ID, nessuna informazione come i nomi ecc, infatti, solo i negozi ID mappe - per esempio, questi mappa l'ID cliente nel sistema A, al Cliente Numero dal sistema B, e al cliente nel sistema di C. interfacce tra i sistemi utilizzano l'hub per sapere come relazionarsi informazioni in un sistema all'altro.

E 'come traduzione centrale; invece di dover scrivere codice specifico per la mappatura da A-> B, A-> C, e B-> C, con il suo incremento esponenziale presenze quando si aggiungono più sistemi, avete solo bisogno di convertire da / per l'hub: A- > Hub, B-> Hub, C-> Hub, D-> Hub, ecc.