Guía del profesional de los datos gráficos

Capítulo 1. Pensamiento gráfico

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Piensa en la primera vez que conociste la tecnología gráfica.

Probablemente la escena empezó en la pizarra donde tu equipo de directores, arquitectos, científicos e ingenieros discutían tus problemas de datos. Al final, alguien dibujó las conexiones de unos datos con otros. Tras dar un paso atrás, alguien observó que los enlaces entre los datos formaban un gráfico.

Esa constatación desencadenó el inicio del viaje gráfico de tu equipo. El grupo vio que se podían utilizar las relaciones entre los datos para proporcionar nuevas y potentes perspectivas a la empresa. Probablemente se encargó a una persona o a un pequeño grupo que evaluara las técnicas y herramientas disponibles para almacenar, analizar y/o recuperar datos en forma de gráfico.

La siguiente gran revelación para tu equipo fue probablemente que es fácil explicar tus datos como un gráfico. Pero es difícil utilizar tus datos como un gráfico.

¿Te suena?

Al igual que esta experiencia de pizarra, los equipos anteriores descubrieron conexiones dentro de sus datos y las convirtieron en valiosas aplicaciones que utilizamos a diario. Piensa en aplicaciones como Netflix, LinkedIn y GitHub. Estos productos convierten los datos conectados en un activo integral utilizado por millones de personas en todo el mundo.

Hemos escrito este libro para enseñarte cómo lo hicieron.

Como creadores y usuarios de herramientas, hemos tenido la oportunidad de sentarnos a ambos lados de la conversación de la pizarra cientos de veces. A partir de nuestras experiencias, hemos recopilado un conjunto básico de opciones y decisiones tecnológicas subsiguientes para acelerar tu viaje con la tecnología gráfica.

Este libro será tu guía para navegar por el espacio entre comprender tus datos como un gráfico y utilizar tus datos como un gráfico.

¿Por qué ahora? Poner en contexto las tecnologías de bases de datos

Los gráficos existen desde hace siglos. ¿Por qué son relevantes ahora?

Y antes de que te saltes esta sección, te pedimos que nos escuches. Estamos a punto de entrar en la historia; no es larga, y no tiene nada que ver. Necesitamos hacerlo porque los éxitos y fracasos de nuestra historia reciente explican por qué la tecnología gráfica vuelve a ser relevante.

Los gráficos son relevantes ahora porque el enfoque de la industria tecnológica ha cambiado en las últimas décadas. Antes, las tecnologías y las bases de datos se centraban en cómo almacenar los datos de la forma más eficiente. Las tecnologías relacionales evolucionaron como la primera opción para lograr esta eficiencia. Ahora queremos saber cómo podemos obtener el máximo valor de los datos.

Hoy se sabe que los datos son intrínsecamente más valiosos cuando están conectados.

Un poco de contexto histórico sobre la evolución de las tecnologías de bases de datos arroja mucha luz sobre cómo hemos llegado hasta aquí, y quizá incluso sobre por qué has cogido este libro. La historia de la tecnología de las bases de datos puede dividirse a grandes rasgos en tres eras: jerárquica, relacional y NoSQL. El siguiente recorrido abreviado explora cada una de estas eras históricas, centrándose en cómo cada era es relevante para este libro.

Nota

Las siguientes secciones te ofrecen una versión abreviada de la evolución de la tecnología gráfica. Sólo destacamos las partes más relevantes de la vasta historia de nuestra industria. Como mínimo, te ahorramos perder tu valioso tiempo en la madriguera del conejo de un recorrido autoguiado por los enlaces de Wikipedia, aunque, irónicamente, la versión autoguiada sería un paseo por el grafo de conocimiento más accesible de la actualidad.

Esta breve historia nos llevará desde los años 60 hasta hoy. Nuestro recorrido culminará con la cuarta era del pensamiento gráfico que está a nuestras puertas, como se muestra en la Figura 1-1. Te pedimos que hagas este breve viaje con nosotros porque creemos que el contexto histórico es una de las claves para desbloquear la amplia adopción de las tecnologías gráficas en nuestra industria.

Figura 1-1. Una línea de tiempo de alto nivel que muestra el contexto histórico de la evolución de la tecnología de bases de datos para ilustrar la aparición del pensamiento gráfico

Década de 1960-1980: Datos jerárquicos

La literatura técnica califica indistintamente de "jerárquicas" o "de navegación" las tecnologías de bases de datos de la década de 1960 a la década de 1980. Independientemente de la etiqueta, el pensamiento de esta época pretendía organizar los datos en estructuras arborescentes.

Durante esta época, las tecnologías de bases de datos almacenaban los datos como registros vinculados entre sí. Los arquitectos de estos sistemas imaginaron recorrer estas estructuras en forma de árbol, de modo que se pudiera acceder a cualquier registro mediante una clave o exploración del sistema o navegando por los enlaces del árbol.

A principios de los años 60, el Grupo de Trabajo de Bases de Datos del CODASYL, la Conferencia/Comité de Lenguajes de Sistemas de Datos, se organizó para crear el primer conjunto de normas del sector. El Grupo de Trabajo de Bases de Datos creó una norma para recuperar registros de estas estructuras de árbol. Esta primera norma se conoce como "el enfoque CODASYL" y establecía los tres objetivos siguientes para recuperar registros de los sistemas de gestión de bases de datos:¹

1. Utilizar una clave primaria

2. Escanear todos los registros en orden secuencial

3. Navegar por los enlaces de un registro a otro

Nota

CODASYL era un consorcio formado en 1959 y fue el grupo responsable de la creación y normalización de COBOL.

