24 febrero 2015

Tarea Execute SQL

Una de las tareas más útiles en SSIS es la tarea Execute SQL. Esta tarea se puede utilizar para la ejecución de cada comando T-SQL en una base de datos originaria. Las bases de datos originarias pueden variar porque hay una amplia variedad de administradores de conexión que tienen soporte de tareas SQL. En este ejemplo, vamos a ver algunos de los escenarios más útiles, tales como la ejecución de comandos T-SQL y los resultados atractivos, o pasar parámetros de entrada y de salida.
El video de este ejercicio esta en esta dirección: https://www.youtube.com/watch?v=QAcsGILXJxg en Youtube.
Ejercicio de Aplicación
1.    Abra el SSDT y cree un nuevo tipo de proyecto Integration Services en la siguiente ubicación: C:\SSIS\Control Flow\ y nombre el proyecto TareaExecuteSQL ó puede ubicarla en cualquier otra ubicación de su agrado.
2.    Renombre el paquete como ResultSet_SingleRow.dtsx.
3.    Del menú SSIS seleccione Variables; el panel Variables aparecerá. Crear una nueva variable con Name RowCount y el Data type Int32 en Scope de paquete.
4.    En la ficha vacía Control Flow del paquete, arrastre y suelte una tarea Execute SQL desde la toolbox en Favorites en el Control Flow.
5.    Doble clic en la tarea Execute SQL; el Editor de Tarea Execute SQL se abrirá. Nombre la tarea como SQL_StaticSelectCommand.
6.    En la propiedad Connection bajo la sección SQL Statement, crear una nueva OLE DB Connection, y en el nuevo OLE DB Connection Manager, establezca el nombre del servidor como (.) para la instancia predeterminada y .\InstanceName para instancias nombradas (por ejemplo: ServerName\InstanceName). En la opción Select or enter a database name elija AdventureWorks2014. Pruebe la conexión y confírmela. Haga clic en el botón OK para retornar al Editor de Tarea Execute SQL.
7.    En la opción SQLStatement introduzca la siguiente consulta Select:
select Count(*) as Cnt from Person.Person
8.    En la pestaña General de la Execute SQL Task Editor, establezca la propiedad ResultSet a Single row.
9.    Confirme todas las configuraciones en la ficha General del editor SQL_StaticSelectCommand como se muestra en la siguiente captura de pantalla:
10.  En la ficha Result Set de la Execute SQL Task Editor, haga clic en el botón Add.  Establecer Result Name como Cnt y establecer Variable Name como User::RowCount. 
11.  Haga clic en OK y cierre el Execute SQL Task Editor. Agregue un Script Task del     Toolbox SSIS en el Control Flow justo después de SQL_StaticSelectCommand y conecte la flecha verde de SQL_StaticSelectCommand a la tarea Script.
12.  Haga doble clic en la tarea Script para abrir su editor y en la pestaña Script, en la propiedad ReadOnlyVariables, escriba el nombre de la variable de usuario como User::RowCount. En la ficha General, nombre la tarea como SCR_ShowRowCount.
13.  Haga clic en Edit Script. En el nuevo Editor de Script, en el método Main, agregue una         línea para MessageBox de la siguiente manera:
public void Main()
   {
     MessageBox.Show(
       Dts.Variables["User::RowCount"].Value.ToString()
     );
     Dts.TaskResult = (int)ScriptResults.Success;
   }
14.  Ejecute el paquete pulsando F5 y verifique el conteo de registro en la caja de mensaje. Dele clic en Aceptar y luego en el botón Stop Debugging (Shift-F5).


15.  Haga clic derecho en la carpeta SSIS Packages en el Solution Explorer y, luego, haga clic en New SSIS Package; nombre este paquete como WorkingWithParameters.
16.  En el Scope de paquete, crear una nueva variable de tipo String. Nómbrela IssueName y establezca su valor por defecto como Engine Malfunctioned. Añadir otra variable de tipo DateTime, y nómbrela Date. Confirme el valor por defecto como la fecha actual.


17.  Arrastre y suelte una nueva tarea Execute SQL en el Control Flow y nómbrelo SQL_ParametrizedCommand.
18.  Haga doble clic en la tarea Execute SQL, y en el editor, establezca una conexión a AdventureWorks2014 y escriba el siguiente comando en la propiedad SQLStatement:
INSERT INTO [Production].[ScrapReason]
        ([Name],[ModifiedDate])
    VALUES (?,?)
19.  Ir a Parameter Mapping y haga clic en el botón Add. Establezca el Variable Name como User::IssueName, Data Type como NVARCHAR y Parameter Name como 0. Luego, añada otra fila con Variable Name como User::Date, tipo de datos como DATE y el nombre del parámetro como 1.
   
20.  Haga clic en OK y cierre la tarea Execute SQL. Clic derecho en la tarea SQL_ParameterizedCommand y seleccione Execute Task. Después de ejecutar la tarea verifique la tabla Production.ScrapReason en AdventureWorks2014.
21.  Confirmar la fila recién insertada como sigue: Abrir el SSMS, bajo Bases de datos expanda AdventureWorks2014, bajo Tablas haga clic derecho en Production.ScrapReason y luego haga clic en Seleccionar las primeras 1,000 filas. Puede encontrar su nueva fila allí.
Funcionamiento
En esta ejercicio, se utilizó una tarea Execute SQL para ejecutar comandos T-SQL en una base de datos SQL Server. En primer lugar, un administrador de conexión debería ser seleccionado a una base de datos originaria; la conexión tiene una amplia gama de tipos que son soportados por SSIS como OLE DB, ADO.NET y Excel.
La sentencia SQL es donde el T-SQL Command toma lugar; el comando puede variar en función de las bases de datos originarias. Por ejemplo, si una base de datos originaria es SQL Server 2005 y superior, funciones tales como row_number() pueden ser utilizadas. Si la base de datos originaria es una Oracle DB, entonces, funciones integradas para Oracle pueden ser utilizadas.
T-SQL Commands en la tarea Execute SQL puede retornar un resultado, y el resultado es definible en la propiedad ResultSet de la ficha General, que puede ser None, Single row, Full result set, o XML. None significa que el T-SQL Command no genera resultado; Single row es utilizada cuando un solo registro de datos es retornado por T-SQL Command.
Cuando se estableció la propiedad ResultSet como una Single row, debemos definir donde se almacenarán las columnas resultantes. La ficha Result Set del editor de tareas Execute SQL es donde asigna los nombres de resultado, que son exactamente los mismos que los nombres de columna en la salida para T-SQL Commands y variables de paquete. Note que si el T-SQL Command retorna columnas sin nombre especificado, deberíamos establecer un nombre de alias para esa columna con el fin de acceder a él.
Es obvio que los T-SQL Commands deben estar parametrizados y que pueden leer los parámetros de entrada de variables de paquete o entregar los parámetros de salida en las variables. La tarea Execute SQL proporciona esta función con marcadores de parámetros en T-SQL Command. El marcador de parámetro es un marcador de posición para valores de parámetro. En el ejemplo, hemos utilizado un signo de interrogación (?) como un marcador de parámetro; el signo de interrogación es un marcador de parámetro para el tipo OLE DB Connection. Cada tipo de conexión tiene su propio marcador de parámetro. Aquí hay una lista de marcadores de parámetro para todos los tipos de conexión:
 
