Construyendo una Organización Basada en Datos, Parte #7: Cargar Big Data de Manera Eficiente en Almacenes en la Nube

bharold

Un colega me preguntó recientemente cómo mover un par de miles de millones de registros al almacén de big data espaciotemporal (STBDS) de GeoEvent en el sitio de un cliente, usando ArcGIS Data Interoperability.  Estos son posiciones archivadas de vehículos para una empresa de servicios públicos, almacenadas en una geodatabase Oracle.  Un par de millones de eventos nuevos llegan diariamente.  Los datos archivados están en más de 70 tablas.<\/P>

Debido a que un servicio de entidades en el STBDS tiene la misma API REST que un servicio de entidades alojado ordinario, el plan inicial era aprovechar el patrón descrito en mi blog anterior<\/A>, es decir, ETL los datos archivados en elementos shapefile del portal y luego usar el endpoint Append REST de la capa objetivo para cargar los datos asincrónicamente.  Una complicación adicional fue paralelizar el ETL como múltiples trabajos concurrentes.  Este enfoque reduciría el riesgo de interrupciones de red mientras se transmiten pequeñas transacciones (1000 entidades es el tamaño predeterminado del lote) al portal.  Resultó que el entorno del cliente no estaba en una versión que soportara el flujo de trabajo y optamos por la transmisión, pero me hizo pensar en cómo hacer ETL de big data a la nueva ola de almacenes en la nube que puedes usar nativamente, y en ArcGIS Pro 2.9.<\/P>

Mi mensaje básico es que puedes hacer estos trabajos de traslado y cambio moviendo grandes conjuntos de datos como archivos, en múltiples trabajos concurrentes, maximizando así el rendimiento y minimizando el riesgo del transporte.  Veamos cómo.<\/STRONG><\/P>Almacenes en la nube como Snowflake, Big Query y Redshift pueden ser consultados y leídos en ArcGIS Pro 2.9, pero no escritos usando las herramientas estándar.  ArcGIS Data Interoperability puede sin embargo escribir a estos almacenes, incluyendo datos espaciales, pero el modo predeterminado es streaming, lo cual podría no escalar como necesitas.  Te voy a mostrar un patrón que puedes usar en los tres almacenes:<\/P>ETL conjuntos completos de datos, incluyendo datos espaciales, como Apache Parquet u otro formato como CSVLa geometría está codificada en un formato estándar basado en caracteres<\/LI><\/UL><\/LI>Automatiza el ETL en múltiples procesos concurrentes<\/STRONG><\/LI>No escribas ningún código<\/STRONG> más allá de cualquier comando SQL o macro requerido por el entorno objetivo<\/LI><\/UL>También daré un guiño a cualquier programador que esté acechando en mi espacio de blog sin código, mira abajo 😉<\/span>, es decir, algunos consejos de Python para crear archivos Parquet (Nota:  Los archivos Parquet son un tipo de elemento soportado en ArcGIS Online desde el 22 de septiembre de 2021.  ¡Comparte algunos!)<\/span>Miles de millones de entidades están dentro del alcance con este patrón pero estoy usando un conjunto de datos más modesto para propósitos demostrativos, solo 2.3 millones de entidades puntuales.<\/P>2.3 Millones de Entidades Puntuales<\/span><\/span><\/P>Mis datos están en 12 clases de entidad, puedes tener cualquier número.  El patrón que mostraré funciona con datos divididos en partes separadas que pueden ser procesadas concurrentemente.  Si tus datos son monolíticos entonces divídelos tú mismo espacialmente (

¿una malla orientada?) o añadiendo un campo que signifique un identificador de lote poblado por posición fila - puedes eliminar el campo durante el procesamiento.<\/P>

Mencioné los almacenes Snowflake, Big Query y Redshift.  En todos los casos puedes colocar archivos Parquet donde el entorno objetivo pueda verlos y luego cargar desde los archivos Parquet.  Para datos espaciales, los archivos Parquet necesitarán geometría codificada en un formato entendido por el entorno objetivo (Snowflake y Big Query soportan GeoJSON y WKT, Redshift soporta WKT).  Solo proporcionaré un ejemplo trabajado con GeoJSON hacia Snowflake.  Mis datos demo son geometría puntual y el campo que uso para almacenar el GeoJSON tiene un ancho de 100, si usas datos polilínea o polígono deberías investigar qué tan ancho es tu característica más rica en puntos al codificar el campo.  Por ejemplo seleccioné un polígono muy rico en puntos en una capa y como GeoJSON tiene 2,071,156 caracteres:<\/P>

 <\/P>

with arcpy.da.SearchCursor('NZ Property Titles','shape@') as cursor: