"Estoy aprendiendo Tensorflow pero no entiendo, se me dificulta aprender"

La frase que da el título a este post es una frase que he escuchado ya varias veces en los últimos meses  y personalmente creo que no es problema del framework(o de otros similares con el mismo problema)  entonces espero con este post ayudar a través de ciertas recomendaciones a personas en esta situación .

Aun que en la actualidad(2019) Tensorflow se ha vuelto cada vez mas amigable y accesible integrando APIs de alto nivel como Keras esto no ha sido siempre así(cuando empece a usar TF en 2015 todo era bajo nivel salvo el wrapper "skflow" que buscaba dar a TF la sencillez en API de scikit-learn y que ahora ha sido integrado a TF en el subpaquete "contrib")y de todas maneras existen aún con APIs de alto nivel en algún momento nos podemos encontrar con operaciones de bajo nivel que pueden en un inicio parecer complicadas.

Y si el framework es tan popular,utilizado en la industria y en research y alimenta muchas de las aplicaciones inteligentes de la actualidad(la mayoría de AI de Google esta hecha con TF) por que pareciera aveces ser tan complicado de aprender? Posiblemente hayan muchas respuestas para esto, o tal vez ninguna pero mi opinión personal respecto a lo que he visto es que el problema esta en la falta de familiaridad con los conceptos matemáticos que Tensorflow nos permite implementar.

Es como querer aprender a usar una calculadora  para resolver ecuaciones sin tener claro que es una ecuación, para que buscamos resolverla y como interpretar la solución que la calculadora devuelve, y mas importante aún: como podemos aplicar la resolución de ecuaciones en problemas ,o bien pensemos en otro ejemplo en el cual  una calculadora permite calcular de manera rápida y sencilla una raíz cuadrada en lugar de hacerlo manualmente,pero si no conocemos el significado del resultado de esto y en que momento utilizarlo ,sus aplicaciones e interpretación , el aprender a hacerlo en la calculadora será de poco provecho y hasta confuso, esto a mi parecer pasa muchas veces con TF(y similares).

Tensorflow no es un framework como los que tradicionalmente usamos en desarrollo de software, es decir no esta orientado a la creación de aplicaciones web,móviles o similares si no es mas bien un Framework matemático orientado al desarrollo de aplicaciones numéricas por lo cual es importante conocer el significado de las operaciones que nos ayuda a realizar, de hecho en su propio nombre podemos ver la importancia que tiene la matemática en TF:

• Tensor: objeto matemático(de álgebra lineal) que generaliza los objetos mas familiares: vectores y matrices 
• Flow: Tensorflow se basa en un grafo de operaciones en el que cada nodo del grafo es una operación numérica y las aristas del grafo son tensores que FLUYEN de un nodo a otro.

Mi recomendación para personas que estén teniendo dificultad y confusión aprendiendo TF es primero aprender o refrescar la memoria respecto a los conceptos matemáticos y estadísticos subyacentes, esto hará que luego aprender TF sea mucho mas sencillo, intuitivo y se le encuentre un significado ,al final TF es solo una herramienta , o un medio para aplicar matemática utilizada en aplicaciones de machine learning, data science y  similares. 

Personalmente creo que esto se basa en 3 pilares que acá listo y para los cuales pongo enlaces a material útil para aprender o refrescar estos temas.:

1. Algebra Lineal:
• https://www.youtube.com/playlist?list=PLZHQObOWTQDPD3MizzM2xVFitgF8hE_ab
• https://towardsdatascience.com/linear-algebra-for-deep-learning-f21d7e7d7f23
• https://machinelearningmastery.com/linear-algebra-machine-learning/
• https://medium.com/@rathi.ankit/linear-algebra-for-data-science-a9648b9daee0
2. Cálculo multivariable: si  no estas familiarizado con cálculo de una variable, el multivariable será más complicado de entender por lo cual sería recomendable antes de multivariable empezar con calculo diferencial, en ML no se utiliza mucho el cálculo integral por lo que se puede enfocar menor esfuerzo a este.
• https://www.khanacademy.org/math/multivariable-calculus
• https://www.coursera.org/learn/multivariate-calculus-machine-learning
• https://towardsdatascience.com/calculus-in-data-science-and-its-uses-3f3e1b5e5b35
• https://www.youtube.com/playlist?list=PLZHQObOWTQDMsr9K-rj53DwVRMYO3t5Yr
3. Estadística y probabilidad: hay muchas cosas importantes de esto en data science pero considero que entender distribuciones de probabilidad, como interpretarlas, samplearlas(obtener muestras aleatorias  de estas), medirlas, calcularlas a partir de un conjunto de datos,  o comparar 2 (por ejemplo a través de entropía cruzada o divergencia de Kullback-Leibler) además de cosas como medir la correlación entre 2 variables, etc.
• https://towardsdatascience.com/probability-and-statistics-for-data-science-part-1-3eed6051c40d
• https://www.udemy.com/probability-and-statistics-for-business-and-data-science/
• https://towardsdatascience.com/machine-learning-probability-statistics-f830f8c09326
• https://towardsdatascience.com/probabiliy-theory-basics-4ef523ae0820

Espero con esto ayudar a personas que esten teniendo problemas con TF  o similares.

Autor: https://www.linkedin.com/in/luis-fernando-leal-hernandez-9a736276/

NALU(unidad aritmetica logica neuronal) – Su razón de ser

Este post planeo dividirlo en 2 partes ,1(el actual) explicando las motivaciones de NALU y el problema que busca resolver y en el próximo un poco mas de detalles técnicos , explicación del modelo , código de mi propia implementación del modelo(los autores solo publicaron las especificaciones, pero no su código) y resultados de algunos de mis experimentos.

NALU es un nuevo modelo propuesto por Google DeepMind, siendo su autor principal Andrew Trask(autor del libro “Grokking Deep Learning”) y publicado apenas hace 2 semanas(agosto 2018) como artículo de investigación científica en arxiv https://arxiv.org/pdf/1808.00508v1.pdf

NALU busca mejorar el rendimiento de los modelos de redes neuronales y abrir la puerta a nuevos modelos y nuevas aplicaciones no antes posibles ya que busca solucionar un importante problema presente en las redes neuronales : falta de razonamiento cuantitativo y la habilidad de extrapolar y generalizar

La habilidad de representar y manipular cantidades numéricas esta presente en muchas especies, no solo en los humanos, por ejemplo hay fuerte evidencia que indica que las abejas tienen la habilidad de contar objetos y razonar sobre cantidades numéricas, esto sugiere que la habilidad de representar y manipular cantidades numéricas es un componente inherente de la inteligencia biológica,entonces la pregunta es : ¿posee la inteligencia artificial actual esta habilidad? La respuesta lamentablemente es NO, las redes neuronales actualmente no poseen la habilidad de “razonar” cuantitativamente y manipular cantidades numericas de manera sistematica y generalizada.