Además de añadir marcadores de parámetro en la propiedad SQL Statement, la asignación de parámetros con variables de paquete debería ser definido en la ficha Parameter Mapping del editor de tareas Execute SQL. En esta ficha, para cada variable o asignación de parámetro, una fila será añadida. Hay algunas propiedades aquí; Direction es de elegir entre la entrada y salida para los parámetros de entrada y de salida si queremos utilizarlas dentro de un procedimiento almacenado. Parameter Name es la siguiente propiedad importante, que debería ser seleccionada basada en el tipo de conexión. Puede ver diferentes nombres de los parámetros para los diferentes tipos de conexión que figuran en la tabla anterior.
Podemos ejecutar procedimientos almacenados sobre una base de datos originaria por ejecutar comandos en SQL (sentencias como exec dbo.CalculateSalarySP ?, ? por ejemplo). Sin embargo, hay otra opción llamada IsQueryStoredProcedure para administradores de conexión ADO.NET y ADO. Cuando esta propiedad es True, la sentencia SQL debería ser el nombre del procedimiento almacenado, tal como, CalculateSalary. La siguiente tabla muestra cómo podemos configurar una tarea Execute SQL para ejecutar procedimientos almacenados:
Adicionales
Utilizamos tareas Execute SQL con dos tipos de sentencias SQL, una sentencia con ningún conjunto de resultados, y otro con un conjunto de resultado de una sola fila. En los escenarios del mundo real tenemos que ejecutar consultas que tienen conjuntos de resultados diferentes.
Full result set
Si la sentencia SQL retorna varias filas, entonces no podemos usar un conjunto de resultados Single row; en este caso deberíamos establecer la propiedad ResultSet de la ficha General a Full result set. Además, en la ficha Result Set, una variable de tipo object debería ser asignada a nombre de resultado 0.
Después de ejecutar la tarea Execute SQL, la variable tipo object tendrá todos los registros del conjunto resultado y podremos recorrer a través de los registros y realizar las operaciones apropiadas.
XML result set
Hay algunos casos donde necesitamos conseguir resultados XML de una consulta T-SQL. Aquí es donde el conjunto resultado XML entra en juego en tareas Execute SQL. Uno de los escenarios más útiles es una consulta T-SQL que utiliza la cláusula FOR XML para retornar los datos como XML.
Todos los tipos de conjuntos resultado y la asignación de salida a variables se describen en la siguiente tabla:
BypassPrepare
La opción BypassPrepare se encuentra en la ficha General del Editor de Tarea Execute SQL. Esta opción sólo está disponible con tipos OLE DB Connection, y proporciona Prepared Execution.
Prepared Execution es una manera de reducir el tiempo para analizar y compilar una sentencia SQL. De esta manera, la función SQLPrepare primero analizará y compilará la sentencia SQL en un plan de ejecución, y luego usará la función SQLExecute para ejecutar el plan de ejecución. Así que combinando SQLPrepare y SQLExecute proporciona una manera de deshacernos de la sobrecarga del análisis y compilación de las sentencias SQL que se ejecutarán muchas veces.

16 febrero 2015

Arquitecturas de Referencia y Appliances de Data Warehouses

La construcción de un data warehouse (DW) comprando y probando componentes de hardware puede ser un proceso complejo, costoso y que consume mucho tiempo. Las arquitecturas de referencia y appliances DW simplifican el proceso de elección del hardware DW, que le ayuda a mantenerse en el presupuesto y en la fecha prevista, y para crear un DW que realmente satisfaga las necesidades de su empresa.

Fast Track Data Warehouse

Configuraciones de Hardware Validadas
El Fast Track Data Warehouse (FTDW) permite a las organizaciones a crear un DW basado en un diseño validado de manera eficiente en tiempo y en costo. El FTDW incluye un conjunto de sistemas validados partiendo de una variedad de proveedores de hardware conocidos. Estos sistemas utilizan hardware estándar, lo que reduce los costos, y la gama de proveedores permite a las empresas que ya tienen relaciones con un proveedor en particular, permanecer con ese proveedor si así lo desean. Cuando selecciona un sistema DW de las configuraciones pre-existentes, se puede elegir entre una evaluación básica o una evaluación completa. La evaluación básica implica una evaluación basada en la carga de trabajo de los requisitos del DW. Este proceso es relativamente breve, y permite a las empresas tener sus DWs en ejecución muy rápidamente. La opción de evaluación completa consiste en la realización de una evaluación más rigurosa de las cargas de trabajo, lo que se traduce en un tiempo de espera más largo, pero ofrece un sistema que pueda satisfacer las necesidades de la organización. Además, una evaluación completa puede reducir el costo de hardware si la prueba revela que, por ejemplo, se requiere un sistema menos potente el que una evaluación básica habría recomendado.
Además de seleccionar a partir de los sistemas pre-configurados, puede utilizar la metodología Fast Track para ayudar a diseñar y construir su propio DW. La metodología Fast Track le permite perfilar las cargas de trabajo e identificar benchmarks de modo que puede estar seguro del diseño que crea, pero este enfoque puede llevar mucho tiempo y requiere de conocimientos técnicos y experiencia para garantizar el éxito.
Hardware Balanceado
Las configuraciones FTDW balancean las partes componentes del sistema para asegurar lograr un flujo óptimo, y que no se originen cuellos de botella creados accidentalmente que le impedirán el rendimiento. Un enfoque balanceado comienza con los procesadores, evaluando la cantidad de datos que cada núcleo puede procesar a medida que es alimentado, y los otros componentes son balanceados sobre esto. Además de identificar la configuración óptima de hardware para un escenario determinado, el FTDW también proporciona recomendaciones para la configuración del SQL Server, incluyendo Resource Governor, particiones, índices, y compresión de datos; así como recomendaciones sobre cómo realizar cargas de datos sin perturbar la organización secuencial de datos en los discos.
Fast Track System Sizing Tool
Puede utilizar la Fast Track System Sizing Tool para ayudarle a obtener una comprensión básica del tipo de sistema que pueda necesitar. El Fast Track System Sizing Tool es un documento de Microsoft Excel, que puede descargarlo en http://www.microsoft.com/en-us/sqlserver/solutions-technologies/data-warehousing/reference-architecture.aspx; en este archivo que puede introducir la tasa de consumo máximo (MCR), el número de sesiones simultáneas, y los valores de requisitos de capacidad de datos, y se calculará el número aproximado de núcleos de procesadores y unidades de almacenamiento que se requieren para satisfacer estos requisitos. MCR es una medida del flujo en MBs por segundo. Para calcular el MCR, debe ejecutar una consulta predefinida, de sólo lectura, del caché del búfer y medir el tiempo que toma en ejecutar la consulta y la cantidad de datos procesados.

Appliances Data Warehouse

Mientras las arquitecturas de referencia FTDW pueden reducir el tiempo y el esfuerzo necesario para implementar un DW, las organizaciones todavía requieren conocimientos técnicos para ensamblar la solución. Para reducir la carga técnica sobre las organizaciones que requieren un DW, y reducir el tiempo que toma implementar una solución, Microsoft se ha asociado con proveedores de hardware para crear appliances DW preconfigurados, que puede obtener con una sola compra.
Los appliances DW que están disponibles de Microsoft y sus socios de hardware están basadas en configuraciones probadas, incluyendo arquitecturas de referencia Fast Track, y pueden reducir significativamente el tiempo requerido en diseñar, instalar y optimizar un sistema DW.
Los appliances DW basados en arquitecturas de referencia FTDW están disponibles para organizaciones o departamentos que necesitan implementar una solución DW rápidamente y con el mínimo esfuerzo de instalación y de configuración. Además, las grandes organizaciones que necesitan un DW empresarial pueden comprar un appliance basado en SQL Server Parallel DW para la escalabilidad y el rendimiento extremo.
Los appliances DW forman parte de una gama de appliances basados en SQL Server que Microsoft y sus socios de hardware han desarrollado para cargas de trabajo de bases de datos comunes. Otros tipos de appliances incluyen appliances de decisiones de negocios que proporcionan capacidades de inteligencia de negocios (BI) autoservidos, y appliances de consolidación de servidores de bases de datos que utilizan las tecnologías de virtualización para crear una infraestructura de nube privada para los servidores de bases de datos. Los appliances basados en SQL Server están disponibles de múltiples proveedores de hardware, e incluyen soporte técnico para todo el appliance, incluyendo software y hardware.

Appliances Data Warehouse Paralelas

