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.