El tema del trabajo era business intelligence, basándose en datos de un típico Video Club. Estaba todo planeado para usar una base de datos IMB DB2, hacer el ETL también con un producto de IBM que no recuerdo el nombre y finalmente acceder a todo eso desde Microstrategy.
Entre los integrantes del grupo para hacer el TP estaba Juan F. Codagnone y como él la tiene muy clara con PostgreSQL quisimos probar con eso. Al fin y al cabo, DB2 es una mierda total, super lenta y con una interfaz horrible y llena de bugs (yo me pregunto a quién se le ocurre pagar por eso hoy en día). Encontramos que Microstrategy había incorporado soporte para bases de datos Open Source y le dimos para adelante.
Todo el trabajo sobre PostgreSQL resultó genial. Tuvimos un warehouse con ETLs hechos a mano (mezcla de scrips de bash, awk y un poco de SQL, en su mayoría hechos por Juan) en poco tiempo y sin problemas.
El problema fue con Microstrategy. Usamos Microstrategy versión 8.0.2 y PostgreSQL versión 8.1.5-1, todo en Windows como decía Microstrategy que soportaba.
Microstrategy tiene unas consultas SQL que utiliza para tomar la metadata de las tablas de la base (léase nombre de las tablas y nombres y tipos de las columnas). De entrada el SQL para levantar los nombres de las tablas tenía errores de sintaxis. Este es el SQL original:
SELECT DISTINCT
TABLE_CATALOG as NAME_SPACE,
TABLE_NAME as TAB_NAME,
COLUMN_NAME as COL_NAME,
DATA_TYPE as DATA_TYPE,
CHARACTER_MAXIMUM_LENGTH as DATA_LEN,
NUMERIC_PRECISION as DATA_PREC,
NUMERIC_SCALE as DATA_SCALE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME IN ('#TABLE_LIST#') Order by 1,2,3
El
#TABLE_LIST# es reemplazado por el nombre entre comillas simples de la tabla que se busca, por ejemplo 'lu_peliculas' (el prefijo lu_ es una convención para referenciar a las tablas de lookup). Cuando reemplazaba en el SQL original quedaba ...TABLE_NAME IN (''lu_peliculas'')... y daba error por las comillas simples repetidas.Solucionado este inconveniente (por suerte el SQL ese es personalizable), había otro. En la consulta mencionada dice
TABLE_CATALOG as NAME_SPACE y en la consulta que utiliza para buscar las tablas dice TABLE_SCHEMA as NAME_SPACE. Como TABLE_SCHEMA no es lo mismo que TABLE_CATALOG (y Microstrategy internamiente los asociaba como lo mismo), luego tenía tablas que para él no tenían columnas.Al corregir ese problema surgieron más. No nos detectaba bien los tipos de datos de las columnas. Sólo detectaba bien los tipos
date, con lo cual luego nos llenaba de errores de Unknown type.Ya estábamos por mandar todo al carajo y rendirnos a usar la mierda de DB2 cuando se nos ocurrió ver qué pasaba si creabamos nuestro catálogo de tablas en MySQL y hacíamos que microstrategy tomara la metadata de allí. Esto fue finalmente la solución. No podíamos pasar todo a MySQL porque en nuestros SQL estábamos usando algunas cosas que PostgreSQL soporta y MySQL, no. Pero, para reconocer a las tablas y sus columnas, a Microstrategy le alcanzaba con que estuvieran creadas las tablas. Una vez reconocido todo, podíamos cambiar la conexión de la base y que hiciera los SELECTs a PostgreSQL (los SELECTs son la especialidad de Microstrategy).
Como conclusión, me parece una vergüenza que Microstrategy anuncie que soporta bases Open Source cuando al intentar usar una de ellas pareciera que ni siquiera la probaron (como dije antes, el SQL generado tenía errores de sintaxis). Por suerte pudimos solucionarlo, pero fue algo que nos quitó mucho tiempo y que nos hizo odiar un poco a Microstrategy. Lo que sí hay que reconocer es que una vez que Microstrategy está bien configurado, es una herramienta potentísima para extraer datos y generar reportes de todo tipo.
Cabe aclarar que la versión de Microstrategy que utilizamos corresponde a una demo que nos dio la gente de Microstrategy en DVD. Es probable que haya algún fix posterior a esa versión que solucione estos inconvenientes, pero no lo se. De todas formas, que el script de SQL ni siquiera compile es impresentable.
No hay comentarios.:
Publicar un comentario