Aparte de la lección de historia, hay un punto irónico al que estamos llegando. Al inicio de este enfoque, los tecnólogos de CODASYL previeron la recuperación de datos mediante claves, escaneos y enlaces. Hasta la fecha, hemos asistido a una importante innovación y adopción de dos de estos tres estándares originales: claves y escaneos.

Pero, ¿qué ocurrió con el tercer objetivo de la normalización de la recuperación del CODASYL: navegar por los enlaces de un registro a otro? Almacenar, navegar y recuperar registros según los enlaces entre ellos describe lo que hoy llamamos tecnología de grafos. Y como hemos dicho antes, los grafos no son nuevos; los tecnólogos llevan años utilizándolos.

La versión resumida de esta parte de nuestra historia es que las tecnologías de navegación por enlaces de CODASYL eran demasiado difíciles y lentas. Las soluciones más innovadoras de la época introdujeron los árboles B, o estructuras de datos en árbol autoequilibradas, como una optimización estructural para abordar los problemas de rendimiento. En este contexto, los árboles B ayudaban a acelerar la recuperación de registros proporcionando rutas de acceso alternativas a través de los registros enlazados.²

Al final, el desequilibrio entre los gastos de implantación, la madurez del hardware y el valor aportado hizo que estos sistemas se dejaran de lado en favor de su primo más rápido: los sistemas relacionales. Como resultado, CODASYL ya no existe hoy en día, aunque algunos de los comités de CODASYL continúan su trabajo.

Década de 1980-2000: Entidad-Relación

La idea de Edgar F. Codd de separar la organización de los datos de su sistema de recuperación encendió la siguiente ola de innovación en las tecnologías de gestión de datos.³ El trabajo de Codd fundó lo que aún conocemos como la era entidad-relación de las bases de datos.

La era entidad-relación abarca las décadas en las que nuestra industria pulió el enfoque para recuperar datos mediante una clave, que era uno de los objetivos fijados por los primeros grupos de trabajo de los años 60. Durante esta era, nuestra industria desarrolló una tecnología que era, y sigue siendo, extremadamente eficaz para almacenar, gestionar y recuperar datos de tablas. Las técnicas desarrolladas durante estas décadas siguen prosperando hoy en día porque están probadas, documentadas y bien comprendidas.

Los sistemas de esta era introdujeron y popularizaron una forma específica de pensar sobre los datos. Ante todo, los sistemas relacionales se basan en la sólida teoría matemática del álgebra relacional. En concreto, los sistemas relacionales organizan tus datos en conjuntos. Estos conjuntos se centran en el almacenamiento y recuperación de entidades del mundo real, como personas, lugares y cosas. Las entidades similares, como las personas, se agrupan en una tabla. En estas tablas, cada registro es una fila. A un registro individual se accede desde la tabla por su clave primaria.

En los sistemas relacionales, las entidades pueden vincularse entre sí. Para crear enlaces entre entidades, se crean más tablas. Una tabla de enlace combinará las claves primarias de cada entidad y las almacenará como una nueva fila en la tabla de enlace. Esta época, y los innovadores que la protagonizaron, crearon la solución para los datos tabulares que aún prospera hoy en día.

Hay volúmenes de libros y más recursos de los que se pueden mencionar sobre el tema de los sistemas relacionales. Este libro no pretende ser uno de ellos. En su lugar, queremos centrarnos en los procesos de pensamiento y los principios de diseño que se han generalizado en la actualidad.

Para bien o para mal, esta época introdujo y arraigó la mentalidad de que todos los datos se mapean en una tabla.

Si tus datos deben organizarse en una tabla y recuperarse de ella, las tecnologías relacionales siguen siendo la solución preferida. Pero por muy integral que siga siendo su papel, las tecnologías relacionales no son una solución única.

Los últimos años de la década de los 90 trajeron los primeros signos de la era de la información a través de la popularización de la web. Esta etapa de nuestra corta historia insinuó volúmenes y formas de datos que hasta entonces no se habían planificado ni utilizado. En este momento de la innovación de las bases de datos, volúmenes incomprensibles de datos con formas diversas empezaron a llenar las colas de las aplicaciones. Una constatación clave en ese momento fue que faltaba el modelo relacional: no se mencionaba el uso que se pretendía dar a los datos. La industria disponía de un modelo de almacenamiento detallado, pero nada para analizar o aplicar inteligentemente esos datos.

Esto nos lleva a la tercera y más reciente ola de innovación de las bases de datos.

Años 2000-2020: NoSQL

El desarrollo de las tecnologías de bases de datos desde la década de 2000 hasta la de 2020, aproximadamente, se caracteriza como el advenimiento del movimiento NoSQL (no SQL o "no sólo SQL"). El objetivo de esta era era crear tecnologías escalables que almacenaran, gestionaran y consultaran todo tipo de datos.

Una forma de describir la era NoSQL relaciona la innovación de las bases de datos con el florecimiento del mercado de la cerveza artesanal en Estados Unidos. El proceso de fermentación de la cerveza no cambió, pero se añadieron sabores y se elevó la calidad y frescura de los ingredientes. Se desarrolló una conexión más estrecha entre el maestro cervecero y el consumidor, lo que produjo un bucle de retroalimentación inmediata sobre la dirección del producto. Ahora, en vez de tres marcas de cerveza en tu supermercado, es probable que tengas más de 30.

En lugar de encontrar nuevas combinaciones para la fermentación, el sector de las bases de datos experimentó un crecimiento exponencial de las opciones de tecnologías de gestión de datos. Los arquitectos necesitaban tecnologías escalables para abordar las diferentes formas, volúmenes y requisitos de sus aplicaciones en rápido crecimiento. Las formas de datos más populares que surgieron durante este movimiento fueron clave-valor, columna ancha, documento, flujo y gráfico.

