11 septiembre 2020

Características claves de Oracle Autonomous Database.

Hoy traigo las principales ideas que han comentado los miembros de Oracle Corp. En una videoconferencia que han tenido la amabilidad de invitarme. Dentro de estas características claves, en la base de datos autónoma de Oracle 19C tenemos:

Autoconducción (Self Driving)
  • Capacidades y beneficios de las bases de datos Autónomas
  • Manejo de Atributos
  • Ajuste automático de sentencias
  • Escalado Automático
  • Indexación automatizada
  • Gestión Automatizada

Auto asegurado (Self Securing)
  • Autoreparación del Hardware
  • Autoreparación del Software
  • Resolución automática de incidencias mediante Machine Learning (ML)
  • Arquitectura de Máxima Disponibilidad (MAA)

Auto Reparado (Self reparing)
  • Seguridad en la base de datos autónoma
  • Cifrado por defecto
  • Auto-parcheado
  • Protección frente a ataques externos
  • Separación de roles
  • Auditoria

Autoconducción (Self Driving)


Capacidades y beneficios de las bases de datos Autónomas

Manejo de Atributos




Ajuste automático de sentencias

Escalado Automático

Indexación automatizada

Gestión Automatizada




Auto asegurado (Self Securing)

Autoreparación del Hardware


Autoreparación del Software


Resolución automática de incidencias mediante Machine Learning (ML)


Arquitectura de Máxima Disponibilidad (MAA)



Auto Reparado (Self reparing)


Seguridad en la base de datos autónoma


Cifrado por defecto


Auto-parcheado


Protección frente a ataques externos


Separación de roles


Auditoria





Estos han sido los factores claves de la Base de datos Autónoma de Oracle.






















29 julio 2020

¿Qué es la arquitectura de datos?


En tecnología de la información, la arquitectura de datos se compone de modelos, políticas, reglas o estándares que rigen qué datos se recopilan y cómo se almacenan, organizan, integran y utilizan en los sistemas de datos y en las organizaciones. [1] Los datos suelen ser uno de varios dominios de arquitectura que forman los pilares de una arquitectura empresarial o arquitectura de solución. [2]
[1] Business Dictionary - Data Architecture*TOGAF® 9.1 - Phase C: Information Systems Architectures - Data Architecture
[2] What is data architecture GeekInterview, 2008-01-28, accessed 2011-04-28



La arquitectura de datos define los flujos de información en una organización y cómo se controlan. Un arquitecto de datos es responsable de comprender los objetivos comerciales y la infraestructura y los activos de datos existentes; definición de principios de arquitectura de datos; y dar forma a la arquitectura de datos empresariales para proporcionar mayores beneficios a la organización.
Algunos conceptos básicos en arquitectura de datos:
  • Modelo de datos conceptual: muestra entidades de datos como clientes, productos y transacciones, y su semántica.
  • Modelo lógico: define los datos con el mayor detalle posible, incluidas las relaciones entre los elementos de datos, pero sin considerar cómo se almacenan o administran los datos.
  • Modelo de datos físicos: define cómo se representan y almacenan los datos, por ejemplo, en un archivo plano, base de datos, almacén de datos, almacén de valores clave.


¿Quién está involucrado en la arquitectura de datos?
Los siguientes roles existen para ayudar a dar forma y mantener una arquitectura de datos moderna:

  • Arquitecto de datos: define la visión de los datos en función de los requisitos comerciales, los traduce a los requisitos tecnológicos y define los estándares y principios de datos.
  • Responsable de proyectos: supervisa proyectos que modifican flujos de datos o crean nuevos flujos de datos.
  • Arquitecto de soluciones: diseña sistemas de datos para cumplir con los requisitos empresariales.
  • Arquitecto en la nube o ingeniero de centro de datos: prepara la infraestructura en la que se ejecutarán los sistemas de datos, incluidas las soluciones de almacenamiento.
  • DBA o ingeniero de datos: crea sistemas de datos, los completa con datos y se ocupa de la calidad de los datos.
  • Analista de datos: un usuario final de la arquitectura de datos, lo utiliza para crear informes y administrar una fuente de datos continua para la empresa.
  • Científicos de datos: también usuarios de la arquitectura de datos, que aprovechan para extraer datos de la organización para obtener nuevas perspectivas.