Sistemas FTDW y appliances basadas en ellas, usan una arquitectura de multiprocesamiento simétrico (SMP). Con sistemas SMP, el bus del sistema es el componente limitante que impide el escalado más allá de un cierto nivel. Conforme el número de procesadores y la carga de datos aumentan, el bus puede sobrecargarse y convertirse en un cuello de botella. Para los data warehouse que requieren mayor escalabilidad que un sistema SMP puede proporcionar, se puede utilizar un appliance DW empresarial basado en Microsoft SQL Server Parallel Data Warehouse.
Data Warehouse Paralelo en SQL Server
Microsoft SQL Server Parallel Data Warehouse es una edición de SQL Server que sólo está disponible como una solución preinstalada y configurada en appliances DW empresarial de Microsoft y sus socios de hardware. Parallel Data Warehouse está diseñado específicamente para DWs extremos de gran envergadura que necesitan almacenar y consultar cientos de terabytes de datos.
Procesamiento Masivamente Paralelo
Parallel Data Warehouse utiliza una arquitectura de procesamiento masivamente paralelo (MPP), nada-compartido, que ofrece una mayor escalabilidad y rendimiento sobre los sistemas SMP. Los sistemas MPP entregan mucho mejor rendimiento que los servidores SMP para grandes cargas de datos. Los sistemas MPP utilizan múltiples servidores, llamados nodos, que procesan consultas independientemente en paralelo. El procesamiento paralelo implica distribuir las consultas a través de los nodos de manera que cada nodo procesa sólo una parte de la consulta; los resultados de las consultas parciales son combinados después que el procesamiento se complete para crear un único conjunto de resultados.
Arquitectura Nada-Compartido
Los sistemas que utilizan componentes compartidos, como la memoria o el almacenamiento en disco, pueden sufrir de problemas de rendimiento debido a la contención de estos componentes compartidos. La contención ocurre cuando varios nodos intentan acceder a un componente a la vez, y por lo general resulta en un degradado del rendimiento como colas de nodos para acceder a los recursos. Las arquitecturas nada-compartido eliminan la contención, debido a que cada nodo tiene su propio conjunto de hardware dedicado, que no es utilizado por los otros nodos. La eliminación de la contención de un sistema resulta en una mejora del rendimiento, y lo habilita para manejar cargas de trabajo más grandes.
Nodos de Control, Nodos de Cálculo, y Nodos de Almacenamiento
Un appliance Parallel Data Warehouse consiste de un servidor que actúa como el nodo de control, y varios servidores que actúan como nodos de cálculo y nodos de almacenamiento. Cada nodo de cálculo tiene sus propios procesadores dedicados, memoria, y está asociado con un nodo de almacenamiento dedicado. Una red InfiniBand dual conecta los nodos juntos, y los canales de fibra dual enlazan los nodos de cálculo a los nodos de almacenamiento. El nodo de control intercepta consultas entrantes, divide cada consulta en varias operaciones más pequeñas y, luego, las pasa a los nodos de cálculo para procesarlas. Cada nodo de cálculo retorna los resultados de su procesamiento al nodo de control. El nodo de control integra los datos para crear un conjunto de resultados, que luego retorna al cliente.
Los nodos de control están alojados en un rack llamado el rack de control. Hay otros tres tipos de nodos que comparten este rack con el nodo de control:
  • Nodos de Gestión, a través del cual los administradores gestionan el appliance.
  • Nodos de Zona Landing, que actúan como áreas staging para los datos que se cargan en el data warehouse utilizando la herramienta de extracción, transformación y carga (ETL).
  • Nodos de Backup, que respaldan el data warehouse.
Los nodos de cálculo y los nodos de almacenamiento son ubicados en un rack separado llamado el rack de datos. Para escalar la aplicación, se puede añadir más racks según sea necesario. Los componentes de hardware son duplicados, incluyendo los nodos de control y de cálculo, para proporcionar redundancia.
Puede utilizar un appliance Parallel Data Warehouse como el hub en una configuración hub y spoke, y poblar los data marts directamente desde el DW. Usando una configuracion hub y spoke que permite integrar el appliance con data marts existentes o crear data marts locales según sea necesario. Si utiliza sistemas FTDW para construir los data marts, puede lograr transferencias de datos muy rápidas entre los hubs y los spokes. 

13 febrero 2015

Consideraciones para Construir un Data Warehouse

Las opciones de hardware que considera cuando diseña y construye un data warehouse afectará directamente al rendimiento que el data warehouse proporciona. Por lo tanto, es muy importante identificar el hardware adecuado en una etapa temprana en el proceso de diseño. Sin embargo, las cargas de trabajo del data warehouse difieren significativamente de las cargas de trabajo de los sistemas transaccionales, y no siempre es obvio que el mejor enfoque de diseño de hardware, podría serlo para cualquier situación dada.
Se describe las características de las cargas de trabajo data warehouse típicas, y se explica cómo se puede utilizar arquitecturas de referencia y los appliances de data warehouse para asegurarse de que construye el sistema adecuado para su organización.
Para construir un data warehouse que cumpla con los requisitos de su organización, es importante que comprenda las características de las cargas de trabajo data warehouse típicas, cómo afecta el hardware al rendimiento del data warehouse, y qué opciones tiene disponibles para implementar una solución data warehouse.

Las Cargas de Trabajo del Data Warehouse

Un data warehouse puede contener millones de filas de datos, y aumentará en tamaño con cada carga de datos. Una consulta data warehouse típica implica seleccionar, resumir, agrupar y filtrar filas para retornar un rango de datos que podría consistir en un gran subconjunto de filas de la base de datos. Por ejemplo, un analista de negocios podría emitir una consulta que retorne un resumen de las ventas para un producto en particular entre dos fechas definidas. Dependiendo de las fechas que el analista elija, la consulta podría requerir que Microsoft SQL Server acceda a cientos de miles o incluso millones de filas. Esto es muy diferente a la forma en que una base de datos de procesamiento transaccional en línea (OLTP) es utilizada generalmente. Con bases de datos OLTP, la mayoría de las actividades implica la adición de nuevas filas, y la actualización o eliminación de filas existentes. Los usuarios usualmente trabajan con datos en las bases de datos OLTP, de unas pocas filas a la vez; por lo tanto, los administradores deben optimizar la base de datos para la recuperación de un pequeño número de filas, como de la creación de índices nonclustered.
Las diferentes características de las consultas data warehouse requieren un enfoque diferente para la configuración de hardware y software que para las bases de datos OLTP. En general, debe optimizar los data warehouses para la actividad de entrada/salida (E/S) de disco secuencial, que consiste en leer filas del disco en el orden en que se solicitan. Por ejemplo, si la mayoría de consultas solicitan datos para rangos de fechas, entonces puede almacenar los datos en orden cronológico, lo que permite que la fecha sea leída desde el disco como una secuencia. También debe tener los siguientes puntos en mente cuando considera las cargas de trabajo data warehouse.
  • Las consultas típicamente escanean un gran número de filas. El escaneo en lugar de la búsqueda para recuperar filas es más eficiente cuando está implicado un gran número de filas, particularmente cuando las filas se almacenan secuencialmente en el disco. Por ejemplo, en una tabla de hechos que almacena las filas ordenadas por fecha, es posible procesar consultas por rangos de fecha por acceder a los datos secuencialmente.
  • Los data warehouses contienen datos relativamente estáticos. El contenido de un data warehouse normalmente permanece estático entre cada carga masiva de datos, ya que los usuarios rara vez realizan operaciones de actualización o eliminación. En consecuencia, la fragmentación de la base de datos es minimizada y los datos permanecen en el mismo orden secuencial en el disco, lo que mejora el rendimiento del escaneado.
  • Los índices nonclustered pueden disminuir el rendimiento. Aunque los índices nonclustered pueden acelerar las consultas que retornan un pequeño número de filas, para consultas que retornan conjuntos de datos grandes los índices nunclustered pueden reducir los tiempos de respuesta, debido a las exploraciones de E/S aleatorias derivadas de su uso. Además, los índices nunclustered requieren mantenimiento y deben ser reconstruidos cada vez que se cargan los datos, que agrega considerable sobrecarga de gestión y procesamiento, y que puede ser problemático cuando se tienen ventanas de procesamiento muy estrechas disponibles.
  • El particionado puede mejorar los tiempos de respuesta de las consultas. El particionado permite un procesamiento más rápido de los datos, ya que reduce la contención y puede reducir el número de filas incluidas en una exploración de tabla. El uso de particiones también simplifica la gestión de conjuntos de datos en la data warehouse y ayuda a minimizar la fragmentación.