El mensaje de la era NoSQL era bastante claro: almacenar, gestionar y consultar datos a escala en tablas no sirve para todo, igual que no todo el mundo quiere beber una pilsner light.

Hubo algunas motivaciones que condujeron al movimiento NoSQL. Estas motivaciones son fundamentales para comprender por qué y dónde nos encontramos dentro del ciclo de exageración del mercado de la tecnología de grafos. Las tres que nos gusta destacar son la necesidad de normas de serialización de datos, herramientas especializadas y escalabilidad horizontal.

En primer lugar, el aumento de la popularidad de las aplicaciones basadas en la web creó canales naturales para pasar datos entre estas aplicaciones. A través de estos canales, los innovadores desarrollaron nuevas y diferentes normas para la serialización de datos, como XML, JSON y YAML.

Naturalmente, estas estandarizaciones condujeron a la segunda motivación: las herramientas especializadas. Los protocolos de intercambio de datos a través de la web crearon estructuras que, de por sí, no eran tabulares. Esta demanda condujo a la innovación y al aumento de popularidad de las bases de datos de clave-valor, de documentos, de grafos y otras bases de datos especializadas.

Por último, esta nueva clase de aplicaciones vino acompañada de una afluencia de datos que presionó la escalabilidad del sistema como nunca antes. Las derivadas y aplicaciones de la ley de Moore predijeron el lado bueno de esta era, ya que vimos que el coste del hardware, y por tanto el coste del almacenamiento de datos, seguía disminuyendo. Los efectos de la ley de Moore permitieron abaratar la duplicación de datos, los sistemas especializados y la potencia de cálculo en general.⁴

Juntas, las innovaciones y las nuevas exigencias de la era NoSQL allanaron el camino para la migración de la industria de los sistemas scale-up a los scale-out. Un sistema scale-out añade máquinas físicas o virtuales para aumentar la capacidad computacional global de un sistema. Un sistema scale-out, generalmente denominado "clúster", aparece ante el usuario final como una única plataforma; el usuario no tiene ni idea de que su carga de trabajo está siendo servida en realidad por un conjunto de servidores. Por otro lado, un sistema de ampliación adquiere máquinas más potentes. ¿No tienes espacio? Consigue una caja más grande, que es más cara, hasta que no haya cajas más grandes que conseguir.

Nota

Ampliar significa añadir más recursos para repartir una carga, normalmente en paralelo. Aumentar significa hacer un recurso más grande o más rápido para que pueda manejar más carga.

Dadas estas tres motivaciones, este versátil conjunto de herramientas para construir arquitecturas de datos escalables para datos no tabulares ha evolucionado hasta convertirse en el producto más importante de la era NoSQL. Ahora los equipos de desarrollo tienen opciones que evaluar a la hora de diseñar su próxima aplicación. Pueden elegir entre un conjunto de tecnologías para adaptarse a las diferentes formas, velocidades y requisitos de escalabilidad de sus datos. Existen herramientas que gestionan, almacenan, buscan y recuperan datos de documentos, clave-valor, columnas anchas y/o gráficos a cualquier escala. Con estas herramientas, empezamos a trabajar con múltiples formas de datos de maneras antes inalcanzables.

¿Qué podemos hacer con esta colección única de herramientas y datos? Podemos resolver problemas más complejos más rápidamente y a mayor escala.

2020s-?: Gráfico

Te prometimos que nuestro recorrido histórico sería breve y útil. Esta sección cumple esa promesa conectando los momentos importantes de nuestro recorrido condensado. Juntas, las conexiones que vemos a lo largo de la historia de nuestra industria sientan las bases para la cuarta era de la innovación en bases de datos: la ola del pensamiento gráfico.

Esta era de la innovación está pasando de la eficiencia de los sistemas de almacenamiento a la extracción de valor de los datos que contienen los sistemas de almacenamiento.

¿Por qué la década de 2020?

Antes de esbozar nuestra perspectiva sobre la era de los gráficos, quizá te preguntes por qué iniciamos la era del pensamiento gráfico en 2020. Queremos dedicar un breve momento a explicar nuestra posición sobre el momento del mercado de los gráficos.

Nuestro llamamiento a la cronología general de 2020 procede de la intersección de dos trenes de pensamiento. En esta intersección, cruzamos el popular modelo de adopción de Geoffrey Moore⁵ con el calendario observado durante las tres últimas eras de innovación de las bases de datos.

Nota

Al igual que el CODASYL, el ciclo de vida de la adopción de tecnología atribuido comúnmente a Moore se originó en la década de 1950. Véase el libro de Everett Roger de 1962 Diffusion of Innovations.⁶

Concretamente, existe un desfase temporal comprobado y observable entre los primeros adoptantes y la adopción generalizada de las nuevas tecnologías. Vimos este desfase en "1980s-2000s: Entidad-Relación " con las bases de datos relacionales durante la década de 1970. Hubo un desfase de 10 años entre el primer artículo y las correspondientes implementaciones viables de la tecnología relacional. Puedes encontrar ejemplos del mismo desfase en cada una de las otras épocas.

La historia nos ha demostrado que todas las épocas anteriores a la era gráfica contenían un nicho que vio una amplia adopción años más tarde. Al mirar hacia la década de 2020, estamos haciendo esta misma suposición sobre el estado del mercado de los gráficos. La historia también nos ha demostrado que esto no significa que las herramientas existentes vayan a desaparecer.