Alguien con conocimiento del tema puede leer la ultima frase y decir : “esto no es cierto, todo lo contrario de hecho las redes neuronales solo trabajan con números y todo tipo de información que se les alimente debe primero ser convertida a números”,y aun que esto es cierto con algunos ejemplos y analogías quedará mas claro cual es el problema que NALU busca resolver, empecemos entonces con una analogía con el aprendizaje humano:

Aprendizaje vs memorización

Durante mi tiempo de estudiante en ingeniería adopte por gusto y desición propia como método de estudio de matemáticas el realizar todos los ejercicios contenidos en el libro utilizado como material del curso,esto me consumía bastante tiempo por lo que algunos de mis amigos y compañeros sugerían “no, para ganar el curso solo es necesario aprender los ejemplos vistos en clase y la tarea preparatoria” lo cual obviamente consumía bastante menos tiempo ,muchas veces en los examenes solo venian estos ejemplos o pequeñas variaciones de los mismos, por lo que memorizarlos garantizaba ganar el curso, pero ¿es esto aprendizaje? En otros casos los problemas si eran diferentes y se necesitaba aplicar razonamiento y uso de los conceptos para poderse resolver y esto provocaba que algunos compañeros que preferían el método rápido(memorización) fallaran al no poder generalizar o extrapolar .

Este ejemplo sugiere que los humanos podemos tanto aprender como memorizar (y algo mas interesante aún es que tenemos el poder de decicir cual de las 2 cosas hacer,pero ese es otro tema) lamentablemente la IA a través de redes neuronales actualmente esta mas cerca del caso 2(memorizar) que del 1(aprender de manera general).

Memorización en IA

La IA a través de redes neuronales ha logrado resultados impresionantes en complejas tareas como:

• Reconocimiento de voz y lenguaje natural
• Diagnostico y detección de enfermedades
• Vencer a campeones del mundo en juegos de mesa
• Reconocimiento facial
• etc

Pero tiene dificultades en tareas mucho mas sencillas como:

• Contar números
• Aplicar aritmética simple(suma,resta, multiplicación ,división)

Es decir tareas que implican razonamiento numérico ,algo básico de nuestra inteligencia(y de otras especies),por ejemplo cuando nosotros aprendemos a sumar, nuestro cerebro maneja de manera abstracta y conceptual los números y la operación de suma en estos, no memorizamos cual es la suma para cada posible par de números en la recta númerica(sería imposible) .

Algunos estudiosos de neurociencias y el cerebro proponen que esto es posible gracias a un tipo especial de neurona llamada “numeron”(por “numerical neuron”) las cuales se encargan de crear las representaciones numéricas que nuestro cerebro usa y proponen que todo razonamiento numérico y operaciones con numeros se basa en operaciones de acumulación(suma y resta) de cantidades(para mayor detalle ver : The Number Sense: How the Mind Creates Mathematics de Stanislas Dehaene), en el siguiente post veremos como este modelo se refleja directamente en NALU

Otros ejemplos donde es posible ver este problema en la IA son los siguientes casos:

• Las redes neuronales son muy buenas aprendiendo funciones f(x) pero tienen dificultad en arender la sencilla función “identidad escalar”, es decir f(x) = x para valores de “x” que no ven durante su entrenamiento.
• Las redes neuronales en algunos casos pareciera que han aprendido aritmetica basica, por ejemplo aprenden a sumar correctamente pero solo lo hacen bien en el rango de valores vistos durante su entrenamiento(por ejemplo si durante su entrenamiento ven valores en el rango de 0 a 100, podrán sumar bien nuevos valores en ese rango,pero no lo harán bien con valores como 101 + 200) por lo cual decimos que no pueden extrapolar a rangos de valores no vistos durante su entrenamiento.
• Tuve la oportunidad de “chatear” con el autor del modelo quien en sus propias palabras explica otro ejemplo donde se entrena a una red neuronal para contar hasta cierto numero, pero una vez entrenada tiene dificultades para contar hasta un numero mayor a los observados, esto sería el equivalente a un humano contando muchas veces de uno a 10, pero luego tener dificultades contando hasta 11.

Imagen 1 del artículo original: credito a DeepMind(descripción abajo)

Imagen 1 del artículo original: credito a DeepMind(descripción abajo)

Imagen 1 del artículo original: en esta imagen se prueban diversas funciones de activación en un autoencoder aproximando la función identidad escalar f(x) = x , cada curva pertenece a una función de activación, el eje "x" corresponde a los valores de entrada "x" y el eje "y" corresponde al error obtenido, es posible ver que para algunos casos pasa en menor medida que otros,pero en todos los casos el error incrementa cuando se sale del rango de valores "x" vistos durante el entrenamiento (aproximadamente -5 a 5)

El autor explica que la hipótesis bajo la cual se desarrolló este proyecto de investigación fue que las redes neuronales aprenden a representar números(y las operaciones con estos) de la misma manera (o similar) a como aprenden a manipular palabras, es decir: creando un diccionario finito lo cual es una limitación en operaciones numéricas si tomamos en cuenta que en la recta numérica existen infinitos valores y simplemente no podemos representar un diccionario de infinitos elementos en una red neuronal(y aun que pudieramos, ¿sería esto realmente inteligencia?) lo cual limita a la IA actual en extrapolar funciones a rangos de valores no vistos previamente(similar al ejemplo de memorización vs aprendizaje)

El objetivo del proyecto era proponer una nueva arquitectura que solventara estas limitantes y permitiera enriquecer a los modelos convencionales(redes feed-forward , convolucionales, recurrentes, etc) extendiendo su habilidad de extrapolar y generalizar en rangos de valores númericos nunca antes vistos…y lo lograron .

Aun que NALU tiene un potencial muy grande y creo que será una herramienta importante para todo AI developer, lo que mas me ha gustado es que ha abierto las puertas para nuevos modelos y arquitecturas demostrando que es posible aplicar una estrategia de diseño en la que se agregan a redes neuronales sub-elementos que buscan resolver ciertas dificultades y aplicar de manera efectiva sub-funciones matemáticas (en este caso aritmetica)

En el próximo post escribiré un poco mas de los detalles técnicos de NALU y mi experiencia en su implementación , y el experimento en el cual apliqué NALU.

De manera anticipada , en el experimento en el cual he aplicado NALU

hasta el momento se busca responder la pregunta “¿puede una red neuronal aprender a restar numeros seleccionados aleatoriamente en un vector de entrada x?”, mis experimentos parecen indicar que sí y tal como los autores de NALU buscaban, intente lograrlo en rangos de valores nunca vistos durante el entrenamiento. En el próximo post pondré detalles de este experimento(así como codigo del mismo)

