En todas partes, las organizaciones de TI están buscando en la nube para resolver sus problemas de almacenamiento de datos, movimiento y análisis … y ¡con buena razón! Los servicios en la nube de Amazon, Google, Microsoft y otros han revolucionado la forma en que pensamos sobre los datos, desde una perspectiva de TI y del usuario final.

Han reducido enormemente la función del centro de datos corporativo, que rara vez es una competencia central de la organización. Han democratizado el acceso a datos, análisis y poder de procesamiento. Han interrumpido nuestra forma de pensar acerca de los costos relacionados con el almacenamiento de datos y los análisis.

La nube es todo esto y más, por lo que no es de extrañar que muchas organizaciones se apresuren a llevar sus operaciones de big data a la nube.

El ahorro de costos, la mejora del rendimiento y las operaciones simplificadas están muy bien, pero ¿qué sucede cuando realmente se pone a trabajar?

Es probable que sus ingenieros de datos sean nuevos en cualquier tecnología de nube que su organización decida utilizar. Este artículo detalla mi propia experiencia como ingeniero de datos al estar expuesto a Google BigQuery (GBQ) por primera vez.

He sido ingeniero de datos durante muchos años y he trabajado con la mayoría de los tipos de RDBMS y SQL en mi carrera. Un proyecto reciente hizo que mis compañeros de trabajo y yo rediseñáramos una base de datos de SQL Server existente en GBQ, lo que me inspiró a escribir este artículo como un recurso para otros ingenieros de datos nuevos en GBQ.

Aquí hay algunas cosas que pueden tardar en acostumbrarse, junto con estrategias de mitigación donde las he encontrado:

• Sensibilidad al caso

  - A diferencia de la mayoría de los RDBMS, Google BigQuery distingue entre mayúsculas y minúsculas, no solo para la comparación de cadenas, sino para el objeto nombres también Para la comparación de cadenas, el uso de la función SUPERIOR en ambos lados (o un lado de la comparación con un literal) eliminará el efecto de la sensibilidad a las mayúsculas y minúsculas. Curiosamente, aunque los nombres de objetos distinguen entre mayúsculas y minúsculas cuando se hace referencia en una cláusula FROM, los nombres de columna no distinguen entre mayúsculas y minúsculas.

• Nombres de objetos totalmente calificados

  todos los nombres de objetos a los que se hace referencia en la cláusula FROM deben estar completamente calificados para el nivel de conjunto de datos, o el nivel del proyecto si no existen en su proyecto de facturación actual. No solo eso, sino que todo el nombre completo debe incluirse entre comillas simples al revés (generalmente comparte una clave con la tilde). Absolutamente pasará varios minutos frustrados en algún momento, tratando de averiguar por qué los errores de una consulta se dan cuenta de que una de esas citas no se parece a la otra.

• SQL estándar vs. SQL heredado

  - Google BigQuery tiene dos tipos de SQL, por alguna razón. El SQL estándar es muy parecido al ANSI SQL y es lo que debe usar. Sin embargo, la clásica interfaz de usuario web de Google BigQuery(que prefiero por razones que describiré en breve) tiene como valor predeterminado el legado de SQL. Hay una opción para usar SQL estándar, y también hay una extensión de Chrome llamada Google BigQuery Mate que te permitirá omitir ese paso.

• No hay procedimientos almacenados o funciones

  - Este es uno grande y realmente no hay una forma fácil de evitarlo. Google proporciona herramientas con las que hacer ETL y la transformación y preparación de datos, pero no ofrecen la flexibilidad de codificar sus propios procedimientos. Se pueden crear funciones, pero son temporales, solo existen para una sola sesión, lo que las hace muy limitadas como herramienta de programación.

• Interfaz de usuario clásica frente a Nueva UI

  - La interfaz de usuario clásica (la que se parece a Gmail) tiene una gran ventaja, ya que le permite agregar un proyecto para el que no tiene acceso explícito al objeto. navegador. Por alguna razón, la nueva interfaz de usuario no tiene esa característica. Sin embargo, lo hace de manera predeterminada a SQL estándar, lo que puede ahorrarle algunos dolores de cabeza. Ambos están bien, pero ninguno es perfecto.