Lo midas como lo midas, no se trata de una predicción bursátil en la que fijemos una fecha. En última instancia, nuestras perspectivas describen una nueva era de adopción de tecnología impulsada por una evolución del valor. Es decir, el valor está pasando de la eficiencia a derivarse de activos de datos altamente conectados. Estos cambios llevan tiempo y no se producen según un calendario.

Uniendo los puntos

Recordemos los tres patrones de recuperación previstos por el comité CODASYL en los años 60: acceder a los datos por claves, escaneos y enlaces. Extraer un dato por su clave, en cualquiera de sus formas, sigue siendo la forma más eficiente de acceder a él. Esta eficacia se consiguió durante la era de las entidades-relación y sigue siendo una solución popular.

En cuanto al segundo objetivo del comité CODASYL, acceder a los datos mediante exploraciones, la era NoSQL creó tecnologías capaces de manejar grandes exploraciones de datos. Ahora disponemos de software y hardware capaces de procesar y extraer valor de conjuntos de datos masivos a una escala inmensa. Es decir: tenemos clavados los dos primeros objetivos del comité.

El último de la lista: acceder a los datos atravesando enlaces. Nuestra industria ha cerrado el círculo.

La vuelta de la industria a centrarse en las tecnologías gráficas va de la mano de nuestro cambio de la gestión eficiente de los datos a la necesidad de extraer valor de ellos. Este cambio no significa que ya no necesitemos gestionar eficazmente los datos; significa que hemos resuelto bien un problema y pasamos a abordar el problema más difícil. Nuestra industria ahora hace hincapié en el valor junto con la velocidad y el coste.

Se puede extraer valor de los datos cuando eres capaz de conectar fragmentos de información y construir nuevas perspectivas. La extracción de valor en los datos proviene de la comprensión de la compleja red de relaciones dentro de tus datos.

Esto es sinónimo de reconocer los problemas complejos y los sistemas complejos observables en la red inherente a tus datos.

Nuestro sector y este libro se centran en el desarrollo y la implementación de tecnologías que aporten valor a partir de los datos. Al igual que en la era relacional, se requiere una nueva forma de pensar para comprender, implementar y aplicar estas tecnologías.

Es necesario un cambio de mentalidad para ver el valor del que hablamos aquí. Este cambio de mentalidad consiste en pasar de pensar en tus datos en una tabla a dar prioridad a las relaciones entre ellos. Es lo que llamamos pensamiento gráfico.

¿Qué es el pensamiento gráfico?

Sin decirlo explícitamente, ya recorrimos lo que llamamos pensamiento gráfico durante la escena de la pizarra al principio de este capítulo.

Cuando ilustramos la comprensión de que tus datos podían parecerse a un gráfico, estábamos recreando el poder del pensamiento gráfico. Es así de sencillo: el pensamiento gráfico engloba tu experiencia y tus realizaciones cuando ves el valor de comprender las relaciones entre tus datos.

Nota

El pensamiento gráfico consiste en entender el dominio de un problema como un gráfico interconectado y utilizar técnicas gráficas para describir la dinámica del dominio en un esfuerzo por resolver los problemas del dominio.

Ser capaz de ver gráficos en tus datos es lo mismo que reconocer la red compleja dentro de tu dominio. Dentro de una red compleja, encontrarás los problemas más complejos de resolver. Y la mayoría de los problemas y oportunidades empresariales de alto valor son problemas complejos.

Por eso, la próxima etapa de la innovación en tecnologías de datos está pasando de centrarse en la eficiencia a centrarse en encontrar valor aplicando específicamente tecnologías de gráficos.

Problemas y sistemas complejos

Ya hemos utilizado varias veces el término problema complejo sin dar una descripción específica. Cuando hablamos de problemas complejos, nos referimos a las redes de los sistemas complejos.

Problemas complejos

Los problemas complejos son los problemas individuales observables y medibles dentro de los sistemas complejos.

Sistemas complejos

Los sistemas complejos son sistemas formados por muchos componentes individuales que están interconectados de diversas formas, de modo que el comportamiento del sistema global no es un simple agregado del comportamiento de los componentes individuales (lo que se denomina "comportamiento emergente").

Los sistemas complejos describen las relaciones, influencias, dependencias e interacciones entre los componentes individuales de las construcciones del mundo real. En pocas palabras, un sistema complejo describe cualquier cosa en la que múltiples componentes interactúan entre sí. Ejemplos de sistemas complejos son el conocimiento humano, las cadenas de suministro, los sistemas de transporte o comunicación, la organización social, el clima global de la Tierra y el universo entero.

La mayoría de los problemas empresariales de alto valor son problemas complejos y requieren un pensamiento gráfico. Este libro te enseñará los cuatro patrones principales -vecindades, jerarquías, rutas y recomendaciones- utilizados para resolver problemas complejos con tecnología de grafos en empresas de todo el mundo.

Problemas complejos en la empresa

Los datos ya no son sólo un subproducto de la actividad empresarial. Los datos se están convirtiendo cada vez más en un activo estratégico de nuestra economía. Antes, los datos eran algo que había que gestionar con la mayor comodidad y el menor coste para permitir el funcionamiento del negocio. Ahora se tratan como una inversión que debe producir beneficios. Esto nos obliga a replantearnos cómo manejamos y trabajamos con los datos.

Por ejemplo, en la última etapa de la era NoSQL se produjeron las adquisiciones de LinkedIn y GitHub por parte de Microsoft. Estas adquisiciones dieron la medida del valor de los datos que resuelven problemas complejos. En concreto, Microsoft adquirió LinkedIn por 26.000 millones de dólares con unos ingresos estimados en 1.000 millones de dólares. La adquisición de GitHub fijó el precio en 7.800 millones de dólares sobre unos ingresos estimados de 300 millones de dólares.

