Con el paso de los años, han surgido varios patrones de arquitectura en el panorama tecnológico de la gestión de datos, todos ellos diseñados específicamente para adaptarse a diferentes casos de uso y requisitos. Entre estos patrones se incluyen los de almacenamiento centralizado, como data warehouse, data lake y data lakehouse, y los patrones distribuidos, como data mesh. Cada una de estas arquitecturas presenta sus propias ventajas e inconvenientes. Dado que históricamente las herramientas y plataformas comerciales solían diseñarse para alinearse con un patrón de arquitectura específico, las organizaciones lo han tenido complicado para adaptarse a las necesidades en constante cambio de los negocios. Esto, además, ha afectado a la arquitectura de datos.

En Snowflake, no creemos que recomendar un mismo patrón a todos los clientes vaya a satisfacer sus necesidades. En vez de eso, tratamos de ayudarlos ofreciéndoles una plataforma en la que crear arquitecturas según lo que funcione en su organización, aunque esto cambie con el paso del tiempo. Según las experiencias que hemos tenido con nuestros clientes, podemos decir que la ley de Conway se ha cumplido en la mayoría de los casos. Los casos de uso, las necesidades y la tecnología cambian, por eso la infraestructura de datos también debería poder escalarse y evolucionar. Nos comprometemos a ofrecer a nuestros clientes la opción y la capacidad de adaptarse sin comprometer nuestros principios fundamentales: seguridad y gobernanza sólidas, rendimiento excelente y sencillez.

Por ejemplo, aquellos clientes que necesitan un almacenamiento de datos centralizado para volúmenes grandes y variados ―como JSON, archivos de texto, documentos, imágenes y vídeos― han creado su propio data lake con Snowflake. Además, muchos clientes que cuentan con un repositorio diseñado para toda la empresa con tablas muy bien optimizadas para SQL, así como workloads e informes de inteligencia empresarial con altos niveles de simultaneidad, han creado un almacén de datos en Snowflake. Por otro lado, los clientes que necesitan algo a medio camino que sea compatible con diferentes herramientas y lenguajes han creado un data lakehouse. Otros muchos clientes prefieren que cada equipo maneje sus datos y cumpla con los estándares (en vez de que se encargue un equipo de datos central) para gestionar la infraestructura. Por eso, han utilizado Snowflake como plataforma para crear su data mesh.

Con el objetivo de satisfacer las necesidades en constante cambio de la gestión de datos, presentamos capacidades nuevas que ayudarán a los clientes con todos estos patrones.

La arquitectura de data lakehouse se ideó para combinar las ventajas de la escalabilidad y la flexibilidad de los data lakes con la gobernanza, la aplicación de esquemas y las propiedades transaccionales de los almacenes de datos. Desde el principio, la plataforma de Snowflake se ha presentado como un servicio que ofrece almacenamiento optimizado, procesamiento multiclúster elástico y servicios en la nube. Nuestro almacenamiento en tablas, desde que lo lanzamos en 2015, es un formato de tablas completamente gestionado que se ha implementado en el almacenamiento de objetos, similar a lo que hoy en día se conoce como código abierto en el mercado, como es el caso de Apache Iceberg, Apache Hudi y Delta Lake. Dado que el formato de tablas de Snowflake está completamente gestionado, funciones como Encryption, Transactional Consistency, Versioning y Time Travel se ofrecen automáticamente.

Mientras que muchos clientes valoran la sencillez de un sistema de almacenamiento completamente gestionado y un único motor de procesamiento multiclúster y para varios lenguajes que respalda los distintos workloads, muchos otros prefieren gestionar su propio almacenamiento mediante formatos abiertos. Por eso, hemos hecho posible la compatibilidad con Apache Iceberg. Aunque existen más formatos libres de tablas, creemos que Apache Iceberg es el principal estándar abierto líder en este tipo de formatos por muchos motivos. Por tanto, priorizamos la compatibilidad con este formato para ofrecer un servicio mejor a nuestros clientes.