Nota. Las cargas de trabajo pueden variar significativamente entre data warehouses, por lo que es importante evaluar cada data warehouse independientemente y no asumir que las consideraciones señaladas anteriormente se aplicarán en todos los casos.

Arquitectura del Sistema Data Warehouse

Mientras que puede instalar el software de base de datos en prácticamente cualquier hardware de computadora y usarlo como un data warehouse; obtendrá resultados óptimos y eficientes utilizando una arquitectura de sistema que esté optimizada para cargas de trabajo data warehouse.
La elección de los componentes adecuados para su data warehouse no es sólo acerca de comprar la solución de almacenamiento más rápida o de más memoria posible. Para construir una solución data warehouse efectiva, debe balancear estos componentes juntos, para que un solo componente no se convierta en un cuello de botella en el sistema y ralentice el rendimiento global. Además, debe balancear la especificación de hardware para su data warehouse sobre el coste de los componentes. La sobre especificación de la configuración de hardware para su data warehouse puede resultar en hardware costosos, infrautilizados que excede los requerimientos para la carga de trabajo de su data warehouse.

Software

Las datas warehouses SQL Server se deberían basar en la edición Datacenter o Enterprise de Windows Server y SQL Server 2012 (o 2014) Enterprise Edition. Estas ediciones de software permiten a su sistema data warehouse aprovechar al máximo los recursos del hardware, como memoria y almacenamiento, así como las capacidades de nivel empresarial tales como el clustering de servidores de alta disponibilidad.
Dependiendo del hardware de servidor y de almacenamiento específico utilizado, también puede beneficiarse del software de gestión específico del vendor de hardware para ayudar a configurar, supervisar y operar el hardware del data warehouse.   
Hardware de Servidor
Un data warehouse requiere un hardware de servidor adecuado para gestionar su carga de trabajo. En la mayoría de los escenarios de la empresa, una data warehouse se implementa como uno o más nodos de servidor en un rack, e incluye los siguientes recursos de hardware:
  • Procesadores. El número de núcleos de procesador y la velocidad del procesador pueden ser factores limitantes donde la capacidad de procesamiento total no es lo suficientemente grande como para manejar el rendimiento de los otros componentes en el sistema. Sin embargo, la adición de más o más rápidos procesadores sólo mejorará el rendimiento si los otros componentes del sistema pueden pasar datos desde y hacia los procesadores a velocidades lo suficientemente rápidos.
  • Memoria. La memoria ayuda al rendimiento de varias maneras, por ejemplo, al permitir que las consultas de SQL Server sean respondidas desde la caché, o por habilitar las operaciones joins y sort para que sean realizadas más eficientemente. Cuando no hay suficiente memoria presente, las operaciones join y sort pueden utilizar el espacio de disco, lo que reduce la capacidad de disco disponible y provoca la fragmentación.
Almacenamiento
Mientras que es posible alojar una data warehouse en el disco duro interno en un servidor de base de datos; en escenarios empresariales es más común utilizar un subsistema de almacenamiento dedicado que incluye:
Enclosures. Enclosures de almacenamiento incluyen controladores de disco en la placa madre que gestionan el almacenamiento de arreglos redundante de discos independientes (RAID) en múltiples discos. El servidor está conectado a los enclosures de almacenamiento a través de una conexión de acceso directo a un adaptador de host, o más comúnmente a través de una conexión de red.
Arreglos de disco. Cada enclosure en un sistema data warehouse contiene varios discos duros, generalmente configurados como arreglos RAID 10. El número y la velocidad de los discos en un arreglo de almacenamiento puede afectar al rendimiento del data warehouse. Puede elegir entre una serie de factores de forma de disco dependiendo de sus requerimientos de capacidad de almacenamiento, tamaño físico y el rendimiento de lectura/escritura. Algunos factores de forma de disco a considerar incluyen:
  • Serial Attached SCSI (SAS) – unidades de discos magnéticos en factores de forma grande (LFF) o factor de forma pequeña (SFF). Los discos SAS ofrecen grandes capacidades de almacenamiento y suficiente rendimiento de lectura/escritura para las cargas de trabajo del data warehouse.
  • Unidad de estado sólido (SSD) - un dispositivo de almacenamiento que utiliza memoria de estado sólido en lugar de un disco giratorio. La falta de piezas móviles hace a las SSDs robustas y reduce el tiempo de acceso al leer los datos; incrementando el rendimiento general. Además, los SSDs típicamente suelen requerir menos energía que los discos mecánicos. Sin embargo, el coste por gigabyte de los SSDs es normalmente mayor que el de los discos SAS.
Los discos son a menudo la causa de los cuellos de botella en los data warehouse, porque si el sistema de almacenamiento no tiene suficientes unidades, o las unidades no son lo suficientemente rápidas, el flujo en los otros componentes en el sistema es menor, y el rendimiento se verá afectado. Además, los requisitos de almacenamiento para un data warehouse generalmente crece considerablemente con el tiempo, por lo que se debe planear para la extensibilidad.

Networking

Cuando implementa networking para un sistema data warehouse, debe considerar dos conexiones de red.
  • Conectividad de almacenamiento. El servidor data warehouse esta típicamente conectado al subsistema de almacenamiento a través de una conexión de red. En la mayoría de los sistemas data warehouse empresariales, un conmutador de canal de fibra es utilizada para proporcionar conectividad de alta velocidad entre un adaptador de bus de host (HBA) sobre el servidor y los enclosures de almacenamiento.
  • Conectividad de red externa. Además de la conexión interna entre el servidor data warehouse y su subsistema de almacenamiento, debe considerar cómo conectará el data warehouse a una red externa para que las aplicaciones de cliente puedan conectar y utilizar el data warehouse. El tipo de conectividad de red utilizado para el acceso del cliente al data warehouse depende de la topología de red de sus organizaciones de redes de área local (LAN), pero debe usar una tecnología de red que proporcione el ancho de banda y el rendimiento adecuado para los volúmenes de datos que serán cargadas en el data warehouse por el proceso de extracción, de transformación y de carga (ETL), y recuperadas por las aplicaciones del cliente.
Opciones para la Implementación de un Data Warehouse
Para construir una data warehouse que cumpla con las demandas de reportes y análisis de datos de su organización requiere una planificación cuidadosa. Un data warehouse no es simplemente una versión modificada de una base de datos transaccional. Las consideraciones de diseño para los data warehouses son muy diferentes a las de los sistemas OLTP. Cuando decide cómo abordar la construcción de un data warehouse, debe tener en cuenta varios factores, incluyendo el presupuesto disponible, la fecha de entrega prevista para la solución completa, y si su organización tiene personas que tienen las habilidades adecuadas y la experiencia para diseñar y construir un data warehouse.

Solución Hecha a Medida

Las soluciones hechas a medida generalmente toman la mayor cantidad de tiempo para completarse. También requieren de la organización para diseñar, evaluar, ensamblar y probar todo en las instalaciones. Por lo tanto, la organización debe tener personas empleadas con las habilidades necesarias, o contratarlas. Aunque el costo aparente de una solución hecha a medida podría ser menor que para las soluciones de arquitectura de referencia o las basadas en appliances, los tiempos de desarrollo prolongados y la contratación de personas cualificadas pueden aumentar significativamente estos costos. Por otra parte, existe el riesgo de que a pesar de la planificación y las pruebas que realice, un sistema de construcción propia podría no ser capaz de satisfacer las demandas que se plantearon. Esto es particularmente un riesgo cuando los individuos involucrados tienen experiencia limitada con las implementaciones data warehouse y conocimientos limitados de la arquitectura data warehouse.

