Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Cumplimiento normativo
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC.
La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto.
En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica.
Contacto Dpto: Oficina Técnica Business Intelligence
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución.
Introducción
Todos los proyectos desarrollados para la STIC deben construirse y desarrollarse en base a los requisitos técnicos y tecnológicos que la infraestructura del SAS soporta. En caso contrario deberá especificarse de forma clara y concisa durante la reunión de lanzamiento del proyecto. A continuación se detalla el conjunto de requisitos a contemplar por parte de los proveedores.
Requisitos mínimos de metadatos
En esta sección se establecen los metadatos mínimos y recomendados que deben ir asociados a cada tipo de asset dentro de la plataforma Big Data para que estos se promocionen desde el entorno de preproducción al de producción. Se entiende por assets a todos aquellos elementos que pueden ser creados dentro de la plataforma Big Data. En el caso del SAS la solución es Stratio, por lo que la definición de estos metadatos se realiza en función de los elementos que se pueden crear en los diferentes módulos que la componen. Es por ello que esta sección se subdivide en los tres módulos principales de Stratio, estableciendo para ellos un conjunto de metadatos comunes a todos los tipos de assets del módulo así como los específicos de cada uno de ellos.
Nota: Esta normativa puede no ser cumplida siempre y cuando la OTBI de su aprobación explícita en caso de ser necesario su incumplimiento.
Governance
Metadatos comunes
A continuación, se presenta una tabla con los metadatos que son comunes a todos los assets que se encuentran en la herramienta de Governance. Algunos de ellos se encuentran establecidos en el activo de forma automática por la herramienta. En aquellos casos en los que el metadato no se grabe de automáticamente por la herramienta, se deben establecer mediante la creación de los atributos adicionales que sean necesarios.
Los assets que se generan automáticamente en la herramienta a partir de las bases de datos orígenes (Data Dictionary) son muy numerosos y, por tanto, no es necesario generar los metadatos de descripción, estado, obsoleto. No obstante, para todos aquellos activos que se vayan generando con el uso de la herramienta sí deben presentar de forma obligatoria en el entorno de producción los metadatos marcados con dicha etiqueta.
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
Descripción | Descripción textual del activo. Debe ser lo más escueta posible al mismo tiempo que ofrezca las características generales del tipo de activo. | Obligatorio | Sí | |
Estado | Metadato que indica el estado de inactividad del asset asociado. | Obligatorio en los intrínsecos. | Sí ( en Business Views, Business rules y Business terms ) | |
Fecha de creación | Establece la fecha de creación del asset pertinente en la herramienta. | Obligatorio en los intrínsecos | Sí (En todos exceptuando las ontologías) | |
Fecha de actualización | Indica la fecha en la que se realizó la última modificación del activo. | Obligatorio | Sí | |
Tipo | Metadato que indica a qué tipo de activo (colecciones, reglas de calidad, vistas técnicas…) pertenece el elemento pertinente. | Obligatorio | Sí | |
Obsoleto | atr_obsoleto | Este metadato indicará si el activo es útil o no independientemente de su estado. De esta manera se identifica con facilidad cuándo el activo debe ser borrado o mantenido en la herramienta. Este campo no se incorporará de forma integral en la herramienta, sino que se irá creando conforme los assets vayan quedando obsoleto. | Obligatorio | No |
Responsable | atr_responsable | Contacto del responsable del mantenimiento y uso del activo asociado. | Recomendable | No |
| Propietario | atr_propietario | Contacto del propietario del activo asociado. | Recomendable | No |
Usuario actualización | atr_usu_act | Metadato que identifica el miembro que ha actualizado por última vez el activo en cuestión. | Recomendable | No |
Metadatos específicos
En este apartado, se especifican los metadatos que son únicos de cada tipo de activo presentes en la herramienta. Es decir, cada asset debe presentar tanto los metadatos comunes como los definidos en este apartado que se encuentren categorizados como obligatorios.
Colecciones
A continuación, se muestra una tabla con los metadatos exclusivo del asset de colecciones.
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
Ámbito | atr_ambito | Departamento dentro del SAS que requiere el uso de la colección pertinente. | Obligatorio | No |
Metadatos de los procesos de ingesta.
Además, existe un conjunto de metadatos asociados a los procesos de ingestas.
Todos los metadatos de este tipo comienzan con los caracteres "dlc".
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
dlc.replication | Indica si la Collection o Technical View debe ser ingestada. Una vista técnica es ingestada sí se cumplen estas dos condiciones:
| Obligatorio | Sí | |
dlc.entity.alias | Este nombre es utilizado para definir el nombre de la entidad en el servicio DLC siguiendo el formato {dlc.entity_alias}-technicalViewName. En la actualidad, se indica como valor el nombre de la colección. | Obligatorio | Sí | |
dlc.instance | Nombre del servicio DLC que va a orquestar el proceso de ingesta para la colección. Por motivos de arquitectura puede existir más de un servicio DLC en un entorno. Actualmente existen 3 instancias DLC, una por entorno:
De este modo,
| Obligatorio | Sí | |
dlc.cron | Indica la planificación de la ejecución de la ingesta en formato de tarea programada Spring. Está formado por 6 campos:
Estos campos siguen la siguiente sintáxis: Sintáxis Cuándo Ejemplo Explicación ----------------------------------------------------------------------------------------- | Obligatorio | Sí | |
dlc.workflow_path | Directorio donde se ubica el workflow en Rocket. El formato del path es el siguiente: /home/{nombre_proyecto}/{path} Donde:
De este modo, si se establece el parámetro a /home/dlc/dlc significa que queremos utilizar un workflow ubicado en el path /dlc del proyecto dlc. En la actualidad, el parámetro se establece con el valor /home/dlc/dlc. | Recomendado | Sí | |
dlc.workflow_name | Nombre del workflow en Rocket. Por defecto, dlc-crossdata-parquet En la actualidad, se realizan dos tipos de ingesta:
Atendiendo a los tipos de ingesta, se utilizan los siguientes workflows:
| Recomendado | Sí | |
dlc.workflow_version | Versión del workflow de Rocket. Por defecto, 1. En la actualidad, las versiones utilizadas para los workflows arriba indicados son los siguientes:
| Recomendado | Sí | |
dlc.table_filter | Filtro where que se desea incluir en la migración, debe incluir la palabra where. Este atributo se realiza cuando la ingesta de la tabla se realiza de forma incremental – por deltas – en lugar de completa - snapshots. Si no existe, la ingesta de la tabla será completa. | Recomendado | Sí | |
dlc.table_fields | Campos de la tabla que se desean migrar, si no se incluye se migrarán todos. | Recomendado | Sí | |
dlc.execution_context | Permite que dlc comunique a Rocket un contexto de ejecución específico. Se utiliza fundamentalmente para realizar la ingesta con unos recursos más elevados para aquellas tablas que, debido a su volumetría, se hace más complicada su ingesta. En el caso de ingestas automáticas, los contextos de ejecución Environment y SparkConfigurations permanecerán con sus valores por defecto, mientras que si se desean modificar, se define un contexto específico mediante el valor SparkResources, que puede tomar los siguientes valores.
Este parámetro no está habilitado para establecerse a nivel Vista Técnica si el parámetro dlc.group_entities es true. En tales casos, se recomienda crear una colección diferenciada y establecer el contexto de ejecución específico a nivel de colección. | Recomendado | Sí | |
dlc.referential_integrity | Permite la ejecución de la ingesta sin tener en cuenta la integridad referencial entre las tablas de la fuente de datos. De este modo, la colección se ingesta en tres fases dependiendo de las constraints referenciadas existentes en la fuente de origen con el siguiente orden: en primer lugar, las tablas sin referencias, en segundo lugar las tablas referenciadas por las tablas de la primera fase y, en tercer lugar, las tablas restantes. Para bases de datos replicadas, es recomendable marcar el parámetro a false. Si el parámetro no es false, al incluir una tabla en la colección, se debe incluir también sus tablas referenciadas, de lo contrario la parametrización será errónea. | Recomendado | Sí | |
dlc.group_entities | Indica si la ejecución se realiza ejecutando la ingesta de varias tablas de forma simultánea para la colección. Esto acelera el proceso de ingesta acortando considerablemente el tiempo total del proceso para una determinada colección. | Recomendado | Sí | |
dlc.group_entities_max_per_wf | Si dlc.group_entities es true, define cuántas entidades se ingestan de forma simultánea. Un valor recomendado depende de las condiciones específicas de cada colección (talla de SparkResources con la que se ejecutan las ingestas, ventana de disponibilidad de la ingesta en el entorno de analítica, etc). Un buen valor inicial puede ser de 10. | Recomendado | Sí | |
dlc.clone_gr | Indica si dlc copia las Quality Rules del asset origen en el asset destino. | Recomendado | Sí | |
dlc.clone_gr_overwrite | Indica a dlc si debe sobreescribir las Quality Rules en destino al realizar la copia de QRs desde origen. | Recomendado | Sí | |
dlc.spark_user | Indica el usuario spark con el que ejecutar el workflow de Rocket para ingestar la entidad. | Recomendado | Sí | |
| dlc.table_partition | Permite especificar una clave de partición al escribir los datos en hdfs. Esta clave de partición debe ser un campo de la tabla a ingestar (o generado en el proceso de ingesta). | Recomendado | Sí | |
| dlc.extra_options | Define parámetros adicionales necesarios para la ejecución de la ingesta. El formato a indicar como valor es el siguiente: [{"clave_1":"valor_1", …, “clave_n”:”valor_n”}] | Recomendado | Sí | |
| dlc.replicates_into | Path de hdfs donde se replicará la colección. | Obligatorio | Sí (Related Asset) |
Technical Views
En la siguiente tabla se presenta el listado de los metadatos únicos que deben presentar las vistas técnicas de una colección determinada.
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
Data Dictionary | Campo que hace referencia al asset del Data Dictionary del que proviene la tabla o columna que compone la technical view. | Obligatorio | Sí | |
Fuente de datos | Nombre de la base de datos del sistema origen en el que se encuentran almacenadas las tablas. | Obligatorio | Sí | |
Alias | Acrónimo breve que permite reconocer con facilidad el activo. | Recomendado | Sí | |
Fecha actualización de los datos en el origen | atr_fec_act_ori | Campo que indica cuál fue la última fecha de actualización de los datos en el origen. Este metadato es diferente al de actualización del activo dentro de la propia plataforma. | Recomendado | No |
Tipo de esquema | Establece el tipo de esquema del sistema origen de los datos. | Obligatorio | Sí | |
Modo de descubrimiento | Mecanismo mediante el cual se ha autodescubierto la fuente de datos origen. | Recomendado | Sí |
Dentro de las Technical Views, a nivel de trabla existen unos atributos que son propios de la base de datos origen en la que se encuentran almacenados dichos datos y también otros metadatos que facilitan la parametrización y el trabajo con los procesos de ingesta. Para facilitar la lectura de dichos metadatos, se dividen en las dos tablas siguientes.
Metadatos relacionados con la base de datos
Todos los metadatos de este tipo comienzan con los caracteres "bdl".
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
bdl.partition | Establece si la tabla se encuentra o no particionada. | Recomendado | Sí | |
bdl.businessSchema | - | Obligatorio | Sí | |
bdl.forcedPartitionColumn | En modo automático, el usuario especifica qué columna quiere usar como columna de partición. | Obligatorio | Sí | |
bdl.limit | Sirve para definir un límite para todas las consultas sobre la tabla. | Obligatorio | Sí | |
bdl.lowerBound | El mínimo valor de PartitionColumn para decidir el número de particiones. | Obligatorio | Sí | |
bdl.numPartitions | Número de particiones. Junto a lowerBound (inclusivo) y upperBound (exclusivo), determinan las distintas particiones que formarán la cláusula where que se usan para dividir la columna partitionColumn de manera uniforme | Obligatorio | Sí | |
bdl.optimization | Define que tipo de optimización se aplicará. Valores posibles:
Si el atributo no se usa, el agente BDL no hará nada. | Obligatorio | Sí | |
bdl.optimizationFailure | BDL ha intentado poner toda la información de partición en el catálogo, pero algo no es correcto. | Obligatorio | Sí | |
bdl.optimized | Indica si el agente ha terminado la optimización. | Obligatorio | Sí | |
bdl.options.customSchema | - | Obligatorio | Sí | |
bdl.options.oracle.jdbc.mapDateToTimeStamp | Metadato booleano cuyo valor false implica que no se realiza el mapeo automático entre los valores Date a Timestamp. | Obligatorio | Sí | |
bdl.options.sessionInitStatement | Establece el formato el formato de fechas en el acceso a Oracle. Para editar este formato es necesario que el metadato bdl.options.oracle.jdbc.mapDateToTimeStamp presente el valor false. | Obligatorio | Sí | |
bdl.partitionColumn | Nombre de la columna que se utilizará para realizar la partición. | Obligatorio | Sí | |
bdl.technicalSchema | - | Obligatorio | Sí | |
bdl.upperBound | El mínimo valor de PartitionColumn para decidir el número de particiones. | Obligatorio | Sí | |
bdl.whereClause | Cláusula where que se utiliza para realizar el número de particiones totales junto con el resto de atributos. | Obligatorio | Sí |
Metadatos relacionados con los procesos de ingesta
Todos los metadatos de este tipo comienzan con los caracteres "dlc".
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
dlc.replication | Indica si la Collection o Technical View debe ser ingestada. Una vista técnica es ingestada sí se cumplen estas dos condiciones:
| Obligatorio | Sí | |
dlc.workflow_path | Directorio donde se ubica el workflow en Rocket. El formato del path es el siguiente: /home/{nombre_proyecto}/{path} Donde:
De este modo, si se establece el parámetro a /home/dlc/dlc significa que queremos utilizar un workflow ubicado en el path /dlc del proyecto dlc. En la actualidad, el parámetro se establece con el valor /home/dlc/dlc. Nota: En caso de tener habilitado el metadato dlc.group_entities a nivel de colección, este metadato no estará disponible a nivel de vista técnica. | Recomendado | Sí | |
dlc.workflow_name | Nombre del workflow en Rocket. Por defecto, dlc-crossdata-parquet En la actualidad, se realizan dos tipos de ingesta:
Atendiendo a los tipos de ingesta, se utilizan los siguientes workflows:
| Recomendado | Sí | |
dlc.workflow_version | Versión del workflow de Rocket. Por defecto, 1. En la actualidad, las versiones utilizadas para los workflows arriba indicados son los siguientes:
| Recomendado | Sí | |
dlc.table_filter | Filtro where que se desea incluir en la migración, debe incluir la palabra where. Este atributo se realiza cuando la ingesta de la tabla se realiza de forma incremental – por deltas – en lugar de completa - snapshots. Si no existe, la ingesta de la tabla será completa. | Recomendado | Sí | |
dlc.table_fields | Campos de la tabla que se desean migrar, si no se incluye se migrarán todos. | Recomendado | Sí | |
dlc.execution_context | Permite que dlc comunique a Rocket un contexto de ejecución específico. Se utiliza fundamentalmente para realizar la ingesta con unos recursos más elevados para aquellas tablas que, debido a su volumetría, se hace más complicada su ingesta. En el caso de ingestas automáticas, los contextos de ejecución Environment y SparkConfigurations permanecerán con sus valores por defecto, mientras que si se desean modificar, se define un contexto específico mediante el valor SparkResources, que puede tomar los siguientes valores.
Este parámetro no está habilitado para establecerse a nivel Vista Técnica si el parámetro dlc.group_entities es true. En tales casos, se recomienda crear una colección diferenciada y establecer el contexto de ejecución específico a nivel de colección. Nota: En caso de tener habilitado el metadato dlc.group_entities a nivel de colección, este metadato no estará disponible a nivel de vista técnica. | Recomendado | Sí | |
dlc.clone_gr | Indica si dlc copia las Quality Rules del asset origen en el asset destino. Actualmente se establece siempre a false a nivel Colección. Nota: En caso de tener habilitado el metadato dlc.group_entities a nivel de colección, este metadato no estará disponible a nivel de vista técnica. | Recomendado | Sí | |
dlc.clone_gr_overwrite | Indica a dlc si debe sobreescribir las Quality Rules en destino al realizar la copia de QRs desde origen. Nota: En caso de tener habilitado el metadato dlc.group_entities a nivel de colección, este metadato no estará disponible a nivel de vista técnica. | Recomendado | Sí | |
dlc.spark_user | Indica el usuario spark con el que ejecutar el workflow de Rocket para ingestar la entidad. | Recomendado | Sí | |
| dlc.table_partition | Permite especificar una clave de partición al escribir los datos en hdfs. Esta clave de partición debe ser un campo de la tabla a ingestar (o generado en el proceso de ingesta). | Recomendado | Sí | |
| dlc.extra_options | Define parámetros adicionales necesarios para la ejecución de la ingesta. El formato a indicar como valor es el siguiente: [{"clave_1":"valor_1", …, “clave_n”:”valor_n”}] | Recomendado | Sí |
Metadatos de las columnas de las Technical Views
Para las columnas que conforman las tablas dentro de la vista técnica, existen una serie de metadatos que son exclusivos de ellos. En la siguiente tabla, se muestran dichos metadatos.
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
type | Establece el tipo del objeto de la columna en cuestión, de forma que pueda identificarse con facilidad si es un entero, un string u otro tipo de objeto. | Obligatorio | Sí | |
nullable | Este metadato establece cuando la columna admite valores nulos. | Obligatorio | Sí | |
ordinal | Establece la posición ordinal de la columna en la tabla. | Obligatorio | Sí | |
typeId | Establece el tipo de indicador que presenta la columna. | Obligatorio | Sí | |
precision | Valor entero que establece la precisión de variables numéricas. | Obligatorio | Sí | |
scale | Establece la escala de una variable numérica. | Obligatorio | Sí | |
isSigned | Valor booleano que establece si la columna está o no firmada. | Obligatorio | Sí | |
Sensibilidad | atr_sensibilidad | Indica el nivel de sensibilidad en materia de seguridad de la tabla o columna. La sensibilidad de los datos puede tomar uno de estos tres valores: “publico”, “personal_identificable” o “personal_especial”. Además, debe tener marcado la característica “Security” que aparece en las opciones de custom attributes. | Obligatorio | No |
Business View
A continuación, se presenta una tabla con los metadatos específicos para las vistas de negocio que componen una colección determinada.
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínsecos |
|---|---|---|---|---|
Modo | Metadato que puede tomar un conjunto de valores predeterminados y que establece automáticamente la plataforma. | Obligatorio | Sí | |
Ontología | Nombre de la ontología en la que se construye la vista de negocio. | Obligatorio | Sí | |
Enlace ontología | Enlace a la ontología en la que se basa el activo. | Obligatorio | Sí | |
Colección | Nombre de la colección a la que pertenece el activo. | Obligatorio | Sí |
Reglas de calidad
En la siguiente tabla se muestran los metadatos específicos de las reglas de calidad tanto genéricas como específicas.
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
Auditoría | Campo seleccionable a la hora de crear reglas de calidad que define si los datos llevan, adicionalmente, a una tabla de auditoría. | Obligatorio | Sí | |
Umbral | Valor umbral por encima del cual los datos analizados cumplen con los criterios de calidad. | Obligatorio | Sí | |
Tipo de ejecución | Puede tomar dos valores, programado o embebido en función de cuándo y cómo se ejecuta la regla. | Obligatorio | Sí | |
Fuente de datos | Datos sobre los que se aplica la regla de calidad. | Obligatorio | Sí | |
Recursos | Exclusiva de las reglas de calidad planificadas. Tamaño de los recursos computacionales asociados al cálculo de la regla de calidad. | Obligatorio | Sí | |
Frecuencia de ejecución | Exclusiva de las reglas de calidad planificadas. Frecuencia con la que se ejecuta la regla de calidad en caso de que sea periódica. | Obligatorio | Sí | |
Tipo de medida | atr_medida | Establece el tipo de regla de calidad según los valores: completitud, actualidad, consistencia, precisión y unicidad. | Obligatorio | No |
Carácter(*) | atr_caracter | Metadato binario que indica cuándo la regla de calidad es de carácter técnico o de negocio. Puede tomar los valores “tec” o “neg”. | Obligatorio | No |
(*) El metadato carácter se creará o no a todas las reglas de calidad ya definidas en la herramienta en función al volumen de estas y el coste de recursos de dichas definiciones. Cualquier regla de calidad nueva que se cree deberá contener este metadato.
Ontologías
A continuación, se muestran los metadatos que son exclusivos de los elementos que componen una ontología.
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
Ontología | Nombre de la ontología a la que pertenece el elemento en cuestión. | Obligatorio | Sí | |
About | Enlace a la definición de la ontología correspondiente. | Obligatorio | Sí | |
Versión | atr_version | Versión de la ontología a la que pertenece. | Obligatorio | No |
Fecha actualización | atr_fec_act | Última fecha de actualización de la ontología a la que pertenece el elemento. | Obligatorio | No |
Communities
A continuación, se muestran en una tabla los metadatos específicos de los assets de las comunidades que componen el glosario de negocio.
Es importante destacar que el metadato que establece el estado ya se encuentra especificado en el apartado de metadatos comunes. No obstante, en el caso de las comunidades este metadato no es intrínseco en la herramienta y, por tanto, es necesario generarlo a través del concepto de atributos adicionales.
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
Versión | atr_version | Valor de la versión de la comunidad. | Recomendado | No |
Estado | atr_estado | Estado que indica la posible inactividad de la comunidad. | Obligatorio | No |
Domains
En la siguiente tabla se muestran los metadatos específicos de los assets de los dominios que componen un dominio concreto dentro del glosario de negocio que se encuentra en la plataforma de Stratio.
Es importante destacar que el metadato que establece el estado ya se encuentra especificado en el apartado de metadatos comunes. No obstante, al igual que en el caso de las comunidades, este metadato no es intrínseco en la herramienta para los dominios y, por tanto, es necesario generarlo a través del concepto de atributos adicionales.
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
|---|---|---|---|---|
Versión | atr_version | Valor de la versión del dominio. | Recomendado | No |
Estado | atr_estado | Estado que indica la posible inactividad de la comunidad. | Obligatorio | No |
Community | atr_community | Nombre de la comunidad a la que pertenece el dominio. | Obligatorio | No |
Business terms/rules
En este apartado se agrupan en una tabla los metadatos específicos tanto de los términos como de las reglas de negocio que componen un dominio determinado.
Metadato | Nombre Custom Attribute | Descripción | Obligatoriedad | Intrínseco |
Responsable actualización | Usuario responsable de la última actualización del término o regla de negocio. | Obligatorio | Sí | |
Versión | atr_version | Valor de la versión del dominio al que pertenece. | Recomendado | No |
Community | Nombre de la comunidad a la que pertenece la regla o el término de negocio. | Obligatorio | Sí | |
Dominio | Nombre del dominio al que pertenece el término o regla de negocio. | Obligatorio | Sí |
Rocket
Esta sección recoge la normativa aplicable para la gestión del módulo de Rocket de la herramienta Stratio, y al igual que en Governance, se distinguen dos grandes bloques para los metadatos. Por un lado, aquellos metadatos comunes a cualquier tipo de asset y, por otro lado, los metadatos específicos para cada uno de ellos.
Cabe destacar que, en Rocket, no se cuenta con la posibilidad de añadir metadatado adicional, al contrario que en Governance.
Metadatos Comunes
Existe un conjunto de metadatos que se repiten a lo largo de todos los assets de la herramienta. Estos se generan automáticamente al crear el asset en cuestión, no obstante, el metadato “descripción” se debe rellenar manualmente de forma obligatoria.
Metadato | Descripción | Obligatoriedad | Intrínseco |
Descripción | Descripción textual del activo. Debe ser lo más escueta posible al mismo tiempo que ofrezca las características generales del tipo de activo. También se debe incorporar información extra a modo de metadato excepcional. | Obligatorio | Sí |
Name | Nombre del asset | Obligatorio | Sí |
Type | Establece la tipología del asset, pudiendo ser: AutoMLPipeline, Batch, Hybrid, Mlproject, Notebook, Streaming. | Obligatorio | Sí |
Last modified | Fecha de la última modificación sufrida por el asset. | Obligatorio | Sí |
Folder | Ruta de la carpeta en la que se encuentra ubicado el asset. | Obligatorio | Sí |
Asset ID | Identificador del asset. | Obligatorio | Sí |
Assets relacionados | Nombre del asset con los que se relaciona. | Opcional | Sí |
Versión | Número de versión en la cual se encuentra el asset. | Obligatorio | Sí |
Además, dentro del metadato de descripción, se deberán añadir los datos mostrados en la siguiente tabla. Estos se indicarán con el nombre mostrado en la tabla seguido de “: “, separándose entre sí con el carácter “; “.
Nombre | Descripción | Obligatoriedad |
Descripcion | Descripción textual del activo. Debe ser lo más escueta posible al mismo tiempo que ofrezca las características generales del tipo de activo. | Obligatorio |
Creacion | Fecha en la que se crea el asset en formato “dd/mm/aaaa" de la útlima versión del asset. | Obligatorio |
Responsable | Usuario que se responsabiliza del funcionamiento de la última versión del asset. | Obligatorio |
Es decir, una descripción genérica tendrá la siguiente apariencia:
<<"Descripcion: Primera etapa del proceso de carga de usuario"; "Creacion: 01/10/2023"; "Responsable: Juan Antonio González Pérez">>.
Nombramiento de assets
En esta sección se establecen las normas que deben seguirse para nombrar los assets que se creen dentro de la plataforma Big Data. Estas normas están enfocadas a los assets que componen la solución Stratio implantada en el SAS, encontrándose divididos en función del módulo al que pertenecen.
A su vez, se definen un conjunto de buenas prácticas para que sirvan como guía para cualquier usuario que quiera cualquier elemento de forma general.
Nota: Esta normativa puede no ser cumplida siempre y cuando la OTBI de su aprobación explícita en caso de ser necesario su incumplimiento.
Buenas prácticas
A continuación, se expone un listado de las buenas prácticas generales que deben seguirse para el nombramiento de cualquier asset que se desee dar de alta en la plataforma Big Data.
- La longitud de los nombres no debe superar el tamaño máximo que permite la herramienta, pero siempre con un límite máximo de 30 caracteres.
- Los nombres han de ser claros y descriptivos, de forma que se entienda el contexto del activo con facilidad y, al mismo tiempo, sean lo más cortos posibles.
- Solo se deben emplear caracteres alfanuméricos y barra baja, evitando así el uso de otro tipo de carácter especial.
- Escribir todos los caracteres alfanuméricos del nombre en minúsculas, incluso cuando el activo se corresponde con una base, esquema o tabla de datos.
- Los caracteres alfanuméricos han de escribirse en español siempre que sea posible y sin usar la letra “ñ”, escribiendo en su lugar “ny”.
Por ejemplo: año_nacimiento → anyo_nacimiento
- Usar barra baja ( _ ) para separar identificadores dentro del nombre.
- Cuando la fecha del asset se deba incluir en el propio nombre, debe aparecer al principio y seguir el formato de fecha recomendada por Oracle sin separaciones: YYYYMMDD y YYYYMMDD-24HHMMSS en el caso de ser necesario las horas, minutos, y segundos.
Por ejemplo: 20220518-140847
- En caso de necesitar un control de las versiones y revisiones del asset, este debe incluirse al final del nombre, separado por una barra baja. El formato tendrá la estructura XXrYY, donde XX e YY son dos números de dos dígitos que indican la versión y revisión del asset respectivamente. La letra r hace referencia a la release de la normativa. Se entiende por revisión cuando se realiza una pequeña modificación en el activo en cuestión sin que los procesos en los que está involucrado se vean muy afectados. Al contrario, un cambio de versión tiene lugar cuando la modificación del activo es más profunda, rompiéndose el modelo o definición de este y afectando en mayor medida a los procesos que lo rodean.
Por ejemplo, nombre_asset_02r01
- El nombre de los assets obsoletos y/o que se encuentren en desuso pero que se requieren conservar debe comenzar con los caracteres "_OLD_". Estos assets solo se deben encontrar en entornos de pruebas o desarrollo, nunca en el productivo.
- El nombre del asset debe ser autocontenido y autodescriptivo, es decir, su comprensión no debe depender del contexto de la herramienta.
- En caso de necesitar añadir una secuencia numérica, se debe intentar estimar cuál va a ser la cantidad total de elementos que van a ser nombrados. Por ejemplo, si el máximo es 999, entonces, la secuencia numérica empezaría por 001, 002, 003…
- Se debe evitar, en todo momento, incluir información sensible en el nombre de los activos.
- Para aquellos assets que dispongan de carácter técnico o de negocio, se deberá de indicar en el nombre esta misma característica, tal y como se establece en el presente documento.
- Cuando el asset se está implementando en un entorno de desarrollo, debe contener el prefijo “dev”. Este prefijo se elimina de forma automática en la plataforma cuando se pasa a un entorno preproductivo y productivo.
Como añadido a todas estas buenas prácticas, es recomendable disponer de una tabla con todas las abreviaturas que se van a usar en los diferentes assets. En dicha tabla, se deben considerar, también, todos los ámbitos y subámbitos de información a los que pertenezcan los diferentes conjuntos de datos. De esta forma, se consigue que todos los usuarios miembros de la organización puedan acceder con facilidad a un determinado asset, comprendiendo sin dificultades el contexto de este. Dicha tabla se encuentra en la sección [Introducir enlace].
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2