Almacenamiento de datos

  • Artículo
  • Tiempo de lectura: 13 minutos

Un almacenamiento de datos es un repositorio centralizado de datos integrados procedentes de uno o varios orígenes dispares. Los almacenamientos de datos almacenan datos históricos y actuales, y se utilizan para realizar informes y análisis de los datos.

Almacenamiento de datos en Azure

Para mover los datos a un almacenamiento de datos, estos se extraen de forma periódica de diversos orígenes que contienen información empresarial de importancia. Cuando se mueven los datos se puede dar formato, limpiar, validar, resumir y reorganizar. Como alternativa, los datos pueden almacenarse en el nivel más bajo de detalle, con vistas agregadas proporcionadas por el almacenamiento para realizar informes. En cualquier caso, el almacenamiento de datos se convierte en un almacén de datos permanente para informes, análisis e inteligencia empresarial (BI).

Arquitecturas de almacenamiento de datos

Las arquitecturas de referencia siguientes muestran las arquitecturas de almacenamiento de datos de un extremo a otro en Azure:

Cuándo se debe utilizar esta solución

Elija un almacenamiento de datos cuando necesite convertir grandes cantidades de datos procedentes de los sistemas operacionales a un formato que sea fácil de entender. No es necesario que los almacenamientos de datos sigan la misma estructura de datos simplificada utilizada en las bases de datos de OLTP. Puede usar nombres de columna que tengan sentido para los analistas y los usuarios empresariales, reestructurar el esquema para simplificar las relaciones y consolidar varias tablas en una. Estos pasos ayudan a guiar a los usuarios que necesitan crear informes y analizar los datos en sistemas de BI, sin la ayuda de un administrador de bases de datos (DBA) ni desarrollador de datos.

Considere el uso de un almacenamiento de datos cuando necesite separar los datos históricos de los sistemas transaccionales de origen por motivos de rendimiento. Los almacenamientos de datos facilitan el acceso a los datos históricos desde varias ubicaciones, proporcionando una ubicación centralizada con formatos, claves y modelos de datos en común.

Dado que los almacenamientos de datos están optimizados para el acceso de lectura, la generación de informes es más rápida que el uso del sistema de transacciones de origen para la generación de informes.

Entre otras ventajas se incluyen las siguientes:

  • El almacenamiento de datos puede almacenar datos históricos de varios orígenes, lo que representa un origen único de verdad.
  • Puede mejorar la calidad de los datos mediante su limpieza en el momento de su importación al almacenamiento de datos.
  • Las herramientas de informes no compiten con los sistemas transaccionales con respecto a los ciclos de procesamiento de las consultas. Un almacenamiento de datos permite que el sistema transaccional se centre en el control de las escrituras, mientras que el almacenamiento de datos atiende la mayoría de las solicitudes de lectura.
  • Un almacenamiento de datos puede consolidar los datos procedentes de software diferentes.
  • Las herramientas de minería de datos pueden buscar patrones ocultos en los datos mediante metodologías automáticas.
  • Un almacenamiento de datos hace que sea más fácil proporcionar acceso seguro a los usuarios autorizados y restringir el acceso a otros usuarios. Los usuarios empresariales no necesitan tener acceso a los datos de origen, lo que elimina un posible vector de ataque.
  • Los almacenamientos de datos hacen que sea más fácil crear soluciones de inteligencia empresarial, como los cubos OLAP.

Desafíos

Para configurar correctamente un almacenamiento de datos para satisfacer las necesidades de su empresa puede encontrarse algunos de los siguientes desafíos:

  • Confirmar el tiempo necesario para modelar correctamente los conceptos del negocio. Los almacenamientos de datos se controlan mediante información. Debe estandarizar los términos relacionados con el negocio y los formatos comunes, como la moneda y las fechas. También debe reestructurar el esquema de forma que tenga sentido para los usuarios empresariales, pero siga garantizando la precisión de los agregados de datos y las relaciones.

  • Planificación y configuración de la orquestación de datos. Piense en cómo copiar los datos desde el sistema transaccional de origen al almacenamiento de datos y cuándo se deben mover los datos históricos desde los almacenes de datos operativos al almacenamiento.

  • Mantener o mejorar la calidad de los datos mediante la limpieza de los mismos en el momento de su importación en el almacenamiento.