Cada una de estas empresas, LinkedIn y GitHub, es propietaria del grafo de sus respectivas redes. Sus redes son el grafo de los profesionales y el de los desarrolladores, respectivamente. Esto multiplica por 26 los datos que modelan el complejo sistema de un dominio. Estas dos adquisiciones empiezan a ilustrar el valor estratégico de los datos que modelan el grafo de un dominio. Poseer el grafo de un dominio produce un rendimiento significativo en la valoración de una empresa.

No queremos tergiversar nuestras intenciones con estas estadísticas. Observar altos múltiplos de ingresos en las startups de rápido crecimiento no es una novedad. Mencionamos específicamente estos dos ejemplos porque GitHub y LinkedIn encontraron y monetizaron el valor de los datos. Estos múltiplos de ingresos son superiores a las valoraciones de las empresas emergentes de tamaño y crecimiento similares, debido al activo de los datos.

Aplicando el pensamiento gráfico, estas empresas son capaces de representar, acceder y comprender el problema más complejo dentro de su dominio. En resumen, estas empresas construyeron soluciones para algunos de los sistemas complejos más grandes y difíciles.

Las empresas que llevan ventaja a la hora de replantearse las estrategias de datos son las que crearon tecnología para modelar los problemas más complejos de sus dominios. En concreto, ¿qué tienen en común Google, Amazon, FedEx, Verizon, Netflix y Facebook? Aparte de estar entre las empresas más valiosas de la actualidad, cada una posee los datos que modelan el problema más grande y complejo de su dominio. Cada una posee los datos que construyen el gráfico de su dominio.

Piénsalo. Google tiene el gráfico de todo el conocimiento humano. Amazon y FedEx contienen los gráficos de nuestras economías mundiales de cadena de suministro y transporte. Los datos de Verizon construyen el gráfico de nuestras telecomunicaciones más grande del mundo. Facebook tiene el gráfico de nuestra red social global. Netflix tiene acceso al grafo del entretenimiento, modelado en la Figura 1-2 e implementado en los últimos capítulos de este libro.

Figura 1-2. Una forma de modelar los datos de Netflix como gráfico y el ejemplo final que pondrás en práctica en este libro: filtrado colaborativo a escala

En el futuro, las empresas que inviertan en arquitecturas de datos para modelar los sistemas complejos de sus dominios se unirán a las filas de estos gigantes. Invertir en tecnologías para modelar sistemas complejos equivale a dar prioridad a la extracción de valor de los datos.

Si quieres obtener valor de tus datos, el primer lugar donde debes buscar es en su interconectividad. Lo que buscas es el sistema complejo que describen tus datos. A partir de ahí, tus próximas decisiones se centran en las tecnologías adecuadas para almacenar, gestionar y extraer esta interconectividad.

Tomar decisiones tecnológicas para resolver problemas complejos

Tanto si trabajas en una de las empresas mencionadas como si no, puedes aprender a aplicar el pensamiento gráfico a los datos de tu dominio.

¿Por dónde empezar?

La dificultad de aprender y aplicar el pensamiento gráfico empieza por reconocer dónde las relaciones añaden o no valor dentro de tus datos. Utilizamos las dos imágenes de esta sección para simplificar las paradas en el camino e ilustrar los retos que nos esperan.

Aunque sencilla, la Figura 1-3 te reta a evaluar cuestiones fundamentales sobre tus datos. Esta primera decisión requiere que tu equipo conozca el tipo de datos que requiere tu aplicación. Empezamos específicamente con esta pregunta porque a menudo se pasa por alto.

Otros equipos anteriores al tuyo han pasado por alto las opciones mostradas en la Figura 1-3 porque el atractivo de lo nuevo les distrajo de seguir los procesos establecidos para crear aplicaciones de producción. Esta tensión entre lo nuevo y lo establecido hizo que los primeros equipos pasaran demasiado rápido de una evaluación crítica de los objetivos de su aplicación. Debido a ello, vimos fracasar y archivarse muchos proyectos gráficos.

Repasemos lo que queremos decir en la Figura 1-3 para evitar que repitas los errores comunes de los primeros en adoptar las tecnologías de gráficos.

Figura 1-3. No todos los problemas son problemas de grafos: la primera decisión que tienes que tomar

Pregunta 1: ¿Necesita tu problema datos gráficos?

Hay muchas formas de pensar sobre los datos. Esta primera pregunta del árbol de decisión te reta a comprender la forma de los datos que requiere tu aplicación. Por ejemplo, la sección de conexiones mutuas de LinkedIn es un gran ejemplo de respuesta afirmativa a la pregunta 1 de la Figura 1-3. LinkedIn utiliza las relaciones entre contactos para que puedas navegar por tu red profesional y comprender tus conexiones compartidas. Presentar una sección de conexiones mutuas a un usuario final es una forma muy popular en que los datos en forma de gráfico también son utilizados por Twitter, Facebook y otras aplicaciones de redes sociales.

Cuando decimos "forma de los datos", nos referimos a la estructura de la información valiosa que quieres obtener de tus datos. ¿Quieres saber el nombre y la edad de una persona? Lo describiríamos como una fila de datos que cabría en una tabla. ¿Quieres saber el capítulo, la sección, la página y el ejemplo de este libro que te muestra cómo añadir un vértice a un gráfico? Lo describiríamos como datos anidados que cabrían en un documento o jerarquía. ¿Quieres conocer la serie de amigos de tus amigos que te conectan con Elon Musk? Aquí estás pidiendo una serie de relaciones que encajen mejor en un grafo.