Arquitecturas de Referencia

El propósito de las arquitecturas de referencia data warehouse es minimizar el riesgo de fracaso, reducir los costos y acelerar el tiempo de entrega de la solución. Una arquitectura de referencia es esencialmente un blueprint que le permite crear un data warehouse basado en un diseño probado y verificado, reduciendo el tiempo de diseño y el nivel de conocimiento y experiencia que una organización requiere. Microsoft Fast Track Data Warehouse es un conjunto de arquitecturas de referencia que están basadas en la plataforma SQL Server. Las arquitecturas de referencia Fast Track utilizan una gama de configuraciones de hardware dedicado, que están diseñados para adaptarse a muchas necesidades diferentes, permitiendo a las empresas a tener su data warehouse en ejecución rápidamente y de manera rentable.

Appliances

Un appliance data warehouse es un sistema de pre-construido que está diseñado y optimizado para data warehousing. Los appliances incluyen servidores, hardware de almacenamiento, un sistema operativo, y un sistema de gestión de base de datos (DBMS). Los appliances data warehouse pueden ser basadas en arquitecturas de hardware de multiproceso simétrico (SMP), o de los cada vez más poderosos, sistemas de procesamiento paralelo masivo (MPP), que están dirigidos a las grandes organizaciones. Debido a que todos los componentes en un appliance ya están construidos y configurados, ofrecen la experiencia de implementación más simple; pero puede ser una solución menos flexible que la hecha a medida o la de arquitecturas de referencia.

30 enero 2015

Consideraciones para una Solución Data Warehouse

Antes de iniciar un proyecto data warehousing, hay varias consideraciones de las que debe estar consciente. La comprensión de estas consideraciones le ayudará a crear una solución data warehousing que direccione sus necesidades y restricciones específicas.

Base de Datos y Almacenamiento Data Warehouse

Un data warehouse es una base de datos relacional que está optimizada para la lectura de datos para el análisis y los reportes. Cuando está planeando un data warehouse, debe tomar en cuenta las siguientes consideraciones.
Esquema de Base de Datos
El esquema lógico de un data warehouse está típicamente diseñado para desnormalizar los datos en una estructura que minimice el número de operaciones JOIN que son requeridas en las consultas utilizadas para recuperar y agregar datos. Un enfoque común es diseñar un esquema estrella en la cual las medidas numéricas son almacenadas en tablas de hechos que tienen llaves foráneas a múltiples tablas de dimensión que contienen las entidades del negocio por la cual las medidas pueden ser agregadas. Antes de diseñar su data warehouse, debe conocer qué dimensiones necesitan utilizar sus usuarios del negocio cuando agregan datos, qué medidas necesitan ser analizadas y en qué granularidad, y cuales hechos incluyen tales medidas. También debe planificar las llaves que serán utilizadas para vincular hechos a dimensiones cuidadosamente, y considerar si su data warehouse debe soportar el uso de dimensiones que cambian con el tiempo (por ejemplo, el manejo de registros de dimensión para clientes que cambian su dirección).
También debe considerar la implementación física de la base de datos, ya que esto afectará el rendimiento y la manejabilidad del data warehouse. Es común utilizar el particionado de tablas para distribuir datos de hechos grandes a través de varios filegroups, cada uno en un disco físico diferente. Esto puede incrementar el rendimiento de la consulta y le permite implementar una estrategia de backup basado en filegroup que puede ayudar a reducir el tiempo de inactividad en caso de una falla de disco único. También debe considerar la estrategia de indexación apropiada para sus datos, y si debe utilizar la compresión de datos cuando almacena los datos.
Hardware
La elección del hardware para su solución data warehouse puede hacer una diferencia significativa en el rendimiento, manejabilidad, y el costo de su data warehouse. Las consideraciones del hardware para una data warehouse incluyen:
  • Los requisitos del procesamiento de consultas, incluyendo la memoria pico previsto y la utilización del CPU.
  • El volumen de almacenamiento y requisitos de entrada/salida de disco.
  • La conectividad de red y ancho de banda.
  • La redundancia de componentes para alta disponibilidad.
Puede optar por construir su propia solución data warehouse por la compra y el montaje de componentes individuales, usando una arquitectura de referencia probada, o comprar un dispositivo de hardware que incluya componentes preconfigurados en un paquete listo para su uso. Los factores que influyen en su elección del hardware incluyen:
  • Presupuesto.
  • Acuerdos de empresa existente con los vendors de hardware.
  • Tiempo de la solución.
  • Experiencia en el ensamblaje de hardware y en la configuración.
Alta Disponibilidad y Recuperación de Desastres
Un data warehouse puede muy rápidamente llegar a ser una parte crítica para el negocio de su infraestructura de aplicación general, por lo que es esencial considerar cómo garantizará su disponibilidad. SQL Server incluye soporte para varias técnicas de alta disponibilidad, incluyendo el reflejado de base de datos y el clustering de servidores. Debe evaluar estas tecnologías y escoger la mejor opción para su solución individual en base a:
  • Los requisitos de tiempo de conmutación por error.
  • Requisitos de hardware y de costos.
  • Complejidad de configuración y de gestión.
Además de una solución de alta disponibilidad a nivel de servidor, también debe considerar la redundancia a nivel de componente individual para las interfaces de red y arreglos de almacenamiento.
La solución de alta disponibilidad más robusta no puede proteger su data warehouse de todas las eventualidades, así que también debe planificar una solución de recuperación a desastres adecuado, que incluye una estrategia de backup completa. Su estrategia backup debe tener en cuenta:
  • El volumen de datos en el data warehouse.
  • La frecuencia de los cambios a los datos en el data warehouse.
  • El efecto del proceso backup en el desempeño del data warehouse.
  • El tiempo de recuperación de la base de datos en el caso de un fallo.
Seguridad
Su data warehouse contiene un gran volumen de datos que es típicamente sensible comercialmente. Además, es posible que desee proporcionar acceso a algunos datos a todos los usuarios, pero restringir el acceso a algunos datos para un subconjunto de usuarios.
Las consideraciones para asegurar su data warehouse incluyen:
  • Los mecanismos de autenticación que debe soportar para proporcionar el acceso al data warehouse.
  • Los permisos que requerirán los distintos usuarios que acceden al data warehouse.
  • Las conexiones sobre las cuales los datos son accedidos.
  • La seguridad física de la base de datos y de los medios de backup.
Orígenes de Datos
Debe identificar los orígenes de datos que proporcionan los datos para su data warehouse, y considerar los siguientes factores a la hora de planificar su solución.
Tipos de Conexión de Orígenes de Datos
Su data warehouse puede requerir datos de una variedad de orígenes de datos. Para cada origen, debe considerar cómo su proceso ETL puede conectar y extraer los datos requeridos. En muchos casos, sus orígenes de datos serán las bases de datos relacionales para las cuales puede utilizar un proveedor OLE DB u Open Database Connectivity (ODBC). Sin embargo, algunos orígenes de datos pueden utilizar un almacenamiento propietario que requiere un proveedor hecho a la medida o para el cual no existe proveedor. En este caso, se debe desarrollar un proveedor personalizado o determinar si es posible exportar los datos del origen de datos en un formato que el proceso ETL puede consumir fácilmente (como XML o texto delimitado por comas).
Credenciales y Permisos
La mayoría de los orígenes de datos requieren un acceso seguro en la forma de autenticación de usuarios y permisos individuales sobre los datos. Debe trabajar con los propietarios de los orígenes de datos que utiliza en su solución data warehousing para establecer:
  • Credenciales que su proceso ETL puede utilizar para acceder al origen de datos.
  • Los permisos requeridos para acceder a los datos que utiliza el data warehouse.
