¿por qué los cubos se tardan cada día más y más en procesarse?

5 11 2008

Tortuga

Es un comentario frecuente “hace un año se tomaba una hora, hoy se tardan 2″ ¿Qué es lo que ha ocurrido? ¿Se puede optimizar?¿se puede bajar el tiempo?

Respuestas hay varias pero creo que las mas importantes son:

El volumen de información ha crecido y no tenemos una estrategia adecuada para refrescar el cubo. He visto MUCHAS veces cubos que se reprocesan completamente en su historia, así que cada mes el volumen a procesar se incrementa… Esto quiere decir que se borran todos los datos y se generan desde cero. Hay una gran oportunidad aquí. Los cubos o las herramientas no necesitan reprocesarse completamente, solo necesitan refrescar aquella parte que ya cambió. Si por ejemplo, las ventas solo están cambiando este mes entonces reprocesemos y refresquemos la información de únicamente este mes. Para esto se pueden usar varias estrategias como las particiones o manipulación de información en el ETL.

…y a veces hasta los 5 años de historia del data warehouse se generan de nuevo Hypnotized

Otra pudiera ser que está procesando únicamente el mes o día actual pero ahora hay mas transacciones. Pareciera obvio pero hay que decirlo. Hace dos años había información de 10 tiendas y ahora tenemos 20, hará una año se vendían 1000 dlls ahora se venden 2000. Mayor volumen implica mas trabajo, mas acceso a disco, etc. A veces sucede que el ancho de banda de la red no es suficiente para transferir la información a buen ritmo. Ha sucedido que existe un superserver, con un super site, pero el socket para el cable de red junto al servidor tiene 10 años y es de 10 MBITs.

Sucede.

About these ads




Creando mejores agregados para optimizar el performance de un cubo (o el Data Warehouse)

19 09 2008

image

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 Doh
  • 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.





Creando un agregado en Artus

8 09 2008

Los agregados son tablas con la información del cubo pre-sumarizada a diferentes niveles. De esta forma cuando usted lanza una consulta la herramienta OLAP determina que es más rápido obtener la información de las tablas de agregados y no del detalle, mejorando increíblemente el tiempo de respuesta (pasando las consultas de 30 mins a 2 o 3 segs algunas veces).

Si usted está trabajando en Artus con cubos propietarios o cubos ROLAP puede utilizar los agregados propietarios de Artus.

Entremos al Administrador de Artus; dé un clic al cubo sobre el que quiere crear un agregado.

agregados

Leer el resto de esta entrada »





Optimizando el tiempo de respuesta de Microsoft Analysis Services con Artus

7 05 2008

Hoy por la mañana revisábamos un indicador en Microsoft Analysis Services (AS) cuyo tiempo de respuesta al desglosarlo a nivel cliente era de varios minutos; finalmente lo dejamos en segundos.

La fórmula de dicho indicador era como esta:

