1. Almacén de datos
1.1 ¿Qué es un almacén de datos?
Data warehouse, el nombre en inglés es Data Warehouse, abreviado como DW o DWH. Un almacén de datos es una recopilación de datos orientada al tema, integrada y variable en el tiempo, pero la información en sí es relativamente estable y se utiliza para respaldar el proceso de toma de decisiones de gestión. Es un almacén de datos único, creado con fines de informes analíticos y apoyo a la toma de decisiones. Brindar orientación para la mejora de los procesos comerciales, monitorear el tiempo, el costo, la calidad y el control para las empresas que requieren inteligencia comercial.
1.2 Cuatro características del almacén de datos
Orientado al tema: el almacén de datos está organizado de acuerdo con un tema determinado y solo almacena datos relacionados con el tema. El tema se refiere a los aspectos clave a los que los usuarios prestan atención al considerar la toma de decisiones al construir un data warehouse, lo cual es conveniente para futuros análisis de datos.
Integración: La fuente de datos del almacén de datos es arbitraria, que puede ser una base de datos operativa o un rastreador web. Después del procesamiento y la integración, estos datos se unifican en una nueva fuente de datos.
Cambios a lo largo del tiempo: el almacén de datos adquiere una gran cantidad de datos de diferentes canales de datos todos los días, y los datos clave cambiarán implícita o explícitamente en función del tiempo.
Los datos son relativamente estables: después de ingresar los datos, generalmente solo se realizan operaciones de consulta y no se realiza ninguna eliminación.
1.3 Capas del almacén de datos
1. Capa de ODS: la capa de datos original, que almacena los datos originales, carga los registros y datos originales directamente y mantiene los datos originales sin procesarlos (al mismo tiempo, desempeña una función de respaldo)
2. Capa DWD: la capa de datos detallados, cada lugar puede llamarse de manera diferente, la estructura y la granularidad son consistentes con la tabla original, la capa DWD limpia los datos de la capa ODS (eliminación de valores vacíos, datos sucios, datos que exceden el rango límite (como cantidad) Aparece un valor negativo)).
ETL que se puede usar: Hive SQL (hql), MR, Spark sql, Python, kettle (se especializan en etl, arrastrar y soltar + sql, preste más atención a la lógica empresarial, pero más subcontratación )
3. Capa DWS: capa de datos de servicio, basada en DWD, ligeramente resumida a diario. Por ejemplo, la tabla amplia de comportamiento del usuario registra el número de pedidos y comentarios realizados por los usuarios en un día.
4. Capa DWT: Capa de sujeto de datos, basada en DWS, resumida por tema. Por ejemplo, la tabla amplia de comportamiento del usuario anterior registra el número de pedidos, comentarios, etc. por día, por lo que aquí puede registrar el número total de pedidos realizados por los usuarios este año y otros temas de compra, que pertenecen a un cierto rango general.
5. Capa ADS: La capa de aplicación de datos proporciona datos para varios informes estadísticos. Se puede calcular a partir de otras capas.
1.4 ¿Por qué los almacenes de datos deben tener capas?
Cuando se recopilan datos de una fuente de datos, pasa por el proceso ETL y luego pasa por las capas del almacén de datos. Se puede comparar con el protocolo TCPip, que se divide en varias capas, y cada capa maneja una cosa. Brindar soporte de datos para la toma de decisiones de la empresa.
(1) Simplifique problemas complejos : descomponga las tareas complejas en varias capas para completar, y cada capa solo maneja tareas simples para facilitar los problemas de ubicación.
(2) Reducir el desarrollo repetitivo: la estandarización de la capa de datos, a través de la capa intermedia, puede reducir los cálculos extremadamente repetitivos y aumentar la capacidad de reutilización de los resultados de los cálculos.
(3) Aislar los datos originales: ya sean anomalías de datos o sensibilidad de datos, desacople los datos reales de los datos estadísticos. Por ejemplo, los datos de la capa ODS mencionada anteriormente son más como datos de respaldo, entonces la capa de datos en la parte posterior puede contar libremente los datos según sea necesario. Si ocurren anormalidades en otras capas, siempre que los datos en la capa ODS aún sean disponible, los datos originales se pueden recuperar, lo que hace que los datos reales y los datos estadísticos se aíslen .
1.4.1 Especificación del comando del almacén de datos
Nomenclatura de la mesa:
-La capa ODS se llama ods_table name
-Capa DWD denominada dwd_dim / fact_ nombre de la tabla (tabla de dimensiones y tabla de hechos)
-La capa DWS se llama dws_table name
-La capa DWT se llama dwt_table name
-La capa ADS se llama ads_ table name
-La tabla temporal se llama xxx_tmp
-Tabla de comportamiento del usuario, con el sufijo log
Denominación de guiones:
Fuente de datos_a _target_db / log.sh
1.5 La diferencia entre el almacén de datos y la base de datos
| Características |
base de datos |
base de datos |
| rango de datos |
Almacene datos históricos y completos que reflejen cambios históricos |
Datos del estado actual |
| Cambios de datos |
Puede agregar, no eliminar, no cambiar, reflejar cambios históricos |
Admite adiciones, eliminaciones, correcciones y verificaciones frecuentes |
| Escenarios de aplicación |
Orientado al análisis, apoya la toma de decisiones estratégicas |
Orientado a los negocios |
| Teoría del diseño |
Pseudoparadigma, redundancia apropiada |
Siga el paradigma (uno, dos y tres paradigmas) para evitar la redundancia |
| Capacidad de procesamiento |
Poco frecuente, lote grande, alto rendimiento, retraso |
Frecuente, pequeño lote, alta concurrencia, baja latencia |
2. Modelado relacional y modelado dimensional
2.1 Modelado de relaciones
El modelo relacional se muestra en la figura, que sigue estrictamente la tercera forma normal (3NF), se puede ver en la figura que es relativamente suelto y fragmentado, con un gran número de tablas físicas y baja redundancia de datos. Debido a que los datos se distribuyen en muchas tablas, estos datos se pueden aplicar de manera más flexible y tienen una funcionalidad más sólida. El modelo relacional se utiliza principalmente en sistemas OLTP Para garantizar la coherencia de los datos y evitar la redundancia, la mayoría de las tablas de sistemas empresariales siguen la tercera forma normal.
2.2 Modelado dimensional
Como se muestra en la figura, el modelo dimensional se usa principalmente en el sistema OLAP . La organización de la tabla generalmente se centra en una tabla de hechos determinada. Está principalmente orientada a los negocios. La característica es que puede haber redundancia de datos, pero la los datos se pueden obtener fácilmente.
** Aunque el modelo relacional tiene menos redundancia, en el proceso de datos a gran escala, análisis de tabla cruzada y consulta estadística, se asociarán múltiples tablas, lo que reducirá en gran medida la eficiencia de ejecución.
** Por lo general, usamos el modelo dimensional para modelar , organizar varias tablas relacionadas en dos tipos: tabla de hechos y tabla dimensional.
Sobre la base del modelado dimensional, se puede dividir en tres modelos: modelo de estrella, modelo de copo de nieve y modelo de constelación.
2.2.1 Modelo estrella
Solo una capa, es decir, una estrella alrededor del modelo estándar solo una tabla de dimensiones alrededor de una tabla de hechos correspondiente .
2.2.2 Modelo de copo de nieve
El modelo de copo de nieve tiene más niveles dimensionales que el modelo de estrella. El modelo de copo de nieve está más cerca de 3NF , pero no se puede cumplir por completo porque el costo de rendimiento de cumplir con 3NF es demasiado alto.
2.2.3 Modelo de constelación
La diferencia entre el modelo de constelación y los dos primeros modelos radica en el número de tablas de hechos. Hay más tablas de hechos en el modelo de constelación . Además, las tablas de dimensiones pueden compartirse entre tablas de hechos.
2.2.4 Selección de modelo
En primer lugar, si la constelación está relacionada con los datos y la demanda, no con el diseño, no hay otra opción.
Estrella o copo de nieve depende de si el rendimiento es la prioridad o la flexibilidad es la prioridad.
En el desarrollo real, no solo elegirá uno, sino que combinará de manera flexible o incluso coexistirá según la situación. Pero en general, se prefiere más el modelo estrella con menos dimensiones. Especialmente para el sistema Hadoop, la reducción de uniones significa reducir la reproducción aleatoria y el rendimiento varía enormemente.
3. Modelado de almacenamiento de datos
3.1 El propósito del modelado de almacenamiento de datos
¿Por qué modelar el almacén de datos? El modelado de almacenamiento de datos de big data consiste en organizar y almacenar mejor los datos a través de métodos de modelado para encontrar el mejor equilibrio entre rendimiento, costo, eficiencia y calidad de los datos . Generalmente, se considera principalmente a partir de los siguientes cuatro puntos
Rendimiento de acceso : capaz de consultar rápidamente los datos necesarios y reducir la E / S de datos
Costo de datos : reduzca la redundancia de datos innecesaria, realice la reutilización de datos de los resultados de los cálculos y reduzca los costos de almacenamiento y cálculo en sistemas de big data
Utilice la eficiencia : mejore la experiencia de la aplicación del usuario y aumente la eficiencia del uso de datos
Calidad de los datos : mejorar las inconsistencias de los datos estadísticos, reducir la posibilidad de errores en el cálculo de los datos, proporcionar una plataforma de acceso a datos consistente y de alta calidad 3 .
3.2 Capa de SAO
Mantenga la apariencia original de los datos sin ninguna modificación y desempeñe el papel de copia de seguridad de los datos;
Los datos se comprimen y almacenan para reducir el espacio en disco;
Cree una tabla de particiones para evitar un escaneo completo
3.3 capa DWD
La capa DWD necesita construir un modelo dimensional, que generalmente usa un modelo de estrella, y el estado presentado es generalmente un modelo de constelación.
El modelado dimensional generalmente sigue los siguientes cuatro pasos:
3.4 capa DWS
Cuente el comportamiento diario de cada objeto sujeto, la tabla amplia del sujeto que sirve a la capa DWT y algunos datos de detalles comerciales para hacer frente a necesidades especiales (por ejemplo, comportamiento de compra, estadísticas sobre tasas de recompra de productos).
3.5 capa DWT
Basado en el análisis del objeto sujeto como el modelo impulsado, basado en la aplicación de nivel superior y los requisitos del índice de producto, se construye una tabla a escala completa de objetos sujetos.
3.6 capa ADS
Analizar los principales indicadores temáticos del sistema de comercio electrónico por separado .
1. ¿Qué es la forma normal?
1.1 Definición
Según la definición del libro de texto, un paradigma es "una colección de patrones relacionales que se ajustan a un cierto nivel, que representa la racionalización de las conexiones entre varios atributos dentro de una relación". Esta definición es demasiado oscura. En pocas palabras, es el nivel y los requisitos de un cierto estándar de diseño lo que cumple la estructura de una tabla de datos.
1.2 Ventajas
Al diseñar una base de datos relacional, se deben seguir ciertas pautas para reducir la redundancia de datos.
¿Por qué reducir la redundancia de datos?
Para reducir el almacenamiento en disco, hace más de una década, los discos eran muy caros
Antes no existía un sistema distribuido y se necesitaban discos para almacenar más datos
Una modificación requiere la modificación de varias tablas, lo que dificulta garantizar la coherencia de los datos.
1.3 Desventajas
Al obtener datos, debe conectarse a través de varias tablas para obtener los datos finales.
1.4 Clasificación
Los paradigmas actuales de la industria son: Primera forma normal (1NF), Segunda forma normal (2NF), Tercera forma normal (3NF), Forma normal de cordón de baño (BCNF), Cuarta forma normal (4NF) y Quinta forma normal (5NF) . En términos generales, la base de datos solo necesita satisfacer la tercera forma normal (3NF).
2. Dependencias funcionales
2.1 Dependencia completamente funcional
Suponga que X e Y son dos conjuntos de atributos de relación R. X 'es un subconjunto propio de X. Hay X → Y, y cada X'tiene X'! → Y, entonces Y es completamente dependiente de X. Denominado:
Por ejemplo, el puntaje se puede retirar mediante (número de estudiante, curso), pero el puntaje no se puede derivar usando solo el número de estudiante, por lo que se puede decir que el puntaje depende completamente de (número de estudiante, curso).
2.2 Dependencias funcionales parciales
Supongamos que Y depende de X, pero no depende completamente de X, entonces Y depende parcialmente de X, denotado como:
Por ejemplo, el nombre se puede introducir mediante (número de alumno, curso), pero el nombre también se puede introducir directamente mediante el número de alumno, por lo que el nombre depende en parte de (número de alumno, curso).
2.3 Dependencia de la función de transferencia
Suponga que X, Y y Z son conjuntos de atributos diferentes en la relación R, y hay X → Y (Y! → X), Y → Z, entonces se dice que Z es transitivamente dependiente de X. Denominado
Por ejemplo, el nombre del departamento se usa para el número del estudiante y el jefe del departamento se usa para el nombre del departamento, pero el jefe del departamento no puede presionar el número del estudiante y el jefe del departamento depende principalmente del nombre del departamento. Esta situación se puede decir: la entrega del decano depende del número de alumno.
3. Tres paradigmas
3.1 Primera forma normal (1NF)
El requisito fundamental del primer paradigma: los atributos no se pueden dividir.
Obviamente, el diseñador de la tabla que se muestra en la figura anterior no se ajusta a la primera forma normal. Los datos de la columna de productos no son un elemento de datos atómicos y pueden dividirse. Por lo tanto, la tabla se modifica para que la tabla se ajuste a la primera forma normal. El resultado es el siguiente:
En cualquier base de datos relacional, la primera forma normal [1NF] es el requisito básico del modelo relacional Una base de datos que no cumple con la primera forma normal (1NF) no es una base de datos relacional. Por ejemplo, al crear una tabla en MySQL, Oracle y SQL Server, si el diseño de la tabla no cumple con este requisito, la operación no debe ser exitosa. En otras palabras, siempre que la tabla ya exista en el RDBMS, debe ajustarse a la primera forma normal.
3.2 Segunda forma normal (2NF)
Para satisfacer la segunda forma normal, primero debe satisfacer la primera forma normal. El requisito central del segundo paradigma: no puede haber dependencia parcial, es decir, garantizar que cada columna de la tabla de la base de datos esté relacionada con la clave principal, y no solo con una determinada parte de la clave principal (principalmente para la clave principal). clave primaria combinada). Es decir, en una tabla de base de datos, solo se puede almacenar un tipo de datos en una tabla y no se pueden almacenar múltiples tipos de datos en la misma tabla de base de datos.
La tabla anterior es obviamente parcialmente dependiente. Por ejemplo, la clave principal de esta tabla es (número de alumno, curso), y la puntuación depende completamente de la clave principal, pero el nombre no depende completamente de la clave principal. Por tanto, deberíamos eliminar parte de la dependencia.
3.3 Tercera forma normal
Para satisfacer la tercera forma normal, primero debe satisfacer la segunda forma normal. El requisito central del tercer paradigma: no puede haber dependencia de la función de transferencia. Eso es para asegurar que cada columna de datos en la tabla de datos esté directamente relacionada con la clave principal, pero no indirectamente relacionada.
En la siguiente tabla, hay una dependencia de la función de transferencia: ID de estudiante -> nombre del departamento -> director, pero el decano no puede presionar la ID de estudiante.
Entonces esta tabla se puede dividir nuevamente:
Estrategia de sincronización de datos de almacén de datos
1. Tipos y conceptos de tablas
1. Tabla de entidades
2. Tabla de dimensiones
3. Hoja informativa
2. Estrategia de sincronización de datos
1. Estrategia de sincronización completa
2. Estrategia de sincronización incremental
3. Estrategias nuevas y modificadas
4. Estrategia especial
1. Tipos y conceptos de tablas
1. Tabla de entidades
Generalmente se refiere a un objeto comercial que existe en la realidad. Los datos que coloca en la tabla de entidades deben ser una pieza de datos objetivos, como usuarios, comerciantes, productos básicos, etc. (una determinada pastilla de ginseng en el este es una entidad)
2. Tabla de dimensiones
Generalmente se refiere a algún estado en el negocio, tabla de interpretación de códigos (también llamada tabla de códigos). La tabla de dimensiones se puede considerar como una ventana para que los usuarios analicen un hecho, y los datos en ella deben describir todos los aspectos del hecho.
Las tablas de dimensiones también se pueden dividir en tablas de dimensiones generales y tablas de dimensiones fijas.
Tabla de dimensiones generales: los datos se pueden aumentar y modificar. Por ejemplo: clasificación de productos, tiempo, etc.
Tabla de dimensiones fijas: los datos son fijos. Por ejemplo: género, estado del pedido, etc.
3. Hoja informativa
La esencia de la tabla de hechos es determinar un hecho mediante la combinación de varias dimensiones y algunos valores de indicador. Por ejemplo, a través de la dimensión de tiempo y la dimensión de organización geográfica, el valor del indicador se puede utilizar para determinar el hecho de algún valor de indicador en en un momento y lugar determinados. Cada dato de la tabla de hechos se obtiene mediante la intersección de los valores de los datos y los indicadores de varias tablas de dimensiones.
Las tablas de hechos también se pueden dividir en tablas de hechos periódicas, tablas de hechos transaccionales y tablas de hechos instantáneos acumulativos.
Tabla de hechos transaccionales
Los hechos a nivel de transacción registrados en la tabla de hechos de transacciones almacenan la mayoría de los datos atómicos, también conocida como "tabla de hechos atómicos". Los datos de la tabla de hechos de la transacción se generan después de que se produce un evento de transacción, y la granularidad de los datos suele ser un registro por transacción. Una vez que se envía la transacción y se insertan los datos de la tabla de hechos, los datos ya no se cambian y su método de actualización es la actualización incremental. Debido a la naturaleza dispersa de la tabla de hechos, sólo los datos del día entrarán en la tabla de hechos del día, lo que equivale a los datos diarios en cada partición, con exclusión de la anterior datos1 . Por ejemplo: flujo de transacciones, registro de operaciones, registros de entrada y salida de almacén, etc.
Las tablas de hechos generalmente se construyen alrededor de métricas. Cuando se generan las métricas, se generan registros de hechos. Las métricas pueden ser valores como el volumen de ventas, la rotación de transacciones y los ahorros de fin de mes. Si se generan varias métricas al mismo tiempo, podemos crear varios hechos en una tabla de hechos. Cuando hay muchos hechos en nuestra tabla de hechos, puede suceder que varios hechos sean diferentes al mismo tiempo. Si la probabilidad de que se generen al mismo tiempo es pequeña, lo llamamos hechos dispersos (Hechos dispersos) 2 .
Tabla de hechos de instantáneas periódicas
La tabla de hechos de instantáneas periódicas registra los hechos a intervalos de tiempo regulares y predecibles, como diarios, mensuales, anuales, etc. Por ejemplo, la tabla de pedidos tiene un campo, estado del pedido, que cambiará periódicamente. Por otro ejemplo, las solicitudes de licencias y préstamos cambian periódicamente con el estado de aprobación; tabla de instantáneas diarias de ventas, tabla de instantáneas diarias de inventario, etc.
La tabla de instantáneas periódicas no tiene el concepto de granularidad. En cambio, es una combinación de medición de período + estado, como el número total de órdenes desde la historia hasta el presente, donde la historia hasta el presente es un período, y el el número total de pedidos es la medida.
Tabla de hechos de instantáneas acumulativas
La tabla de hechos de instantáneas periódicas registra datos de un período determinado, y la tabla de hechos de instantáneas acumulativas registra datos de un período incierto. La tabla de hechos de instantáneas acumulativas representa el lapso de tiempo que cubre completamente el ciclo de vida de una transacción o producto. Por lo general, tiene varios campos de fecha para registrar puntos clave en todo el ciclo de vida. Por ejemplo, la tabla de hechos de instantáneas acumulativas del pedido tendrá puntos de tiempo como la fecha de pago, la fecha de entrega y la fecha de entrega. Otro ejemplo es la información del registro de modificación del usuario.
** La tabla de hechos de instantáneas acumulativas se utiliza para realizar un seguimiento de los cambios en los hechos comerciales. ** Por ejemplo, es posible que el almacén de datos necesite acumular o almacenar los datos del punto de tiempo de las diversas etapas comerciales desde el momento en que se realiza el pedido hasta que se empaqueta, transporta y firma para rastrear el progreso del ciclo de declaración del pedido. . A medida que avanza este proceso empresarial, los registros de la tabla de hechos también deben actualizarse constantemente.
|
|
Hechos transaccionales |
Datos de la instantánea del ciclo |
Hechos de instantáneas acumulativas |
| Periodo de tiempo |
Punto de transacción discreto en el tiempo |
Intervalo de tiempo regular |
Múltiples puntos en un corto período de tiempo |
| granularidad |
Cada fila representa un evento de transacción |
Cada fila representa una entidad en un período de tiempo |
Cada fila representa el ciclo de vida de una entidad. |
| Carga de la tabla de hechos |
Agregar |
Agregar |
Agregar y modificar |
| Actualización de la tabla de hechos |
No actualices |
No actualices |
Actualizar cuando ocurra un nuevo evento |
| Dimensión de tiempo |
Fecha comercial |
Fin del periodo |
La fecha de finalización de múltiples procesos comerciales. |
| hecho |
Hechos de la transacción |
Hechos acumulados |
Hechos del proceso empresarial |
2. Estrategia de sincronización de datos
1. Estrategia de sincronización completa
Los datos completos se almacenan todos los días y los datos completos se almacenan todos los días como una partición. Es adecuado para escenarios donde los datos de la tabla no son grandes, y se insertan nuevos datos todos los días y también se modifican los datos antiguos.
Por ejemplo: tabla de diccionario de codificación, tabla de marca, tabla de clasificación de producto, tabla de descuento, tabla de actividad, tabla de producto, tabla de compra adicional, tabla de SPU, etc.
2. Estrategia de sincronización incremental
Cada día se almacena un dato incremental como una partición. Es adecuado para escenarios donde la cantidad de datos de la tabla es grande y solo se insertan datos nuevos todos los días. Por ejemplo: formulario de reembolso, tabla de estado de la orden, tabla de flujo de pago, tabla de detalles de la orden, tabla de revisión de productos, etc.
3. Estrategias nuevas y modificadas
Las adiciones y cambios diarios significan que el tiempo de creación de almacenamiento y el tiempo de operación son datos de hoy. El escenario aplicable es que la cantidad de datos en la tabla es grande y habrá nuevas adiciones y cambios. Por ejemplo, tabla de usuarios, tabla de pedidos, tabla de solicitud de cupones, etc.
4. Estrategia especial
Dimensión objetiva del mundo
Las dimensiones del mundo objetivo inmutable (como el género, la región, la etnia, la composición política, el tamaño de los zapatos) solo pueden almacenar un valor fijo.
Dimensión de la fecha
La dimensión de fecha puede importar un año o varios años de datos a la vez.
Dimensión regional
Tabla de provincia, tabla de región.
Capas del almacén de datos:
Proceso de negocio de almacenamiento de datos:
Datos comunes: datos de registro de inicio (datos al inicio)
Datos comerciales: datos de registro de eventos (clics del usuario y otros comportamientos)
Punto enterrado: js, obtenga todas las acciones de clic
Los dos primeros nodos de canal:
-
Recopilar datos del servidor de registros
-
Como productor de Kafka, transfiera datos a Kafka
El tercer nodo de canal:
1. Como consumidor de Kafka, obtenga datos de Kafka
2. Almacene los datos obtenidos en hdfs
Flume: agente del concepto central
El agente se divide en 3 módulos: fuente, canal, sumidero
1.fuente: fuente de datos, una fuente de canal. Entrada RPC, archivo, exec, syslog
2.canal: grupo de almacenamiento: caché de mensajes
3. sumidero: coloque los datos (evento evento) en un medio de datos externo. Salida hdfs, hbase, kafka, Flume, DB
Función de interceptor: distinga los dos datos anteriores
1. Interceptor ETL (limpieza ligera): etl (extraer, transformar, cargar), filtrar formato json incorrecto y datos incompletos
2. Tipo de interceptor: clasificación
Pasos para compilar el archivo conf de flume:
1. Primero defina tres nombres
2. Escribe fuente, canal, sumidero a su vez
3.canal conecta la fuente y el sumidero por su nombre
Retransmisión de punto de interrupción: TAILDIR, varios directorios