Pensando de arriba abajo, aconsejamos que la forma de tus datos impulse la decisión sobre tu base de datos y las opciones tecnológicas. Los tipos de datos utilizados habitualmente en las aplicaciones modernas se muestran en la Tabla 1-1.

Tabla 1-1. Resumen abreviado de los tipos de datos más comunes, sus formas y los tipos de bases de datos recomendados

Descripción de los datos	Forma de los datos	Utilización	Recomendación de la base de datos
Hojas de cálculo o tablas	Relacional	Recuperado por una clave primaria	Bases de datos RDBMS
Colecciones de archivos o documentos	Jerárquico o anidado	Raíz identificada por un ID	Bases de datos de documentos
Relaciones o vínculos	Gráfico	Consultado por un patrón	Bases de datos gráficas

Para los problemas de datos más interesantes de hoy en día, tienes que ser capaz de aplicar las tres formas de pensar sobre tus datos. Tienes que aplicar con soltura cada una de ellas a tu problema de datos y a sus subproblemas. Para cada parte de tu problema, necesitas comprender la forma de los datos que entran, residen y salen de tu aplicación. Cada uno de estos puntos, y cualquier momento en que los datos estén en vuelo, determinan los requisitos de las opciones tecnológicas de tu aplicación.

Si no estás seguro de la forma de los datos que requiere tu problema, la siguiente pregunta de la Figura 1-3 te reta a pensar en la importancia de las relaciones dentro de tus datos.

Pregunta 2: ¿Te ayudan las relaciones dentro de tus datos a comprender tu problema?

La pregunta más fundamental de la Figura 1-3 se refiere a si existen relaciones dentro de tus datos y aportan valor a tu problema empresarial. El éxito de la utilización de la tecnología gráfica depende de la aplicación de esta segunda pregunta del árbol de decisión. Para nosotros, sólo hay tres respuestas a esta pregunta: sí, no o quizá.

Si puedes responder con seguridad sí o no, entonces el camino está claro. Por ejemplo, la sección de conexiones mutuas de LinkedIn ejemplifica un claro "sí" para los datos con forma de gráfico, mientras que el cuadro de búsqueda de LinkedIn requiere una funcionalidad de búsqueda facetada y es un claro "no". Podemos hacer estas claras distinciones comprendiendo la forma de los datos necesaria para resolver el problema empresarial.

Si las relaciones dentro de tus datos ayudan a resolver tu problema empresarial, entonces necesitas utilizar y aplicar tecnologías de grafos dentro de tu aplicación. Si no lo hacen, entonces necesitas encontrar una herramienta diferente. Tal vez una opción de la Tabla 1-1 sea una solución para tu problema actual.

La parte complicada entra en juego cuando no estás exactamente seguro de si las relaciones son importantes para tu problema empresarial. Esto se muestra con la opción "¿Quizás?" a la izquierda en la Figura 1-3. Según nuestra experiencia, si tu línea de pensamiento te lleva a este punto de decisión, es probable que estés intentando resolver un problema demasiado grande. Te aconsejamos que desgloses tu problema y vuelvas a empezar por la parte superior de la Figura 1-3. El problema más común que aconsejamos a los equipos que desglosen es la resolución de entidades, o saber quién es quién en tus datos. En el Capítulo 11 se detalla un ejemplo de cuándo utilizar la estructura de grafos en la resolución de entidades.

Errores comunes en la comprensión de tus datos

A veces, ver la forma de tus datos como un gráfico puede subsumir la importancia de las otras dos formas de datos: anidados y tabulares. Los equipos suelen malinterpretar esta pista falsa.

Aunque pienses en tu problema como un problema complejo y, por tanto, emplees el pensamiento gráfico para darle sentido, eso no significa que tengas que aplicar tecnologías gráficas a todos los componentes de datos de tu problema. De hecho, puede ser ventajoso proyectar determinados componentes o subproblemas en tablas o documentos anidados.

Siempre será útil pensar en proyecciones (a ficheros o tablas). Así que nuestro ejercicio de pensamiento de la Figura 1-3 es algo más que "¿Cuál es la mejor forma de pensar sobre tus datos?". Se trata más bien de profundizar en un proceso de pensamiento más ágil para descomponer los problemas complejos en componentes más pequeños. Es decir, te animamos a que consideres la mejor forma de pensar sobre tus datos para el problema actual que tienes entre manos.

La versión más breve de lo que intentamos decir en la Figura 1-3 es: utiliza la herramienta adecuada para el problema que tienes entre manos. Y cuando aquí decimos "herramienta", estamos pensando en términos muy amplios. No estamos utilizando necesariamente ese término para referirnos a la elección de bases de datos; estamos pensando más ampliamente en el ámbito de las opciones de representación de datos.

Así que tienes datos gráficos. ¿Y ahora qué?

La primera pregunta de la Figura 1-3 te reta a aplicar el diseño basado en consultas a tus decisiones de representación de datos. Puede que haya partes de tu complejo problema que se representen mejor con tablas o documentos anidados. Eso es de esperar.

Pero, ¿qué ocurre cuando tienes datos gráficos y necesitas utilizarlos? Esto nos lleva a la segunda parte de nuestro proceso de pensamiento gráfico, que se muestra en la Figura 1-4.

Figura 1-4. Cómo navegar por la aplicabilidad y uso de los datos gráficos dentro de tu aplicación

De cara al futuro, partimos de la base de que tu aplicación se beneficia de comprender, modelar y utilizar las relaciones dentro de tus datos.