Formatos de Datos
Un origen de datos puede almacenar los datos en un formato diferente. Su solución debe tener en cuenta los problemas derivadas de esto, incluyendo:
  • La conversión de datos de un tipo de datos a otro, por ejemplo, la extracción de valores numéricos desde un archivo de texto.
  • El truncamiento de datos cuando copia datos a un destino, que tiene una longitud de datos limitados.
  • Los formatos de fecha y de tiempo que son utilizados en los orígenes de datos.
  • Los formatos numéricos, escalas y precisiones.
  • Soporte para caracteres Unicode.
Ventanas de Adquisición de Datos
Dependiendo de los patrones de carga de trabajo de la empresa, cada origen de datos puede tener períodos de tiempo donde el origen de datos no está disponible o el nivel de uso es tal que la sobrecarga adicional de una extracción de datos no es deseable. Cuando planea una solución data warehousing, debe trabajar con cada propietario de los orígenes de datos para determinar la ventana de adquisición de datos adecuada basada en:
  • El patrón de la carga de trabajo del origen de datos, y sus niveles de capacidad y utilización de los recursos.
  • El volumen de datos a ser extraídos, y el tiempo que toma extraerlo.
  • La frecuencia con la cual necesita actualizar el data warehouse con nuevos datos.
  • Si es aplicable, las zonas de tiempo en el cual los usuarios del negocio están accediendo a los datos.
Procesos de Extracción, Transformación y Carga
Una parte importante de los esfuerzos en la creación de una solución data warehouse es la implementación de un proceso ETL. Cuando se diseña un proceso ETL para una solución data warehousing, debe tener en cuenta los siguientes factores.
Staging
En algunas soluciones data warehousing, puede transferir datos directamente de los orígenes de datos para al data warehouse sin ningún staging intermedio. Sin embargo, en muchos casos, debe considerar el staging de datos para:
  • Sincronizar una actualización del data warehouse que incluye los datos de origen que han sido extraídos durante varias ventanas de adquisición de datos.
  • Realizar la validación de datos, la limpieza, y las operaciones de deduplicación de los datos antes de que sean cargados al data warehouse.
  • Realizar transformaciones en los datos que no pueden ser realizados durante los procesos de extracción de datos o del flujo de datos.
Si un área staging es requerido en su solución, debe decidir en un formato para los datos staged. Los formatos posibles son:
  • Una base de datos relacional.
  • Archivos de texto o de XML.
  • Archivos RAW (archivos binarios en un formato propietario de la plataforma ETL que está siendo utilizada).
La decisión sobre el formato se basa en varios factores, incluyendo:
  • La necesidad de acceder y modificar los datos staged.
  • El tiempo que es tomado para almacenar y leer los datos staging.
Por último, si una base de datos relacional es utilizada como el área staging, debe decidir dónde residirá esta base de datos. Las opciones posibles son:
  • Un servidor staging dedicado.
  • Una instancia de SQL Server dedicado en el servidor data warehouse.
  • Una base de datos staging dedicado en la misma instancia de SQL Server así como el data warehouse.
  • Una colección de tablas staging (tal vez en un esquema dedicado) en la base de datos data warehouse.
Los factores que debería considerar cuando decide la ubicación de la base de datos staging incluyen:
  • Los requisitos del hardware de Servidor y los costos.
  • El tiempo que toma transferir los datos a través de las conexiones de red.
  • El uso de técnicas de carga Transact-SQL que son realizados mejor cuando los datos staging y de data warehouse son co-localizados en la misma instancia de SQL Server.
  • Las sobrecargas de recursos del servidor que son asociadas con el proceso de carga de staging y del data warehouse.
Transformaciones Requeridas
La mayoría de los procesos ETL requieren que los datos que están siendo extraídos de los orígenes de datos sean modificados para coincidir con el esquema del data warehouse. Cuando planea un proceso ETL para una solución data warehousing, debe examinar el esquema de datos de origen y de destino, e identificar qué transformaciones son requeridas. Entonces, debe determinar el lugar óptimo dentro del proceso ETL para realizar estas transformaciones. Las opciones para la implementación de las transformaciones de datos incluyen:
  • Durante la extracción de datos. Por ejemplo, por la concatenación de dos campos en un origen de datos SQL Server en un único campo en la consulta Transact-SQL que es utilizada para extraer los datos.
  • En el flujo de datos. Por ejemplo, por utilizar una tarea de transformación de datos Derived Column en un flujo de datos de SQL Server Integration Services.
  • En el área staging. Por ejemplo, por utilizar una consulta Transact-SQL para aplicar los valores por defecto a campos null en una tabla staging.
Factores que afectan la elección de la técnica de transformación de datos incluyen:
  • La sobrecarga del rendimiento de la transformación. Por lo general, es mejor utilizar el enfoque que tiene la menor sobrecarga del rendimiento. Las operaciones basadas en conjuntos que son realizadas en consultas Transact-SQL generalmente tienen mejor desempeño que las transformaciones basadas en filas que son aplicadas en un flujo de datos.
  • El nivel de soporte para consultas y actualización en los orígenes de datos o área staging. En los casos en que está extrayendo los datos de un archivo delimitado por comas y son staged en un archivo RAW, sus opciones para realizar transformaciones están limitadas a transformaciones de fila por fila en el flujo de datos.
  • Dependencias sobre los datos son requeridos para la transformación. Por ejemplo, puede necesitar mirar un valor en un origen de datos para obtener datos adicionales de otro origen de datos. En este caso, debe realizar la transformación de datos en una ubicación donde ambos orígenes de datos sean accesibles.
  • La complejidad de la lógica que está implicada en la transformación. En algunos casos, una transformación puede requerir múltiples pasos y ramas dependiendo de la presencia o el valor de campos de datos específicos. En este caso, a menudo es más fácil aplicar la transformación por la combinación de varios pasos en un flujo de datos de lo que sería crear una sentencia Transact-SQL para realizar la transformación.
ETL Incremental
Después de la carga inicial del data warehouse, generalmente necesitará nuevas cargas incrementales o datos de origen actualizados en el data warehouse. Cuando planea su solución data warehousing, debe considerar los siguientes factores que se relaciona con el ETL incremental:
  • ¿Cómo identificará registros nuevos o modificados en los orígenes de datos?
  • ¿Necesita eliminar registros en el data warehouse cuando los registros correspondientes en los orígenes de datos son eliminados? Si es así, ¿Eliminará físicamente los registros, o simplemente les marcará como inactivos (a menudo referido como un borrado lógico)?
  • ¿Cómo determinará si un registro que será cargado en el data warehouse debería ser un nuevo registro o una actualización de un registro existente?
  • ¿Existen registros en el data warehouse para el cual los valores históricos deban ser preservados por la creación de una nueva versión del registro en lugar de actualizar el registro existente?
Calidad de Datos y Gestión de Datos Maestros
La utilidad de un data warehouse es determinada en gran medida por la calidad de los datos que contiene. Por esta razón, cuando se planea un proyecto data warehousing, debería determinar cómo asegurará la calidad de los datos y si debería considerar el uso de una solución de gestión de datos maestros.
Calidad de Datos
Para validar y hacer cumplir la calidad de los datos en el data warehouse, es recomendado que los usuarios del negocio que tienen conocimiento de un área comprendida en el data warehouse, tomen el rol de steward de datos para esa área. Un steward de datos es responsable de:
  • Construir y mantener una base de conocimiento que identifica los errores de datos comunes y sus correcciones.
  • Validación de datos sobre la base de conocimientos.
  • Asegurar que los valores consistentes sean utilizados para los atributos de datos donde múltiples formas del valor pueden considerarse válidos (por ejemplo, asegurar que un campo Country siempre utiliza el valor "United States" cuando se refiere a America, aun cuando "USA", "The U.S." y "America" son también valores válidos).
  • Identificar y corregir los valores de datos faltantes.
  • Identificación y consolidación de entidades de datos duplicados (así como un registro de cliente para "Robert Smith" y un registro de cliente para "Bob Smith" que ambos se refieren a un mismo cliente físico).
