Este puede no ser tu problema exacto - cargar 100 millones de features en un servicio de features alojado en ArcGIS Online - pero el tema aquí es cargar big data en un servicio de features alojado en Online, 100 millones es la escala de la que estoy hablando.<\/P>
Aquí está cómo se ven 100,000,000 de features con la densidad con la que estoy trabajando.<\/P>
Un extent aproximadamente del tamaño de una manzana:<\/P>
Layer not visible<\/span><\/span><\/P>Luego activando la visibilidad de la capa:<\/P>Layer visible<\/span><\/span><\/P>Los datos<\/A> son tan grandes que Pro 2.9 no intentará mostrarlos a escalas menores que 1:500.<\/P>Aquí está la historia de fondo. Uno de los equipos de Esri con los que trabajo ocasionalmente aborda big data destinado a un servicio de features alojado en Online. La web siendo lo que es, las transacciones muy grandes de compartición pueden fallar debido a problemas de red u otros, momento en el cual tienes que recuperar la situación donde se rompió<\/EM> o volver a ejecutar todo el proceso de compartición<\/EM>. Querían un proceso que funcione confiablemente y con un mecanismo de recuperación para cualquier fallo. Iban por el camino de Python, lo cual está bien para los Pythonistas pero yo soy el tipo sin código en la oficina (digamos un coder en recuperación que ocasionalmente tiene lapsos). ¡ArcGIS Data Interoperability al rescate!<\/STRONG><\/P>Mis datos de prueba son un archivo CSV de 143,751,910<\/STRONG> filas.<\/P>Obtener conteo<\/span><\/span><\/P> <\/P>Tomé 100 millones de filas desde el principio solo como un número redondo agradable. Los datos tienen valores latitud/longitud así que el aspecto ETL es una habilitación espacial simple para crear features puntuales. Ahora, ¿cómo enviar estos a una capa de features puntuales?<\/P>Un paso preliminar fue tomar una muestra de los datos a file geodatabase y crear un servicio de features a partir de ella, esto solo instancia la capa objetivo. Luego el problema aguas abajo es doble:<\/P>Cargar los datos tan eficientemente como sea posible<\/LI>Usar una metodología que soporte recuperación ante fallos<\/LI><\/UL>El equipo Online sugirió un 'punto óptimo' para cargar datos a esta escala sería usar el endpoint Append<\/A> para el servicio de features con lotes de 500K registros en dos procesos concurrentes, y ejecutarlo 'fuera del horario laboral' hora US. Sin problema, aquí están mis espacios de trabajo:<\/P>LoadTaxis<\/span><\/span><\/P>LoadTaxis<\/STRONG> crea file geodatabases comprimidos con conjuntos de 500K registros<\/STRONG> y luego pasa la ruta del dato a LoadTaxisWorker<\/STRONG> en un máximo de dos procesos que corren asincrónicamente. Encontré que el tiempo que toma preparar los datos encaja bien con cuánto tarda Online en procesarlos, un poco menos de 2 minutos por lote durante horas de baja carga. Viendo pasar el archivo log, hubo algunas instancias donde LoadTaxis<\/STRONG> pausó esperando que un slot de proceso estuviera disponible, pero usualmente Online estaba listo para el siguiente lote, así que las cosas funcionaban tan rápido como mi ETL podía correr.<\/P> <\/P>LoadTaxisWorker<\/span><\/span><\/P>LoadTaxisWorker<\/STRONG> sube cada file geodatabase comprimido a Online y luego llama al endpoint Append<\/A> del servicio, iniciando una carga desde el nuevo ítem file geodatabase. Esto inicia un trabajo en Online. Un transformador personalizado en bucle verifica la finalización del trabajo cada 5 segundos (con un conteo máximo de chequeos de
Aquí está la historia de fondo. Uno de los equipos de Esri con los que trabajo ocasionalmente aborda big data destinado a un servicio de features alojado en Online. La web siendo lo que es, las transacciones muy grandes de compartición pueden fallar debido a problemas de red u otros, momento en el cual tienes que recuperar la situación donde se rompió<\/EM> o volver a ejecutar todo el proceso de compartición<\/EM>. Querían un proceso que funcione confiablemente y con un mecanismo de recuperación para cualquier fallo. Iban por el camino de Python, lo cual está bien para los Pythonistas pero yo soy el tipo sin código en la oficina (digamos un coder en recuperación que ocasionalmente tiene lapsos). ¡ArcGIS Data Interoperability al rescate!<\/STRONG><\/P>Mis datos de prueba son un archivo CSV de 143,751,910<\/STRONG> filas.<\/P>Obtener conteo<\/span><\/span><\/P> <\/P>Tomé 100 millones de filas desde el principio solo como un número redondo agradable. Los datos tienen valores latitud/longitud así que el aspecto ETL es una habilitación espacial simple para crear features puntuales. Ahora, ¿cómo enviar estos a una capa de features puntuales?<\/P>Un paso preliminar fue tomar una muestra de los datos a file geodatabase y crear un servicio de features a partir de ella, esto solo instancia la capa objetivo. Luego el problema aguas abajo es doble:<\/P>Cargar los datos tan eficientemente como sea posible<\/LI>Usar una metodología que soporte recuperación ante fallos<\/LI><\/UL>El equipo Online sugirió un 'punto óptimo' para cargar datos a esta escala sería usar el endpoint
LoadTaxis<\/span><\/span><\/P>LoadTaxis<\/STRONG> crea file geodatabases comprimidos con conjuntos de 500K registros<\/STRONG> y luego pasa la ruta del dato a LoadTaxisWorker<\/STRONG> en un máximo de dos procesos que corren asincrónicamente. Encontré que el tiempo que toma preparar los datos encaja bien con cuánto tarda Online en procesarlos, un poco menos de 2 minutos por lote durante horas de baja carga. Viendo pasar el archivo log, hubo algunas instancias donde LoadTaxis<\/STRONG> pausó esperando que un slot de proceso estuviera disponible, pero usualmente Online estaba listo para el siguiente lote, así que las cosas funcionaban tan rápido como mi ETL podía correr.<\/P> <\/P>LoadTaxisWorker<\/span><\/span><\/P>LoadTaxisWorker<\/STRONG> sube cada file geodatabase comprimido a Online y luego llama al endpoint
En realidad, prefiero ejecutar la herramienta LoadTaxisWorker en modo de edición (es decir, en Workbench) para poder hacer cosas como activar los Emailers y capturar la acción en detalle. También hay este problema a tener en cuenta que pondré en una etiqueta de spoiler:<\/P>
Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate gratis.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