• Sin estimaciones del plan de consultas

  : debe preguntarse si el responsable de la división de Servicios en la nube de Google fue un médico en una vida pasada. ¿Qué otra industria realizaría un servicio sin explicar el costo primero? Eso es esencialmente lo que Google está haciendo aquí, aunque de una manera menos depredadora. En pocas palabras, no hay manera de determinar si su consulta compleja se ejecutará de manera eficiente hasta que realmente la ejecute. Una vez que ejecuta la consulta, el plan de ejecución es realmente muy útil y práctico.

• Capacidad DDL limitada

  - Existe una capacidad muy pequeña para alterar una tabla una vez que existe. No puede eliminar una columna o cambiar un tipo de datos. No puedes renombrar campos o tablas. Casi cualquier operación de alteración de tabla o vista implica un tipo de operación “CREAR TABLA COMO SELECCIONAR”, lo que significa que técnicamente terminará con una tabla o vista “nueva”.

Me imagino que al leer esa lista, parece que estoy despreciando bastante a Google BigQuery. Ese no es el caso en absoluto. Estas son, en su mayor parte, las molestias que los nuevos desarrolladores de GBQ encontrarán y superarán. En realidad, también hay mucho que gustar.

Aquí hay algunas sorpresas agradables que encontré durante mi primer proyecto de GBQ:

• Expiración automática de objetos

  - Esta es para el DBA perezoso que siempre tiene 25 tablas temporales cubiertas de polvo en la esquina de su base de datos. En GBQ, puede (y debe) crear un conjunto de datos y especificar una vida útil corta del objeto. De esta manera, puede tener un entorno de recinto de seguridad que se limpia solo y no tiene que preocuparse por incurrir en cargos de almacenamiento adicionales para los datos que ya no necesita.

• Historial de consultas

  - GBQ registra todas las consultas que ejecuta para fines de facturación, por supuesto, pero también las expone a usted en una lista de fácil búsqueda. Esto puede ser extremadamente útil si alguna vez pierde el rastro de un fragmento de código, lo que nos sucede a los mejores de nosotros.

• Resultados de consultas en caché

  - Google cobra por almacenar datos y, en la mayoría de los casos, por recuperarlos también. Si eres como yo, puedes encontrarte ejecutando la misma consulta periódicamente durante el desarrollo. GBQ almacenará en caché esos resultados de manera predeterminada y su proyecto no se cobrará. Hay una opción para desactivar esta función en las opciones de la interfaz de usuario web si lo desea.

• Autocompletar

  La mayoría de las herramientas de consulta, como TOAD o SQL Management Studio, completarán automáticamente los nombres de las tablas y las columnas con diversos grados de éxito. He encontrado que la interfaz de usuario web GBQ autocompletar

• Creación de tablas basadas en GUI

  - A veces solo necesitas crear una tabla pequeña rápida para almacenar parámetros o algo así. La interfaz de usuario web de GBQ permite a un usuario sin conocimientos de SQL la posibilidad de crear una tabla y agregar columnas de varios tipos de datos.

El resultado final es que GBQ tarda un poco en acostumbrarse y aún tiene uno o dos vacíos de funcionalidad evidentes, principalmente relacionados con la incapacidad de crear procedimientos o funciones almacenados. Sin embargo, los beneficios potenciales del almacenamiento y análisis de datos en la nube superan con creces estas consideraciones. Continúo aprendiendo nuevos métodos abreviados y técnicas todos los días y, a medida que supero los pequeños desafíos, puedo ver el brillante futuro “nublado” frente a mí.

Bio: Josh Levy es un gerente en la práctica analítica de aspirante. Ha pasado los últimos 20 años trabajando en diversas capacidades e industrias dentro del espacio de Business Intelligence. Para obtener más información, visite, www.aspirent.com .

Relacionado: