martes, 4 de noviembre de 2008

Best Practices en QlikView: cuando empieza a crecer el número de documentos en el servidor


En mi empresa llevamos 5 años utilizando QlikView como he comentado en algún otro artículo y puedo asegurar que cuando lo compré no tenía la más remota idea de lo que podría llegar a convertirse para ciertas personas y los problemas que iba a lucionarso con este producto. Lo compramos un poco para probar como aquel que dice.


Como todo, esta situación tiene un lado bueno, y otro malo.

El bueno: la de pasta gansa que nos hemos ahorrado en horas de programación de informes con el sistema operativo actual.

La mala: esto ha llevado a una situación un tanto caótica en cuanto al volumen de documentos que hemos llegado a generar y, en bastantes casos, el volumen se mide en cientos de MB comprimidos.


Otro factor siempre presente en nuestra vida, además del tener que comer, dormir, y...., son las prisas. Este último factor nos ha llevado a la situación que actualmente tenemos: infinidad de documentos que no están relacionados entre sí, que se recargan de forma separada cada día, con información redundada y que comienza a hacerse insostenible sus modificaciones (campos, tablas, etc). Con lo cual me enfrento, después de una cierta experiencia, con problemas de "sostenibilidad". La versión 32 bits además acentúa los problemas de los usuarios con algunos problemas de memoria ajenos a QlikView y que son imputables a la arquitectura de gestión de la memoria en máquinas windows de 32 bits (en fin, otro cantar).


Por resumir, inconvenientes:


  • Una lista de tareas programadas interminable recargando documentos diariamente, incluso cada hora.

  • La información está redundada en algún caso más de 15 veces (por ejemplo, la tabla "ARTICULOS")

  • Modificar, añadir, o eliminar un campo de una tabla (ARTICULOS por ejemplo) supone repetir n veces la modificación de este campo en cada documento que contenga esta tabla. En algún caso, los documentos han sido hechos por personas diferentes con lo que os podéis imaginar.

  • Las estructuras internas de tablas son diferentes en distintos documentos. Esto supone un problema sobre todo cuando se dispone de licencias Profesional o Enterprise (o en la versión nueva 8.5 si se habilita la creación de objetos compartidos de servidor) y los usuarios pueden ver los campos. Imaginad explicar a un usuario diferentes arquitecturas para la misma BD, un desastre...

  • No queda ventana de horas disponible por la noche para ejecutar todas las recargas de documentos. Ejemplo: 10 documentos que tarden 1 hora en recargarse = 10 horas.

Todos estos problemas y algún otro más, los hemos pasado en mi empresa por lo que voy a intentar hacer una especie de documento de buenas prácticas (o "Best Practices") para la creación y mantenimiento de numerosos documentos en un servidor. Me gustaría no ser el único que hace anotaciones en esta entrada y que aportéis vuestras ideas o soluciones:


"Best Practices" para la sostenibilidad de documentos grandes de QlikView:



  1. Piensa antes de hacer. Creo que el más importante. Pensar y estudiar lo que se pretende con el documento y si ya tenemos otro con datos similares. Es posible que convenga ampliar el existente y no crear uno nuevo.

  2. Archivos QVD. QlikView hace ya tiempo que inventó estos archivitos. La ventaja es que los recargas una vez y que tarde lo que tarde. Desde tu nuevo documento de QlikView puedes recargar tablas enteras alojadas en estos archivos QVD como si se tratasen de un excel o archivo de texto, con las siguientes ventajas: 1.- Velocidad (es entre 10 y 100 veces más rápida la recarga de un archivo QVD que un equivalente en otro formato) y 2.- La estructura de campos es única y hay un único punto de mantenimiento.

  3. Recargas Parciales: Es aconsejable utilizar la sentencia "Partial Load ..." para ganar en velocidad de recarga.

  4. Invierte más horas en el script de carga y menos en formulación extraña en los objetos y en código en el editor de módulo: Ganarás en velocidad de cara al usuario al tener el dato ya pre-calculado. Créeme, el usuario notará que vuela al hacer selecciones, bookmarks, etc...

  5. Utiliza la sentencia $(include=""). Puedes dejar fuera de QlikView fragmentos comunes entre varios documentos para que modificarlo sea cosa de abrir el notepad. Además (que me perdone la gente de QlikView) pero otras personas de tu departamento podrán mantener código de script genérico sin necesidad de tener acceso a la aplicación (evidentemente nos ahorramos unas pelillas...;-). Ni que decir tiene que deben primero controlar y conocer lo que tocan...

  6. Oculta las pestañas. Esto se lo ví a un gran amigo (http://http://www.cmigestion.es/) y me dió la idea perfecta para documentos de mucho contenido (muchas pestañas). Una primera hoja con una especie de menú te va a permitir que el usuario navegue de una forma controlada para obtener lo que necesita, frente a mostrar todas las pestañas y que vaya entrando en información que no le es necesario en ese momento. (Estoy preparando un documento que explique esto para una próxima entrega).

  7. Los nombres de campos claritos: Sobretodo si sois varias personas manteniendo los documentos. QlikView tiene la posibilidad de cualificar o no los campos de las tablas. Una buena especificación a la hora de llamar a los campos por su nombre puede ahorrarnos muchos dolores de cabeza, os lo aseguro. Los campos del tipo "CArtN" son menos descriptivos que "Costo Neto Articulo". Es triste decirlo pero más triste es robar ;-)

  8. NO al editor de módulo: QlikView desaconseja encarecidamente su uso salvo excepciones, claro está. Entre que el editor no lo tienen muy currado y que en posteriores versiones no te garantizan al 100% su correcto funcionamiento, muerto el perro, se acabó la rabia...

  9. Be graphic, my friend... Uséase, que como todo en esta vida, es importante hacerlo bien, pero casi más importante es venderlo bien. ¿No conocéis el típico en la empresa que no hace grandes cosas pero que las sabe vender?. Si tenéis un departamento de diseño gráfico o, simplemente alguien con un poco de gusto estético, no dejar al informático de turno hacer con vuestra obra de arte a presentar a dirección, un cuadro de Miró (con todos mis respetos...).

  10. Let's Backup. Backup, backup y más backup....

Estos son consejos a la hora de hacer un documento. A la hora de montar la estructura de carpetas NTFS en el server yo lo tengo montado de la siguiente forma:


RAIZ



  • QVD (carpeta con archivos QVD)

  • SCRIPTS (carpeta con permisos NTFS selectivos para modificar partes de ciertos script de carga)

  • DOCUMENTOS (esta es la carpeta pública a la que tienen acceso los usuarios y que contiene a su vez, subcarpetas y archivos QVW)

  • LOGS (carpeta con archivos logs del servidor, archivos .mem, etc...)

Esta parte es un ejemplo pero que podéis montarlo cómo queráis. QlikView tiene más opciones como la posibilidad de montar en el servidor de QlikView otras carpetas con rutas diferentes.


Un saludo

7 comentarios:

Sirdarkmod dijo...

Buenos dias, excelente comentario sobre la organizacion, nosotros como llevamos poco tiempo trabajando con el QV lo tenemos ahora mas o menos controlado aunque cierto es que me gustaria montar una arquitectura mas definida.
Pero si es verdad que debo buscar mas informacion sobre lo que has dicho de ocultar pestañas, te pongo un ejemplo.
En uno de los ficheros que tenemos aqui, para el jefe tiene un numero determinado de pestañas y para dos de los encargados tiene menos, el problema que tengo es que como es el mismo pero mas capado tengo dos archivos y cuando modifico uno tengo que ir a modificar el otro...Consultare tambien el blog que mencionas, a ver si encuentro ayuda al respecto
Saludos....

Carlos Gutierrez dijo...

Hola.
Si creo entenderte, lo que tienes son 2 documentos de Qlikview, ¿no?, donde son idénticos el uno y el otro pero con distintos accesos (usando permisos NTFS), ¿no?. Corrígeme si me equivoco.