Iceberg Tables (próximamente en vista previa pública) es un tipo de tablas único que ofrece la gestión sencilla y el buen rendimiento de Snowflake a la hora de almacenar los datos de forma externa en un formato abierto. También es más fácil y económico incorporar Iceberg Tables sin necesidad de realizar una ingesta de datos de antemano. Para que los clientes puedan incorporar Snowflake en su arquitectura con flexibilidad, Iceberg Tables se puede configurar de forma que utilice Snowflake o un servicio externo, como AWS Glue, a modo de catálogo de tablas para hacer seguimientos de los metadatos, con un comando SQL sencillo de una línea para pasarlas a Snowflake en una operación solo de metadatos.

Independientemente de la configuración del catálogo de Iceberg Tables, hay varios aspectos que no cambian:

• Los datos se almacenan de forma externa en los contenedores de almacenamiento proporcionados por el cliente.
• El rendimiento de las consultas de Snowflake es, de media, dos veces mejor que el de External Tables.
• Hay otras muchas funciones que se pueden utilizar, como Data Sharing, Role-Based Access Controls, Time Travel, Snowpark, Object Tagging, Row Access Policies y Masking Policies.

Además, cuando Iceberg Tables se sirve de Snowflake como catálogo de tablas para gestionar metadatos, se ofrecen muchas más ventajas:

• Snowflake puede realizar operaciones de escritura como INSERT, MERGE, UPDATE y DELETE.
• Se pueden llevar a cabo operaciones automáticas para mantener el almacenamiento, como compactar, consultar la fecha de vencimiento de las instantáneas y eliminar archivos huérfanos.
• Es posible crear clústeres automáticamente para realizar consultas más rápido (opcional).
• Apache Spark puede servirse del kit de desarrollo de software (software development kit, SDK) del catálogo de Iceberg de Snowflake para leer Iceberg Tables sin necesidad de utilizar recursos de procesamiento de Snowflake.

Un data lake es un patrón de arquitectura muy interesante por la capacidad del almacén de objetos para guardar prácticamente cualquier formato de archivo, de cualquier esquema, a gran escala y a un precio relativamente bajo. En lugar de definir el esquema de antemano, el usuario puede decidir qué datos y esquema necesita para cada caso de uso. Hace tiempo que Snowflake es compatible con tipos de datos semiestructurados y formatos de archivo como JSON, XML y Parquet. Más recientemente, ha incorporado la capacidad de almacenar y procesar datos no estructurados, como documentos PDF, imágenes, vídeos y archivos de audio. Independientemente del lugar en el que se almacenen los archivos, ya sea en el sistema de almacenamiento gestionado por Snowflake (nivel interno) o en el almacenamiento de objetos externo (nivel externo), contamos con nuevas funciones que respaldan estos tipos de datos y casos de uso.

Hemos ampliado nuestra compatibilidad con datos semiestructurados con la capacidad de inferir fácilmente el esquema de archivos JSON y CSV (disponible próximamente a nivel general) en un data lake. El esquema de los datos semiestructurados suele evolucionar con el tiempo. Los sistemas que generan datos añaden nuevas columnas para poder incluir información adicional, por lo que las tablas que reciben esos datos tienen que evolucionar en consecuencia. Para respaldar mejor esto, hemos añadido la compatibilidad con la evolución de los esquemas de las tablas (disponible próximamente a nivel general).

Para los casos de uso en los que haya documentos PDF, imágenes, vídeos y archivos de audio, también puedes utilizar Snowpark para Python y Scala (disponible a nivel general) a fin de procesar de manera dinámica cualquier tipo de archivo. Los ingenieros y científicos de datos se beneficiarán del motor rápido de Snowflake, que ofrece un acceso seguro a bibliotecas de código abierto para procesar imágenes, vídeos, audios y mucho más.

SQL es, sin duda alguna, el lenguaje que más se utiliza en los workloads de Data Warehouse. Además, seguimos intentando superar los límites de los tipos de procesamiento que se pueden realizar con SQL. Por ejemplo, gracias a la nueva compatibilidad con AS OF JOINs (próximamente en vista previa privada), los analistas de datos ya pueden realizar consultas mucho más sencillas que combinan datos de series temporales. Estos casos de uso son habituales en los servicios financieros y el Internet de las cosas (IdC), así como en casos de uso de ingeniería de funciones, en los que las uniones realizadas con marca de tiempo no coinciden completamente, sino que se aproximan al registro más cercano, ya sea el anterior o el siguiente. También vamos a mejorar la compatibilidad con las analíticas avanzadas en Snowflake ampliando el límite de tamaño de los archivos al cargarlos (próximamente en vista previa privada). Ahora puedes cargar objetos más grandes (de hasta 128 MB), ya que suelen ser necesarios en los casos de uso que implican el procesamiento del lenguaje natural y el análisis de imágenes y sentimiento.

