Plataforma de datos - Plataforma de datos descentralizada
Utiliza un data lakehouse para recopilar y analizar datos de eventos y transmisión de dispositivos en tiempo real y correlacionarlos con una amplia gama de recursos de datos empresariales para obtener la información que deseas.
¿Cuál es la mejor manera de respaldar y potenciar a los distintos equipos de su organización, como marketing, finanzas o logística, con la flexibilidad necesaria para trabajar con datos específicos de dominio y, al mismo tiempo, permitir el uso compartido y el consumo seguros de datos entre dominios sin duplicar datos y crear silos de datos?
Adopte una arquitectura de datos basada en dominios que proporcione a los equipos y departamentos de toda la organización la agilidad y flexibilidad necesarias para utilizar eficazmente sus datos y desarrollar los productos de datos esenciales para su negocio.
Esta arquitectura de referencia posiciona la solución tecnológica dentro del contexto empresarial general, donde las intenciones estratégicas impulsan la creación de resultados estratégicos medibles. Estos resultados generan nuevas intenciones estratégicas, ofreciendo de forma eficaz mejoras empresariales continuas y basadas en datos.
Cada dominio sigue de forma independiente el proceso de alto nivel mostrado anteriormente para crear sus productos de datos de dominio. Las arquitecturas de datos basadas en dominios proporcionan la flexibilidad que requieren las organizaciones al evitar depender de un único punto de conflicto, como una plataforma de datos totalmente centralizada y un equipo de TI, y al fomentar la innovación ágil para producir productos de datos de confianza dentro de cada dominio.
visión general de la plataforma de datos descentralizada-oracle.zip
El objetivo de cada dominio es adquirir datos relacionados con el dominio y, a continuación, producir productos de datos que sean consumidos por otros dominios o consumidores finales de datos.
Los dominios pueden ser:
- Alineado con origen: obtiene datos directamente de orígenes de datos de dominio relevantes, como aplicaciones empresariales, y produce productos de datos que son consumidos por dominios agregados o alineados con el consumidor. Estos productos de datos representan la fuente de datos para un dominio concreto. Los datos son granulares, seleccionados y fundamentales dentro y entre dominios.
- Agregado: Consume y combina datos alineados con el origen, creando productos de datos agregados y de valor añadido que fomentan la reutilización, reducen la duplicación y comprenden la lógica empresarial fundamental necesaria para los dominios alineados con el consumidor.
- Alineado por el consumidor: Consume datos de dominios agregados y alineados con el origen para crear productos de datos que atiendan casos de uso específicos y aborden las necesidades del consumidor de datos dentro de un dominio determinado.
Los equipos de dominio de datos y sus expertos en la materia (PYME) tienen la flexibilidad de elegir la tecnología necesaria para curar sus productos de datos, reduciendo la fricción y la complejidad de los procesos de selección de tecnología largos y reduciendo el tiempo para entregar productos de datos.
La tecnología elegida se suele determinar a nivel empresarial para que cumpla los requisitos de seguridad, escalabilidad, resiliencia y alta disponibilidad. Esta arquitectura supone que cualquier servicio de Oracle Cloud Infrastructure (OCI) utilizado con un data lakehouse puede ser aprovechado por cualquier dominio.
Los equipos de dominios de datos a menudo utilizan la automatización para desplegar arquetipos de dominio, lo que hace que las tecnologías preconfiguradas estén disponibles para incorporar rápidamente nuevos dominios y, al mismo tiempo, garantiza que se apliquen los requisitos de nivel empresarial, como la seguridad.
Una vez creados, los productos de datos se sirven a otros dominios o usuarios finales y aplicaciones. Los productos de datos se seleccionan continuamente para proporcionar información e información.
- Juegos de datos
- API
- Paneles de control
- Flujos
- Modelos de IA y machine learning (ML) que abordan una necesidad específica
Esta arquitectura de referencia utiliza principalmente el uso compartido de datos como mecanismo subyacente para proporcionar y consumir productos de datos entre dominios.
Oracle Autonomous Data Warehouse permite compartir datos y compartir datos en directo entre instancias de Autonomous Data Warehouse o con datos versionados de cualquier tecnología que sea compatible con el protocolo abierto Delta Sharing.
Arquitectura funcional
Esta arquitectura representa una plataforma descentralizada donde cada dominio es un subconjunto de la plataforma de datos general y donde cada dominio puede elegir las tecnologías y servicios utilizados.
La arquitectura utiliza un data lakehouse para almacenar y proporcionar datos, independientemente de su forma o forma. Por simplicidad, la arquitectura representará algunos dominios que utilizan un subconjunto de los servicios de Data Lakehouse disponibles.
Una plataforma de datos descentralizada que utiliza una arquitectura de data lakehouse proporciona:
- Una arquitectura de lakehouse interoperable y modular en la que los dominios de datos pueden ingerir y curar cualquier tipo de datos para cualquier caso de uso
- Flexibilidad para que cada dominio de datos utilice los servicios de Oracle Cloud Infrastructure (OCI) necesarios para soportar la creación de sus productos de datos
- Selección de productos de datos que se pueden compartir de forma segura mediante el uso compartido de datos, la transmisión, las API, los paneles de control o las aplicaciones
- Agilidad en la creación de productos de datos, reduciendo las dependencias entre dominios, excepto las necesarias para el intercambio de productos de datos
- Aumento del aislamiento del dominio de datos y reducción de la complejidad del intercambio de datos mediante el uso de mecanismos y contratos de intercambio de datos aceptados para intercambiar datos entre dominios
- Aumento de la gobernanza y la confianza de los datos gracias a que expertos en la materia (PYME) cualificados recopilan datos y productos de datos para sus dominios
- Facilidad de incorporación de nuevos dominios de datos mediante el uso de infraestructura como código (IaC) para automatizar el despliegue mediante pilas de Terraform predefinidas y probadas
- Rentabilidad de recursos y costos a medida que los equipos de dominio de datos ajustan el tamaño de los servicios específicos que utilizan para crear productos de datos
- Responsabilidad de costos adecuada para cada dominio de datos con la opción de control de costos detallado dentro de los dominios específicos
El siguiente diagrama ilustra la arquitectura funcional. Por motivos de simplicidad, solo se muestran cuatro dominios de datos y solo se muestran algunas de las capacidades de Data Lakehouse que pueden utilizar los dominios de datos.
descentralized-data-platform-logical-oracle.zip
Debido a que la industria y la organización en particular que despliega una plataforma de datos descentralizada determina los dominios de datos, esta arquitectura de referencia no prescribe cómo se deben definir los dominios de datos. Los dominios de datos representados son solo un ejemplo.
La arquitectura se centra en las siguientes divisiones lógicas utilizadas por todos los dominios:
- Conexión, ingestión, transformación
Se conecta a orígenes de datos e ingiere y acota sus datos para su uso en cada una de las capas de datos de la arquitectura.
Los dominios de datos alineados con el origen obtienen datos de orígenes de datos internos y externos y de otros dominios que consumen sus productos de datos. Los dominios de datos agregados y alineados con el consumidor suelen obtener sus datos de otros productos de datos de dominios. Todos los dominios pueden obtener datos de dominio relevantes de orígenes externos.
- Persistir, curar, crear
Facilita el acceso y la navegación de los datos para mostrar la vista de negocio actual. Para las tecnologías relacionales, los datos pueden estar estructurados lógica o físicamente en formas relacionales simples, longitudinales, dimensionales o OLAP. Para los datos no relacionales, esta capa contiene uno o más pools de datos, ya sea la salida de un proceso analítico o los datos optimizados para una tarea analítica específica.
En esta capa, cada dominio de datos cura los datos que utiliza para crear y exponer productos de datos. Por lo general, los datos se curan y organizan utilizando una arquitectura de medallón que promueve datos de bronce, plata, oro, según su valor y calidad.
Los productos de datos a menudo sirven datos que están en la capa dorada o plateada. Si el producto de datos proporciona datos granulares, esos datos se proporcionan desde la capa de plata. Si el producto de datos proporciona datos que se agregan o que ya son un juego de datos aumentado adicional, esos datos generalmente se proporcionan desde la capa principal.
- Análisis, aprendizaje y predicción
Abstrae la vista lógica de negocio de los datos para los consumidores. Esta abstracción facilita los enfoques ágiles de desarrollo, la migración a la arquitectura de destino y el suministro de una única capa de informes desde varios orígenes de datos.
Cada dominio de datos suele tener sus propios consumidores de datos, como usuarios de dominio, aplicaciones o sistemas que consumen datos seleccionados en forma de paneles de control, aplicaciones de datos, flujos o API.
Los dominios de datos pueden servir productos de datos a otros dominios de datos y dentro de su propio dominio como una forma de organizar el uso compartido de datos entre proyectos.
La arquitectura tiene las siguientes características funcionales:
- Se representan cuatro dominios de datos. Cada dominio selecciona datos específicos de ese dominio, crea productos de datos basados en esos datos seleccionados y, a continuación, los comparte con otros dominios de la organización o con entidades externas.
- Los dominios pueden obtener datos de orígenes de datos internos, productos de datos seleccionados por otros dominios o datos compartidos por entidades externas.
- Los dominios de cliente y finanzas son dominios alineados con el origen que ingieren y curan datos de sistemas internos, tienen sus propios usuarios y curan productos de datos para servir a otros dominios.
- El dominio Riesgo es un dominio agregado que obtiene datos de los dominios Cliente y Finanzas para obtener perfiles de Cliente y transacciones financieras aumentadas, respectivamente. Estos datos se utilizan para crear y entrenar modelos de riesgo de aprendizaje automático (AA) e indicadores clave de rendimiento (KPI) que utilizan los paneles de control y que se comparten con el dominio de marketing.
- El dominio Marketing es un dominio alineado con el consumidor que obtiene perfiles de cliente y datos de propensión al riesgo de los dominios Cliente y Riesgo exclusivamente. Este dominio crea modelos de ML de segmentación que determinan las mejores ofertas personalizadas. Se ponen a disposición de las aplicaciones internas mediante el uso de API de inferencia y los resultados de inferencia por lotes se comparten como producto de datos a los partners que ejecutan campañas de salida.
- Todos los dominios comparten un catálogo de datos común que contiene información sobre sus activos de datos, entidades de datos y glosarios de negocio.
- Cada equipo de dominio de datos y sus propietarios de productos de datos mantienen sus objetos de catálogo de datos específicos. El aislamiento de seguridad se garantiza mediante políticas de Oracle Cloud Infrastructure Identity and Access Management que definen qué equipo puede gestionar qué entidades del catálogo de datos.
- Las entidades comunes del catálogo de datos, como los términos del glosario de negocio que se utilizan en toda la organización, las mantiene un cuerpo de gobernanza de datos compuesto por todos los propietarios de productos de dominio.
- Los productos de datos se marcan en el catálogo de datos para que se puedan buscar, contengan su propia semántica y estén relacionados con el glosario de negocio.
- El uso compartido de datos se utiliza para compartir productos de datos en directo o versionados entre dominios. La elección de utilizar productos de datos en directo o con versiones depende de cada producto de datos y caso de uso.
Los principales componentes funcionales de la arquitectura son:
- Dominios alineados con el origen: cliente y finanzas
Estos dominios se centran en la selección de datos de clientes y finanzas que se derivan de datos estructurados y no estructurados.
El dominio de cliente utiliza las siguientes capacidades para crear un producto de datos de perfiles de cliente:
- Ingesta por lotes (Oracle Cloud Infrastructure Data Integration): ingiere datos de CRM, sitios web y aplicaciones orientadas al cliente.
- Procesamiento por lotes (Oracle Cloud Infrastructure Data Integration, Oracle Cloud Infrastructure Data Flow): procesa datos estructurados y no estructurados mediante ELT con poco código, ETL centrada en código o ambos, para crear productos de datos de perfiles de cliente.
- Servicio (Oracle Autonomous Data Warehouse): selecciona y proporciona datos de perfiles de cliente a los dominios de riesgo y marketing.
- Cloud Storage/Data Lake (Oracle Cloud Infrastructure Object Storage): almacena documentos, contratos o formularios de clientes.
- Visualizar/aprender (Oracle Analytics Cloud): sirve a los usuarios finales de dominio de análisis aumentados, incluidos los KPI relacionados con el cliente, como el valor de tiempo de vida (LTV), la tasa de retención, la puntuación de satisfacción del cliente (CSAT) y la puntuación neta del promotor (NPS).
- AI y servicios de IA generativa: Oracle Cloud Infrastructure Document Understanding extrae datos de formularios y documentos de clientes y Oracle Cloud Infrastructure Language procesa datos de texto y los enriquece con análisis de sentimientos, reconocimiento de entidades con nombre o clasificación de texto.
El dominio Finanzas utiliza las siguientes capacidades para crear un producto de datos de Transacciones financieras aumentadas:
- Inversión en tiempo real (Oracle Cloud Infrastructure GoldenGate): captura transacciones financieras del sistema bancario principal casi en tiempo real y de una forma no intrusiva.
- Procesamiento por lotes (transformaciones de datos de Oracle Cloud Infrastructure): con ELT con poco código, valida, forma y transforma los datos raw en un producto de datos seleccionado categorizando y aumentando los datos de transacciones financieras con categorías de gasto, detalles de comerciante o datos de ubicación.
- Servicio (Oracle Autonomous Data Warehouse): contiene datos seleccionados y proporciona transacciones aumentadas al dominio de riesgo.
- Cloud Storage/Data Lake (Oracle Cloud Infrastructure Object Storage): almacena formularios relacionados con las finanzas a los que se hace referencia en los registros de transacciones financieras almacenados en Oracle Autonomous Data Warehouse.
- Dominio agregado: riesgo
Este dominio se centra en la creación, formación y ejecución de modelos de aprendizaje automático para detectar riesgos basados en datos internos, como perfiles de clientes y transacciones aumentadas, y datos externos, como datos económicos y macroeconómicos.
Este dominio cuenta con PYMES especializadas en análisis y prevención de riesgos y sirve a todos los demás dominios que necesitan sus productos de datos. El dominio tiene usuarios internos que consumen análisis aumentados, pero la mayor parte de su trabajo es compartir los resultados de inferencia por lotes de aprendizaje automático. Por ejemplo, la inferencia por lotes podría calcular la propensión al riesgo de los clientes que suscriben servicios financieros en función de su estilo de vida y gasto y de factores macroeconómicos, como el crecimiento de la economía, la inflación o la tasa de desempleo.
Este dominio utiliza las siguientes capacidades para crear un producto de datos de propensión al riesgo:
- Servicio (Oracle Autonomous Data Warehouse): procesa transformaciones e ingeniería de funciones para alimentar los modelos de aprendizaje automático, así como para almacenar los resultados de inferencia por lotes y producir KPI relacionados con el riesgo. El dominio de agregación de riesgo es un consumidor de los perfiles de cliente y los datos de transacciones aumentadas, compartidos por los dominios de cliente y finanzas, respectivamente. Proporciona datos de propensión al riesgo para el dominio de marketing.
- Aprender y predecir (Oracle Cloud Infrastructure Data Science): abarca todo el ciclo de vida de las operaciones de aprendizaje automático, desde el análisis exploratorio de datos, el desarrollo de modelos, la ejecución y la mejora continua. Produce resultados de inferencia por lotes que son la base de los datos compartidos de propensión al riesgo.
- Dominio alineado con el consumidor: marketing
Este dominio se centra en la selección de datos para respaldar campañas personalizadas y específicas. Utiliza datos compartidos de otros dominios como entrada y proporciona la segmentación y la siguiente mejor oferta de datos en tiempo real mediante el uso de inferencias basadas en API y el intercambio de datos con socios de marketing de 3a parte que ejecutan campañas y comparten los resultados de ejecución de la campaña.
Este dominio utiliza las siguientes capacidades para crear productos de datos de segmentación de campañas:
- Procesamiento por lotes (transformaciones de datos de Oracle Cloud Infrastructure): procesa y forma los datos consumidos de los recursos compartidos de datos. También se puede utilizar para replicar datos de los recursos compartidos de datos en Oracle Autonomous Data Warehouse.
- Servicio (Oracle Autonomous Data Warehouse): almacena datos seleccionados, información de campaña, segmentos y ofertas específicas para una campaña determinada.
- Almacenamiento en la nube/Lago de datos (Oracle Cloud Infrastructure Object Storage): almacena cualquier dato no estructurado que utilice el dominio.
- Visualizar/aprender (Oracle Analytics Cloud): sirve a los usuarios finales de dominio de análisis aumentados, como objetivos de campaña y KPI de ejecución.
- Aprender y predecir (Oracle Machine Learning): abarca todo el ciclo de vida de las operaciones de aprendizaje automático, desde el análisis exploratorio de datos hasta el despliegue de modelos. Los usuarios aprovechan AutoML para acelerar la creación y el entrenamiento de modelos. En función de las campañas, los resultados del modelo de inferencia por lotes se sirven mediante el uso compartido de datos a partners externos que ejecutan las campañas o mediante despliegues de Oracle Machine Learning para la inferencia en tiempo real invocada por aplicaciones orientadas al cliente.
- API (Oracle Cloud Infrastructure API Gateway): protege y controla los puntos finales de la API de despliegue de Oracle Machine Learning.
- Servicios compartidos
Los servicios utilizados por todos los dominios para la gobernanza y seguridad de datos incluyen:
- Gobernanza de datos (Oracle Cloud Infrastructure Data Catalog): cataloga el glosario de negocio y todas las entidades de datos de dominio, categorizando cuáles son productos de datos para que se puedan detectar.
- Seguridad de datos (Oracle Data Safe, OCI Audit, OCI Logging, OCI Vault): aumenta la estrategia de seguridad de todos los dominios.
Variante de Arquitectura: Despliegue Compartido
Es posible tener una plataforma descentralizada que se ejecute en una plataforma de datos compartida, donde un conjunto común de instancias de servicio soporte a los diferentes equipos de dominio de datos.
La arquitectura primaria permite el más alto nivel de aislamiento y flexibilidad para cada dominio y es altamente escalable para abordar plataformas de datos descentralizadas con un gran número de dominios. Los requisitos para una plataforma de datos descentralizada pueden variar y para casos de uso específicos una variante de patrón de arquitectura diferente podría ser más adecuada.
En el siguiente diagrama se muestra una variación de despliegue compartido del patrón de plataforma distribuida.
descentralized-variant-shared-oracle.zip
Se comparte una única instancia de Oracle Autonomous Data Warehouse entre todos los dominios, que están aislados mediante el acceso basado en roles (RBAC) y diferentes esquemas. Los datos que residen en el lago también se aíslan para cada dominio mediante políticas de Oracle Cloud Infrastructure Identity and Access Management y distintos compartimentos. Los productos de datos se seleccionan dentro de sus respectivos esquemas, se catalogan y se comparten mediante el uso compartido en directo y con versiones.
Para la ingestión y el procesamiento de datos, los dominios A y B utilizan las mismas instancias y aplicaciones de Oracle Cloud Infrastructure Data Integration y Oracle Cloud Infrastructure Data Flow. Los dominios C y D tienen requisitos muy específicos para la ingestión y el procesamiento de datos y, por lo tanto, tienen instancias independientes.
La misma lógica se aplica a la capa de consumo en la que los dominios A y B comparten una única instancia de análisis en la nube, segregada mediante RBAC, mientras que los dominios C y D utilizan sus propias instancias de servicios.
También es posible utilizar una solución híbrida; en lugar de tener una única instancia para todos los dominios o una instancia por dominio, algunos dominios pueden estar utilizando una instancia compartida mientras que otros tienen una instancia dedicada.
Una solución híbrida de este tipo suele estar controlada por requisitos distintos de los funcionales, como los requisitos de rendimiento, seguridad, alta disponibilidad o recuperación ante desastres, que son más exigentes para algunos dominios, y que requieren instancias independientes para abordar dichos requisitos, sin que ello afecte negativamente a las cargas de trabajo de otros dominios.
Variante de Arquitectura: Hub y Spoke
A menudo, las grandes organizaciones con subsidiarias en diferentes regiones y países necesitan ejecutar sus plataformas de datos de forma independiente, sin una plataforma de datos centralizada que atienda a todas las cargas de trabajo de las subsidiarias, al tiempo que necesitan compartir datos con la sede para obtener visibilidad global e indicadores clave de rendimiento (KPI).
Una plataforma de datos descentralizada es una buena solución para este escenario, donde hay un centro (la sede) y varios radios (las subsidiarias) que necesitan intercambiar datos de forma segura y eficiente.
Esta variante utiliza la geografía como ejemplo para un patrón de hub y radio, pero el mismo patrón también se puede aplicar a otros ejemplos como una compañía matriz y sus subsidiarias.
Los radios se pueden desplegar en el mismo arrendamiento que el hub o en distintos arrendamientos.
En el siguiente diagrama, se muestra un hub y varios radios desplegados en diferentes regiones y que utilizan recursos compartidos con versiones, activados por el protocolo Delta Sharing, para intercambiar datos. En este diagrama se muestran solo los componentes funcionales del motor de servicio. El resto de la arquitectura funcional es similar a la que se muestra en la arquitectura funcional primaria.
descentralized-variant-hub-spoke-oracle.zip
Dado que los datos se intercambian de forma segura y se transmiten entre regiones a través de Internet, debe tener en cuenta la latencia. Si los productos de datos compartidos entre los radios y el hub son conjuntos de datos agregados y KPI, y no grandes volúmenes de datos granulares, este patrón es fácil de implementar, mantener y operar.
Un enfoque alternativo es utilizar enlaces en la nube de Oracle Autonomous Database que permitan compartir datos sin problemas entre instancias, incluso si se encuentran en otras regiones.
Para el uso compartido de datos entre regiones, la instancia de Oracle Autonomous Data Warehouse de origen se debe clonar en la región de destino para que la instancia de hub de Autonomous Data Warehouse pueda acceder a ella sin problemas. Las clonaciones se pueden refrescar periódicamente, ya sea de forma manual o automática, para que el hub Autonomous Data Warehouse pueda consumir productos de datos actualizados compartidos por los radios.
Debido a que el hub probablemente consumirá productos de datos que son un subjuego de todo el juego de datos que cura el portavoz, los radios pueden tener una instancia de Autonomous Data Warehouse dedicada solo para contener productos de datos que se compartan con el hub, optimizando la clonación de refrescamiento.
El tráfico de red para clonaciones de refrescamiento se enruta a través del eje central de Oracle y tiene una latencia más baja y un ancho de banda más alto al mover productos de datos de gran tamaño que residen en las instancias de Autonomous Data Warehouse radiales.
La elección entre el uso de recursos compartidos con versiones o enlaces a la nube se ve influida principalmente por el rendimiento y el costo, en lugar de por los requisitos funcionales.
Independientemente de la opción utilizada, el hub y los radios tienen su propia plataforma de datos local que podría utilizar el enfoque descentralizado que se muestra en esta arquitectura.
Variante de arquitectura: ecosistema de datos heterogéneos
Sin embargo, puede utilizar la misma arquitectura para soportar un ecosistema de datos heterogéneo con diferentes organizaciones que comparten datos mediante diferentes tecnologías y para diferentes fines.
Los casos de uso pueden incluir hospitales que comparten datos anónimos con universidades con fines de investigación, o proveedores que comparten datos de piezas con fabricantes de automóviles.
Las organizaciones que utilizan Oracle Autonomous Data Warehouse como motor de servicio pueden proporcionar y consumir datos compartidos de otras tecnologías que soportan el protocolo abierto Delta Sharing.
Delta Sharing es una buena opción para apoyar los ecosistemas de datos debido a su amplio apoyo y debido a la simplicidad por la que proporciona y consume datos de forma segura.
También puede compartir datos mediante el uso de otros mecanismos, como API o transmisión de datos.
Arquitectura Física
La arquitectura física de esta plataforma de datos descentralizada admite lo siguiente:
- Aislamiento de dominio mediante compartimentos y políticas de Oracle Cloud Infrastructure Identity and Access Management en los que los equipos respectivos solo están autorizados a utilizar y desplegar recursos en la nube en su compartimento
- Despliegue de dominios en sus respectivas redes virtuales en la nube de carga de trabajo para un mayor nivel de aislamiento y una mayor estrategia de seguridad
- Procesos de ingestión, almacenamiento, procesamiento y servicio de datos gestionados por equipos de dominio con recursos en la nube desplegados en sus compartimentos y redes virtuales en la nube
- Soporte para requisitos no funcionales como escalabilidad, alta disponibilidad, recuperación ante desastres, seguridad y objetivos de nivel de servicio (SLO) porque cada equipo de dominio utiliza recursos en la nube independientes según sus requisitos de dominio específicos
- Control de costos detallado para cada uso de recursos de dominio en la nube
- Tráfico integral totalmente seguro y privado mediante puntos finales privados e instancias desplegadas en subredes privadas
También es posible tener algunos servicios desplegados con puntos finales públicos por dominio, al tiempo que se adhieren a las reglas de seguridad corporativas.
- Uso compartido de datos activado por Oracle Autonomous Data Warehouse mediante recursos compartidos activos o recursos compartidos con versiones y si se deben proporcionar datos actualizados o con versiones, según el caso de uso
- Catálogo de datos centralizado para todos los dominios, con las subentidades del catálogo de datos aisladas por dominio mediante las políticas de Oracle Cloud Infrastructure Identity and Access Management, excepto los productos de datos que se deben poder detectar
- Despliegue altamente escalable, ya que cada nuevo dominio se puede incorporar mediante la automatización de la infraestructura como código (IaC) sin que esto afecte a los dominios de datos existentes
El siguiente diagrama ilustra esta arquitectura de referencia.
descentralized-data-platform-physical-oracle.zip
El diagrama de arquitectura física representa dos dominios para ejemplificar cómo se establecen las redes y los servicios en la nube para cada dominio. Normalmente, todas las redes de dominio y los compartimentos son iguales, a menos que haya una excepción basada en requisitos específicos no funcionales.
El diseño de la arquitectura física:
- Aprovecha una VCN de hub y una VCN para cada dominio de datos que contiene la carga de trabajo de ese dominio
- Aprovecha la conectividad local mediante el uso de Oracle Cloud Infrastructure FastConnect y la VPN de sitio a sitio para la redundancia
- Enruta todo el tráfico entrante desde las ubicaciones locales y desde Internet, en primer lugar, a la VCN del hub y, a continuación, a las VCN de carga de trabajo del dominio de datos.
- Protege todos los datos en tránsito y estáticos
- Despliega servicios con puntos finales privados para aumentar la estrategia de seguridad
- Segmenta las redes virtuales en la nube en varias subredes privadas para aumentar la estrategia de seguridad
- Proporciona un compartimento para cada dominio para el aislamiento de recursos
- Utiliza un gateway de enrutamiento dinámico (DRG) para que los recursos en la nube admitan el tráfico entrante y saliente a los demás dominios VCN
- Coloca instancias de Autonomous Data Warehouse en la subred privada de datos para una mayor seguridad, pero puede proporcionar y consumir recursos compartidos activos y con versiones de otras instancias de Autonomous Data Warehouse de dominio si se establecen rutas para activar ese tráfico
Las posibles mejoras de diseño no representadas en este despliegue por simplicidad incluyen:
- Aprovechamiento de una zona de aterrizaje completa compatible con CIS
- Despliegue de un firewall de red en la VCN de hub para mejorar la estrategia de seguridad general mediante la inspección de todo el tráfico y la aplicación de políticas
Recomendaciones
Utilice las siguientes recomendaciones como punto de partida para compartir datos de forma segura. Sus requisitos pueden diferir de la arquitectura descrita aquí.
Oracle Autonomous Data Warehouse
Esta arquitectura utiliza Oracle Autonomous Data Warehouse en una infraestructura compartida.
- Utilice una arquitectura de medallón para el lakehouse y cree productos de datos basados en las capas de plata (granular, aumentada) y oro (enriquecida, agregada).
- Considere compartir productos de datos mediante el uso de Autonomous Data Warehouse con su soporte nativo para el uso compartido de datos heterogéneos para proporcionar una arquitectura más sencilla, segura y fiable.
- Considere la posibilidad de compartir datos externos, expuestos en Autonomous Data Warehouse como tablas externas o tablas híbridas, para beneficiarse de las funciones de seguridad del uso compartido con versiones o en directo.
- Considere la posibilidad de crear vistas para las tablas de productos de datos para diferenciar los objetos base (tablas) de los objetos compartidos (vistas).
- Para aumentar la seguridad al compartir datos con recursos compartidos activos, considere el uso de espacios de nombres y valores de nombres diferentes de los esquemas y las tablas subyacentes para ocultar los nombres de objetos internos.
- Para aumentar la seguridad al utilizar el uso compartido en directo con enlaces en la nube, pida al administrador de registro del juego de datos que defina el ámbito del juego de datos más restrictivo para sus casos de uso.
- Al utilizar el uso compartido en directo con enlaces en la nube, considere la posibilidad de activar el almacenamiento en caché para mejorar el rendimiento de las consultas de los consumidores de datos.
- Al utilizar el uso compartido en directo con enlaces en la nube con un gran volumen de productos de datos, considere la posibilidad de descargar las consultas para realizar clonaciones de refrescamiento a fin de mejorar el rendimiento del consumidor de datos y la segregación de la carga de trabajo.
- Si tiene un gran número de instancias de Autonomous Data Warehouse de dominio o si los requisitos de recursos informáticos de la instancia son altos, considere la posibilidad de consolidarlas en un pool elástico.
OCI Object Storage
Esta arquitectura utiliza Oracle Cloud Infrastructure Object Storage de alta escalabilidad y durabilidad como almacenamiento de lago.
Considere el uso de varios compartimentos granulares para organizar los dominios de datos y los equipos dentro de los dominios de datos para ayudar a separar sus cargas de trabajo con las políticas de Oracle Cloud Infrastructure Identity and Access Management.
Oracle Cloud Infrastructure Data Catalog
Esta arquitectura utiliza Oracle Cloud Infrastructure Data Catalog para gestionar metadatos técnicos, empresariales y operativos para productos de datos, de modo que se puedan detectar automáticamente.
- Considere el uso de una única instancia de Data Catalog para todos los dominios a fin de centralizar la gobernanza de metadatos y productos de datos
- Considere la posibilidad de otorgar acceso de gestión a los usuarios de dominio solo para sus activos de datos
- Considere la posibilidad de otorgar acceso de lectura a todos los usuarios para que puedan encontrar productos de datos mantenidos en toda la organización
- Considere el uso de propiedades personalizadas para enriquecer los metadatos operativos con propiedades como el propietario del producto de datos, la disponibilidad, la fecha de la última actualización, la versión, etc.
Despliegue de dominios de datos
Esta arquitectura utiliza el patrón Data Lakehouse y los servicios de OCI disponibles para admitir una carga de trabajo integral de datos, análisis e IA.
- Considere la segregación de dominios mediante el uso de redes virtuales en la nube independientes para cada dominio a fin de aumentar la estrategia de seguridad y la flexibilidad del dominio al desplegar recursos en la nube.
- Considere la posibilidad de segregar los diferentes servicios de OCI que utiliza cada dominio, aprovechando los compartimentos y las políticas de IAM.
Uso compartido de productos de datos
- Si necesita servir productos de datos mediante API, considere el uso de Oracle REST Data Services.
- Si comparte productos de datos con Oracle REST Data Services, considere utilizar Oracle Cloud Infrastructure API Gateway para proteger las API.
- Si necesita transmitir productos de datos, considere el uso de Oracle Cloud Infrastructure GoldenGate y Oracle Cloud Infrastructure Streaming.
Explorar más
Obtenga más información sobre las funciones de esta arquitectura y sobre las arquitecturas relacionadas.