Yo te propongo lo siguiente:
Creas un único documento (para solo mantener uno) y si las fuentes de datos de los que se recarga son los mismos, méte en el script de carga una sección de Acceso (utilizando "Section Access" y "Section Application").
Los usuarios tendrán que introducir un usuario y un pass al entrar y QlikView recargará más o menos datos en función de este.
Además, también puedes ocultar una pestaña entera en función del valor de una variable que dependa del usuario introducido.
Para ocultar las pestañas (esto es ocultar todas las pestañas del documento, pero no las hojas, cuidadín!) es tan simple como ir a "Propiedades del documento > pestaña general " y clic en "Ocultar pestañas".
Ocultar pestañas no impide que el usuario llegue a otra pestaña por otros medios (navegador de hojas, por ejemplo...).

De todos modos, este ejemplo que tú planteas, si me das algo más de información, te puedo publicar un ejemplo completo con sección de acceso y restricciones de usuario, pestañas, y objetos esta misma noche (cuando llegue a casa).

Un saludo y gracias por seguir el blog

Francisco Páez dijo...

Hola Carlos,

Como se nota que te gusta el tema. Muy buena la lista de "Best Practices". Cuando tenga un ratito (uuffff...) haré una lista de problemas raros que he ido resolviendo, por si quieres añadirlo a tu "Manual".

Saludos.

Francisco Páez
www.cmigestion.es/blog

Anónimo dijo...

a simple vista la empresa es un desorden, pero no por qlikview, no puedes recargar a cada 1 hora, que software te va a aguantar eso?
Quien lo habra implementado?

qe mala fama le hacen a qlikview.

Carlos Gutierrez dijo...

Perdona "anónimo" por el retraso, en fin...

cita:"qe mala fama le hacen a qlikview"

Perdona "anónimo" pero creo que no has leido más artículos de mi blog ya que hoy por hoy no puedo tener palabras que no sean buenas para QlikView y precísamente es lo que intento con el blog, recomendarlo como me lo recomendaron otras personas en su día.
Ahora bien, la realidad de un departamento de sistemas es muy diferente según qué empresas. Es decir, nunca me ha gustado valorar el trabajo de otros a primera vista y menos jurgar ya que, si se hace el pequeño esfuerzo de tener algo de empatía, seguramente se podría llegar al mismo resultado, mejorarlo o, empeorarlo.

Lo que quiero decir es que, el artículo publicado, son consejos para aquellos que el día a día les ha llevado a un crecimiento "no sostenible" de sus archivos QV.

Os recomiendo un blog muy bueno de metodología ASM (http://metodologiaasm.blogspot.com) que es la metodología que se utiliza en una gran mayoría de empresas. Otras, por contra, tienen suerte y se respetan los tiempos, las fases de un proyecto, se definen requerimientos, el alcance, objetivos, se valoran herramientas, se dota de recursos en exceso, ... pero esto no es así en otras tantas empresas.

Así que, para aquellos que se encuentren en la misma situación, estoy seguro que les será de ayuda. Al resto, creo que no merece la pena que lean esto, no va para ellos.

Un saludo y feliz año nuevo.

Unknown dijo...

Buenas,

Personalmente me parece buenísimo el artículo que has escrito, y habrán cosas que utilizaré.

Te quisiera hacer un apunte con respecto a las recargas, yo tengo un montón de documentos, y me pasaba lo mismo hasta que hice una pequeña trampa: Tengo un .bat donde pongo las instrucciones de recarga, y así me realiza las recargas secuenciales, y nunca se solapan en el tiempo.
Antes eran varias horas, y ahora en 1 hora me las realiza todas.

Un saludo.

iPokme dijo...

Hola quisiera saber como generar una base en QV con documentos de SAP directamente desde el server. Y por ultimo como generar instrucciones de sum, vista, etc para generar graficos, ayudaaaaaaa por favor, saludossssssssssssssss