Cómo compartir datos a través de una organización

Question

¿Cuáles son algunas maneras buenas para una organización para compartir datos clave a través de muchos deparments y aplicaciones?

Para dar un ejemplo, digamos que es una aplicación primaria y base de datos para gestionar datos de clientes. Hay diez otras aplicaciones y bases de datos de la organización que leen los datos y lo relacionan con sus propios datos. Actualmente este intercambio de datos se realiza a través de una mezcla de enlaces de base de datos (DB), materializado vistas, disparadores, puesta en escena mesas, volver a introducir información, servicios web, etc.

¿Hay enfoques cualquier otro bien para el intercambio de datos? Y, ¿cómo se comparan sus enfoques a los anteriormente con respecto a las preocupaciones como:

los datos duplicados

error propenso procesos de sincronización de datos

apretada contra la articulación flexible (reduciendo la coordinación dependencias / fragilidad / prueba)

simplificación de arquitectura

Seguridad

Rendimiento

interfaces bien definidas

otras preocupaciones pertinentes?

Tenga en cuenta que los datos del cliente compartida se utiliza de muchas maneras, desde la simple, solo registro de consultas al complejo, multi-predicado, multi-especie, se une con otros datos de la organización almacenados en diferentes bases de datos.

Gracias por sus sugerencias y consejos ...

    

Answer 1

Estoy seguro de que lo vio venir, "depende".

Depende de todo. Y la solución para el intercambio de datos de clientes para el departamento de A puede ser completamente diferente para el intercambio de datos de clientes con el departamento B.

Mi concepto favorito que se ha levantado en los últimos años es el concepto de "consistencia eventual". El término proviene de Amazon hablando de sistemas distribuidos.

La premisa es que si bien el estado de los datos a través de una empresa distribuida puede no ser perfectamente coherente ahora, "con el tiempo" será.

Por ejemplo, cuando un registro de cliente se actualiza en el sistema A, datos de clientes del sistema de B es ahora obsoleto y que no coincida. Pero, "con el tiempo", el registro de la A se enviará a B a través de algún proceso. Así, con el tiempo, los dos casos coincidirán.

Cuando se trabaja con un único sistema, que no tiene "CE", en lugar usted tiene actualizaciones instantáneas, una única "fuente de la verdad", y, por lo general, un mecanismo de bloqueo a las condiciones de carrera mango y conflictos.

Cuanto más capaces sus operaciones son capaces de trabajar con datos "CE", más fácil es separar estos sistemas. Un ejemplo sencillo es un almacén de datos utilizado por las ventas. Utilizan el DW para ejecutar sus informes diarios, pero que no se ejecutan sus informes hasta la madrugada, y siempre miran "ayeres" (o antes) de datos. Así que no hay necesidad real de tiempo para que el DW para ser perfectamente compatible con el sistema de operaciones de cada día. Es perfectamente aceptable que un proceso se ejecute en, por ejemplo, cerca de los negocios y se mueven sobre las transacciones y actividades en masa en una operación de actualización grande, solo días.

Se puede ver cómo este requisito puede resolver un montón de problemas. No hay competencia por los datos de las transacciones, no hay preocupaciones de que algunos informes de datos va a cambiar en el medio de la acumulación de la estadística porque el informe hace dos consultas individuales a la base de datos activa. No hay necesidad para el alto detalle charla succionar procesamiento de la red y la CPU, etc., durante el día.

Ahora, que es un extremo, simplificado, y un ejemplo muy gruesa de la CE.

Pero considere un sistema grande como Google. Como consumidor de búsqueda, no tenemos idea de cuándo o cuánto tiempo se necesita para obtener un resultado de búsqueda que las cosechas de Google a la forma arriba en una página de búsqueda. 1 ms? 1s? 10s? 10hrs? Es fácil de imagen cómo, si usted está golpeando los servidores de Google de la Costa Oeste, que muy bien puede obtener un resultado de búsqueda diferente que si se golpea sus servidores de la Costa Este. En ningún momento son estos dos casos completamente consistente. Pero por gran medida, en su mayoría son consistentes. Y por su caso de uso, sus consumidores no están muy afectados por el retraso y el retraso.