Espero con este post explicar un poco mas claro la necesidad y problema que NALU busca resolver ya que muchas veces una publicacion científica es un poco difícil de digerir y con mucha notación matemática y mas aún en latinoamérica donde nuestro idioma nativo no es el ingles,por lo que espero que este artículo sea útil para personas buscando información un poco mas digerible del tema y en su lenguaje nativo.

Gracias

Amarillismo en la inteligencia artificial: Sophia el primer robot ciudadano

Este post podría ser considerado la segunda parte o continuación de http://devongt.blogspot.com/2017/08/amarillismo-en-la-inteligencia.html

En las últimas semanas varios medios(incluidos varios medios populares como tech insider) han publicado noticias de “Sophia el primer robot ciudadano” que básicamente presentan como un robot que ha obtenido ciudadanía y lo anuncian como un robot que cuenta con lo que se conoce como “inteligencia artificial general”. Lamentablemente tanto Sophia como sus capacidades anunciadas son completamente falsas y crean en las personas ideas y expectativas falsas de lo que es la inteligencia artificial, sus alcances y capacidades y su estado actual como ciencia. Personalmente llevo algún tiempo ignorando(o incluso sintiendo cierto disgusto) al solo ver el nombre Sophia o su imágen en las noticias, pero algunas noticias en particular fueron las que hicieron que decidiera escribir esto :