El papel del arquitecto de datos

¿Qué habilidades ayudan a alguien a convertirse en un arquitecto de datos?

  • Comprender y comunicar cómo los datos impulsan el negocio.
  • Capaz de trabajar con diversas fuentes de datos, comprender su estructura, contenido y significado.
  • Profundamente informado sobre herramientas y tecnologías de datos.

¿Cómo se puede formar un candidato a ser arquitecto de datos?
La capacitación de arquitectos de datos generalmente ocurre en el trabajo, en roles relacionados con datos como ingeniero de datos, científico de datos o arquitecto de soluciones. No existe un programa de certificación o capacitación estándar de la industria para arquitectos de datos, pero es valioso para los arquitectos tener certificación en las plataformas de datos primarias utilizadas por su organización. Algo así como un OCP, en el caso de Bases de datos Oracle.

¿Cuáles son los roles y responsabilidades del arquitecto de datos?
·         Traduce los requisitos del cliente o de su organización a especificaciones técnicas:
o   flujos de datos
o   transformaciones
o   integraciones
o   bases de datos
o   almacenes de datos (datawarehouse)

  • Define los estándares y los principios de la arquitectura de datos: modelado, metadatos, seguridad, datos de referencia como códigos de productos y categorías de clientes, y datos maestros como clientes, proveedores, materiales y empleados.
  • Define una arquitectura de referencia: un patrón que otros en la organización pueden seguir para crear y mejorar los sistemas de datos.
  • Define los flujos de datos: qué partes de la organización generan datos, qué datos requieren para funcionar, cómo se gestionan los flujos de datos y cómo cambian los datos en la transición.
  • Colaboración y coordinación: los proyectos de datos a menudo abarcan múltiples departamentos y partes interesadas, así como socios y proveedores externos; El arquitecto de datos es un punto focal que coordina a todas las partes en torno a los objetivos de la organización.


¿Cómo puede ayudar la tecnología?
Hace muchos años, la infraestructura de datos era monolítica. Las organizaciones invirtieron millones en grandes sistemas que almacenarían y procesarían todos los datos de la organización. Con el advenimiento de la tecnología de código abierto y las metodologías ágiles, los sistemas de datos se están volviendo más simples y más livianos, en algunos casos, y al mismo tiempo más efectivos y más flexibles.

Las herramientas tecnológicas que nos encontramos son:

  • Contenedores: plataformas como Docker y Kubernetes ayudan a acelerar e implementar la infraestructura de datos con solo hacer clic en un botón, y orquestar sistemas complejos de manera flexible y escalable.
  • Almacén de datos: una piedra angular de la infraestructura de datos de la vieja escuela, los almacenes de datos siguen siendo importantes, pero se están trasladando a la nube e interactuando con lagos de datos, bases de datos tradicionales y fuentes de datos no estructuradas
  • Base de datos relacional: los antiguos dominadores como Oracle, DB2, o incluso SQL Server, todavía están en uso, pero las alternativas de código abierto como MariaDB, MySQL y PostgreSQL están en todas partes
  • Base de datos NoSQL: almacenas cantidades masivas de datos semiestructurados y no estructurados. Las soluciones populares son Redis, MongoDB o Cassandra.
  • Transmisión en tiempo real: nuevas herramientas como Apache Kafka, ElasticSearch Logstash, Flume y AWS Kinesis ayudan a transmitir grandes volúmenes de datos desde los registros del sistema y los sistemas de producción.
  • Microservicios y computación sin servidor: los sistemas de datos creados utilizando microservicios o funciones como servicio (FaaS) son unidades independientes que exponen una interfaz estándar, lo que permite a los arquitectos de datos componer y organizar entornos de datos para satisfacer las necesidades del negocio.