Almacenamiento de datos en Azure

Puede tener uno o varios orígenes de datos, ya sea desde las transacciones de los clientes o aplicaciones empresariales. Estos datos se almacenan normalmente en una o varias bases de datos OLTP. Los datos podrían conservarse en otros medios de almacenamiento, como recursos compartidos de red, blobs de Azure Storage o una instancia de Data Lake. Los datos también se pueden almacenar en el propio almacenamiento de datos o en una base de datos relacional como Azure SQL Database. El propósito de la capa de almacenamiento de datos analíticos es satisfacer las consultas emitidas por las herramientas de generación de informes y análisis sobre el almacenamiento de datos. En Azure, esta funcionalidad de almacenamiento analítico se puede lograr con Azure Synapse o con Azure HDInsight con Hive o Interactive Query. Además, necesitará cierto nivel de orquestación para mover o copiar los datos del almacén de datos al almacenamiento de datos, algo que se puede llevar a cabo mediante Azure Data Factory o Oozie en Azure HDInsight.

Hay varias opciones para la implementación de un almacenamiento de datos en Azure, con el fin de que pueda elegir la que más se ajuste a sus necesidades. Las listas siguientes se dividen en dos categorías: multiproceso simétrico (SMP) y procesamiento paralelo masivo (MPP).

SMP:

MPP:

Como norma general, los almacenamientos basados en SMP son más adecuados para conjuntos de datos pequeños a medianos (hasta 4-100 TB), mientras que MPP se utiliza a menudo para macrodatos. La delineación entre pequeño/mediano y macrodatos en parte tiene que ver con la infraestructura de soporte y la definición de su organización (consulte Elección de un almacén de datos de OLTP).

Más allá de los tamaños de los datos, es probable que el tipo de patrón de la carga de trabajo sea un factor determinante mayor. Por ejemplo, las consultas más complejas pueden ser demasiado lentas para una solución SMP y requerir una solución MPP. En general, los sistemas basados en MPP imponen una penalización de rendimiento con tamaños de datos pequeños, debido a la forma en que los trabajos se distribuyen y se consolidan en los nodos. Si el tamaño de los datos ya supera 1 TB y se espera que siga creciendo, considere la posibilidad de elegir una solución MPP. Sin embargo, si el tamaño de los datos es menor, pero las cargas de trabajo superan los recursos disponibles de la solución SMP, es posible que MPP sea la mejor opción.

Los datos que el almacenamiento de datos ha guardado, o a los que ha accedido, pueden proceder de varios orígenes de datos, entre los que se incluye un lago de datos, como Azure Data Lake Storage. Para ver una sesión de vídeo en la que se comparan los diversos puntos fuertes de los servicios MPP que pueden usar Azure Data Lake, consulte Azure Data Lake and Azure Data Warehouse: Applying Modern Practices to Your App (Azure Data Lake y Almacenamiento de datos de Azure: aplicación de prácticas modernas en una aplicación).

Los sistemas SMP se caracterizan por una única instancia de un sistema de administración de bases de datos relacionales que comparte todos los recursos (CPU/memoria/disco). Un sistema SMP se puede escalar verticalmente. En el caso de que SQL Server se ejecute en una máquina virtual, se puede escalar verticalmente el tamaño de la máquina virtual. En el caso de Azure SQL Database, se puede escalar verticalmente seleccionando otro nivel de servicio.

Los sistemas MPP se pueden escalar horizontalmente mediante la adición de más nodos de proceso (que tienen sus propios subsistemas de CPU, memoria y E/S). Hay limitaciones físicas a la hora de escalar verticalmente un servidor. En ese momento el escalado horizontal es más deseable, en función de la carga de trabajo. Sin embargo, las diferencias en las consultas, el modelado y la creación de particiones de datos significan que las soluciones MPP requieren un conjunto de aptitudes diferente.

