Muchas veces he visto cubos saturados de agregados. Los agregados son totales pre-calculados de la información y sirven para acelerar el tiempo de respuesta de las consultas.
Un agregado:
- Ocupa espacio
- Toma tiempo de procesamiento el llenarlo.
Lo anterior quiere decir que los agregados no son gratis.
Puede ser que un mes de información en la tabla de hechos ocupe 100 megas y los agregados para ese mes 50 megas. Tal vez llenar la tabla de hechos tome 10 minutos pero calcular los agregados tome una hora.
Así que no hay que crear agregados por crearlos, hay que analizar y poner en la balanza cuales realmente traerán beneficios y el costo que implicarán mantenerlos.
Los motores de cubos normalmente tienen un "query advisor" o parecido que pueden ayudar a sugerir los agregados. Hagamos de cuenta que esto no existe ¿cuáles pueden ser buenos agregados?
Pensemos:
Un agregado es un total de la información, si tengo un cubo, estrella o copo de nieve de ventas con 540 millones de registros y mi compañía se divide en 4 regiones (Norteamérica, América Latina, Europa y Asia) y quiero un agregado por región lo que obtendremos es una tabla con 4 registros. 1 registro con el total para la zona norte, uno para la zona sur, uno para la zona este y otro para la oeste.
| Norteamérica | $2,345,000 |
| América Latina | $1,934,567 |
| Europa | $2,567,000 |
| Asian | $2,200,000 |
Si quiero saber cuánto vendió la zona norte solo se barren únicamente 4 registros y no los 54 millones. Ahora, normalmente las regiones agrupan paises. Si quiero saber cuánto vendimos se vendió en la Canadá que pertenece a la zona norte no podemos usar el agregado anterior.
Lo que necesitamos es un agregado por Ciudad.
| EUA | $1,250,000 |
| Canada | $1,095,000 |
| Inglaterra | $1,490,000 |
| España | $1,077,000 |
| China | $989,000 |
| Japon | $1,211,000 |
Suponiendo que tenemos ventas en 20 países nos quedaría una tabla con 20 registros. Pero ahora el problema es que tengo 2 agregados, uno para resolver las consultas por ciudad y uno para las de región.
La mayoría de las herramientas OLAP pueden deducir un total a partir de su nivel inmediato inferior de granularidad. Esto es, debiera ser posible calcular el total por región a partir de las ciudades lo cual implicaría que no sería necesario tener los 2 agregados si no solamente uno. El de menor nivel. Las herramientas OLAP resuelven esto usando las jerarquías de las dimensiones, esa es una de las razones de establecer las jerarquías en Oracle o Analysis Services por ejemplo.
Cuando me ahorro agregados me estoy ahorrando espacio y tiempo de procesamiento del agregado.
Regresando al ejemplo anterior que pasaría si en cada ciudad tengo 3 tiendas, ¿no sería conveniente mejor realizar el agregado a nivel tienda (ya que tendríamos 20 x 3 = 60 registros) y ahorrarnos 2 agregados para matar 3 consultas diferentes? 60 registros para una tabla aun es nada
Bueno, la cosa no es tan fácil, tener un agregado sin incluir la dimensión tiempo no sirve de nada. Si queremos un total por mes necesitamos multiplicar por 12 la cantidad de registros, pero si nuestros usuarios consultan el detalle a nivel diario entonces tal vez nos interese el detalle mensual, entonces necesitaríamos multiplicar por 365 los registros.
Usted tiene que poner en la balanza que cantidad de registros es el máximo óptimo en un agregado.
Cosas que nunca haga, (ok, tips):
- Si tiene una tabla de hechos cuyo menor nivel de detalle es cliente, producto entonces no haga un agregado x la combinación de cliente + producto por que estaría obteniendo un agregado con la misma cantidad de registros que la tabla de hechos
- Nunca haga un agregado con todas las dimensiones. Obtendría una tabla más grande que la tabla de hechos.
- Incluya en el agregado todos los campos de la tabla de hechos así cuando esté realizando una consulta no planeada el usuario tendrá el mismo performance al incluir en la consulta los diferentes indicadores que el cubo tiene.
- Normalmente no se requieren agregados a nivel muy granular, a nadie le sirve para un análisis saber cuánto vendí en $ de cada uno de los 158 mil 289 productos en el catálogo. Es muy importante saber el detalle de algunos de ellos (los de mayor venta). Bastará hacer agregados a los niveles superiores. Al hacer dril down en alguna tienda, alguna familia de productos, alguna categoría, la consulta se irá acotando. Bastará con algunos índices adecuados en la tabla de hechos para saber cuánto se ha vendido en la tienda 25 de algún producto.
- A veces se requieren agregados exactos.
- No olvide que los agregados siguen siendo tablas por lo que también es válido indexarlas.
PD: Si el motor OLAP que está usando no soporta jerarquías puede usar entonces un agregado compuesto: Región+Ciudad+Tienda; el efecto es el mismo ya que de un agregado se puede calcular el total de ventas por cualquiera combinación de las 3 dimensiones.
Hablando de agregaciones, y de acelerar el performance
en un proyecto de una compañía telefónica celular, sobre su call center, los dueños de los celulares llaman y ponían su queja o dudas
tenían las siguientes dimensiones con los siguientes números de registros
“Tipo de queja”; 4 distintas
“Supervisor”; 5 distintos
“Agente”; 21 distintos
“Cliente”; 1,000,000 distintos aprox por día
En total la tabla tenia como 1,000,500 de registros diarios aprox, entonces esto quiere decir que en todo el día algunos clientes (menos de 500) hablaban mas de una vez; y son atendidos por distinto Agente o ponen una distinta queja.
Fecha Queja Sup Agt Cte
567 1 2 4 534
567 2 2 7 534
567 1 2 4 41
567 1 2 4 16
567 3 1 15 26
567 2 1 16 78
.. … … … …
Cree una agregación que tenia las dimensiones: “Tipo de Queja”, “Supervisor”, Agente”, con esa agregación que solo tenia 84 registros por día, se resolvía casi todos las consultas y todos era felicidad.
Haaaa pero tenían un escenario que tenia los top 10 clientes con mas quejas entonces para ese escenario usaba la tabla de hechos con mas de 1 millón de registros y se te hacia mas tardado que un dia en ayunas, entonces cree una nueva columna; ClienteTop
En la que le puse el mismo numero de Cliente , pero solo a los que tuvieran mas de una llamada ( Osea Having cont(*) > 1 )
Fecha Queja Sup Agt Cte CteTop
567 1 2 4 534 534
567 2 2 7 534 534
567 1 2 4 41 0
567 1 2 4 16 0
567 3 1 15 26 0
567 2 1 16 78 0
.. … … … …
Y entonces cree una agregación que tenia las dimensiones: “ClienteTOP”, “Tipo de Queja”, “Supervisor”, Agente”; esta agregación tiene menos de 500 registros
Y el escenario en lugar de desglozar la tabla por la dimensión Cliente, la desgloso por la dimensión ClienteTop y usa la agregación
PD:
Para los que hicieron cuantas y no les cuadro como es posible que 21 Agentes pueden atender mas de 1 millón de llamadas por día, lo que pasa es que 20 son humanos y uno de los “agentes” es una contestadota automática con muchas líneas que recibe la mayoría de las llamadas; ya saben de esos sistemas desesperantes que te dicen “Gracias por llamar, Si usted no escucha presione 1, si tiene problemas con el teclado de su celular y no puede presionar teclas presione 2, …un sinfín de opciones… si quiere hablar con un humano presione 34 o espere en la linea”
Te lo mando de nuevo porque veo que lostabs los puso como un caracter espacio
Hablando de agregaciones, y de acelerar el performance
en un proyecto de una compañía telefónica celular, sobre su call center, los dueños de los celulares llaman y ponían su queja o dudas
tenían las siguientes dimensiones con los siguientes números de registros
“Tipo de queja”; 4 distintas
“Supervisor”; 5 distintos
“Agente”; 21 distintos
“Cliente”; 1,000,000 distintos aprox por día
En total la tabla tenia como 1,000,500 de registros diarios aprox, entonces esto quiere decir que en todo el día algunos clientes (menos de 500) hablaban mas de una vez; y son atendidos por distinto Agente o ponen una distinta queja.
Fecha Queja Sup Agt Cte
567 1 2 4 534
567 2 2 7 534
567 1 2 4 41
567 1 2 4 16
567 3 1 1 26
567 2 1 6 78
.. … … … …
Cree una agregación que tenia las dimensiones: “Tipo de Queja”, “Supervisor”, Agente”, con esa agregación que solo tenia 84 registros por día, se resolvía casi todos las consultas y todos era felicidad.
Haaaa pero tenían un escenario que tenia los top 10 clientes con mas quejas entonces para ese escenario usaba la tabla de hechos con mas de 1 millón de registros y se te hacia mas tardado que un dia en ayunas, entonces cree una nueva columna; ClienteTop
En la que le puse el mismo numero de Cliente , pero solo a los que tuvieran mas de una llamada ( Osea Having cont(*) > 1 )
Fecha Queja Sup Agt Cte CteTop
567 1 2 4 534 534
567 2 2 7 534 534
567 1 2 4 41 0
567 1 2 4 16 0
567 3 1 1 26 0
567 2 1 6 78 0
.. … … … …
Y entonces cree una agregación que tenia las dimensiones: “ClienteTOP”, “Tipo de Queja”, “Supervisor”, Agente”; esta agregación tiene menos de 500 registros
Y el escenario en lugar de desglozar la tabla por la dimensión Cliente, la desgloso por la dimensión ClienteTop y usa la agregación
PD:
Para los que hicieron cuantas y no les cuadro como es posible que 21 Agentes pueden atender mas de 1 millón de llamadas por día, lo que pasa es que 20 son humanos y uno de los “agentes” es una contestadota automática con muchas líneas que recibe la mayoría de las llamadas; ya saben de esos sistemas desesperantes que te dicen “Gracias por llamar, Si usted no escucha presione 1, si tiene problemas con el teclado de su celular y no puede presionar teclas presione 2, …un sinfín de opciones… si quiere hablar con un humano presione 34 o espere en la linea”