Tenga en cuenta de correo electrónico. A quiere enviar un mensaje a B, pero en el proceso el mensaje se enruta a través del sistema C, D y E. Cada sistema acepta el mensaje, asumen la responsabilidad completa de ella, y luego se lo da a otra. El emisor ve la marcha de correo electrónico en su camino. El receptor en realidad no lo pierda porque no saben necesariamente su entrada. Por lo tanto, hay una gran ventana de tiempo que puede tomar para que el mensaje se mueva a través del sistema sin que nadie se trate saber o preocuparse acerca de lo rápido que es.

Por otra parte, podría haber un estado en el teléfono con B. "Sólo envié, lo has conseguido todavía? Ahora? Ahora? Consíguelo ahora?"

Por lo tanto, hay algún tipo de subyacente, el nivel implícito de actuación y respuesta. Al final, "con el tiempo", bandeja de salida de una bandeja de entrada coincide B.

Estos retrasos, la aceptación de datos obsoletos, si es un día de vida o 1-5s de edad, son los que controlan el acoplamiento final de sus sistemas. El más flojo este requisito, el más flojo del acoplamiento, y la mayor flexibilidad que tiene a su disposición en términos de diseño.

Esto es cierto hasta los núcleos de la CPU. de núcleo múltiple, aplicaciones modernas, multi-hilo que se ejecutan en el mismo sistema, pueden tener diferentes puntos de vista de los "mismos" los datos, sólo microsegundos de retraso. Si su código puede funcionar correctamente con los datos potentiaLLY inconsistentes entre sí los días, entonces feliz, cremalleras a lo largo. Si no es necesario prestar especial atención a garantizar que sus datos están completamente consistente, utilizando técnicas como la califica de memoria volátil o bloqueo construcciones, etc. Todo lo cual, a su manera, funcionamiento de coste.

Por lo tanto, esta es la consideración de base. Todas las demás decisiones de empezar aquí. Para responder a esta le puede decir cómo las aplicaciones de partición a través de las máquinas, lo que recursos son compartidos, y la forma en que son compartidos. ¿Qué protocolos y técnicas están disponibles para mover los datos, y cuánto va a costar en términos de procesamiento para realizar la transferencia. Replicación, balanceo de carga, las acciones de datos, etc, etc Todos basa en este concepto.

Editar, en respuesta al primer comentario.

Así es, exactamente. El juego aquí, por ejemplo, si B no puede cambiar los datos del cliente, entonces ¿cuál es el daño con los datos del cliente ha cambiado? ¿Puede usted "riesgo" que estar fuera de fecha para un corto período de tiempo? Tal vez sus datos de cliente entra en juego lo suficientemente lento que se puede replicar de A a B de inmediato. Dicen que el cambio se pone en una cola que, debido a la baja el volumen, es recogido fácilmente (<1s), pero aún así sería "fuera de transacción" con el cambio original, por lo que hay una pequeña ventana en la que A tendría datos que B no.

Ahora la mente realmente comienza a girar. Lo que sucede durante ese 1s de "retraso", cuál es el peor escenario posible. Y se puede diseñar a su alrededor? Si se puede diseñar en torno a 1s Lag, que puede ser capaz de diseñar en torno a un 5 s, 1 m, o incluso más tiempo de retraso. ¿Qué parte de los datos de los clientes es lo que realmente se utilicen en B? Tal vez B es un sistema diseñado para facilitar la preparación de pedidos de inventario. Es difícil imaginar algo más que simplemente siendo necesario un ID de cliente y tal vez un nombre. Sólo algo para identificar groseramente que la orden es para mientras está siendo ensamblado.

El sistema de recogida no necesariamente tienen que imprimir toda la información de los clientes hasta el final del proceso de picking, y para entonces la orden pudo haber pasado a otro sistema que tal vez es más actual con, sobre todo, el envío información, por lo que al final el sistema de preparación no necesita casi ningún datos de los clientes en absoluto. De hecho, se podría incrustar y desnormalizar la información de los clientes dentro de la preparación de pedidos, así que no hay necesidad o expectativa de sincronizar más tarde. Mientras el ID de cliente es correcta (que nunca va a cambiar de todos modos) y el nombre (que cambia con tan poca frecuencia que no vale la pena discutir), que es la única referencia real que necesita, y todos sus recibos de recogida son muy exactos en el momento de la creación.