A la hora de decidir qué solución SMP se va a usar, consulte Azure SQL Database y SQL Server on Azure VMs en detalle.

Azure Synapse (anteriormente Azure SQL Data Warehouse) también puede utilizarse para conjuntos de datos pequeños y medianas, donde la carga de trabajo es proceso y la memoria intensiva. Más información acerca de los patrones de Azure Synapse y escenarios comunes:

Principales criterios de selección

Para restringir las opciones, empiece por responder a estas preguntas:

  • ¿Quiere un servicio administrado en lugar de administrar sus propios servidores?

  • ¿Trabaja con conjuntos de datos muy grandes o con consultas muy complejas y de larga ejecución? Si es así, considere la posibilidad de usar MPP.

  • En un conjunto de datos grande, ¿es el origen de datos estructurado o no estructurado? Es posible que los datos sin estructura se deban procesar en un entorno de macrodatos como Spark on HDInsight, Azure Databricks, Hive LLAP on HDInsight o Azure Data Lake Analytics. Todos ellos pueden servir como motores ELT (extracción, carga y transformación de datos) y ETL (extracción, transformación y carga de datos). Pueden convertir los datos procesados en datos estructurados, lo que facilita su carga en Azure Synapse o en una de las otras opciones. En el caso de los datos estructurados, Azure Synapse tiene un nivel de rendimiento denominado Optimizado para Compute, para las cargas de trabajo con muchos procesos que requieren un rendimiento ultraalto.

  • ¿Desea separar los datos históricos de los datos operativos actuales? En ese caso, seleccione una de las opciones en las que se requiera orquestación. Estos son almacenes independiente optimizados para un acceso de lectura intensivo y son más adecuados como almacén de datos históricos independiente.

  • ¿Necesita integrar datos de varios orígenes, más allá de su almacén de datos de OLTP? Si es así, considere la posibilidad de usar opciones que integren fácilmente varios orígenes de datos.

  • ¿Tiene un requisito de multiempresa? En ese caso, Azure Synapse no es ideal para este requisito. Para obtener más información, consulte Patrones y antipatrones de Azure Synapse.

  • ¿Prefiere un almacén de datos relacional? Si es así, elija una opción con un almacén de datos relacional, pero tenga también en cuenta que puede usar una herramienta como PolyBase para consultar los almacenes de datos no relacionales, en caso de que sea necesario. Si decide usar PolyBase, ejecute las pruebas de rendimiento en los conjuntos de datos no estructurados de su carga de trabajo.

  • ¿Tiene requisitos de informes en tiempo real? Si requiere cortos tiempos de respuesta a consultas en grandes volúmenes de inserciones singleton, elija una opción que admita informes en tiempo real.

  • ¿Necesita admitir un gran número de usuarios y conexiones simultáneamente? La capacidad para admitir varios usuarios o conexiones simultáneamente depende de varios factores.

    • En el caso de Azure SQL Database, consulte los límites de recursos documentados en función de su nivel de servicio.

    • SQL Server permite un máximo de 32 767 conexiones de usuario. Cuando se ejecuta en una máquina virtual, el rendimiento dependerá del tamaño de la máquina virtual y de otros factores.

    • Azure Synapse tiene límites relativos a las consultas simultáneas y a las conexiones simultáneas. Para obtener más información, consulte Simultaneidad y administración de cargas de trabajo en Azure Synapse. Considere la posibilidad de usar servicios complementarios, como Azure Analysis Services, para superar los límites de Azure Synapse.

  • ¿Qué tipo de carga de trabajo tiene? En general, las soluciones de almacenamiento basado en MPP son más apropiadas para cargas de trabajo de análisis, orientadas al proceso por lotes. Si sus cargas de trabajo son transaccionales por naturaleza y se producen muchas operaciones pequeñas de lectura y escritura, o varias operaciones fila a fila, considere la posibilidad de usar una de las opciones de SMP. Una excepción a esta directriz es cuando se usa el procesamiento de flujos en un clúster de HDInsight, como Spark Streaming, y se almacenan los datos en una tabla de Hive.