Prácticas que mejorarán la arquitectura de datos
Las siguientes prácticas pueden ayudarnos a lograr una arquitectura de datos más efectiva:

  • Vea los datos como activos compartidos: elimine los silos organizativos y vea los datos de los clientes de manera integral, combinando datos de todas las partes de la organización.
  • Diseñar e implementar las interfaces adecuadas para que los usuarios consuman datos: los datos son insignificantes si no se pueden consumir de manera conveniente. Las interfaces pueden ser paneles basados ​​en web, BI, consultas SQL, R o cualquier otra cosa que los usuarios comerciales o analistas utilicen para obtener información.
  • Asegurar el control de acceso: clasifique los datos de acuerdo con su sensibilidad e importancia comercial, y diseñe cuidadosamente los controles de acceso para garantizar que los datos estén fácilmente disponibles, pero solo para aquellos que lo requieran.
  • Apoyar la administración del dato: los administradores de datos son expertos en la materia que pueden ayudar a limpiar, verificar y agregar datos de la organización. Por ejemplo, un gerente de línea de productos que tiene una visión especial de miles de productos. Construya una comunidad de administradores de datos, contribuyentes y ciudadanos de datos que puedan mejorar la calidad de los datos para todos.
  • Conservación de los datos: considere qué datos son realmente procesables para diferentes roles organizativos y cree procesos para seleccionar los datos más relevantes. Más allá de la curación de arriba hacia abajo, permita a los usuarios realizar fácilmente filtros y consultas para obtener datos relevantes más rápido.
  • Elimine las copias y el movimiento de datos: en las grandes organizaciones, es difícil estandarizar los datos sin reglas estrictas que sofocan la creatividad. Esfuércese por crear formatos y estructuras de datos que alienten a los usuarios a colaborar en las mismas entidades de datos, en lugar de crear múltiples versiones de la misma entidad.
  • Automatizar todo lo que sea posible: la clave para una arquitectura de datos eficiente.




29 marzo 2019

¿Hay vida más allá de Oracle? KQL: Kibana Query Language




Este tutorial es una explicación breve sobre cómo escribir consultas en Kibana, en la barra de búsqueda en la parte superior, o en Elasticsearch, utilizando la consulta de cadena de consulta. El lenguaje de consulta utilizado es en realidad el lenguaje de consulta de Apache Lucene, ya que es Lucene  el motor utilizado en Elasticsearch para indexar datos.

Comprender cómo se indexan sus datos en Elasticsearch influye en gran medida en qué y cómo puede buscar con sus consultas. Por eso esta no solo será otra entrada del Lucene query parser.

Por lo tanto, el tema de este tutorial no es solo explicar el lenguaje de consulta, sino también explicar por qué puede o no encontrar sus documentos almacenados en Elasticsearch.

Indexación de documentos
Primero, es crucial entender cómo Elasticsearch indexa los datos. Por lo tanto, ponemos los siguientes dos documentos en nuestra instancia de Elasticsearch.
:

{
  "title": "Lord Jim",
  "author": "Joseph Conrad"
}
{
  "title": "The Last Command",
  "author": "Timothy Zahn"
}
{
  "title": "Heart of Darkness",
  "author": "Joseph Conrad"
}


Si no cambiamos nada en las asignaciones de Elasticsearch para ese índice, Elasticsearch detectará automáticamente la cadena como el tipo de ambos campos al insertar el primer documento.

¿Qué hace un analizador?
Un analizador tiene varios tokenizadores y / o filtros adjuntos. El tokenizer obtendrá el valor del campo que se debe indexar (por ejemplo, "The Heart of Darkness") y puede dividir el valor en varios fragmentos que el usuario debería poder buscar (más en un momento). Los filtros de un analizador pueden transformar o filtrar tokens que produce el tokenizador.

Todas las fichas resultantes se almacenarán en un llamado índice invertido. Ese índice contendrá todos los tokens producidos por el analizador y un enlace a cuál de los documentos los contenían.

Por lo tanto, si el usuario presenta Elasticsearch con una palabra de búsqueda, solo tiene que buscarlo en el índice invertido y verá instantáneamente qué documentos debe devolver. Dado que no especificamos ninguna asignación para nuestro índice de Elasticsearch, los campos de la cadena de tipo se analizarán con el Analizador Estándar de forma predeterminada.