El truco está en el modo de pensar, de romper los sistemas y centrándose en los datos esenciales que es necesario para la tarea. Los datos que no es necesario no necesita ser replicados o sincronizada. La gente se irritan las cosas como desnormalización y reducción de datos, especialmente cuando están en el mundo del modelaje de datos relacional. Y con buena razón, debe considerarse con precaución. Pero una vez que vaya distribuida, que ha desnormalizado implícita. Heck, que está copiando al por mayor ahora. Por lo tanto, es posible que también sea más inteligente al respecto.

Todo esto puede mitigarse mediante procedimientos sólidos y conocimiento profundo de flujo de trabajo. Identificar los riesgos y trabajar hasta las políticas y procedimientos para manejarlos.

Sin embargo, la parte difícil es romper la cadena de la BD central al principio, e instruir a la gente de que no pueden "tenerlo todo", como que pueden esperar cuando se tiene una sola tienda perfecta, central, de la información.

Answer 2

Esto definitivamente no es una respuesta completa. Lo siento, para mi post largo y espero que se suma a los pensamientos que se presentan aquí.

Tengo algunas observaciones sobre algunos de los aspectos que usted ha mencionado.

duplicate data

Ha sido mi experiencia que esto suele ser un efecto secundario de la departamentalización o especialización. Una colección pioneros departamento de ciertos datos que se considera como útil por otros grupos especializados. Puesto que no tienen acceso exclusivo a estos datos, ya que se entremezcla con otras recopilaciones de datos, con el fin de utilizarlo, ellos también comenzar a recoger / almacenar los datos, por lo que intrínsecamente se duplica. Este problema nunca desaparece y al igual que hay un esfuerzo continuo en la refactorización de código y la eliminación de la duplicación, existe la necesidad de llevar continuamente los datos duplicados para el acceso centralizado, almacenamiento y modificación.

well-defined interfaces

La mayoría de las interfaces se definen con buena intención mantener otras limitaciones en mente. Sin embargo, simplemente no tenemos el hábito de crecimiento de las restricciones impuestas por las interfaces definidas previamente. De nuevo un caso para continuo refactorización.

tight coupling vs loose coupling

Si cualquier cosa, la mayoría del software está plagada de este problema. El estrecho acoplamiento es generalmente el resultado de la solución conveniente dada la limitación de tiempo que nos enfrentamos. la articulación flexible incurre en un cierto grado de complejidad, que no nos gusta cuando queremos hacer las cosas. El mantra servicios web ha estado pasando rondas para un número de años y todavía estoy de ver un buen ejemplo de solución que alivia por completo el punto

architectural simplification

Para mí esta es la clave para luchar contra todas las cuestiones que usted ha mencionado en su pregunta. SIP vs historia VoIP H.323 viene a la mente. SIP es muy simplificado, fácil de construir, mientras que H.323 como un estándar de telecomunicaciones típica trató de prever todos los problemas en el planeta sobre VoIP y proporcionar una solución para ello. resultado final, SIP creció mucho más rápidamente. Es un dolor para ser compatible con H.323 solución. De hecho, el cumplimiento H.323 es una industria de mega inversión.

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

Durante años, he empezado a como la arquitectura REST para su simplicidad. Proporciona un simple acceso único a los datos y aplicaciones fáciles de construir a su alrededor. He visto solución empresarial sufren más de la duplicación, el aislamiento y el acceso de los datos que cualquier otro tema como el rendimiento, etc. RESTO me proporciona una panacea para algunos de esos males.

Answer 3

Para resolver algunos de estos problemas, me gusta el concepto de central "concentradores de datos". Un concentrador de datos representa una "única fuente de verdad" para una entidad en particular, pero sólo almacena los identificadores, no hay información como nombres etc. De hecho, sólo almacena los mapas de Identificación - por ejemplo, éstos correlacionar el ID de cliente en el sistema A, a la Número de cliente del sistema B, y el número de cliente en el sistema C. interfaces entre los sistemas utilizan el centro para saber cómo relacionar la información de un sistema a otro.

Es como una central de traducción; en lugar de tener que escribir código específico para el mapeo de A-> B, A-> C, y B> C, con su aumento exponencial de asistencia a medida que añada más sistemas, sólo es necesario para convertir a / desde el centro de: A- > Hub, B-> Hub, C-> Hub, D-> Hub, etc.