Puede utilizar SQL Server Data Quality Services para proporcionar una solución de calidad de datos que ayude al steward de datos a realizar estas tareas.
Gestión de Datos Maestros
Es común en las grandes organizaciones tener múltiples aplicaciones de negocio, y en muchos casos, estos sistemas realizan tareas que están relacionadas con las mismas entidades de la empresa. Por ejemplo, una organización puede tener una aplicación e-commerce que permite a los clientes a comprar productos, y un sistema de gestión de inventario separado que también almacena datos acerca de los productos. Un registro representando un producto en particular puede existir en ambos sistemas. Puede ser útil en este escenario implementar un sistema de gestión de datos maestros que proporcione una definición autorizada de cada entidad del negocio (en este ejemplo, un producto en particular) que puede utilizar sobre múltiples aplicaciones para garantizar la coherencia.
En un escenario data warehousing, el uso de la gestión de datos maestros es especialmente importante, ya que garantiza que los datos en el data warehouse se ajusten a la definición acordada por las entidades del negocio que serán incluidos en cualquier solución de análisis y de reportes que deben soportar.
Puede utilizar SQL Server Master Data Services para implementar una solución de gestión de datos maestros.

27 enero 2015

Introducción al Data Warehousing

El data warehousing es una solución que las organizaciones pueden utilizar para centralizar los datos del negocio, para la presentación de reportes y análisis. La implementación de una solución data warehouse lo puede proporcionar una empresa u otra organización con importantes beneficios, incluyendo:
  • Reportes completos y precisos de la información clave del negocio.
  • Un origen centralizado de datos del negocio para el análisis y la toma de decisiones.
  • La base para una solución de inteligencia de negocios empresarial (BI).
El data warehousing es una técnica bien establecida para los datos del negocio centralizada en la presentación de reportes y análisis. Aunque los detalles específicos de soluciones individuales pueden variar, hay algunos elementos comunes en la mayoría de las implementaciones data warehousing. La familiaridad con estos elementos le permitirá planificar mejor y construir una solución data warehousing eficiente.

El Problema de la Empresa

El manejo efectivo de una empresa puede presentar un reto importante, especialmente cuando el negocio crece o se ve afectado por las tendencias en el mercado objetivo del negocio o la economía global. Para tener éxito, una empresa debe adaptarse a las condiciones cambiantes, lo que requiere personas en las organizaciones para tomar buenas decisiones estratégicas y tácticas del negocio. Sin embargo, los siguientes problemas del negocio a menudo pueden hacer difíciles la toma de decisiones:
  • Los datos claves del negocio se distribuyen a través de múltiples sistemas. Esto hace que sea difícil recopilar toda la información necesaria para una decisión de un negocio en particular.
  • La búsqueda de la información necesaria para la toma de decisiones del negocio toma tiempo y es propenso a errores. La necesidad de reunir y conciliar los datos de múltiples orígenes resulta en procesos de toma de decisiones ineficientes y lentos, que pueden ser agudizados aún más a través de las inconsistencias entre duplicados, y orígenes contradictorios de la misma información.
  • Las preguntas del negocio fundamentales son difíciles de responder. La mayoría de las decisiones del negocio requieren un conocimiento de los hechos fundamentales, tales como "¿Cuántos clientes tenemos?" o "¿Qué productos vendemos más frecuentemente?" Aunque estas preguntas pueden parecer simples, la distribución de los datos a través de múltiples sistemas en una organización típica puede hacerlos difíciles, o incluso imposibles, de responder.
Al resolver estos problemas, es posible tomar decisiones efectivas que ayuden a la empresa a ser más exitosa, tanto a nivel estratégico, como ejecutivo y durante las operaciones del día a día del negocio.

¿Qué es un Data Warehouse?

Un data warehouse proporciona una solución al problema de datos distribuidos que evita la toma de decisiones efectiva del negocio. Hay muchas definiciones para el término "data warehouse", y desacuerdos sobre los detalles de implementación específicos, pero es generalmente aceptado que un data warehouse es un almacén centralizado de datos del negocio que puede ser utilizado para reportes y análisis, para informar las decisiones del negocio.
Típicamente, una data warehouse:
  • Contiene grandes volúmenes de datos históricos, referidos a las transacciones del negocio.
  • Está optimizado para operaciones de lectura que soportan la consulta de los datos. Esto está en contraste con una base de datos de procesamiento de transacciones en línea (OLTP) típica, que está diseñada para soportar operaciones de inserción, de actualización, y de eliminación de datos, también.
  • Se carga con datos nuevos o actualizados a intervalos regulares.
  • Proporciona la base para aplicaciones empresariales de BI. 

Arquitecturas de Data Warehouse

Hay muchas maneras de implementar una solución data warehouse en una organización. Algunos enfoques comunes incluyen:
  • La creación de un único, data warehouse empresarial central, para todas las unidades del negocio.
  • La creación de pequeños, data warehouses departamentales, para las unidades del negocio individuales.
  • La creación de una arquitectura hub-and-spoke, que sincroniza un data warehouse empresarial central, con los data marts departamentales que contienen un subconjunto de los datos del data warehouse.
La arquitectura adecuada para que una empresa dada, podría ser uno de estas, o una combinación de varios elementos de los tres enfoques.

Componentes de una Solución Data Warehousing

Una solución data warehousing usualmente consiste de los siguientes elementos:
  • Data sources. Los orígenes de datos del negocio para el data warehouse, a menudo incluyen las bases de datos de aplicaciones OLTP y datos que han sido exportados desde sistemas propietarios como las aplicaciones de contabilidad.
  • Un proceso de extracción, transformación y carga (ETL). Un flujo de trabajo para acceder a los datos de los orígenes de datos, modificándolo para ajustarse al modelo de datos para el data warehouse y cargándolo en el data warehouse.
  • Areas de staging de datos. Son ubicaciones intermedias donde los datos que están siendo transferidos al data warehouse, son almacenados para prepararlos para importarlos al data warehouse y sincronizar las cargas del data warehouse.
  • Un data warehouse. Una base de datos relacional que ha sido diseñado para proporcionar consultas de alto rendimiento de los datos históricos de la empresa, para reportes y análisis.
Además, muchas de las soluciones data warehousing también incluyen:
  • Limpieza de datos y deduplicación. Una solución para resolver los problemas de calidad en los datos antes de que sean cargados en el data warehouse.
  • Gestión de datos maestros (MDM). Una solución que proporciona una definición de datos autorizada por las entidades de la empresa que usan los múltiples sistemas a través de la organización.

Proyectos Data Warehousing

Un proyecto data warehousing tiene mucho en común con cualquier otro proyecto de implementación TI, por lo que es posible aplicar las metodologías más comúnmente utilizadas, como Agile o Microsoft Solutions Framework (MSF). Sin embargo, un proyecto data warehousing a menudo requiere de una comprensión profunda de los objetivos claves del negocio y las métricas que son utilizadas para impulsar la toma de decisiones, a diferencia de otros proyectos de desarrollo de software o infraestructura.
Un enfoque de alto nivel para la implementación de un proyecto data warehousing por lo general incluye los siguientes pasos:
1. Trabajar con los interesados del negocio y trabajadores de la información para determinar las preguntas del negocio a la cual el data warehouse debe proporcionar respuestas. Pueden incluir preguntas tales como:
  • ¿Cuál fue el ingreso total de ventas para cada territorio geográfico de ventas en un mes determinado?
  • ¿Cuáles son nuestros productos o servicios más rentables?
  • ¿Están nuestros costos creciendo o reduciendo sobre el tiempo?
  • ¿Qué empleados de ventas están cumpliendo con sus objetivos de ventas?