Pregunta 3: ¿Qué vas a hacer con las relaciones de tus datos?

En el mundo de las tecnologías de grafos, hay dos cosas principales que tendrás que hacer con tus datos de grafos: analizarlos o consultarlos. Siguiendo con el ejemplo de LinkedIn, la sección de conexiones mutuas es un ejemplo de cuándo se consultan los datos del grafo y se cargan en la vista. El equipo de investigación de LinkedIn probablemente rastrea el número medio de conexiones entre dos personas cualesquiera, lo cual es un ejemplo de análisis de datos de grafos.

La respuesta a esta tercera pregunta divide las decisiones sobre tecnología gráfica en dos bandos: análisis de datos frente a gestión de datos. El centro de la Figura 1-4 muestra esta pregunta y el flujo de decisión para cada opción.

Nota

Cuando decimos analizar, nos referimos a cuando necesitas examinar tus datos. Normalmente, los equipos dedican tiempo a estudiar las relaciones dentro de sus datos con el objetivo de encontrar qué relaciones son importantes. Este proceso es diferente de la consulta de los datos de tu gráfico. La consulta se refiere a cuando necesitas recuperar datos de un sistema. En este caso, conoces la pregunta que necesitas formular y las relaciones necesarias para responder a la pregunta.

Empecemos por la opción que se mueve hacia la derecha: los casos en los que sabes que tu aplicación final necesita almacenar y consultar las relaciones dentro de tus datos. Es cierto que éste es el camino menos probable hoy en día, debido a la etapa y la edad de la industria gráfica. Pero en estos casos, estás preparado y listo para pasar directamente a utilizar una base de datos de grafos dentro de tu aplicación.

A partir de nuestras colaboraciones, hemos encontrado un conjunto común de casos de uso en los que se necesitan bases de datos para gestionar datos de grafos. Esos casos de uso son los temas de los próximos capítulos, y los reservaremos para discutirlos más adelante.

Sin embargo, lo más frecuente es que los equipos sepan que sus problemas requieren datos en forma de gráfico, pero no sepan exactamente cómo responder a sus preguntas o qué relaciones son importantes. Esto apunta a la necesidad de analizar los datos de sus gráficos.

A partir de aquí, te retamos a ti y a tu equipo a dar un paso más en este viaje. Nuestra petición es que pienses en los resultados del análisis de tus datos gráficos. Crear una estructura y un propósito en torno al análisis de gráficos ayuda a tu equipo a tomar decisiones más informadas sobre tu infraestructura y herramientas. Esta es la última pregunta planteada en la Figura 1-4.

Pregunta 4: ¿Para qué necesitas los resultados?

Los temas del análisis de datos de grafos pueden abarcar desde la comprensión de distribuciones específicas en las relaciones hasta la ejecución de algoritmos en toda la estructura. Este es el ámbito de algoritmos como los componentes conectados, la detección de camarillas, el recuento de triángulos, el cálculo de la distribución de grados de un grafo, el rango de páginas, los razonadores, el filtrado colaborativo y muchos, muchos otros. Definiremos muchos de estos términos en los próximos capítulos.

A menudo vemos tres objetivos finales diferentes para los resultados de un algoritmo gráfico: informes, investigación o recuperación. Profundicemos en lo que queremos decir con cada una de esas opciones.

Nota

Vamos a entrar en detalle en las tres opciones (informes, investigación y recuperación) porque esto es lo que la mayoría de la gente hace hoy con los datos de gráficos. El resto de ejemplos técnicos y debates de este libro se centran principalmente en el momento en que has decidido que necesitas una base de datos de gráficos.

En primer lugar, hablemos de los informes. El uso que hacemos de la palabra informes se refiere a la necesidad tradicional de inteligencia y conocimiento de los datos de tu empresa. Esto se conoce comúnmente como inteligencia empresarial (BI). Aunque debatiblemente mal aplicados, los resultados de muchos de los primeros proyectos de gráficos tenían como objetivo proporcionar métricas o entradas en el canal de BI establecido de un ejecutivo. Las herramientas y la infraestructura que necesitarás para aumentar o crear procesos de inteligencia empresarial a partir de datos de grafos merecen su propio libro y una inmersión en profundidad. Este libro no se centra en la arquitectura o los enfoques de los problemas de BI.

En el ámbito de la ciencia de datos y el aprendizaje automático, se encuentra otro uso común de los algoritmos de grafos: la investigación y el desarrollo en general. Las empresas invierten en investigación y desarrollo para encontrar el valor dentro de sus datos estructurados en grafos. Hay algunos libros que exploran las herramientas y la infraestructura que necesitarás para investigar datos estructurados en grafos; este libro no es uno de ellos.

Esto nos lleva a la última ruta, denominada "recuperación". En la Figura 1-4, nos referimos específicamente a las aplicaciones que prestan un servicio a un usuario final. Estamos hablando de productos basados en datos que sirven a tus clientes. Estos productos vienen con expectativas en torno a la latencia, la disponibilidad, la personalización, etc. Estas aplicaciones tienen requisitos arquitectónicos diferentes a los de las aplicaciones que pretenden crear métricas para un público interno. Este libro tratará estos temas y casos de uso en los próximos capítulos sobre tecnología.

