Introducción a la ingesta de datos en Azure Data Explorer
La ingesta de datos es el proceso que se usa para cargar registros de datos desde uno o varios orígenes a una tabla de Azure Data Explorer. Una vez ingeridos, los datos están disponibles para su consulta.
El diagrama siguiente muestra el flujo de un extremo a otro para trabajar en Azure Data Explorer y muestra diferentes métodos de ingesta.
El servicio de administración de datos Azure Data Explorer, que es el responsable de la ingesta de datos, implementa el siguiente proceso:
Azure Data Explorer extrae los datos de un origen externo y lee las solicitudes de una cola de pendientes de Azure. Los datos se procesan por lotes o se transmiten a Data Manager. El procesamiento por lotes de los datos que fluyen en la misma base de datos y tabla se optimiza para mejorar el rendimiento de la ingesta. Azure Data Explorer valida los datos iniciales y convierte los formatos de datos cuando es necesario. Una posterior manipulación de los datos incluye hacer coincidir los esquemas, así como organizar, indexar, codificar y comprimir los datos. Los datos se conservan en el almacenamiento de acuerdo con la directiva de retención establecida. A continuación, Data Manager confirma la ingesta de datos en el motor, donde están disponibles para su consulta.
Formatos de datos compatibles, propiedades y permisos
Propiedades de la ingesta : las propiedades que afectan a la forma en que se van a ingerir los datos (por ejemplo, etiquetado, asignación u hora de creación).
Permisos: Para ingerir datos, el proceso necesitapermisos de nivel de agente de ingesta de bases de datos. Otras acciones, como la consulta, pueden requerir permisos de administrador de base de datos, usuario de base de datos o administrador de tabla.
Ingesta de procesamiento por lotes frente a ingesta de streaming
La ingesta de procesamiento por lotes realiza el procesamiento por lotes de los datos y está optimizada para lograr un alto rendimiento de la ingesta. Este método es el tipo de ingesta preferido y de mayor rendimiento. Los datos se procesan por lotes en función de las propiedades de la ingesta. Después se combinan y optimizan pequeños lotes de datos para agilizar los resultados de la consulta. La directiva de procesamiento por lotes de la ingesta se puede establecer en bases de datos o en tablas. De forma predeterminada, el valor máximo del procesamiento por lotes es de 5 minutos, 1000 elementos o un tamaño total de 1 GB. El límite de tamaño de los datos para un comando de ingesta por lotes es de 6 GB.
Ingesta en streaming es la ingesta de datos en curso desde un origen de streaming. La ingesta de streaming permite una latencia casi en tiempo real para pequeños conjuntos pequeños de datos por tabla. En un principio, los datos se ingieren en el almacén de filas y posteriormente se mueven a las extensiones del almacén de columnas. La ingesta en streaming se puede realizar mediante una biblioteca de cliente de Azure Data Explorer, o bien desde una de las canalizaciones de datos admitidas.
Métodos y herramientas de ingesta
Azure Data Explorer admite varios métodos de ingesta, cada uno con sus propios escenarios de destino. Estos métodos incluyen herramientas de ingesta, conectores y complementos para diversos servicios, canalizaciones administradas, ingesta mediante programación mediante distintos SDK y acceso directo a la ingesta.
Ingesta mediante canalizaciones administradas
Para aquellas organizaciones que deseen que sea un servicio externo el que realice la administración (límites, reintentos, supervisiones, alertas, etc.), es probable que un conector sea la solución más adecuada. La ingesta en cola es apropiada para grandes volúmenes de datos. Azure Data Explorer admite las siguientes instancias de Azure Pipelines:
Event Grid : una canalización que escucha Azure Storage y actualiza Azure Data Explorer para extraer información cuando se producen eventos suscritos. Para más información, consulte Ingesta de blobs de Azure en Azure Data Explorer.
Event Hubs: una canalización que transfiere eventos de los servicios a Azure Data Explorer. Para más información, consulte Ingesta de datos desde el centro de eventos en Azure Data Explorer.
IoT Hub : una canalización que se usa para la transferencia de datos desde dispositivos IoT compatibles a Azure Data Explorer. Para más información, consulte Ingesta de IoT Hub.
Azure Data Factory (ADF) : un servicio de integración de datos totalmente administrado para cargas de trabajo de análisis en Azure. Azure Data Factory se conecta con más de 90 orígenes admitidos para proporcionar una transferencia de datos eficaz y resistente. ADF prepara, transforma y enriquece los datos para proporcionar información que se puede supervisar de varias formas. Este servicio se puede usar como solución de un solo uso, en una escala de tiempo periódica o desencadenada por eventos específicos.
- Integración de Azure Data Explorer con Azure Data Factory.
- Uso de Azure Data Factory para copiar datos de orígenes compatibles a Azure Data Explorer.
- Copia en bloque desde una base de datos a Azure Data Explorer mediante la plantilla de Azure Data Factory.
- Uso de la actividad de comandos de Azure Data Factory para ejecutar comandos de control de Azure Data Explorer.
Ingesta mediante conectores y complementos
Complemento Logstash, consulte Ingesta de datos de Logstash en Azure Data Explorer.
Conector de Kafka, consulte Ingesta de datos de Kafka en Azure Data Explorer.
Power Automate : una canalización de flujos de trabajo automatizada a Azure Data Explorer. Power Automate se puede usar para ejecutar una consulta y realizar acciones preestablecidas con los resultados de la consulta como desencadenador. Vea Azure Data Explorer connector to Power Automate (Preview).
Conector de Apache Spark: es un proyecto de código abierto que se puede ejecutar en cualquier clúster de Spark. Implementa el origen y el receptor de datos para mover datos entre los clústeres de Azure Data Explorer y de Spark. Puede compilar aplicaciones rápidas y escalables orientadas a escenarios controlados por datos. Consulte Conector de Azure Data Explorer para Apache Spark.
Ingesta mediante programación mediante SDK
Azure Data Explorer proporciona SDK que pueden usarse para la consulta e ingesta de datos. La ingesta mediante programación está optimizada para reducir los costos de ingesta (COG), minimizando las transacciones de almacenamiento durante y después del proceso de ingesta.
SDK y proyectos de código abierto disponibles
Herramientas
El Asistente para ingesta: permite ingerir datos rápidamente mediante la creación y ajuste de tablas a partir de una amplia gama de tipos de origen. El asistente para ingesta sugiere tablas y estructuras de asignación automáticamente en función del origen de datos de Azure Data Explorer. El asistente se puede usar para la ingesta puntual, o bien para definir una ingesta continua mediante Event Grid en el contenedor en el que se han ingerido los datos.
LightIngest : utilidad de línea de comandos para la ingesta de datos ad-hoc en Azure Data Explorer. La utilidad puede extraer datos de origen de una carpeta local o de un contenedor de almacenamiento de blobs de Azure.
Ingesta de comandos de control
Use comandos para ingerir datos directamente en el motor. Este método omite los servicios de Administración de datos y, por tanto, solo se debe usar para la exploración y la creación de prototipos. No se debe usar en escenarios de producción o de gran volumen.
Ingesta insertada: se envía un comando de control .ingest inline al motor y los datos que se van a ingerir forman parte del propio texto del comando. Este método está pensado para la realización de pruebas improvisadas.
Ingesta desde consulta: se envía un comando de control .set, .append, .set-or-append o .set-or-replace al motor y los datos se especifican indirectamente como los resultados de una consulta o un comando.
Ingesta desde almacenamiento (extracción) : se envía un comando de control .ingest into al motor con los datos almacenados en algún almacenamiento externo (por ejemplo, Azure Blob Storage) al que el motor puede acceder y al que el comando señala.
Comparación de métodos y herramientas de ingesta
| Nombre de ingesta | Tipo de datos | Tamaño de archivo máximo | Streaming, procesamiento por lotes, directo | La mayoría de los escenarios comunes | Consideraciones |
|---|---|---|---|---|---|
| Asistente para ingesta | *sv, JSON | 1 GB sin comprimir (vea la nota) | Procesamiento por lotes en el contenedor, el archivo local y el blob en la ingesta directa. | Un esquema de creación de tablas de un solo uso, definición de ingesta continua con Event Grid, ingesta en bloque con contenedor (hasta 5000 blobs; sin límite al usar la ingesta histórica) | |
| LightIngest | Se admiten todos los formatos | 1 GB sin comprimir (vea la nota) | Procesamiento por lotes a través del DM o de la ingesta directa al motor. | Migración de datos, datos históricos con marcas de tiempo de ingesta ajustadas, ingesta en bloque (sin restricción de tamaño). | Distingue mayúsculas de minúsculas, con distinción de espacio. |
| ADX Kafka | Avro, ApacheAvro, JSON, CSV, Parquet y ORC | Sin límite. Hereda las restricciones de Java. | Procesamiento por lotes, streaming | Canalización existente, consumo de gran volumen desde el origen. | La preferencia puede determinarse mediante qué servicio de "varios productores o consumidores" ya se usa, o cómo se desea administrar un servicio. |
| ADX a Apache Spark | Todos los formatos admitidos por el entorno de Spark | Sin límite | Lotes | Canalización existente, preprocesamiento en Spark antes de la ingesta, forma rápida de crear una canalización de streaming segura (Spark) a partir de los distintos orígenes que admite el entorno de Spark. | Considere el costo del clúster de Spark. Para la escritura por lotes, compare con la conexión de datos de Azure Data Explorer para Event Grid. En el caso del streaming de Spark, compare con la conexión de datos de Event Hubs. |
| LogStash | JSON | Sin límite. Hereda las restricciones de Java. | Las entradas al conector son eventos Logstash y el conector se genera en Kusto mediante la ingesta de procesamiento por lotes. | Canalización existente, aproveche la naturaleza evolucionada y de código abierto de Logstash para un consumo de gran volumen a partir de las entradas. | La preferencia puede determinarse mediante qué servicio de "varios productores o consumidores" ya se usa, o cómo se desea administrar un servicio. |
| Azure Data Factory (ADF) | Formatos de datos compatibles | Ilimitado *(por restricciones de ADF) | Procesamiento por lotes o por desencadenador de Azure Data Factory. | Admite formatos que normalmente no se admiten, archivos grandes, puede copiar de más de 90 orígenes, desde permanentes hasta la nube. | Este método tarda bastante más tiempo hasta que se ingieren los datos. ADF carga todos los datos en la memoria y, a continuación, comienza la ingesta. |
| Power Automate | Se admiten todos los formatos | 1 GB sin comprimir (vea la nota) | Lotes | Comandos de ingesta como parte del flujo. Se usa para automatizar canalizaciones. | |
| Logic Apps | Se admiten todos los formatos | 1 GB sin comprimir (vea la nota) | Lotes | Se usa para automatizar canalizaciones. | |
| IoT Hub | Formatos de datos compatibles | N/D | Procesamiento por lotes, streaming | Mensajes de IoT, eventos de IoT, propiedades de IoT | |
| Event Hub | Formatos de datos compatibles | N/D | Procesamiento por lotes, streaming | Mensajes, eventos | |
| Event Grid | Formatos de datos compatibles | 1 GB sin comprimir | Procesamiento por lotes | Ingesta continua desde Azure Storage, datos externos en Azure Storage | La ingesta se puede desencadenar mediante las acciones de cambio de nombre o creación de blob. |
| SDK de .NET | Se admiten todos los formatos | 1 GB sin comprimir (vea la nota) | Procesamiento por lotes, streaming, directo | Escriba su propio código en función de las necesidades de la organización. | |
| Python | Se admiten todos los formatos | 1 GB sin comprimir (vea la nota) | Procesamiento por lotes, streaming, directo | Escriba su propio código en función de las necesidades de la organización. | |
| Node.js | Se admiten todos los formatos | 1 GB sin comprimir (vea la nota) | Procesamiento por lotes, streaming, directo | Escriba su propio código en función de las necesidades de la organización. | |
| Java | Se admiten todos los formatos | 1 GB sin comprimir (vea la nota) | Procesamiento por lotes, streaming, directo | Escriba su propio código en función de las necesidades de la organización. | |
| REST | Se admiten todos los formatos | 1 GB sin comprimir (vea la nota) | Procesamiento por lotes, streaming, directo | Escriba su propio código en función de las necesidades de la organización. | |
| Go | Se admiten todos los formatos | 1 GB sin comprimir (vea la nota) | Procesamiento por lotes, streaming, directo | Escriba su propio código en función de las necesidades de la organización. |
Nota
Cuando se hace referencia a ella en la tabla anterior, la ingesta admite un tamaño de archivo máximo de 6 GB. Se recomienda ingerir archivos de entre 100 MB y 1 GB.
Proceso de ingesta
Una vez que haya elegido el método de ingesta que más se ajuste a sus necesidades, siga estos pasos:
Establecimiento de una directiva de procesamiento por lotes (opcional)
El administrador de esta operación procesará por lotes los datos de ingesta según la directiva de procesamiento por lotes de ingesta. Defina una directiva de procesamiento por lotes antes de la ingesta. Consulte Procedimientos recomendados de ingesta: Optimización del rendimiento. Los cambios en la directiva de procesamiento por lotes pueden tardar hasta 5 minutos en tener efecto. La directiva establece límites de lotes según tres factores: tiempo transcurrido desde la creación del lote, número acumulado de elementos (blobs) o tamaño total del lote. De forma predeterminada, la configuración es de 5 minutos, 1000 blobs o 1 GB. El límite que primero se alcance es el que surtirá efecto. Por tanto, normalmente hay un retraso de cinco minutos al poner en cola los datos de ejemplo para la ingesta.
Establecimiento de una directiva de retención
Los datos ingeridos en una tabla de Azure Data Explorer están sujetos a la directiva de retención vigente de la tabla. Salvo que la directiva de retención vigente se establezca explícitamente en una tabla, deriva de la directiva de retención de la base de datos. La retención activa es una función del tamaño del clúster y de la directiva de retención. Si el espacio disponible es insuficiente para la cantidad de datos que se ingieren se obligará a realizar una retención esporádica de los primeros datos.
Asegúrese de que la directiva de retención de la base de datos se ajusta a sus necesidades. Si no es así, anúlela explícitamente en el nivel de tabla. Para más información, consulte Directiva de retención.
de una tabla
Para poder ingerir datos, es preciso crear una tabla con antelación. Use una de las siguientes opciones:
- Cree una tabla con un comando.
- Cree una tabla mediante el Asistente para ingesta.
Nota
Si un registro está incompleto o un campo no se puede analizar como tipo el de datos necesarios, las columnas de tabla correspondientes se rellenará con valores nulos.
Creación de la asignación de esquemas
La asignación de esquemas ayuda a enlazar los campos de datos de origen a las columnas de la tabla de destino. La asignación permite tomar datos de distintos orígenes en la misma tabla, en función de los atributos definidos. Se admiten diferentes tipos de asignaciones, tanto orientadas a filas (CSV, JSON y AVRO) como orientadas a columnas (Parquet). En la mayoría de los métodos, las asignaciones también se pueden crear previamente en la tabla y hacer referencia a ellas desde el parámetro de comando de ingesta.
Establecimiento de una directiva de actualización (opcional)
Algunas de las asignaciones de formato de datos (Parquet, JSON y Avro) admiten transformaciones sencillas y útiles en el momento de la ingesta. Si el escenario requiere un procesamiento más complejo en el momento de la ingesta, ajuste la directiva de actualización, lo que facilitará el procesamiento ligero mediante los comandos de consulta. La directiva de actualización ejecuta automáticamente extracciones y transformaciones en los datos ingeridos en la tabla original e ingiere los datos resultantes en una o varias tablas de destino.
Ingerir datos
Puede ingerir datos de ejemplo en la tabla que ha creado en la base de datos mediante comandos o el asistente para ingesta. Para ingerir sus propios datos, puede seleccionar entre una amplia gama de opciones, entre las que se incluyen herramientas de ingesta, conectores y complementos para diversos servicios, canalizaciones administradas, ingesta mediante programación mediante distintos SDK y acceso directo a la ingesta.