Afianzamos nuestro compromiso de mejorar el rendimiento y ofrecer a los clientes oportunidades para ahorrar en costes. Gracias a las optimizaciones nuevas y perfeccionadas, los clientes experimentarán una mejora en el rendimiento y ahorrarán de varias formas:

• Las consultas ad hoc en almacenes relacionadas con casos de uso de aprendizaje automático (machine learning, ML) que hacen un uso intensivo de memoria son ahora más rápidas y rentables con Query Acceleration Service para Snowpark Optimized Warehouses (disponible a nivel general).
• Las sentencias SELECT que contienen las cláusulas ORDER BY y LIMIT son más rápidas, sobre todo en tablas grandes, con poda de top-k (próximamente disponible a nivel general).
• Los costes de mantenimiento de Materialized View se reducen en más de un 50 % con las nuevas eficiencias del almacén (disponibles a nivel general).
• Las consultas que emplean funciones que no son deterministas, como ANY_VALUE() y MODE(), entre otras, ahora se benefician de una caché de resultados que mejora el rendimiento. Según nuestro análisis, existen ciertos patrones de consultas que disminuyeron los créditos de los trabajos de las consultas afectadas en un 13 % (disponibles a nivel general).
• Las sentencias INSERT son más rápidas gracias a la compatibilidad añadida en Query Acceleration Service (en vista previa privada).
• Una nueva función ayuda a estimar de antemano, así como de forma continua, los costes de mantenimiento de los clústeres automáticos en una tabla concreta (en vista previa privada).

Nos entusiasma la idea de ofrecer estas capacidades nuevas a los clientes en una única plataforma para que puedan seguir desarrollando y adaptando la arquitectura que elijan con el Data Cloud. Contacta con el responsable de tu cuenta de Snowflake para solicitar acceso a las funciones mencionadas anteriormente que estén en vista previa privada. En cuanto a las funciones disponibles a nivel general o en vista previa pública, lee atentamente las notas de la versión y la documentación para obtener más información y poder empezar a utilizarlas.

Para obtener más información sobre la compatibilidad de Snowflake con los patrones de arquitectura descritos en esta entrada de blog, visita nuestras páginas de data warehouse, data lake, data lakehouse y data mesh.

¿Quieres ver estas funciones en acción? Echa un vistazo a la sesión del Snowday.

Declaraciones prospectivas
Este comunicado de prensa contiene declaraciones expresas e implícitas sobre previsiones de futuro, incluidas las declaraciones relativas a (i) la estrategia empresarial de Snowflake, (ii) los productos, servicios y ofertas tecnológicas de Snowflake, incluidos los que están en fase de desarrollo o no cuentan con disponibilidad general, (iii) el crecimiento del mercado, las tendencias y las consideraciones competitivas, y (iv) la integración, interoperabilidad y disponibilidad de los productos de Snowflake con y en plataformas de terceros. Estas declaraciones prospectivas están sujetas a una serie de riesgos, incertidumbres y suposiciones, lo que incluye pero no se limita solamente a los riesgos detallados en nuestros archivos con la Comisión de Valores y Bolsa. En vista de estos riesgos, incertidumbres y suposiciones, los resultados reales podrían diferir material y adversamente de los previstos o implícitos en las declaraciones prospectivas. Estas afirmaciones solo son válidas en la fecha en que se hacen por primera vez. Salvo que lo exija la ley, Snowflake no asume obligación alguna de actualizar las afirmaciones contenidas en este comunicado de prensa. En consecuencia, no se debe confiar en ninguna de las declaraciones prospectivas como predicción de acontecimientos futuros.  

Cualquier información sobre futuros productos incluida en este comunicado de prensa tiene por objeto esbozar la orientación general del producto. El lanzamiento real de cualquier producto, función o funcionalidad que finalmente se ponga a disposición del público puede ser diferente de lo que se presenta en este comunicado de prensa.