Piensa en nuestra mención a LinkedIn. Si utilizas LinkedIn, es probable que hayas interactuado con uno de los mejores ejemplos que se nos ocurren para describir la ruta de "recuperación" de la Figura 1-4. Hay una función en LinkedIn que describe cómo estás conectado con cualquier otra persona de la red. Cuando miras el perfil profesional de otra persona, esta característica describe si esa persona es una conexión de 1er grado, de 2º grado o de 3er grado. La duración de la conexión entre tú y cualquier otra persona en LinkedIn te proporciona información útil sobre tu red profesional. Esta función de LinkedIn es un ejemplo de producto de datos que siguió la ruta de recuperación de la Figura 1-4 para ofrecer una métrica gráfica contextual a los usuarios finales.

Las líneas entre estos tres caminos pueden ser borrosas. La diferencia radica entre crear un producto basado en datos o necesitar obtener información de los datos. Los productos basados en datos aportan un valor único a tus clientes. La próxima ola de innovación de estos productos consistirá en utilizar datos gráficos para ofrecer experiencias más relevantes y significativas. Estos son los problemas y arquitecturas interesantes que queremos explorar a lo largo de este libro.

Rómpelo e inténtalo de nuevo

Puede que a veces respondas a las preguntas de la Figura 1-3 y la Figura 1-4 con un "no lo sé", y no pasa nada.

En última instancia, es probable que estés leyendo este libro porque tu empresa tiene datos y un problema complejo. Tales problemas son vastos e interdependientes. En el nivel más alto de tu problema, navegar por el proceso de pensamiento que presentamos a lo largo de la Figura 1-3 y la Figura 1-4 puede parecer ajeno a tus datos complejos.

Sin embargo, basándonos en nuestra experiencia colectiva ayudando a cientos de equipos de todo el mundo, nuestro consejo sigue siendo que desgloses tu problema y vuelvas a pasar por el proceso.

Equilibrar las exigencias de las partes interesadas ejecutivas, las habilidades de los desarrolladores y las demandas de la industria es extremadamente difícil. Tienes que empezar poco a poco. Construye una base sobre un valor conocido y probado que te acerque un paso más a la solución de tu complejo problema.

Nota

¿Qué ocurre si ignoras tomar una decisión? Con demasiada frecuencia, hemos visto cómo grandes ideas fracasaban en la transición de la investigación y el desarrollo a una aplicación de producción: la vieja parálisis del análisis. El objetivo de ejecutar algoritmos gráficos es determinar cómo aportan valor las relaciones a tu aplicación basada en datos. Tendrás que tomar algunas decisiones difíciles sobre la cantidad de tiempo y recursos que dedicas a esta área.

Ver el panorama más amplio

El camino para comprender la importancia estratégica de los datos de tu empresa es sinónimo de encontrar dónde (y si) encaja la tecnología gráfica en tu aplicación. Para ayudarte a determinar la importancia estratégica de los datos gráficos para tu empresa, hemos recorrido cuatro preguntas muy importantes sobre el desarrollo de tu aplicación:

1. ¿Tu problema necesita datos gráficos?

2. ¿Te ayudan las relaciones dentro de tus datos a comprender tu problema?

3. ¿Qué vas a hacer con las relaciones de tus datos?

4. ¿Qué tienes que hacer con los resultados de un algoritmo gráfico?

Uniendo estos procesos de pensamiento, la Figura 1-5 combina las cuatro preguntas en un solo gráfico.

Figura 1-5. El proceso de decisión que desencadenó la creación de este libro: cómo navegar por la aplicabilidad y el uso de la tecnología de grafos dentro de tu aplicación

Dedicamos tiempo a recorrer todo el árbol de decisiones por dos motivos. En primer lugar, el árbol de decisiones representa una imagen completa del proceso de pensamiento que utilizamos cuando construimos, asesoramos y aplicamos tecnologías de grafos. En segundo lugar, el árbol de decisiones ilustra dónde encaja el propósito de este libro en el espacio del pensamiento gráfico.

Es decir, este libro te sirve de guía para navegar por el pensamiento grafo en los caminos que a lo largo de la Figura 1-5 terminan en la necesidad de una base de datos grafo.

Comenzar tu viaje con el pensamiento gráfico

Si se aprovechan adecuadamente, los datos de tu empresa pueden ser un activo estratégico y una inversión rentable. Los gráficos son de especial importancia en este caso, ya que los efectos de red son una fuerza poderosa que proporciona una exquisita ventaja competitiva. Además, el pensamiento de diseño actual anima a los arquitectos a considerar los datos de su empresa como algo que debe gestionarse con la máxima comodidad y el mínimo coste.

Esta mentalidad requiere un replanteamiento de cómo manejamos y trabajamos con los datos.

Cambiar de mentalidad es un largo viaje, y todo viaje comienza con un paso. Demos ese paso juntos y aprendamos el nuevo conjunto de términos que utilizaremos por el camino.

¹ T. William Olle, The CODASYL Approach to Data Base Management (Chichester, Inglaterra: Wiley-Interscience, 1978). Nº 04; QA76. 9. D3, O5.

² Rudolph Bayer y Edward McCreight, "Organización y mantenimiento de grandes índices ordenados", en Pioneros del software, ed.: Manfred Broy y Ernst Denert. Manfred Broy y Ernst Denert (Berlín: Springer-Verlag, 2002), 245-262.

³ Edgar F. Codd, "Un modelo relacional de datos para grandes bancos de datos compartidos", Communications of the ACM 13, nº 6 (1970): 377-387.

⁴ Clair Brown y Greg Linden, Chips and Change: How Crisis Reshapes the Semiconductor Industry (Cambridge: MIT Press, 2011).

⁵ Geoffrey A. Moore y Regis McKenna, Cruzar el abismo (Nueva York: HarperBusiness, 1999).

⁶ Everett M. Rogers, Diffusion of Innovations (Nueva York: Simon and Schuster, 2010).