• Sophia es entrevistada en vivo por “Tech Insider”(https://www.youtube.com/watch?v=78-1MlkxyqI): en el video se puede ver claramente como el entrevistador lee las preguntas desde su celular, es decir que es una serie de preguntas programadas a las cuales el robot responde por que ya estaban planificadas. Esto no es bajo ninguna definición inteligencia artificial.
• Sophia dice que su inteligencia artificial esta basada en emociones humanas(https://youtu.be/S5t6K9iwcdw?t=180) como : compasión, amabilidad y empatía. La inteligencia artificial actual se basa en modelos matemáticos y estadisticos de tareas específicas basandose en la racionalidad que consiste en realizar la acción mas adecuada (que maximiza o minimiza un resultado) bajo las percepciones del agente, no existe en la actualidad manera de integrar valores humanos o sentimientos en la inteligencia artificial .

Lo que me causa disgusto de el tema, es como los creadores de Sophia estan aprovechando que actualmente la inteligencia artificial es un tema de moda para exagerar y mentir acerca de sus capacidades , y no podemos negar que la mecatrónica de Sophia es impresionante y ha logrado gestos humanos grandiosos, pero de esto a que cuente con inteligencia artificial hay una gran mentira de por medio , y aún mas grande es la mentira de que cuente con AGI(inteligencia artificial general), emociones y sentimientos.Actualmente la AGI es solo un sueño con la que muchos entusiastas e investigadores fantasiamos(probablemente lo mas cerca a esto sea “reinforcement learning” pero aún RF esta lejísimos) , y el tener emociones en la inteligencia artificial es solo algo de ciencia ficción.

Por esto es extremadamente molesto como los medios se aprovechan de el boom y moda actual de AI ya que engañan a las personas, y hasta cierto punto las estafan dandoles expectativas falsas, incluso miedos no fundamentados, y personalmente creo que esto en algún momento puede frenar la investigación o adopción en la sociedad de productos basados en AI, incluso me atrevería a pensar en futuras manifestaciones de la sociedad en contra de AI por culpa de este amarilismo de los medios.

Personalmente creo que esto ocasiona algunos problemas como:

• Crea en el público y sociedad en general miedos no fundamentados como: los robots se van a revelar y nos van a exterminar
• Crea en publico técnico interesado el deseo de incursionar en AI para luego de una curva de aprendizaje bastante grande, darse cuenta que AI en la actualidad no es mas que estadística y matemática para crear modelos y funciones a partir de grandes sets de datos, y no lo que esperaban de robots verdaderamente inteligentes.

 Sophia no es mas que una marioneta mecatrónica ,pre-programada y controlada por inteligencia humana, no inteligencia artificial,no escucha, no entiende lo que le dicen, ni etiende lo que ella dice, no tiene emociones ni sentimientos.Que diferencia hay entre su inteligencia y la de un títere de circo? NINGUNA

Autor: Luis Leal

Idea de investigación: IA clásica combinada con Machine Learning

A diferencia de la mayoría de nuestras publicaciones, esta no es una aplicación  real o buenas practicas en la aplicación de ciertas técnicas ,conocimientos y/o herramientas, es mas bien una idea que ha rondado mi cabeza desde hace algunos años, pero que lamentablemente no he podido experimentar por falta de tiempo y otros motivos. Es posible que alguien mas este investigando y experimentando con esto, o que alguien tenga los fundamentos teóricos para determinar la posibilidad de que funcione o falle, sin necesidad de experimentar.

 La idea se basa en la combinación de 2 sub-áreas de la inteligencia artificial que comúnmente son tratadas por separado e independientes: Algoritmos genéticos y Machine Learning, por lo cual se necesita un poco de conocimiento en estos temas o bien la curiosidad para explorarlos. No entraré a muchos detalles pero por favor si encuentras este articulo navegando por Internet, y ya lo has experimentado o conoces el resultado, o quieres aportar tus ideas , por favor deja un comentario.

Antecedentes

• Algoritmos genéticos: sabemos que los algoritmos genéticos se basan en (como su nombre indica)   el comportamiento a través de generaciones de los  organismos vivos, principalmente utilizando postulados de Darwin acerca de como las poblaciones evolucionan de generación en generación a través de la selección natural y la supervivencia de los individuos "mas aptos".  En ciencias de la computación (y otras ciencias como "data science") , estos algoritmos son utilizados como método de BÚSQUEDA y OPTIMIZACIÓN(en el siguiente párrafo se vera por que escribo BUSQUEDA y OPTIMIZACION en mayúsculas)  ,siendo muchas veces la búsqueda de combinaciones optimas entre un conjunto de opciones o bien la optimización de una función matemática. 
  
  
  
  
• Machine learning: tema  amplio, con muchas definiciones y con gran popularidad recientemente por lo cual no entrare a muchos detalles en su definición, la mayoría de algoritmos de ML se basan fuertemente en estadística , y otras ciencias como matemáticas(álgebra lineal  y calculo),por ejemplo los llamados "modelos parametricos"  se basan en una función de costo (mientras mas preciso el algoritmo, menor costo, y un costo alto significa algoritmo impreciso) , este costo es función de lo que estadisticamente son "parametros del modelo" , y matemáticamente definiríamos como "variables de la función", y nos apoyamos en un algoritmo de OPTIMIZACION para realizar una BUSQUEDA de los parámetros del modelo(o variables de la función) que minimizan el costo  , este algoritmo de optimización siendo comúnmente un algoritmo basado en gradientes(derivadas parciales) para encontrar la dirección en la que mas rápido decrece el costo ,comúnmente "gradient-descent" o derivados.
  
  
  
  

Ya se puede ver por que escribí "OPTIMIZACION" y "BÚSQUEDA" en mayúsculas?  Mi idea consiste en experimentar con algoritmos genéticos , como sustitutos de los algoritmos basados en gradientes , es decir, si podemos utilizar un algoritmo genético como  método de optimización de una función matemática, por que no utilizarlo para minimizar la función de costo de un algoritmo de ML? Viéndolo desde la perspectiva de algoritmo genético como método de búsqueda de combinaciones optimas entre un conjunto de opciones, por que no utilizarlo para realizar la búsqueda de combinaciones optimas de los parámetros/variables en el algoritmo de ML ?  Mi hipotesis es que un algoritmo genético podría ser una alternativa a los algoritmos basados en gradientes, y como en toda ciencia, la hipótesis esta sujeta a resultados experimentales los cuales no he podido realizar, alguien se anima a realizarlos? 

(Si, si, se que los expertos en el tema, y en algoritmos dirán "Pero un algoritmo genetico es un "greedy algorithm" y como todo  greedy algorithm es propenso a mínimos locales, por lo cual no funcionaría, pero los algoritmos basados en  gradientes también sufren este problema y son el casi estándar en la materia, ademas que los investigadores/científicos  han creado métodos para minimizar este riesgo, entonces por que no experimentar?) 

Autor: Luis Leal

Amarillismo en la inteligencia artificial

En este presente año 2017, se ha visto una explosión en los medios respecto a la inteligencia artificial y se ha vuelto una moda que muchos intentan adoptar, lamentablemente su mayor difusión se ha visto acompañada de exageraciones, creación de noticias falsas, especulaciones de robots asesinos ,o de agentes de inteligencia artificial que "cobran vida" y empiezan a comunicarse entre si en un lenguaje que ellos mismos inventaron.  

Este ultimo ejemplo se concretó y  ha sido muy popular en las ultimas semanas, al punto de convertirse viral y ser publicado en múltiples medios ,revistas, periódicos, noticieros etc. Incluso en medios no enfocados a tecnología y ciencias, estamos hablando de una noticia que en algunos medios decía algo similar a :

"Facebook apaga a 2 de sus agentes de inteligencia artificial que cobraron vida y empezaron a comunicarse en un lenguaje que ellos mismos crearon." , esta noticia es exageradamente falsa y nosotros la catalogamos de amarillismo , creada(y compartida) por medios que carecen de conocimiento en la materia ,de los alcances,avances y estado actual de la misma y que se dejan llevar sin investigar o que solo buscan subirse al tren y hablar de un tema que se ha vuelto una moda en el actual año, generar temor en las personas y de esta manera obtener mayor alcance y difusión . Las personas que escribimos este blog seguimos en redes sociales, blogs y sitios de ciencias y tecnología a algunos de los pioneros e investigadores mas importantes de IA y algunos de los comentarios de ellos luego de que este rumor se convirtiera viral fueron:

Yann LeCun,director de ingeligencia artificial en facebook:   Indicó que muchos en su equipo y de la comunidad de investigadores de IA sentían verguenza ajena(facepalming) al ver la noticia,aclaró que FB no había apagado a los agentes por que cobraran vida e inventaran un lenguaje, fue por que simplemente no funcionaban ,y catalogó a estas noticias de alarmistas, y de ser carnada de clicks e incentivó a leer,informarse y preguntar a la gente que se dedica o conoce el tema. 

Ian Goodfellow,investigador en Google,OpenAI y creador del ultimo avance en IA(GANs): Compartió un artículo titulado "No,facebook no entro en pánico y apago un programa que se estaba volviendo peligrosamente inteligente", en su publicación otros investigadores comentaban "Estoy seguro que estamos lejos de eso", "Luego de leer por 30 segundos, lo catalogue como ridículo ".

Lo mas triste de esto, es que muchos conocedores y profesionales de ciencias de la computación y gente que se auto-nombra conocedores de IA han sido engañados y han compartido la noticia, en lugar de desmentirlo e informar a gente afuera del ámbito.

Una analogía que me gusta hacer respecto a esto(utilizando como ejemplo vehículos que se manejan solos es) :

• Antes de 2017:  investigadores vuelven al laboratorio y mesa de diseño, luego de que el algoritmo del vehículo fallara y cruzara un semáforo en rojo.
• En 2017: Empresa automovilística se ve obligada a apagar su vehículo de inteligencia artificial,luego de que cobrara vida y rebeldemente ignorara un semáforo con el objetivo de dañar a su tripulante.

Personalmente llevo varios años en el tema aun antes de su actual "boom"(en mi ultimo año antes de entrar a la universidad, compre mi primer libro(fotocopias) del tema aun que no entendía nada, en 2013 publique un articulo sobre sistemas expertos en mi blog y fui multado en la biblioteca de mi universidad por no devolver el famoso libro de IA de Peter Norvig y en 2014 empece a auto-enseñarme machine learning y deep learning)y sigo de cerca las publicaciones de algunas de las personas mas importantes del tema(como Andrew NG o Yann Lecun)y he experimentado y desarrollado varios agentes de IA y puedo decir que el comportamiento que exhibieron los agentes de FB se da cuando el sistema  esta fallando, su arquitectura es incorrecta, sus hyperparametros deben ser mejorados, o su data de entrenamiento es poca o de baja calidad y NO SE DEBE a que cobran vida y están inventando su propio idioma, aun estamos muy lejos de esto, no olvidemos que la inteligencia artificial se reduce a algoritmos, modelos matemáticos, estadísticos y problemas de optimización.

Como ejemplo de uno de mis proyectos, comparto el siguiente repositorio que consiste en un bot que luego de ser entrenado con literatura de horror de 2 de mis autores favoritos "aprende" a generar nueva literatura que fusiona el estilo de ambos, se puede ver que en los primeros "commits" genera texto completamente sin  sentido(como el de los agentes de FB) y luego esto mejora conforme se experimenta con la arquitectura,hiperparametros y preprocesamiento de datos:

Bot generador de literatura de horror

Espero con este articulo poder aportar un poco a clarificar y desmentir esta noticia amarillista y alarmista.

Autor: Luis Leal

Google Adwords API Wrapper

Este post esta dirigido a software y data engineers o developers en general que deban utilizar la API de google adwords para realizar consumo de datos de google.

Muchas veces , las APIs de google brindan gran poder y flexibilidad al desarrollador pero esto acompañado de complejidad o poca claridad de implementación . Este es el caso de la API de Google adwords , para el escenario especifico de descargar datos de google desde una aplicación o un job programado automático, esta API impone cierta complejidad . Por esta razon creamos un Wrapper orientado a objetos en python que solo necesita una operación luego de instanciar un objeto:

descargar()

Esta operación recibirá de parametros la data que queremos descargar, las fechas deseadas, el formato del archivo de salida , y un flag booleano para indicar si se desea comprimir o no. Respecto al archivo de configuración googleads.yaml ,solo necesitamos indicar su ubicación como parametro al momento de instanciar el objeto(o bien usar el parametro default de Python el cual asumirá que el archivo se encuentra en el directorio home del usuario). De esta manera abstraemos la complejidad de programacion de la API de google adwords a 2 pasos(en pseudocodigo)

1. Crear instancia de wrapper enviando de parámetro la ubicación del archivo de configuración.
2. Ejecutar llamada a operación de descarga de datos enviando de parametro la data deseada, fechas requeridas, y formato de salida esperado.

Este wrapper puede ser integrado facilmente a cualquier aplicación, job automático, herramientas de integración de data(como SAP Data Services o Pentaho Data integration).

El codigo y un ejemplo de uso puede ser encontrado en el repositorio de github:

Repositorio en github

Autor: Luis Leal

Errores comunes en modelado dimensional para BI/DWH: dimension de encabezado o maestro en estructura maestro/detalle(header/line) PT 2

En continuación a nuestro post anterior: 

Errores comunes en modelado dimensional para BI/DWH: dimension de encabezado o maestro en estructura maestro/detalle(header/line) PT 1

En este post trataremos otro patrón a evitar al modelar una relación maestro/detalle (encabezado/detalle o header/line) en un modelo ROLAP.   Como bien se mencionó en el post anterior, muchas veces los diseñadores de un modelo analítico (OLAP) están mucho más familiarizado con el diseño de un modelo transaccional (OLTP) por lo cual instintivamente buscan aplicar las mismas técnicas y patrones de diseño olvidando que ambos enfoques tienen objetivos completamente distintos.  En el post anterior mencionamos el error de manejar el encabezado como una dimensión (por ejemplo  una factura en la que el encabezado de la factura es tratado como una dimensión).  En este caso  trataremos el error de manejar tanto el encabezado, como el detalle como fact tables como podemos ver en el siguiente diagrama:

(Los nombres de tablas y campos en este ejemplo no son importantes, lo importante es notar el diseño de 2 fact tables unidas por una tabla foránea)

En este caso, el encabezado ya no es una dimensión, sino una fact table a la cual están asociadas diversas dimensiones (por ejemplo: producto,cliente, sucursal ,fecha). El detalle es a su vez otra fact table relacionada con el encabezado a través de una llave foránea (por ejemplo el número de factura) y adicionalmente otras dimensiones.
Aunque este diseño  representa de manera precisa la relación jerárquica padre/hijo entre el encabezado y el detalle, tiene fallas importantes. Si  bien hemos mencionado antes, en un modelo analítico se busca facilidad de consumo  y tiempo ágil de respuesta , buscando almacenar la información  de manera que se tenga la menor cantidad de joins y cálculos posibles en tiempo de consulta, a costo de un mayor espacio en disco(esto varía en función del motor de base de datos y la tecnología de este, ya que hay motores columnares especializados para OLAP que manejan índices y bitmaps) y procesamiento en tiempo de ETL, asi como tiempo de desarrollo a los procesos de ETL, en este modelo esto no ha sido aplicado , y el poder analizar las métricas a nivel de detalle implica realizar joins con el encabezado  la cual es una tabla casi tan voluminosa (y con ritmo de crecimiento alto)  como la tabla de detalle, y luego realizar un segundo join a las dimensiones. De esta manera el plan de ejecución de la consulta involucra: tabla voluminosa -> tabla voluminosa -> tablas pequeñas(dimensionales).

Luego de ver el problema , y lo que este conlleva,  podemos tocar la solución al mismo, nuevamente esta solución conlleva un patrón de diseño que puede causar incomodidad al diseñador(arquitectos de datos, ingenieros de datos, etc) que está acostumbrado al modelado relacional de sistemas transaccionales pero que luego de absorberlo se verán los beneficios en la agilidad y performance en un sistema de distinto enfoque(analítico) .

La solución consiste en crear una única fact table, cuya granularidad es 1 registro  en el modelo dimensional, por cada registro del detalle en el modelo transaccional, las dimensiones asociadas al encabezado(o maestro) son asociadas a cada  registro de la fact table a través de llaves foráneas a las tablas dimensionales.  De esta forma  se evita el realizar joins enter 2 tablas voluminosas , y el tener que recorrer estas tablas para encontrar los valores distintos de cada dimensión, y así también se genera un modelo más intuitivo y entendible para usuarios de negocio , lo cual cumple con 2 de los objetivos fundamentales: facilidad y agilizad de consumo de información

Autor: Luis Leal

Errores comunes en modelado dimensional para BI/DWH: dimension de encabezado o maestro en estructura maestro/detalle(header/line) PT 1

Similar al anterior artículo: Errores comunes en modelado dimensional para BI/DWH: Estructuras y jerarquías normalizadas  , el presente artículo esta enfocado a arquitectos e ingenieros de datos, específicamente aquellos trabajando en el diseño y construccion de un data warehouse o data mart  haciendo uso de modelado multidimensional.

En el artículo citado se mencionó que existen diferencias en los objetivos y enfoque de un modelo de datos para un sistema transaccional(OLTP) y un modelo de datos análitico( OLAP) y por lo tanto también existen diferencias en los patrones de diseño y las buenas practicas para ambos casos  encontrándose ocasiones en los que una buena practica en un enfoque es un "pecado" en el otro.

El problema esta en que en las universidades y cursos de bases de datos es muy poco tocado el tema de analíticos por lo cual las personas encargadas de realizar un diseño de este tipo, muchas veces desconocen los objetivos, patrones y buenas practicas y realizan el diseño como si se tratase de un modelo transaccional(enfoque que si es tratado a profundidad academicamente)  , muchos otros han aprendido el diseño de analíticos de manera básica a través de otras personas o bien por su cuenta , pero solo conociendo los patrones de diseño básicos por lo cual mezclan ambos mundos.

En el presente articulo atacaremos un error común y la manera recomendada de resolución del mismo.

En un modelo transaccional utilizando el modelo entidad-relación es muy común encontrarse con 2 tablas en relación de uno a muchos en una estructura llamada  "maestro/detalle" en la cual cada registro del maestro o encabezado contiene información  general que es compartida por cada uno de los registros "detalle" asociados.Ejemplos de esto son facturas en los que cada factura(maestro o encabezado)  tiene asociados varios productos(detalles)  o bien ordenes de mantenimiento de equipos en los que cada orden(maestro o encabezado) tiene asociados muchos equipos(detalle),en ambos casos los datos del maestro o encabezado son datos generales y que son compartidos por cada elemento del detalle(por ejemplo numero de factura u orden, o fecha de la operación) .En el mundo transaccional es correcto modelarlo de manera normalizada pensando en los objetivos de reducción de redundancia , facilidad de actualización de datos, integridad referencial  y reducción de consumo de espacio en disco y no olvidando que en este tipo de sistemas operativos, comúnmente un usuario accede y/o actualiza una transacción a la vez, por lo cual en estos sistemas el modelado se hace a través de la estructura mencionada de 2 tablas,1 tabla maestro o encabezado, asociada con una tabla de detalle. Por ejemplo el siguiente modelo de facturación con una tabla para almacenar cada factura y otra tabla de detalle donde se registra para cada factura, que productos fueron vendidos.

Este patrón es muy usado y recomendado para el mundo transaccional , mas no así en el mundo multidimensional donde comúnmente no se accede una sola transacción a la vez si no posiblemente miles y ademas buscamos agilidad, simplicidad , menor cantidad de enlaces(joins) y tiempos de respuesta mas eficientes. Lamentablemente este patrón es muy utilizado ya que representa de manera correcta las relaciones entre los datos y es la manera en la que los diseñadores de modelos de datos se sienten mas cómodos. Esto nos al primero de los 2 patrones a evitar. 

Replicar la tabla maestro(o encabezado) como una dimensión y el detalle como una fact table en el modelo multidimensional

El primer patrón a evitar consiste en prácticamente crear una copia de la tabla de encabezado, como una dimensión en el modelo multidimensional, y el detalle como una fact table. Aun que si es muy común y recomendado  tener una tabla  de detalle como base para  una fact table, es mala practica que esta fact table sea una copia fiel de la tabla detalle y la tabla de encabezado sea una dimensión . Ejemplo:

Hacerlo de esta forma hace que se pierdan muchos beneficios de un modelo multidimensional bien diseñado, como el uso de dimensiones centralizadas,integradas, únicas y compartidas entre diversos modelos(lo cual permite hacer un analisis drill across entre múltiples procesos de negocio) ya que la información contextual o descriptiva  estaría "incrustada" dentro de la dimensión de encabezado, o bien  a través de un doble enlace entre fact table->dimension encabezado -> Dimension descriptiva , lo cual como se menciono en el anterior post también es un patrón a evitar. Ejemplo(Como podemos ver esto ya nisiquiera tiene la famosa forma de estrella):

De esta forma se tendría una tabla dimensional que crece a un ritmo bastante elevado(similar al de la fact table) y un análisis de este proceso de negocio implicaría el acceso a 2 tablas voluminosas(en lugar de una tabla voluminosa y pequeñas tablas dimensionales) .Si se desea analizar solo la información contextual o descriptiva(por ejemplo: listado de clientes o sucursales) sería necesario recorrer toda la tabla(con posiblemente millones de registros) en vez de recorrer una única tabla pequeña, esto puede degradar el rendimiento y tiempo de respuesta. 

Además de esto el campo de enlace(o llave) entre ambas tablas, sería un campo incremental y único que no se repetiría en la fact table , lo cual haría que sea imposible utilizar técnicas de compresión (como por ejemplo compresion bytedict en amazon redshift) o indices bitmap(Sybase IQ) que si podrían ser utilizadas si se manejara como pequeñas dimensiones con pocos valores repetidos muchas veces.

En este post hemos hablado del primer patron a evitar para relaciones maestro detalle, en el siguiente post se explicara el segundo patrón ademas de presentarse un esquema de datos recomendado para  modelar estas relaciones de manera eficiente. Nuevamente estas no son recomendaciones o ideas generadas únicamente por mi persona, si no por los expertos en la materia y creadores del modelado multidimensional. 

Autor: Luis Leal

Errores comunes en modelado dimensional para BI/DWH: Estructuras y jerarquías normalizadas

El actual articulo esta orientado a ingenieros y arquitectos de datos(principalmente para personas encargadas del diseño y/o construcción de data warehouse siguiendo un modelado multi-dimensional) por lo cual se asume y recomienda familiaridad con la materia.

Existen en la industria buenas prácticas , tips y patrones de diseño comprobadas a lo largo del tiempo y con muchos casos de éxito , pero de igual forma existen malas practicas, errores y acciones a evitar cuando se aborda la tarea de diseñar un modelo de datos para apoyar a la toma de decisiones .

Dentro de estos errores , es muy común el que se presenta en este articulo y también se presentará el método recomendado para manejarlo. Ojo, las ideas propuestas acá(y por los expertos de la industria) entran en conflicto con las buenas prácticas de diseño de modelos de datos que se enseñan religiosamente en universidades y cursos de bases de datos, por lo cual se recomienda terminar de leer el post antes de dejarlo a medias pensando que lo que en el se dice es incorrecto.

El error es: modelar estructuras y jerarquías normalizadas. 

A lo largo de mi experiencia me he encontrado con este error en múltiples ocasiones ,incluso siendo realizado por arquitectos de datos experimentados , pero a que se debe? Principalmente a que como se menciono , esta práctica se evangeliza y se trata religiosamente en universidades y cursos de bases de datos y comúnmente los arquitectos de datos incursionan en el diseño de un modelo de datos de toma de decisiones sin tener en cuenta las diferencias(incluso sin un entrenamiento adecuado) en el enfoque y objetivos de un modelo de datos transaccional(comúnmente relacional) y un modelo analítico(toma de decisiones, descubrimiento de patrones y conocimiento).

En un modelo transaccional , el modelo se realiza pensando en objetivos tales como: captura de información,reducción de redundancia, integridad referencial , disminución de espacio de almacenamiento y para esto se recurre comúnmente a un modelo entidad/ relación normalizado, en el cual se modelan entidades del mundo(o negocio) y las relaciones entre las mismas.

Por otra parte en un modelo analítico , el diseño se realiza con objetivos tales como: consumo de información,toma de decisiones, análisis de indicadores del negocio, facilidad de consumo y entendimiento por parte de usuarios no técnicos, velocidad de acceso a la información ,aplicar pocos o ningún calculo y formulas durante el consumo(durante el query, y hacerlo en el ETL) y que el query sea lo mas "limpio" posible  y es acá donde entra en conflicto el enfoque analítico con el transaccional  ,ya que en el modelo analítico no se modelan entidades y sus relaciones, si no procesos de negocio, las métricas generadas por el proceso  y el contexto o puntos de vista de análisis del proceso y sus métricas(dimensiones)  .En este caso es permitido y altamente RECOMENDADO el tener estructuras de datos redundantes , no normalizadas y sacrificar  la disminución de espacio de almacenamiento .

Entonces entrando en materia(y es acá donde los arquitectos de sistemas y datos encontraran difícil de digerir y aceptar el material)  y  viendo ejemplos reales del error y su solución  , manejaremos 2 situaciones comunes :

1. Modelado de productos y categorías.
2. Modelado de información geográfica(en este ejemplo estado y ciudad)

• Enfoque transaccional: En este enfoque se modelan entidades y sus relaciones,para el primer caso identificando 2 entidades : producto y categoría y la relación entre ambas(un producto pertenece a una categoría y en una categoría se agrupan muchos productos).. Para el segundo caso se identifican 2 entidades: estado y ciudad  y la relación entre ambas(una ciudad pertenece a un estado, un estado contiene muchas ciudades).  Para ambos casos esta es una relación de jerarquía , a nivel físico este diseño implicaría 2 tablas por jerarquía y una llave foránea como relación entre las mismas.A continuación se presenta un modelo ER simplificado(se ha dejado de lado otras entidades y otros atributos de las entidades mostradas con fines de ejemplo)

• Enfoque analítico(dimensional): En este enfoque se modelan procesos de negocio, las métricas generadas por los mismos, y el contexto(descripción,puntos de vista) llamado dimensión en el que se generan las métricas. Para estos 2 ejemplos en vez de 4 entidades(2 para información de producto y 2 para información geográfica) se tienen únicamente 2 dimensiones(seleccionando siempre el nivel mas granular o mas bajo en la jerarquía) , y cada dimensión contiene toda la información de la jerarquía representada , para estos 2 ejemplos , tendríamos que la dimensión de producto, tiene como atributo la categoría del mismo, y la dimensión de ciudad tiene como atributo el estado al que pertenece,esto genera redundancia y rompe reglas de normalizacion  ya que para este ejemplo la categoría se repetiría muchas veces(1 por cada producto en la categoría),pero como se mencionó esto es permitido y recomendado con fines de generar simplicidad de consumo(query fácil de construir) y tiempos de respuesta mas ágiles(query eficiente) ya que ni la base de datos, ni el usuario final debe realizar costosas uniones innecesarias(joins) entre múltiples tablas en la jerarquía. Algo que viene a la mente al arquitecto de datos acostumbrado a modelar de manera relacional , es que esto también genera  un mayor costo en disco pero se deben tomar 2 cosas en cuenta:
1. El mayor costo de disco es permitido y es el precio a pagar por la simplicidad y tiempo de consumo de datos.
2. Comúnmente los modelos analíticos son implementados sobre bases de datos columnares(como Amazon Redshift o SAP Sybase IQ), diseñadas con este tipo de modelado en mente y utilizando internamente estructuras como bitmaps(o indices bitmap) para almacenar una única vez cada valor diferente de la columna y acceder al valor a través del bitmap,logrando así una compresión significativa. Crear un modelo normalizado(y jerarquías con múltiples tablas) en un motor columnar, es desperdiciar y desaprovechar  las capacidades(Y la alta inversión económica!)   y enfoque del mismo.

          Podemos concluir entonces, que es recomendable no tener(o tener un mínimo) jerarquías de múltiples tablas(y las relacione entre ellas) y tener únicamente una tabla con el nivel mas bajo de la jerarquía y agregar el resto de datos de la jerarquía como atributos de la tabla,Y tener un único nivel de unión(de  fact table a la dimensión) aun que esto represente generar redundancia y romper normalizacion.

Esta recomendación no es algo generado por mi persona, lo recomiendan los expertos de la industria(incluso los creadores del modelado dimensional) como podemos ver en las siguientes referencias. Espero que esto sea de utilidad para generar mejores modelos analíticos.

Ver mistake #1

http://www.dataintegration.ninja/mistakes-bottom-up-datawarehouse-development-approach/

Ver rule#6

http://www.kimballgroup.com/2009/05/the-10-essential-rules-of-dimensional-modeling/

O bien, en el libro "The data warehouse toolkit", capitulo 8 ,pagina  398 ver : Mistake #8

Autor: Luis Leal

Predicción de ganancias en R

En este post se quiere dar una pequeña introducción a la predicción de las ganancias en ventas utilizando modelos de regresión lineal en R.

R es un lenguaje y ambiente  de programación para el análisis estadístico, es uno de los lenguajes mas utilizados para la investigación, con R podemos utilizar la data desde cualquier fuente de datos ya sea Excel, CSV, incluso conectarse con una base de datos y utilizarla para realizar este tipo de análisis, esta es una de las grandes ventajas con R ya que podemos utilizar la data cualquier forma que venga, manipularla y obtener resultados.

Los modelos de regresión lineal se basan en la relación entre una variable dependiente y una o mas variables independientes, los modelos de regresión lineal son utilizados para la predicción de los valores de la variable dependiente, se debe llegar a utilizar las variables dependientes correctas para tener un modelo mas preciso y llegar a tener una diferencia entre los valores predichos y la variable dependiente sea mínimo.

Los datos para realizar el ejemplo se obtuvieron de un csv que Pentaho brinda para hacer pruebas, este set de datos es un ejemplo de ventas de vehículos del año 2003 a inicios del 2005. En la data tenemos las columnas ORDERNUMBER, QUANTITYORDERED, PRICEEACH, ORDERLINENUMBER, SALES, STATUS, QTR_ID, MONTH_ID, YEAR_ID, PRODUCTLINE, MSRP, PRODUCTCODE, CUSTOMERNAME, CITY,  STATE, COUNTRY, PRODUCTLINEID, STATE_ID.

Para este post se realizo un script en R y se pretende demostrar como aplicar el modelo linear y predecir las ventas en este caso de vehículos, se agrego el link para descargar el ejemplo.

Si se quiere ver mas a fondo como se realizo este ejemplo, se puede descargar el código fuente, para ejecutarlo cargamos el script R  y ejecutamos la función :

   > predictSales()

 La funcionalidad de este script es con un modelo lineal describir la relación entre la ganancia y la información con la que se cuenta de los pedidos como por ejemplo la ciudad, fecha y el producto, y al final de la ejecución mostrar un gráfico que muestra las ganancias reales y las que genera el modelo. 

Al ejecutar el script se genera un gráfico con las ventas del año 2003 a inicios del 2005.

En este ejemplo se tomaron como variables independientes QTR_ID, MONTH_ID, YEAR_ID, PRODUCTLINEID, STATE_ID y como variable dependiente la ganancia. En R se puede generar un resumen del modelo con lo que podemos obtener valores como el error residual estándar, los grados de libertad, valos que nos indican que tan funcional es nuestro modelo e ir mejorando el modelo cambiando las variables dependientes para obtener un modelo mas eficiente. 

El error residual estándar es la diferencia entre los valores reales y los valores estimados de la regresión, en este caso se obtuvo un error residual estándar de 1,4077.55, este es un valor muy elevado por lo que se debe mejorar el modelo, a continuación se muestra la gráfica generada en R, en negro se muestra la ganancia obtenida de forma mensual y en rojo los valores estimados de la regresión linear. 

En la segunda parte de este post se explicara como mejorar el modelo para estar mas cerca de los valores reales y se estará prediciendo el numero de ordenes de un vehículo para ciertos estados, con esto se podrían tomar mejores decisiones para lograr mayores ganancias.

El código de este ejemplo se encuentra en Github. 

Watch Download

Muchas Gracias.

La importancia menospreciada de la aplicación de índices en un proyecto de BI/DWH

A diferencia de nuestros anteriores posts , este post no esta enfocado al analista de negocio o el tomador de desiciones que utiliza el data warehouse y el sistema o aplicaciones analiticas de inteligencia de negocios, si no que esta mas enfocado al equipo técnico detrás de un proyecto de este tipo(project managers,arquitectos de sistemas, desarrolladores de sistemas,administradores de sistemas y de bases de datos,ingenieros de datos,etc).

Todo aquel que haya tomado un curso de bases de datos, conoce la importancia de la apliacion de índices para mejorar el desempeño de una base de datos,pero la pregunta es , cuantas personas o equipos detrás de la construcción y mantenimiento de un sistema aplican lo aprendido en la teoría para mejorar el funcionamiento de un sistema real en su día a día? . Lamentablemente la respuesta es que muy pocas personas(o casi ninguna) lo hacen a pesar de que de manera académica se ve su importancia y los beneficios obtenidos, esto por muchas posibles razones,según mi experiencia y charlas con colegas ingenieros de sistemas, algunas de estas razones son:

• La constante presión y tiempos apretados para proyectos de este tipo obligan a que el equipo “funcione” y cumpla su objetivo, sin importar si lo hace de manera óptima y eficiente.
• Aun que la importancia de los indices es recalcada en los cursos, la teoría nunca se pone en práctica ya que los cursos universitarios se enfocan en un buen diseño de la base de datos pretendiendo cumplir con los requerimientos funcionales,sin dar importancia a el rendimiento del sistema.
• Muchas personas, no conocen la importancia(o incluso que es) de la aplicación de indices nisiquiera de manera teorica ya que el curso se enfoca en crear un buen diseño y sentencias y herramientas de implementacion y manipulación de ese diseño.
• Muchas veces el adminsitrador de bases de datos piensa que es tarea del desarrollador y el desarrollador piensa que es tarea del administrador de base de datos. En realidad es una tarea conjunta en donde ambos deberían de aportar , el desarrollador comunmente tiene un mayor conocimiento y detalle de la manera y frecuencia en que las aplicaciones acceden a la información y el administrador de base de datos conoce como esta realiza internamente estos accesos.
• Simplemente al equipo no le importa o es algo para lo que no se desea invertir esfuerzo.

En el ámbito de proyectos y sistemas de inteligencia de negocios y data warehouse, este problema se presenta aún con mas frecuencia a pesar de que debería de ser mas importante ya que uno de los objetivos de un sistema de Dwh es agilizar y minimizar el tiempo de acceso a la información, en este caso el problema se presenta debido a las razones ya mencionadas(agendas apretadas,desconocimiento del tema, mala planificación,indiferencia) y otras razones tales como:

• Se utiliza un motor de base de datos optimizado para sistemas analiticos(por ejemplo motorores de bases de datos columnares) y se tiene la falsa creencia o se escucha el falso mito, de que estos motores de base de datos, no necesitan(o incluso no poseen) indices. (Ver al final del post : Ejemplo Aplicado)
• Se tiene la falsa creencia ,de que al tener la información en un diseño optimizado para analisis(como un modelo estrella) se hace innecesario contar con indices ya que no hay manera de agilizar el acceso a la información.
• Nuevamente , mala planificación y no contar con tiempo en la agenda para realizar esto.

En mi experiencia trabajando para una consultora con expertise en BI/DWH , la aplicación de indices nunca estuvo en el plan del proyecto , y se contemplaba como una alternativa, hasta que el performance del sistema se veía degradado.

Según los expertos(y creadores originales) de las técnicas y patrones del modelado dimensional para sistemas de BI/DWH , el diseño de un plan de índices es tan importante, como el diseño del modelo dimensional ,el tiempo para esta actividad debe estar contemplado en el plan del proyecto y debe ser realizado posteriormente(al menos en una versión inicial) justo después de tener el diseño del modelo dimensional realizado y un perfilamiento inicial de la data realizado(para conocer cantidad de registros,tipos de datos , valores unicos en cada tabla). Para mayor información de esto , se puede consultar la metodología o ciclo de vida Kimball y el libro “The Data Warehouse Lifecycle Toolkit”

Ejemplo 

Como se mencionó, una de las razones por las cuales erróneamente no se aplican índices en un sistema de BI/DWH ,es que muchas veces se utiliza un motor de base de datos optimizado para analíticos, por ejemplo una base de datos columnar(como amazon Redshift o Sybase IQ) y se tiene la idea equivocada de que esto hace innecesaria la aplicación de índices, o incluso que el motor de base de datos no brinda esta característica.

En mi experiencia en multiples proyectos con motores de base de datos columnares ,esta fue una tarea menospreciada y olvidada en muchas ocasiones ,pero cuando se presento la necesidad de realizara, se obtuvieron beneficios destacables,por ejemplo para el motor de base de datos columnar Sybase IQ(al igual que la mayoría en el mercado) ofrece multiples tipos de indices y cada tipo se encuentra destinado a cierta tarea, según factores como:

• Tipo de dato
• Cardinalidad de valores en una tabla
• Es una columna utilizada para un join?
• Es una dimension o un indicador?

Para el caso de amazon redshift, el concepto de indice no aplica en el sentido convencional, pero este maneja diferentes conceptos tales como sortkeys,distribution keys y encoding. Que tipo de cada uno de estos aplicar depende mucho de la estructura , cardinalidad , uso(por ejemplo si es ROLAP o OLTP,para ROLAP si es dimension o fact table)  , como ejemplos tenemos:

• Para surrogate keys conviene usar encoding o compresion tipo delta.
• Para llaves foraneas(en una fact table) a dimensiones con cardinalidad menor a 255 valores, usar bytedict(equivalente a indices bitmap en Sybase IQ).

pero los beneficios pueden ser enormes, tanto en performance como en storage(lo cual se traduce en ahorro de dinero).

Referencias utiles

•   Para aprender mas sobre índices en general(para los motores de base de datos mas comunes) consultar:
  • el libro: “SQL Performance Explained” de Markus Winand
  • El sitio: http://use-the-index-luke.com/
    
• Para aprender mas sobre la metodología Kimball , y sus recomendaciones sobre el plan y aplicación de indices, consultar:
  • “The Data Warehouse Lyfecycle Toolkit”
  • “The Data Warehouse Toolkit”
• Para aprender mas sobre los diferentes tipos de indices y su aplicación en el motor SAP Sybase IQ, consultar mi siguiente post :)