2. Determinar los datos requeridos para responder a estas preguntas. Es normal pensar en estos datos en términos de "dimensiones" y "hechos". Los hechos contienen las medidas numéricas que necesita agregar para que pueda responder a las preguntas del negocio, que fueron identificados en el paso 1 (por ejemplo, para determinar los ingresos por ventas, es posible que necesite el monto de venta para cada transacción de venta individual). Las dimensiones representan los diferentes aspectos del negocio para los cuales desea agregar las medidas (por ejemplo, para determinar los ingresos por ventas de cada territorio en un mes determinado, puede que necesite dos dimensiones: una dimensión geográfica, para que pueda agregar las ventas por territorio, y una dimensión tiempo de modo que pueda agregar las ventas por mes).
3. Identificar los orígenes de datos que contienen los datos requeridos para responder a las preguntas del negocio. Estas son comúnmente las bases de datos relacionales que las aplicaciones de línea de negocio existentes utilizan, pero también pueden incluir:
  • Archivos planos o documentos XML que han sido extraídos de sistemas propietarios.
  • Los datos en la lista de Microsoft SharePoint.
  • Los datos disponibles comercialmente, que han sido comprados de un proveedor de datos, tales como el Microsoft Windows Azure Marketplace.
4. Determinar la prioridad de cada pregunta del negocio basado en:
  • La importancia de responder la pregunta, en relación a la conducción de los objetivos clave del negocio.
  • La factibilidad de responder la pregunta de los datos disponibles.
Un enfoque común para priorizar las preguntas del negocio, que abordará en la solución data warehousing, es trabajar con los interesados claves del negocio y ubicar cada pregunta en una matriz basada en cuadrantes como la mostrada abajo. La posición de las preguntas en la matriz ayuda a reconocer el alcance del proyecto data warehousing.
Si un gran número de preguntas caen en la categoría alta importancia, alta factibilidad, es posible que desee considerar un enfoque incremental en el proyecto, en el cual distribuye el desafío en una serie de sub-proyectos. Cada sub-proyecto aborda el problema de implementar el esquema data warehouse, solución ETL, y los procedimientos de calidad de datos para un área específica de la empresa, partiendo de las preguntas del negocio de más alta prioridad. Si toma este enfoque incremental, debe tener cuidado para crear un diseño global para tablas de dimensión y de hechos en las primeras iteraciones de la solución, para que las adiciones posteriores a la solución pueden reutilizarlas.

Roles de Proyecto Data Warehousing

Un proyecto data warehousing normalmente implica varios roles. Estas roles incluyen:
  • Un director de proyecto. Coordina tareas y calendarios del proyecto y asegura que el proyecto sea completado a tiempo y dentro del presupuesto.
  • Un arquitecto de la solución. Tiene la responsabilidad general del diseño técnico de la solución data warehousing.
  • Un modelador de datos. Diseña el esquema del data warehouse.
  • Un administrador de base de datos. Diseña la arquitectura física y la configuración de la base de datos data warehouse. Además, los administradores de bases de datos que tienen la responsabilidad de los orígenes de datos que son utilizados en la solución data warehousing, deben estar involucrados en el proyecto para proporcionar el acceso a los orígenes de datos, que el proceso ETL utiliza.
  • Un especialista en infraestructura. Implementa la infraestructura de servidores y de red para la solución data warehousing.
  • Un desarrollador de ETL. Construye el flujo de trabajo ETL para la solución data warehousing.
  • Los usuarios del negocio. Proporcionan los requisitos y ayudan a priorizar las preguntas del negocio que la solución data warehousing responderá. A menudo, el equipo incluye un analista del negocio como un miembro a tiempo completo para ayudar a interpretar las preguntas del negocio y asegurar que el diseño de la solución satisfaga las necesidades de los usuarios.
  • Testers. Verifican la funcionalidad operativa y del negocio de la solución, así como su desarrollo.
  • Los stewards de datos para cada tema clave en la solución data warehousing. Determinan las reglas de calidad de datos y validan los datos antes de que entren al data warehouse. Los stewards de datos son algunas veces referidos como los gobernadores de datos.
Además de garantizar la asignación adecuada de estos roles, también debe considerar la importancia del patrocinio a nivel ejecutivo del proyecto data warehousing. El proyecto tiene más altas probabilidades de éxito si un patrocinador ejecutivo de alto nivel está apoyando activamente la creación de la solución data warehousing.

SQL Server como una Plataforma Data Warehousing

SQL Server incluye componentes y características que puede utilizar para implementar los diferentes elementos de la arquitectura de una solución data warehousing. Estos componentes incluyen:
  • El motor de base de datos SQL Server. Un sistema relacional altamente escalable de gestión de base de datos (RDBMS) en el que se puede implementar un data warehouse. SQL Server Enterprise incluye características que lo hacen especialmente adecuado para las soluciones data warehousing. Una característica es la optimización de las consultas de unión estrella, que aumenta significativamente el rendimiento de las consultas en un esquema data warehouse típico. Otra característica es el índice columnstore, que puede mejorar significativamente el rendimiento de las cargas de trabajo del data warehouse.
  • SQL Server Integration Services. Una plataforma completa y extensible para la creación de soluciones ETL, incluyendo soporte para una amplia gama de orígenes de datos y numerosas tareas de transformaciones data flow y de control flow integradas para los requerimientos ETL comunes.
  • SQL Server Master Data Services. Una solución de gestión de datos maestros que permite a las organizaciones crear definiciones de datos autorizadas para las entidades del negocio claves, y asegurar la consistencia de datos a través de múltiples aplicaciones y sistemas.
  • SQL Server Data Quality Services. Una solución basada en el conocimiento para la validación, la limpieza, y la deduplicación de datos.
  • Microsoft SQL Azure. Una plataforma de base de datos basada en la nube, que podría ser utilizada para proporcionar un origen de datos en una solución data warehousing.
  • Windows Azure Marketplace DataMarket. Un repositorio basado en la nube de los datasets disponibles comercialmente que pueden ser incorporados en su data warehouse o que el SQL Server Data Quality Services puede utilizar para validar y limpiar los datos.
Además, puede utilizar algunos componentes de SQL Server y otros productos Microsoft para construir una solución BI empresarial que amplíe el valor de su data warehouse significativamente. Estos componentes y productos incluyen:
  • SQL Server Analysis Services. Un servicio para la creación de modelos de datos analíticos multidimensionales y tabulares para el llamado análisis "slice and dice", y para la implementación de modelos de minería de datos que se puede utilizar para identificar tendencias y patrones en sus datos.
  • SQL Server Reporting Services. Una solución para la creación y distribución de reportes en una variedad de formatos para la visualización en línea o impresión.
  • Microsoft SharePoint Server. Un portal basado en la web a través del cual los trabajadores de la información pueden usar reportes y otros entregables de BI.
  • Microsoft Excel. La herramienta de análisis de datos y hoja de cálculo más comúnmente utilizada en el mundo.
  • Tecnologías Microsoft PowePivot. Un poderoso motor analítico que habilita el análisis de grandes volúmenes de datos en Excel y comparte los modelos de datos tabulares en el servidor SharePoint.
  • Microsoft Power View. Una herramienta de visualización de datos que proporciona una experiencia intuitiva, interactiva para usuarios que necesitan realizar el análisis de los datos no estructurados en un modelo semántico BI. 


22 enero 2015

Certificaciones de Business Intelligence en SQL Server 2012

El mes pasado rendí y aprobé el examen 70-463 (Implementing a Data Warehouse with Microsoft SQL Server 2012), que es parte de la certificación MCSA para Microsoft SQL Server 2012; me base en el Training Kit de Microsoft para este examen. También consulte el material del curso de certificación 10777 que tome en un instituto. No se me ocurrió mejor idea que traducir el training kit, para que este libro traducido me sirva para consultas posteriores; una tarea titánica pero que al final valió la pena. La ultima semana rendí los exámenes del simulador, los cuales me sirvieron bastante. Aprobando este examen ya tengo mi usuario MCP y puedo usar el logo.


Ahora me encuentro preparándome para el siguiente examen, el 70-461 (Querying Microsotf SQL Server 2012), con la misma metodología. Espero lograr este objetivo en 2 meses aproximadamente. Luego debo seguir con el examen 70-462, para obtener el MCSA.
La siguiente certificación es el MCSE, el examen 70-466 y el 70-476. Aunque ya esta año salio la certificación para la nueva versión SQL Server 2014.