Cuando bi conoció a Hekaton (una historia de amor)
•Descargar como PPTX, PDF•
0 recomendaciones•854 vistas
http://summit.solidq.com Presentación realizada por Pau Sempere durante el SolidQ Summit 2014.
Recomendados
Más contenido relacionado
Destacado
Destacado (13)
Similar a Cuando bi conoció a Hekaton (una historia de amor)
Similar a Cuando bi conoció a Hekaton (una historia de amor) (20)
Más de SolidQ
Más de SolidQ (20)
Último
Último (20)
Cuando bi conoció a Hekaton (una historia de amor)
- 1. Cuando BI conoció a Hekaton Una historia de amor @pausempere #SQSummit Pau Sempere Sánchez DPS – Business Intelligence psempere@solidq.com MAP 2012
- 2. Objetivos Revisar las técnicas que nos permiten trabajar con BI en escenarios de tiempo real o semi-real Introducir nuevas tecnologías de Microsoft SQL Server 2014 en dichos escenarios
- 3. Agenda Tiempo real en BI Nuevas tecnologías en SQL Server 2014 Tiempo real en ETL – In-Memory ETL Tiempo real en análisis de datos – Clustered Columnstore para el DWH
- 4. Agenda Tiempo real en BI Nuevas tecnologías en SQL Server 2014 Tiempo real en ETL – In-Memory ETL Tiempo real en análisis de datos – Clustered Columnstore para el DWH
- 5. Adaptando la actualización de datos DB DW Cubo Optimización de Staging Modelado simple Optimización de consultas Usuario Latencia T. Consulta Nuevos Datos Datos Disponibles Datos Disponibles Staging
- 6. Agenda Tiempo real en BI Nuevas tecnologías en SQL Server 2014 Tiempo real en ETL – In-Memory ETL Tiempo real en análisis de datos – Clustered Columnstore para el DWH
- 7. Novedades en SQL Server 2014 Nuevo motor In-Memory OLTP (a.k.a. Hekaton) – Tablas en memoria • SCHEMA_ONLY • SCHEMA_AND_DATA – Nuevas estructuras de datos latch-free – Procedimientos almacenados compilados Índices columnares clústered
- 8. Nuevas tecnologías SQL Server 2014 Tablas In-Memory SCHEMA_ONLY Sin accesos a disco Sin bloqueos Sin logging Sin checkpoints Tipos de índices propios Cumplen ACI
- 9. Nuevas tecnologías SQL Server 2014 Tablas In-Memory Memoria disponible Collations Número de índices Tipos de datos
- 10. Nuevas tecnologías SQL Server 2014 Clustered Clustered Columnstore Indexes Completamente actualizables Aún mejor compresión
- 11. Agenda Tiempo real en BI Nuevas tecnologías en SQL Server 2014 Tiempo real en ETL – In-Memory ETL Tiempo real en análisis de datos – Clustered Columnstore para el DWH
- 12. Tiempo real en ETL Reducción de la latencia Entrada / Salida (IO) Eliminar bloqueos Datos carga ETL Staging SCHEMA_ONLY Data WareHouse Transformaciones nativamente compiladas
- 13. DEMO 20 In-Memory ETL
- 14. Optimizando Staging Transformaciones ETL optimizadas IO mejorada Ausencia de bloqueos
- 15. Agenda Tiempo real en BI Nuevas tecnologías en SQL Server 2014 Tiempo real en ETL – In-Memory ETL Tiempo real en análisis de datos – Clustered Columnstore para el DWH
- 16. Clustered Columnstore Index Segment C1 C2 C3 C4 C5 C6 Row Group
- 17. Clustered Columnstore Index OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount 20101107 106 01 1 6 30.00 20101107 103 04 2 1 17.00 20101107 109 04 2 2 20.00 20101107 103 03 2 1 17.00 20101107 106 05 3 4 20.00 20101108 106 02 1 5 25.00 20101108 102 02 1 1 14.00 20101108 106 03 2 5 25.00 20101108 109 01 1 1 10.00 20101109 106 04 2 4 20.00 20101109 106 04 2 5 25.00 20101109 103 01 1 1 17.00 24
- 18. Particionamiento Horizontal (Row Groups) OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount 20101107 106 01 1 6 30.00 20101107 103 04 2 1 17.00 20101107 109 04 2 2 20.00 20101107 103 03 2 1 17.00 20101107 106 05 3 4 20.00 20101108 106 02 1 5 25.00 OrderDateKey ProductKey StoreKey RegionKey Quantity SalesAmount 20101108 102 02 1 1 14.00 20101108 106 03 2 5 25.00 20101108 109 01 1 1 10.00 20101109 106 04 2 4 20.00 20101109 106 04 2 5 25.00 20101109 103 01 1 1 17.00 25
- 19. Particionamiento Vertical (Segmentos) OrderDateKey 20101107 20101107 20101107 20101107 20101107 20101108 ProductKey 106 103 109 103 106 106 StoreKey 01 04 04 03 05 02 RegionKey 1 2 2 2 3 1 Quantity 6 1 2 1 4 5 SalesAmount 30.00 17.00 20.00 17.00 20.00 25.00 OrderDateKey 20101108 20101108 20101108 20101109 20101109 20101109 ProductKey 102 106 109 106 106 103 StoreKey 02 03 01 04 04 01 RegionKey 1 2 1 2 2 1 Quantity 1 5 1 4 5 1 SalesAmount 14.00 25.00 10.00 20.00 25.00 17.00 26
- 20. Compresión OrderDateKey 20101107 20101108 ProductKey 106 103 109 StoreKey 01 04 03 05 02 RegionKey 1 2 Quantity 6 1 2 4 5 SalesAmount 30.00 17.00 20.00 25.00 OrderDateKey 20101108 20101109 ProductKey 102 106 109 103 StoreKey 02 03 01 04 RegionKey 1 2 Quantity 1 5 4 SalesAmount 14.00 25.00 10.00 20.00 25.00 17.00 27
- 21. La ley del mínimo esfuerzo SELECT ProductKey, SUM (SalesAmount) FROM SalesTable WHERE OrderDateKey < 20101108 GROUP BY ProductKey StoreKey 01 04 03 05 02 StoreKey 02 03 01 04 RegionKey 1 2 3 RegionKey 1 2 Quantity 6 1 2 4 5 Quantity 1 5 4 OrderDateKey 20101107 20101108 OrderDateKey 20101108 20101109 ProductKey 106 103 109 ProductKey 102 106 109 103 SalesAmount 30.00 17.00 20.00 25.00 SalesAmount 14.00 25.00 10.00 20.00 25.00 17.00 28
- 22. Optimizando la entrada al DWH
- 23. Optimizando la entrada al DWH Tuple Mover De Delta Store a Row Groups – 100k filas (BULK INSERT) / 1M filas (INSERT) – 5 minutos – ALTER INDEX … REORGANIZE
- 24. Optimizando la entrada al DWH Row Groups 102.400 – 1.048.576 filas Filas (BULK Load) Filas al Columnstore Filas en el Delta Store 102.000 0 102.000 145.000 145.000 (RowGroup de 145000) 0 1.048.577 1.048.576 (RowGroup de 1.048.576) 1 2.522.152 2.252.152 2 x 1.048.576 + 1 x 155.000 0
- 25. DEMO 32 Optimizando el DWH
- 26. Conclusiones ETL Tablas InMemory SCHEMA_ONLY Transformaciones compiladas DWH Clustered Columnstore Index Adaptar la inserción a las necesidades de consulta
- 27. 34 Power BI para usuarios de negocio Curso online Clases virtuales presenciales 14, 15, 16, 21, 22 y 23 de Julio De 16 a 20 h Máster en BI 4ª Edición (Inicio Octubre 2014) - Clases presenciales virtuales - 450 horas (60 ECTS) - SolidQ – UPM - Clases + trabajo práctico + proyecto - Beca de hasta 1.300 € para los primeros inscritos. 34 Máster en Big Data & Analytics 1ª Edición (Inicio Octubre 2014) - Clases presenciales virtuales - 1 año (60 ECTS) UMA - Clases + trabajo práctico + proyecto Información e inscripción: http://university.solidq.com / ibinfo@solidq.com
- 28. DPS – Business Intelligence Si quieres disfrutar de las mejores sesiones de nuestros mentores de España y Latino América, ésta es tu oportunidad. http://summit.solidq.com Síguenos: 35
Notas del editor
- En esta sesión vamos a ver como reducimos la latencia hasta que el dato está disponible para acercarnos cuanto podamos al tiempo real. Por un lado veremos como tener el dato preparado en un menor tiempo y por otra como acceder a él de manera más rápida.
- Las mejores prácticas de input y output que ya teníamos en versiones anteriores siguen siendo completamente válidas
- Nos enfocamos a reducir la latencia hasta que el dato está disponible. Las tablas con índices columnares clústered son candidatas como tablas intermedias mucho más firmes ahora y no en 2012 porque ya no tienen las grandes limitaciones que tenían antes Solo lectura Necesitan un apoyo sobre un índice clásico (árbol B). Ahora son el propio dato, no necesitan de estructuras adicionales para apoyarse.
- No tienen bloqueos porque utiliza estructuras latch-free, que se basan en versionados de cada fila Con los nuevos tipos de índices se reduce el impacto de absorber gran cantidad de datos, ya que la complejidad de expandir el índice es la que las funciones de hash o rangos tarden, no escala exponencialmente con la complejidad del árbol B Sin accesos a disco ya que todo el dato está en memoria. No usa disco tampoco para controlar el dato que habrá que restaurar, sólo se restaura la estructura No hay checkpoints, la operación que se produce cada X tiempo (o manualmente) para tener un punto de restauración en caso de tener que levantar datos… … ni tampoco logging, que se usa para completar la recuperación de datos. No es durable, como ya hemos dicho, pero sí cumple el resto de propiedades transaccionales: Atomicidad Consistencia Isolated (aisladas)
- La memoria disponible es el primer factor a tener en cuenta. Todo dependerá del entorno de ejecución y de la carga de trabajo. Podemos calcularlo (ancho de columna x número de columnas) + índices, pero habrá que testear. Estimaciones ocupación de memoria: Para tabla: 2 veces el dato de la tabla en disco (tener en cuenta el espacio para el versionado) Para índices: Nonclustered Hash: Tamaño fijo bucket_count * 8 bytes Nonclustered Range: Tamaño variable campos clave + 8 bytes Tipos de datos no soportados: ntext, text, and image varchar(max) and nvarchar(max) rowversion (and timestamp) sql_variant CLR types (hierarchyid and spatial types) xml Indices Maximo 8 índices Todas las columnas han de ser not null La collation para textos solo puede ser BIN2 (comparación de binarios, complicaciones para internacionalización) Guía para índices: Si va a haber muchas consultas de tipo where field = @param_1 hash index (requieren la clave completa, en caso contrario se efectúa un full scan y un filter) Si va a haber consultas de rangos o necesitamos devolver los datos en cierto orden, índice nonclustered (normalmente este será el que más nos convenga, soporta rangos y order by para ahorrar SORT en SSIS) Se pueden combinar ambos índices sobre los mismos campos Consideraciones Memoria extra que ocupan los índices Calcular bien el BUCKET_COUNT en el caso de los hash. Mejor pasarse (a costa de memoria que se reserva) que quedarse corto, hay una degradación de rendimiento importante.
- Ya no tenemos que hacer trucos de reconstruir el índice por las noches o en ventanas de poca actividad con una tabla auxiliar y una vista que los cubra a los dos Mejor compresión gracias a COLUMNSTORE_ARCHIVE. Muy pensado para DWH, donde particionamos la información (por ejemplo por tiempo) y podemos aumentar la compresión de los datos menos accedidos. Al ser completamente clustered, cubren todas las columnas y no necesitan estructuras de apoyo como antes. El índice ES la tabla. Esto mejora mucho el rendimiento en consultas de tipo DWH en esquema estrella, siempre tendremos todas las SK cubiertas. Además estas consultas suelen ser de agregados, que es donde entra el modo batch.
- Mismo escenario (origen rápido -> tabla intermedia -> output a tabla final) Limitaciones de In-Memory OLTP: Nos quedamos sin memoria Purgador de datos, va volcando los top N a tabla en disco Con schema only el dato se volatiliza cuando se cae el servicio o reiniciamos (pero si solo queremos la tabla para staging, nos vale Cual es mejor en input, en ouput y en el global. In-Memory, pero tiene limitaciones
- Hay dos puntos fundamentales para conseguir mejorar los tiempos de latencia: Mejorar el sistema de entrada y salida (mejor dispositivo de almacenamiento y mejor sistema de obtención de datos – procedimientos almacenados nativamente compilados- ) Reducir el latching (protección de datos mientras se está escribiendo) para poder insertar en paralelo y aumentar la ratio de filas insertadas/segundo Además, usando transformaciones dentro de procedimientos nativamente compilados reducimos la carga de procesador y aceleramos el proceso de ciertas fases muy comunes en cargas incrementales de DWH (Agregados, filtrados, ordenaciones, etc.)
- IO mejorada: al no tocar disco ni para hacer logging de las inserciones optimizamos muchísimo el throughput Sin bloqueos podemos aumentar la concurrencia al insertar aumentando el ratio de filas / segundo y no tener miedo a leer mientras seguimos insertando (acercarnos al real time OLAP) Si las transformaciones que en SSIS penalizarían mucho el rendimiento (bloqueantes) las hacemos ya en memoria y además con procedimientos nativamente compilados ganamos en el proceso de ETL propiamente dicho Citar CONSIDERACIONES: Hay que tener en cuenta las restricciones de memoria, pero no más que si hablamos de un proceso ETL con SSIS, por ejemplo, que también puede fallar o ralentizarse muchísimo por falta de memoria.
- Summary: Three fundamental steps occur *under the covers* during Columnstore Index creation (this is transparent to the user): Horizontal partitioning into Row Groups (1M rows each) Vertical partitioning into Segments (constituent columns) Compression (aggressive—because columnar data tends to be homogenous)
- Depending on query, the Optimizer performs Row Group (or Partition) & Segment elimination
- Deletes of rows in the clustered Column Store Index: Just mark the row in the ‘Delete Bitmap’ as logically deleted. This is nothing special in a sense, since such a practice already is applied in the row oriented implementation as well. Changes (Updates) to rows in the clustered Column Store Index: Is a two-step process which marks a row in the existing Column Store Index as deleted and a second steps inserts the row with the changed column values into the delta store. Inserting a row: The row is going to be inserted into the delta store.
- Mismo informe, acumulado, contra Clasica CS Insertado a 100k CS Fragmentado CS Fresco Diferencias entre cache fría y cache caliente. ¿Que pasa cuando volvemos a insertar datos? Usa la caché o vuelve a leer de disco? Si es así, perdemos el “beneficio” en el fragmentado