Matriz de funcionalidades

En las tablas siguientes se resumen las diferencias clave en cuanto a funcionalidades.

Funcionalidades generales

Capacidad Azure SQL Database SQL Server (máquina virtual) Azure Synapse Apache Hive en HDInsight Hive LLAP en HDInsight
Es un servicio administrado Sí No Sí Sí 1 Sí 1
Requiere la orquestación de datos (contiene una copia de los datos y datos históricos) No No Sí Sí Sí
Integra fácilmente varios orígenes de datos No No Sí Sí Sí
Admite la pausa del proceso No No Sí No 2 No 2
Almacenes de datos relacionales Sí Sí Sí No No
Informes en tiempo real Sí Sí No No Sí
Puntos de restauración de copia de seguridad flexibles Sí Sí No 3 Sí 4 Sí 4
SMP/MPP SMP SMP MPP MPP MPP

[1] Configuración y escalado manuales.

[2] Los clústeres de HDInsight se pueden eliminar cuando no se necesiten y, posteriormente, se pueden volver a crear. Asocie un almacén de datos externo a un clúster para que los datos se conserven cuando se elimine el clúster. Puede utilizar Azure Data Factory para automatizar el ciclo de vida del clúster mediante la creación de un clúster de HDInsight a petición para procesar la carga de trabajo y, después, elimínelo una vez que el procesamiento se haya completado.

[3] Con Azure Synapse, puede restaurar una base de datos a cualquier punto de restauración disponible de los últimos siete días. Las instantáneas comienzan cada cuatro a ocho horas y están disponibles durante siete días. Cuando una instantánea tiene una antigüedad superior a siete días, caduca y su punto de restauración ya no está disponible.

[4] Considere la posibilidad de usar una instancia de Hive Metastore externa de la que se pueda realizar copia de seguridad y que se pueda restaurar cuando sea necesario. Las opciones de copia de seguridad y restauración estándar que se aplican a Blob Storage y Data Lake Storage se pueden utilizar para los datos, o bien se pueden usar algunas soluciones de copia de seguridad y restauración de HDInsight de terceros, como Imanis Data, ya que ofrecen mayor flexibilidad y facilidad de uso.

Funcionalidades de escalabilidad

Capacidad Azure SQL Database SQL Server (máquina virtual) Azure Synapse Apache Hive en HDInsight Hive LLAP en HDInsight
Servidores regionales redundantes para lograr alta disponibilidad Sí Sí Sí No No
Admite escalado horizontal de consultas (consultas distribuidas) No No Sí Sí Sí
Escalabilidad dinámica Sí No Sí 1 No No
Admite el almacenamiento en caché en memoria de datos Sí Sí Sí Sí Sí

[1] Azure Synapse le permite realizar el escalado vertical u horizontal ajustando el número de unidades de almacenamiento de datos (DWU). Consulte Administración de la potencia de proceso en Azure Synapse.

Funcionalidades de seguridad

Capacidad Azure SQL Database SQL Server en una máquina virtual Azure Synapse Apache Hive en HDInsight Hive LLAP en HDInsight
Authentication SQL/Azure Active Directory (Azure AD) SQL/Azure AD/Active Directory SQL/Azure AD local/Azure AD 1 local/Azure AD 1
Authorization Sí Sí Sí Sí Sí 1
Auditoría Sí Sí Sí Sí Sí 1
Cifrado de datos en reposo Sí 2 Sí 2 Sí 2 Sí 2 Sí 1
Seguridad de nivel de fila Sí Sí Sí No Sí 1
Admite firewalls Sí Sí Sí Sí Sí 3
Enmascaramiento de datos dinámicos Sí Sí Sí No Sí 1

[1] Requiere el uso de un clúster de HDInsight unido a un dominio.

[2] Requiere el uso de cifrado de datos transparente (TDE) para cifrar y descifrar los datos en reposo.

[3] Se admite cuando se usa en una instancia de Azure Virtual Network.

Más información acerca de cómo proteger un almacenamiento de datos: