Arquitectura en la Nube y Base Gobernada

Para una base gobernada en Snowflake, ponemos el primer valor en producción en 8 a 16 semanas. El mecanismo importa más que el número: un discovery fija el scope desde el inicio, la entrega corre en sprints por caso de uso y cada pieza se comprueba antes de escalar. Un ambiente completo toma más tiempo, pero nadie espera hasta el final para ver productos de datos funcionando.

Es una auditoría estructurada de un ambiente Snowflake existente: topología de cuentas, diseño de seguridad y accesos, los drivers de costo y la confiabilidad de los pipelines, evaluados contra la forma en que Snowflake está hecho para operar. Queda una lista de hallazgos priorizada y con el razonamiento documentado, para que el equipo interno la ejecute con nosotros o por cuenta propia.

Iceberg tiene sentido cuando otros motores necesitan leer las mismas tablas, cuando el volumen de datos empuja hacia la economía del almacenamiento abierto o cuando la organización adopta formatos abiertos como política. Open Catalog (Polaris) mantiene esas tablas gobernadas en cualquier caso. Si las cargas de trabajo viven de punta a punta en Snowflake, las tablas nativas suelen ser más simples; en el discovery lo decidimos con evidencia, no por default.

El gobierno de datos en Snowflake se hace cumplir como configuración sobre los datos, no como un documento de políticas. El control de acceso basado en roles se modela según la organización, para que cada persona vea solo los datos que necesita, aplicado en Snowflake y no añadido después, y los datos sensibles se clasifican y enmascaran con etiquetado y políticas de fila y columna desde la primera tabla que se construye. Horizon Catalog lleva el linaje y el historial de accesos, así que cada número es rastreable hasta su origen y cada acceso queda registrado para auditoría. Todo se ejecuta en la cuenta de Snowflake del propio cliente, así que ninguna copia sale de ese perímetro.

Un golden record se construye por capas dentro de la propia cuenta de Snowflake del cliente. Los datos de origen llegan a Bronze, se limpian y conforman en Silver, y se resuelven en registros Gold gobernados, con claves maestras, emparejamiento y fusión, reglas de survivorship, linaje y auditoría diseñados desde la primera tabla. Todo el modelado se ejecuta en dbt bajo Git, de modo que cada regla que decide qué valor sobrevive se revisa, se prueba y es trazable. En un grupo de concesionarios de vehículos comerciales, Openflow carga el ERP, el dealer management system y el sistema de nómina y recursos humanos con una programación incremental nocturna, y produce una sola versión gobernada de cliente, vehículo, repuesto, proveedor y empleado, cada una trazable hasta su origen.

Los dominios de datos maestros se consolidan de forma secuencial, así que cada uno alcanza un golden record confiable por turno y no todos a la vez. En la base de datos maestros de un grupo de concesionarios de vehículos comerciales, ocho dominios de negocio, desde posventa y catálogos de repuestos hasta finanzas y recursos humanos, se entregan en tres lanzamientos a lo largo de una hoja de ruta de doce meses. Las pruebas de dbt validan el emparejamiento, el survivorship y la conformidad en cada ejecución, de modo que un registro defectuoso se detecta antes de llegar a Gold y cada dominio sigue siendo confiable después del lanzamiento que lo creó.