¿Limpia los mismos datos una y otra vez en cada script de carga de Qlik?

Una aplicación que limpia datos en bruto es un apaño. Diez aplicaciones que limpian los mismos datos en bruto, cada una de forma algo distinta, son un segundo warehouse que nadie diseñó.

Dónde se vuelve a escribir la misma limpieza

• Cada aplicación copia el mapeo. El mismo MAPPING LOAD y ApplyMap para códigos de país, producto y cliente, pegado en cada script que necesita el campo.
• Cada copia diverge. Un script aplica trim y pasa a mayúsculas, otro no, un tercero añadió un código nuevo el mes pasado. El mismo campo, valores distintos.
• Cada capa de QVD lo repite. Las aplicaciones de extracción, transformación y generación de QVD limpian los datos, y la siguiente aplicación los vuelve a limpiar por si acaso.
• Cada cambio es una búsqueda. Un código nuevo del origen hay que encontrarlo y corregirlo en cada script, y el que se pasó por alto falla sin avisar.

Un archivo $(Include) mantiene el texto idéntico. No impide que cada aplicación decida si lo usa, cuándo y en qué orden.

Por qué le toca a usted

• Cada aplicación se construyó cuando hacía falta, y copiar las correcciones del último script era la forma más rápida de entregarla.
• Nadie es responsable de la regla, así que nadie se da cuenta cuando dos scripts empiezan a no coincidir.
• Puede alinear los scripts que mantiene. No puede impedir que el origen envíe datos en bruto a todos ellos.

El trabajo está en el lugar equivocado

• Limpiar los datos de origen es trabajo del data warehouse. En Qlik se vuelve a escribir en cada script de carga que toca el campo.
• Debe hacerse en un único lugar central: un data warehouse o un data hub, construido una vez y leído por todas las aplicaciones.
• Si eso le parece caro, probablemente la estimación parte de pipelines construidos a mano. Una plataforma de automatización especializada los genera a partir de un modelo, lo que cambia tanto el coste como el tiempo necesario.

Qué cambia cuando el modelo llega terminado

Datavault Builder genera el vault integrado e historizado y la capa dimensional encima, de forma nativa en la base de datos que ya utiliza, desde SQL Server y Azure SQL hasta Snowflake o BigQuery.

• Cada regla de limpieza se define una sola vez, así que un mapeo de códigos cambia en un solo lugar, no en cada script.
• Los duplicados se resuelven en la integración, a partir de claves de negocio en lugar de filtrarse en cada aplicación.
• El historial se guarda como satélites, así que ningún QVD tiene que conservar la versión de ayer.
• El script de carga se convierte en un simple LOAD desde tablas limpias, lo bastante corto para leerlo.
• El lineage muestra cada transformación, así que una regla modificada se puede rastrear antes de desplegarla.

Qué pedir

No “el script de transformación es un caos”, sino:

“Limpiamos y mapeamos los mismos campos de origen en varias aplicaciones generadoras de QVD, y ya no coinciden. ¿Puede esa limpieza vivir en una capa integrada del warehouse, para que nuestras aplicaciones carguen dimensiones terminadas en lugar de extracts en bruto?”

Si construir esa capa suena a un año de trabajo de pipelines, la estimación supone que se escribe a mano. Esa es precisamente la parte que genera Datavault Builder.