iif( [Measures].[Ventas] = 0,0,1- ([Measures].[Ventas]/[Measures].[Costo])

La fórmula regresa un cero para todo aquello cuyo costo es cero. Cuando Artus lee el resul set que mostrará, por default se trae todos los valores NON_EMPTY (así es como le solicita los registros a AS: NON EMPTY). Para la fórmula anterior si el costo es cero la fórmula devuelve un cero; cero es NON_EMPTY por lo tanto AS lo incluye en el result set y Artus lo lee.

Por otra parte, Artus por default solo muestra aquellos valores del indicador que no son cero, hay que en propiedades de la tabla activar Mostrar Ceros.

¿Qué es lo que estaba pasando? Que el indicador tenía miles de registros con valor cero que como quiera se estaban calculando y además Artus los estaba leyendo, como por default no los mostraba (los ceros) nunca nos dábamos cuenta.

Dándonos cuenta de lo que estaba pasando, modificamos el indicador:

iif( [Measures].[Ventas] = 0,NULL,1- ([Measures].[Ventas]/[Measures].[Costo])

Al devolver un NULL, los AS toman este valor como EMPTY  por lo que no se incluye en el result set y además Artus no lo lee. Resultado, ahora AS preparaba un result set mucho más pequeño (lo que le toma menos tiempo y menos memoria) y Artus solo lee los 10 o 20 registros con valor.

El tiempo de respuesta quedó en segundos.

Otro método para obtener lo mismo, es clic derecho sobre el cubo y en preferencias activar excluir ceros y nulos. Este método de “por la fuerza bruta” activa esto a nivel cubo.

ExcluirCeros

Es mejor el primer método que este segundo. Por que este es global y ocultaría los ceros para todos los indicadores.





Usando esteroides con SAP BW

16 04 2008

Hará cosa de un año buscando la forma de acelerar el tiempo de respuesta de los cubos de SAP BW encontré un documento muy pero muy interesante.

SAP_MS1

Resulta, que se le puede montar a SAP los Analysis Services de Microsoft para aumentar el tiempo de respuesta. De esta forma, Analysis Services se encargará de manejar los agregados y así acelerar el tiempo de respuesta. Dicho de otra manera, SAP BW se monta encima de los Analysis Services.

SAP_MS

Es un excelente documento para mejorar el tiempo de respuesta de SAP BW, así que si todo está lento y es la muerte es hora de echarle un vistazo.

Para aquellos que alguna vez me han dicho:

—…es que estamos evaluando entre SAP BW y Analysis Services…

pues les dejamos el documento de tarea, ¿que no?

P.D. ….si, es posible bajarse el documento de SAP

PD2: Me comentan que la liga está rota, afortunadamente obtuve un respaldo.





Los discos duros y el desempeño del servidor

20 11 2007

¿los discos?¿alguna vez sea ha preocupado por esto?

Imagine que va al estadio. El estadio está al lado de una importante avenida por lo que no es problema llegar a el. El estacionamiento es inmenso por lo que no hay problema al estacionarse. Ahora imagine que solo hay 2 salidas en el estacionamiento, Pregunta: ¿Qué sucede al terminar el partido cuando todos quieren salir de ahí?

Por más grande que sea el estacionamiento, por mejores que sean las avenidas, si solo hay 2 salidas todo se atascara al salir. La desesperación cunde, los autos no avanzan y todo está a vuelta de rueda. Por más rápido que los autos puedan conducirse, a muchos kilómetros por hora, por la puerta no pueden salir más autos de los que caben por ahí.

Bueno, pues lo mismo pasa con los discos duros que almacenan la información en un data warehouse. Cada disco tiene cierta capacidad y velocidad para leer los datos. Los discos tienen cierta capacidad de trasmisión de esos datos a la tarjeta controladora de los discos y la tarjeta controladora de los discos a su vez solo pueden pasar al servidor cierta cantidad de datos por segundo al servidor (eso es el ancho de banda).

Uno no puede pedirle que trabajen más rápido o envíen los datos más rápido de lo que pueden hacerlo.

Si diseñamos mal nuestro data warehouse y sobrepasamos esas capacidades, entonces el servidor se se atora, los procesadores se van al 100%, las luces de los discos se encienden y los usuarios se quejan de que todo está lento y no sirve para nada.

Alguna vez se han preguntado si el problema de desempeño está en los discos duros ¿el I/O de datos?

Mucha gente no. Se quejan de que su servidor es lento y se compran otro más grande pero los problemas siguen. Le echan la culpa a la base de datos y cambian de marca. Le echan la culpa a la herramienta y buscan otra. Cambian Windows por Unix. Y cuando tienen un mega servidor, una base de datos carísima y licencias de cuanta herramienta hay disponible en el mercado; todo sigue igual de lento. Entonces, proclaman maldiciones a los 4 vientos y determinan que data warehousing es una basura, que es una falacia, que no sirve para nada, que han tirado miles de dólares a la basura.

Si usted tiene problemas de desempeño con el servidor, antes de pasar por todo esto pregúntese si el almacenamiento está bien diseñado, si la información está bien distribuida en los díscos, si no está sobrepasando los límites de transmisión de datos.

Este problema es mucho más común si tiene SQLServer de Microsoft ya que aunque es una base de datos que se auto-administra de manera admirable uno olvida a veces que con esos gigantescos volúmenes de datos necesita ayuda. En Oracle u otras bases de datos ocurre menos debido a que por la administración que se hace de ella (la base de datos) se le obliga a uno a administrar mejor el almacenamiento. SQLServer tiene muchas de las cosas que Oracle tiene, están ahí, escondidas, solo tiene que investigarlas. Un buen DBA debería detectar estos problemas rápidamente y solucionarlos.

Regresemos al problema del estacionamiento, si ponemos 10 salidas en vez de 2 entonces todo se aligera ¿no? Piense también en que no basta poner 10 salidas, hay que distribuir los autos en el estacionamiento para que al terminar el partido todos tomen una salida diferente. Si tenemos 10 salidas y todos intentan salir por una el problema sigue.

Lo mismo pasará pasar en el servidor.

Si ponemos 10 discos duros, el servidor puede escribir o leer 5 gigas de datos más rápido en 10 discos que en uno solo. Pero hay que diseñar la base de datos para que esté distribuida en esos 10 discos de tal forma que al leer lo haga de varios discos a la ves. En SQLServer para eso existen los filegroups que serían los equivalentes de los table spaces de Oracle. También existen las tablas particionadas para que pueda distribuir el contenido de una tabla en varios archivos y estos a su vez en varios discos.

Tenga presente el ejemplo de los autos, repítalo una y otra vez. Si el estacionamiento tiene 10 salidas en vez de dos, uno puede salir más rápido de ahí pero las salidas tienen que estar bien distribuidas y los autos haberse estacionado a lo largo del estacionamiento para que al terminar el partido cada uno de ellos tenga una salida cerca. De esta forma cuando usted piense en datos recuerde distribuir los datos en los diferentes discos duros para que las lecturas puedan distribuirse.

Un amigo compartió conmigo un documento como ejemplo de como pueden ser las cosas. Un disco para los catálogos, discos para la tabla de hechos, discos para la base de datos temporal, etc. Es un ejemplo más que claro de como se logran esos volúmenes gigantescos con determinado hardware.

Por cierto, se supone que los arreglos de discos hacen todo esto en automático pero me duele el hígado cada vez que me lo mencionan. Lo mismo me ocurre cuando me mencionan la palabra SAN. Asegurese de el arreglo o la SAN estén configurados correctamente.

Importante: todo esto no lo exime de usar índices. Tampoco significa que lo óptimo es llenar de discos el servidor. Debe de hacer un análisis para detectar si existen problemas de contención de datos.

Technorati tags: ,




Agregados

25 10 2007

sumas

En una empresa con 10,000 empleados si el Director de la empresa desea saber a cuanto asciende la nómina en su empresa ¿Cómo es más rápido obtener ese total?

  1. A cada uno de los 10000 empleados les pregunta cuanto gana, cuantas prestaciones tiene y toma nota. Cuando haya tomado nota de cada uno de ellos calcula el total.
  2. Levanta el teléfono, marca la extensión del departamento de recursos humanos y nómina y les pregunta que cuál es el total de la nómina, que seguramente ya lo tienen a la mano y siempre actualizado.

Obviamente es mucho más rápido el segundo método.

Este es el concepto de agregados (aggregates por su nombre en inglés) o agregaciones. En vez de recorrer el detalle me voy sobre un total yá calculado.

En los data warehouses y cubos este es un concepto importantísimo. Para que su herramienta de BI no tenga que hacer los cálculos de los totales a nivel registros se usan agregados.

Todas las herramientas y motores OLAP manejan o usan el concepto de agregados. Analysis Services (7, 2000, y 2005), Oracle 8 o mayor, Redbrick, DB2, SAP BW, Teradata, HP NeoViews, Artus, Pentaho, Cognos…y ahora sí que etc. Ciertamente Oracle y HP NeoViews les llaman vistas materializadas o materialized views pero el concepto es el mismo.

El administrador es el que define que agregados desea calcular y cuando se deben de recalcular. Lo normal es que se recalculen en la carga del cubo o datawarehose. Los usuarios de la información no se enteran si existen agregados, ellos lanzan la consulta sobre el cubo o la estrella principal y el motor de cubos o base de datos detecta que para resolver la consulta puede usar un agregado, toma la información de ahí y se la regresa al usuario.

Tome en cuenta que los agregados toman tiempo y espacio. Así que tampoco llene su servidor con todos los agregados posibles. Cree solo aquellos que ocupa y créelos en base a elementos que reduzcan el # de registros a recorrer. Por ejemplo, si tiene 100 tiendas, cree un agregado o total por tienda ya que serán 100 registros por día o por mes. Si tiene 17 millones 244 mil facturas NO cree un agregado a nivel factura ya que se está haciendo harakiri.

Todas los motores olap y herramientas tienen query advisors que monitorean los querys y le sugieren que agregados crear además de índices. Solo tiene que activar esos servicios. Por ejemplo en Microsoft Analysis Services puede usar la “optimización basada en uso”.

En otras palabras, si el tiempo de respuesta de sus consultas es lentísimo y desesperante, el foquito del disco duro siempre está encendido o el procesador está al 100% durante las búsquedas, no sea sádico, use agregados.Nerd

Technorati tags: ,







Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 29 seguidores