Snowflake IPADDRESS: una IP, varias redes

Una dirección IP puede estar perfectamente validada y acabar asignada a dos departamentos. El fallo no tiene por qué estar en el dato: una dirección pertenece a una subred y también a las redes más amplias que la contienen. Si cruzamos un registro de tráfico con todas ellas, varias coincidencias pueden ser correctas. Lo que todavía no hemos decidido es cuál debe recibir el consumo.

La nueva preview de IPADDRESS en Snowflake 10.38, cuya nota final se publicó el 22 de octubre de 2026, vuelve pertinente esta distinción. Facilita trabajar con direcciones como valores de red, en lugar de cadenas de texto. Pero una representación mejor no decide el significado del cruce.

Para atribuir un evento de red necesitamos una dirección, el espacio en el que existe, el instante de referencia y una regla para resolver coincidencias múltiples. El tipo nativo ayuda con la primera parte. Confundirla con las otras tres puede producir una consulta técnicamente impecable y una imputación equivocada.

Qué cambia al dejar de comparar texto

Según la documentación de IPADDRESS, el tipo representa IPv4 e IPv6 mediante valores de 128 bits, valida las entradas y compara en orden numérico. Conserva la dirección, no su escritura original. Una dirección IPv6 expandida y su forma comprimida pueden representar el mismo valor. El tipo contiene una dirección individual; el prefijo o los extremos de un rango deben modelarse aparte.

La normalización textual de IPv6 tampoco nace con esta función: la RFC 5952, de agosto de 2010, ya definía una representación canónica para reducir variantes de escritura. Lo nuevo aquí es disponer de un tipo nativo de Snowflake que participa en comparaciones y cruces de rangos.

Esto elimina una clase de errores: tratar dos escrituras como dos direcciones o suponer que ordenar cadenas equivale a ordenar direcciones. No elimina una clase distinta: obtener varios candidatos válidos para el mismo evento. Acelerar ese cruce solo nos permite producir antes la ambigüedad.

Una coincidencia múltiple no siempre es un duplicado

Consideremos este pequeño catálogo de ejemplo: la red 192.0.2.0/24 representa un entorno completo y 192.0.2.128/25 una de sus áreas. La dirección 192.0.2.200 pertenece a ambas. Un evento de diez unidades de consumo genera dos coincidencias si buscamos todas las redes que lo contienen.

Si el objetivo es mostrar pertenencia jerárquica, conservar ambas filas puede ser correcto. Si pretendemos repartir esas diez unidades entre centros de coste, sumarlas en las dos filas produce veinte unidades atribuidas. El error aparece al convertir una relación de pertenencia en una distribución económica sin haber definido esa transformación.

Eliminar filas repetidas no responde a la pregunta. Las dos redes son diferentes y ambas contienen la dirección. Tampoco basta con quedarse con la primera fila: sin una prioridad semántica, el orden del resultado no constituye una política de asignación.

Podemos elegir la red con el prefijo más específico. Es una regla defendible cuando el catálogo representa una jerarquía de responsabilidad y sus excepciones se expresan mediante subredes. No es una regla universal: una red más pequeña puede representar una ubicación física, mientras que otra clasificación representa al equipo que paga. La precisión geométrica no concede autoridad contable.

El espacio de direcciones forma parte de la identidad

La siguiente dificultad aparece incluso cuando hemos resuelto los prefijos. Dos entornos aislados pueden reutilizar la misma dirección privada. Si un catálogo reúne redes de clientes, laboratorios o entornos separados, la igualdad de IP no basta para afirmar que se trata del mismo origen.

La clave analítica debe incluir el ámbito pertinente: por ejemplo, entorno y dirección. Ese ámbito tiene que proceder de una fuente fiable del evento. Añadir después una etiqueta inferida a partir de la propia IP reconstruye exactamente la ambigüedad que queríamos evitar.

También importa el tiempo. Una asignación puede cambiar de responsable sin que cambie la red. Para explicar un evento pasado debemos decidir si queremos la responsabilidad vigente cuando ocurrió o la organización actual. Ambas consultas pueden ser útiles; producen respuestas distintas. Un cruce que ignora la vigencia adopta una de ellas accidentalmente.

En el análisis de backfills aparece esa diferencia entre pasado observado y reinterpretación presente. En redes, se concreta en algo muy material: qué versión del catálogo tuvo derecho a asignar cada evento.

Cuatro decisiones antes de elegir una red ganadora

Propongo separar el contrato del cruce en cuatro preguntas. Así podemos discutir el modelo sin esconder decisiones de negocio dentro de una ordenación de filas.

¿Pertenencia o atribución?

Decisión que debe quedar explícita: Conservar todas las coincidencias o escoger/repartir entre responsables.

Señal de un modelo incompleto: La suma cambia al añadir una red contenedora.

¿Dentro de qué ámbito?

Decisión que debe quedar explícita: Identificar el espacio de red antes del cruce.

Señal de un modelo incompleto: Dos entornos aislados compiten por el mismo evento.

¿Vigente cuándo?

Decisión que debe quedar explícita: Elegir tiempo del evento o reinterpretación actual.

Señal de un modelo incompleto: Un cambio del catálogo modifica el histórico sin explicación.

¿Cómo se resuelve el empate?

Decisión que debe quedar explícita: Prioridad justificada o conflicto pendiente.

Señal de un modelo incompleto: Un orden arbitrario decide quién recibe el consumo.

La función IPADDRESS_TRUNC permite obtener la dirección de red para un prefijo, conservando sus bits iniciales y poniendo a cero los del host. Es una herramienta para construir pertenencia. La política que convierte esa pertenencia en un ganador sigue siendo nuestra.

Para una atribución exclusiva, exigiría que cada evento terminara en un responsable o en un estado de conflicto visible. No aceptaría que una segunda coincidencia desapareciese silenciosamente. Para pertenencia múltiple, exigiría que la capa de consumo supiese que las categorías se solapan y no presentase sus sumas como un reparto aditivo.

Qué merece probar esta preview

Mi evaluación empezaría por un catálogo pequeño que contenga redes anidadas, dos ámbitos que reutilicen dirección, un cambio de responsable y un empate sin prioridad. Su valor está en comprobar qué respuesta produce el modelo cuando varias coincidencias son legítimas. Un conjunto grande con redes disjuntas puede dar mucha confianza y poner a prueba muy poca semántica.

La documentación consultada mantiene limitaciones, entre ellas la falta de soporte del tipo en Snowpark y como columna de tablas Iceberg. Además, Snowflake presenta sus funciones preview para evaluación y pruebas, no para sistemas o datos de producción. Por tanto, esta novedad justifica un laboratorio aislado y una revisión del modelo; no una migración inmediata de la imputación productiva.

La mejora interesante no consiste en sustituir VARCHAR por un nombre más preciso. Consiste en poder explicar por qué dos redes coinciden, cuándo debemos conservar ambas y qué evidencia autoriza a elegir una. Si esa explicación no existe, el tipo nuevo ordenará las direcciones; la responsabilidad seguirá desordenada.