Este analizador dividirá primero el valor del campo en palabras (utilizará caracteres de espacio y puntuación como límites) y luego utilizará un filtro para transformar todas las fichas en minúsculas. Después de insertar los dos documentos anteriores, el índice invertido para el campo de título se vería de la siguiente manera, con 1 que se refiere al primer documento “Lord Jim”, 2 al segundo. "The Last Command" y 3 al tercero que se refieren al "The heart of Darkness":

Término
Documento
lord
1
jim
1
the
2,3
last
2
command
2
heart
3
of
3
darkness
3


También se creará un índice invertido para el campo de autor. Este contendrá cuatro entradas: una para “Timothy”, otra para  “Zahn” una para "Joseph" y otra para "Conrad" que están vinculadas a ambos documentos.

Ese índice invertido ahora permite a Elasticsearch buscar rápidamente qué documentos devolver para una búsqueda si el usuario busca "guía". Además, los Términos-Agregación en Elasticsearch / Kibana solo analizan ese índice invertido y devuelven los términos que tienen los documentos más / menos (según el orden especificado por el usuario) adjuntos.

Mapeos en Elasticsearch
Si inserta datos en elasticsearch, eso no es realmente texto, pero, por ejemplo, una URL o similar que el análisis predeterminado no tiene mucho sentido. Especialmente si va a visualizar sus datos con Kibana, no desea que un gráfico de las URL más visitadas contenga una entrada para "http" y la ruta de acceso se divide en cada barra. Le gustaría tener una entrada por dominio real. Lo que desea es que Elasticsearch no analice los valores de sus documentos.

Por lo tanto, debe definir una asignación para su índice manualmente. Esto no está cubierto en ese tutorial, pero eche un vistazo a la documentación oficial. Si específica “index: not_analyzed“ en el mapeo, el índice invertido para el campo del título se vería de la siguiente manera:


Término
Documento
Lord Jim
1
The Last Commnad
2
The heart of darkness
3

Y el índice invertido del campo de autor ahora se vería así.

Término
Documento
Joseph Conrad
1,3
Timothy Zahn
2


Como ves, Elasticsearch ya no divide los valores y tampoco los transforma en minúsculas. Ya sea que sus valores sean analizados o no (es decir, qué términos están en el índice invertido) tienen un gran impacto en qué y cómo puede buscar, como veremos en las siguientes secciones.

Cuando hablamos de los "datos analizados", esto significa que tiene los datos en los campos de cadena analizados. Cuando hablamos de "datos no analizados", esto significa que usted tiene una asignación que tiene ambos campos como no analizados.

Ahora explicaremos cómo Elasticsearch indexa los datos, podemos continuar con el tema real: la búsqueda.

Las siguientes consultas siempre se pueden usar en Kibana en la parte superior de la pestaña Descubrir, su visualización y / o paneles de control. Además, estas consultas se pueden usar en la consulta de cadena de consulta cuando se habla directamente con Elasticsearch.

Empecemos con el autor de la consulta bastante simple: joseph. Si ingresa esta consulta en el conjunto de datos analizado, Elasticsearch devolverá ambos documentos. ¿Por qué? Buscará el término "joseph" en el índice invertido para el campo del autor. Está allí enlazando a ambos documentos, por lo que Elasticsearch devolverá esos dos documentos como resultados.

Si utilizará la misma búsqueda en el conjunto de datos no analizados, no obtendrá ningún resultado. ¿Por qué? Elasticsearch busca de nuevo "joseph" en el índice invertido. No hay ninguna entrada para solo "joseph" como término (solo para "Joseph Conrad"), por lo que no devolverá ningún resultado.

Si intenta buscar el autor: Conrard (primera letra en mayúscula) en los datos analizados, obtendrá como resultado ambos documentos. ¿Por qué? Debido a que Elasticsearch reconoce que el campo del autor ha sido analizado e intenta aplicar el mismo analizador a su consulta de búsqueda "Conrad", significa que también se transformará en minúsculas antes de que se busque en el índice invertido. Por eso sigue encontrando los documentos. La misma consulta en datos no analizados aún no producirá ningún resultado, ya que no hay ninguna entrada para "Joseph" (solo para "Joseph Conrad").