Elección de un almacén de datos analíticos en Azure
En una arquitectura de macrodatos, a menudo se necesita un almacén de datos analíticos que sirva los datos procesados en un formato estructurado que se pueda consultar mediante herramientas de análisis. Los almacenes de datos analíticos que admiten la consulta tanto de los datos de la ruta de acceso rápido como de la ruta de acceso preciso se denominan colectivamente la capa de servicios o el almacenamiento de servicios de datos.
La capa de servicio afecta a los datos procesados tanto de la ruta de acceso activa a la ruta de acceso inactiva. En la arquitectura lambda, la capa de servicio se subdivide en una capa de servicios de velocidad, que almacena los datos que se ha procesado de forma incremental, y una capa de servicios por lotes, que contiene la salida procesada por lotes. La capa de servicios requiere una compatibilidad total con las lecturas aleatorias con latencia baja. El almacenamiento de datos en la capa de velocidad también debe admitir operaciones de escritura aleatorias, ya que el lote que carga los datos en este almacén introduciría retrasos no deseados. Por otra parte, el almacenamiento de datos en la capa por lotes no es preciso que admita operaciones de escritura aleatorias, sino operaciones de escritura por lotes.
No hay ninguna opción individual de administración de datos que sea la mejor para todas las tareas del almacenamiento de datos. Las distintas soluciones de administración de datos están optimizadas para tareas diferentes. La mayoría de las aplicaciones en la nube y procesos de macrodatos reales tienen una gran variedad de requisitos de almacenamiento de datos y a menudo usan una combinación de soluciones de almacenamiento de datos.
¿Cuáles son las opciones disponibles cuando se elige un almacén de datos analíticos?
Hay varias opciones para el almacenamiento de servicios de datos en Azure, con el fin de que pueda elegir la que más se ajuste a sus necesidades:
- Azure Synapse Analytics
- Grupos de Spark de Azure Synapse
- Azure Databricks
- Azure Data Explorer
- Azure SQL Database
- SQL Server en VM de Azure
- HBase/Phoenix en HDInsight
- Hive LLAP en HDInsight
- Azure Analysis Services
- Azure Cosmos DB
Estas opciones proporcionan varios modelos de base de datos que están optimizados para los distintos tipos de tareas:
- Las bases de datos de clave/valor contienen un objeto serializado individual para cada valor de clave. Se recomiendan para almacenar grandes volúmenes de datos donde se desee obtener un elemento para un valor de clave determinado valor de clave y no tiene que realizar consultas basándose en otras propiedades del elemento.
- Las bases de datos de documentos son las bases de datos de clave/valor en las que los valores son documentos. En este contexto, un "documento" es una colección de campos con nombre y valores. Normalmente, la base de datos almacena los datos en un formato como XML, YAML, JSON o JSON binario (BSON), pero puede usar texto sin formato. Las bases de datos de documentos pueden realizar consultas en los campos que no sean clave y definir índices secundarios, con el fin de aumentar la eficacia de las consultas. Esto hace que las bases de datos de documentos sean más apropiadas para aplicaciones que requieren recuperar datos según más complejos que el valor de la clave del documento. Por ejemplo, puede realizar consultas en campos como el de id. del producto, id. del cliente o nombre del cliente.
- Las bases de datos de almacén de columnas son almacenes de datos de clave y valor que almacenan cada columna por separado en el disco. Una base de datos de almacenamiento de columnas anchas es un tipo de base de datos de almacenamiento de columnas que almacena familias de columnas, no solo columnas individuales. Por ejemplo, una base de datos del censo podría tener una familia de columnas para el nombre de una persona (nombre, segundo nombre y apellidos), una familia para la dirección de la persona y otra familia para la información personal de la persona (fecha de nacimiento y género). La base de datos puede almacenar cada familia de columnas en una partición independiente, al tiempo que mantiene todos los datos de una persona relacionados con la misma clave. Una aplicación puede leer la familia de una sola columna sin necesidad de leer todos los datos de una entidad.
- Las bases de datos de grafos almacenan la información como una colección de objetos y relaciones. Una base de datos de grafos puede realizar de manera eficaz consultas que atraviesan la red de objetos y las relaciones entre ellos. Por ejemplo, los objetos podrían ser los empleados en una base de datos de recursos humanos y puede desear facilitar consultas como "buscar todos los empleados que trabajan directa o indirectamente para Scott".
- Las bases de datos de telemetría y de serie temporal son una colección de objetos que solo se anexan. Las bases de datos de telemetría indexan eficazmente los datos en una variedad de almacenes en columnas y estructuras en memoria, lo que las convierte en la opción óptima para almacenar y analizar grandes cantidades de datos de telemetría y de series temporales.
Principales criterios de selección
Para restringir las opciones, empiece por responder a estas preguntas:
¿Necesita almacenamiento de servicios que pueda servir como ruta de acceso activa para los datos? En caso afirmativo, limite las opciones a las que están optimizados para una capa de servicios de velocidad.
¿Necesita compatibilidad con el procesamiento paralelo masivo (MPP), donde las consultas se distribuyen automáticamente a través de varios procesos o nodos? Si es así, seleccione una opción que admita el escalado horizontal de consultas.
¿Prefiere usar un almacén de datos relacional? Si es así, limite las opciones a las que tengan un modelo de base de datos relacional. Sin embargo, tenga en cuenta que algunos almacenes no relacionales admiten la sintaxis SQL para consultar y herramientas como PolyBase se pueden usar para consultar los almacenes de datos no relacionales.
¿Se recopilan datos de series temporales? ¿Se usan datos que solo se anexan?
Matriz de funcionalidades
En las tablas siguientes se resumen las diferencias clave en cuanto a funcionalidades.
Funcionalidades generales
Capacidad | SQL Database | Grupo de SQL de Azure Synapse | Grupo de Spark de Azure Synapse | Explorador de datos de Azure | HBase/Phoenix en HDInsight | Hive LLAP en HDInsight | Azure Analysis Services | Azure Cosmos DB |
---|---|---|---|---|---|---|---|---|
Es un servicio administrado | Sí | Sí | Sí | Sí | Sí 1 | Sí 1 | Sí | Sí |
Modelo de la base de datos principal | Relacional (formato de almacenamiento de columnas cuando se usan índices de almacén de columnas) | Tablas relacionales con almacenamiento de columnas | Almacenamiento de columnas anchas | Almacén relacional (de columnas), de telemetría y de series temporales | Almacenamiento de columnas anchas | Hive/In-Memory | Modelos semánticos tabulares | Almacenamiento de documentos, grafos, almacenamiento de clave-valor, almacenamiento de columnas anchas |
Compatibilidad con lenguaje SQL | Sí | Sí | Sí | Sí | Sí (mediante el controlador JDBC Phoenix) | Sí | No | Sí |
Optimizado para la capa de servicios de velocidad | Sí 2 | Sí 3 | Sí | Sí | Sí | Sí | No | Sí |
[1] Con configuración y escalado manuales.
[2] Mediante tablas optimizadas para memoria y hash o índices no agrupados en clúster.
[3] Se admite como una salida de Azure Stream Analytics.
Funcionalidades de escalabilidad
Capacidad | SQL Database | Grupo de SQL de Azure Synapse | Grupo de Spark de Azure Synapse | Explorador de datos de Azure | HBase/Phoenix en HDInsight | Hive LLAP en HDInsight | Azure Analysis Services | Azure Cosmos DB |
---|---|---|---|---|---|---|---|---|
Servidores regionales redundantes para lograr alta disponibilidad | Sí | No | No | Sí | Sí | No | Sí | Sí |
Admite el escalado horizontal de consultas | No | Sí | Sí | Sí | Sí | Sí | Sí | Sí |
Escalabilidad dinámica (escalado vertical) | Sí | Sí | Sí | Sí | No | No | Sí | Sí |
Admite el almacenamiento en caché en memoria de datos | Sí | Sí | Sí | Sí | No | Sí | Sí | No |
Funcionalidades de seguridad
Capacidad | SQL Database | Azure Synapse | Explorador de datos de Azure | HBase/Phoenix en HDInsight | Hive LLAP en HDInsight | Azure Analysis Services | Azure Cosmos DB |
---|---|---|---|---|---|---|---|
Autenticación | SQL/Microsoft Entra ID | SQL/Microsoft Entra ID | Microsoft Entra ID | Local/Microsoft Entra ID 1 | Local/Microsoft Entra ID 1 | Microsoft Entra ID | Usuarios de base de datos / ID de Microsoft Entra a través del control de acceso (administración de identidades y accesos (IAM)) |
Cifrado de datos en reposo | Sí 2 | Sí 2 | Sí | Sí 1 | Sí 1 | Sí | Sí |
Seguridad de nivel de fila | Sí | Sí 3 | Sí | Sí 1 | Sí 1 | Sí | No |
Admite firewalls | Sí | Sí | Sí | Sí 4 | Sí 4 | Sí | Sí |
Enmascaramiento de datos dinámicos | Sí | Sí | Sí | Sí 1 | Sí | No | No |
[1] Requiere el uso de un clúster de HDInsight unido a un dominio.
[2] Requiere el uso de cifrado de datos transparente para cifrar y descifrar los datos en reposo.
[3] Solo predicados de filtro. Consulte Seguridad de nivel de fila.
[4] Cuando se usa en una instancia de Azure Virtual Network. Para obtener más información, consulte Extensión de Azure HDInsight con Azure Virtual Network.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Zoiner Tejada | Director ejecutivo y arquitecto
Pasos siguientes
- Análisis de datos en un almacenamiento de datos relacional
- Creación de una base de datos única: Azure SQL Database
- Creación de un área de trabajo de Azure Databricks
- Creación de un clúster de Apache Spark en Azure HDInsight mediante Azure Portal
- Creación de un área de trabajo de Synapse
- Exploración de los servicios de datos de Azure para el análisis moderno
- Exploración de los servicios de análisis y bases de datos de Azure
- Consulta de Azure Cosmos DB mediante la API para NoSQL