Publicidad programática: la diferencia entre comprar espacios publicitarios y comprar directamente audiencias

2014 febrero 20
por classora

La publicidad programática es un sistema semi-automático para la compra-venta de publicidad a través de pujas en tiempo real (RTB). La compra programática funciona buscando coincidencias entre la información de audiencia suministrada por el anunciante y los espacios publicitarios (inventarios) disponibles en la web.

El proceso por el cual se realiza la compra se denomina RTB: Real Time Bidding o puja en tiempo real. El RTB consiste en una subasta digital por la cual la plataforma se encarga de realizar ofertas por impresiones deseadas –de acuerdo a los datos de audiencia suministrados por el anunciante- en los inventarios disponibles que coincidan con el perfil al que se desea llegar.

Ecosistema publicidad programática

Ecosistema general de la publicidad programática

Estas plataformas derivan de la compra-venta de publicidad a través de Google AdWords y Google AdSense. La novedad es que este proceso se realiza de forma constante en diferentes plataformas, por lo que el sistema es capaz de determinar, en milisegundos, qué anunciante obtiene determinadas impresiones en un medio, o qué medio se lleva las impresiones mejor pagadas de una determinada campaña en un momento dado.

¿Comprar espacio publicitario o comprar audiencias?

La compra tradicional de publicidad en medios digitales implica realizar un análisis de los periódicos o revistas en los que queremos emplazar publicidad. Entre otras cosas, este análisis incluye pensar en la imagen de marca del medio, su ideología, a qué audiencia llega, su tráfico web… etc. Con el advenimiento de la compra programática, para algunos especialistas cambiará la concepción misma de lo que se entiende por “compra”. Se dejará de comprar “medios” para comprar directamente “audiencias”.

La gran ventaja es que la definición original de audiencia también va a evolucionar para adaptarse a los nuevos tiempos: los usuarios dejarán de segmentarse por dimensiones clásicas como sexo, edad, lugar de nacimiento o poder económico. Pronto podrán estudiarse por muchas más dimensiones de utilidad para el anunciante. Por ejemplo, podremos pensar en audiencias que se definan por “ser seguidores del Real Madrid”, “que se hayan comprado una nevera hace poco”, “que prefieran McDonals a Burger King”… etc.

Presente y futuro de la publicidad programática

La compra programática de medios digitales viene ganando terreno en Estados Unidos y está comenzando a utilizarse en Europa y Latinoamérica. En general, tanto las agencias como los anunciantes y los medios de comunicación se encuentran en pleno proceso de entendimiento de este nuevo sistema.

De hecho, ni siquiera en Estados Unidos la compra programática se ha establecido en todos los mercados. Si bien está avanzando se manera rápida. Un estudio de Magna Global proyecta que para el año 2017 casi la mitad de las compras de publicidad en medios digitales de Estados Unidos se realizarán por medio de la compra-venta programática.

Ventajas e inconvenientes de la publicidad programática

Aunque la mayoría de las agencias coincide en que la compra programática es algo positivo y que necesita implementarse para obtener mejores resultados en los ROI, también hay opiniones que guardan cierto recelo a estas nuevas tecnologías, en su mayoría en relación a la forma de medir los resultados. A continuación reproducimos parcialmente algunas opiniones interesantes de expertos, extraídas de la revista Portada:

  • Axel Steinman, de Microsoft aseguró que “las nuevas tecnologías no resuelven el problema más grande en la industria: la falta de consenso para utilizar datos y métricas de manera inteligente. Sería maravilloso si como industria pudiéramos acordar algo”.
  • Diego Fernández, director de medios de comunicación para USA de Burger King: “La compra programática aún es lenta, ya que los anunciantes y agencias no están compartiendo mucha información, aunque creo que los próximos años va a ser muy importante y bueno ver más de lo mismo”.
  • Juan Pablo Suárez, de US Media Consulting agrega que “La compra programática es enriquecimiento y aceleración del proceso tradicional. Es una evolución natural, durante los últimos 15 años la publicidad digital experimentó ciclos donde surgieron agregadores de inventario y de demanda en distintas capas (Sitios, AdNetworks, AdExchanges, DSPs) cada uno integrando la oferta de la capa anterior y limitados exclusivamente por la tecnología y capacidad de procesamiento disponible”.
  • Alejandro Campos, de StartMeApp, también considera que la compra programática será positiva para el sector: “Si lo ves desde la perspectiva del anunciante te permite conocer el valor y la calidad de la impresión antes de comprarla. La impresión se hace relevante porque llegas a la audiencia en tiempo real, y eso marca toda la diferencia. Y tira por la borda el targeting, el estudio de comportamientos, etc.”.
  • Lucio Grimaldi, de Publicitas coincide en que la compra programática es algo beneficioso para la industria y plantea que la compra programática no va a sustituir a la publicidad tradicional. “No creo que la compra programática sustituya a la compra tradicional ya que sus funciones y objetivos son diferentes. La compra tradicional siempre requerirá un factor humano, mientras que la compra programática está basada en inventarios remanentes”.

Más información

Como en otras ocasiones, si te interesa conocer más información sobre este tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Cuenta con Classora Technologies para estar informado sobre publicidad programática y publicidad nativa.

IPTC: el formato estándar para intercambiar contenidos informativos

2014 enero 8
por classora

El International Press Telecommunications Council (IPTC) es una asociación que agrupa a varias de las empresas de comunicación más importantes del mundo, incluyendo a agencias de noticias, medios digitales y prensa escrita. Su objetivo inicial era salvaguardar los intereses en las telecomunicaciones de la prensa mundial, si bien hoy en día se ha centrado en desarrollar y mantener estándares técnicos para mejorar el intercambio de noticias.

IPTC: International Press Telecommunications Council

El IPTC tiene su sede central en Windsor (Reino Unido). Fue fundado en el año 1965 por un grupo de organizaciones de prensa, incluyendo la Alianza Europea de Agencias de Prensa (EANA), la Asociación de Periódicos de Norteamérica (NAA) y la Asociación Mundial de Periódicos (WAN), precursora de la actual WAN-IFRA (World Association of Newspapers and News Publishers).

Los primeros estándares y la simbiosis con Adobe

IPTC definió en 1979 un conjunto de metadatos para clasificar e intercambiar imágenes. Sin embargo, no fue hasta 1994, con la digitalización masiva de fotografías, cuando este concepto fue retomado e impulsado a escala global. Este impulso fue debido en gran medida a la empresa americana Adobe, que definió una especificación para introducir estos metadatos en archivos de imágenes digitales (JPEG, TIFF… etc.), ahora conocidos como encabezados IPTC.

Un poco más tarde, en 2001, Adobe introdujo el Extensible Metadata Platform (XMP), un esquema XML para datos como los encabezados IPTC, pero basado en XML/RDF y, por tanto, extensible. Este esfuerzo alentó una nueva colaboración con el IPTC, dando lugar al IPTC Core Schema for XMP, que combina los dos acercamientos a la incrustación de metadatos.

Metadatos IPTC en imágenes digitales

El estándar internacional de prensa IPTC

Llegados a este punto fue cuando el IPTC se animó a generar un modelo estándar para el intercambio de información de todo tipo (noticias, textos, imágenes, vídeos, eventos… etc.). A este estándar se le denominó Information Interchange Model (IIM). Debido a la inercia de los encabezados IPTC, la aceptación del IIM fue todo un éxito en el mundo de la fotografía (tanto profesional como amateur), si bien en el mundo de la prensa digital apenas tuvo repercusión, utilizándose al principio únicamente en agencias de noticias de algunos países europeos.

No obstante, poco a poco la evolución de la Web Semántica y la mayor acogida general de los estándares de clasificación y representación de la información (RDF, Dublin Core… etc.) están haciendo que también los estándares IIM de IPTC vuelvan a estar entre las prioridades de varias compañías del sector en todo el mundo.

Una de las principales ventajas a la hora de explotar las recomendaciones del IPTC reside en poder vender noticias a otros medios de comunicación anotándolas con categorías y etiquetas estándares. Dentro del IIM, el IPTC generó un listado pormenorizado y flexible de categorías para clasificar textos y noticias de todo tipo (tabla original IPTC, resto de tablas IPTC). Este listado, dotado de varios niveles jerárquicos y de códigos universales para identificar a cada categoría informativa, tiene un valor estratégico incalculable para intercambiar información y abrir nuevas vías de negocio.

Proyecto rNews del New York Times con anotaciones IPTC

En el momento en el que nos encontramos, en el que la mayor parte de los medios digitales manejan etiquetas propias para clasificar las noticias, y en el que los medios líderes otorgan una importancia crucial a las páginas de estas etiquetas/temas (por su valor SEO y sus capacidades para reciclar la hemeroteca digital) la existencia de un conjunto estándar de etiquetas abre las puertas no sólo a colaboraciones para minimizar la dependencia de las agencias, sino a la generación de un mercado interno para el intercambio y la compra-venta de contenidos. Un mercado especialmente útil para cubrir determinados temas o complementar noticias locales, ya que cada periódico puede obtener de él no sólo textos neutrales (sin ideología política asociada y carentes de toda opinión) sino contenidos afines a la ideología, a la línea editorial y a las expectativas de la audiencia en cada medio concreto.

En Classora Technologies somos expertos en etiquetar y clasificar contenidos de medios digitales. Manejamos con toda probabilidad la tecnología que está obteniendo los mejores resultados de etiquetado para español, con clientes muy satisfechos en prensa digital de España y en diferentes países de Latinoamérica. Los servicios de Classora se pueden basar en el estándar IPTC o, si el cliente así lo desea, se puede crear una ontología/folksonomía propia para representar la información, de manera completamente exclusiva y pormenorizada.

Más información

Como en otras ocasiones, si te interesa conocer más información sobre este tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Cuenta con Classora Technologies para estar informado sobre IPTC y otros formatos estándares para intercambiar contenidos informativos.

Componentes interactivos para visualizar datos de acontecimientos en medios digitales

2013 diciembre 16
por classora

Publicar los datos de manera visual y sencilla es prácticamente tan importante como disponer de ellos. Por eso, y con la excusa de que ya se empieza a aproximar el mundial de fútbol de Brasil, en este post vamos a hablar brevemente acerca de los componentes interactivos que están utilizando los medios de comunicación digitales para visualizar datos sobre este tipo de eventos.

De hecho, las infografías interactivas han sido tradicionalmente uno de los recursos más utilizados por los medios digitales para marcar una ventaja en la cobertura de ciertos eventos. Esto se debe a que en determinados acontecimientos deportivos, como los juegos olímpicos o los mundiales de fútbol, los usuarios se encuentran ávidos de datos actualizados, en los que están mucho más interesados que en largas noticias explicativas, a las que solo acuden una vez que han saciado su curiosidad inicial. Hagamos un repaso rápido.

Visualización gráfica de un mundial en una estructura OLAP

Con motivo del mundial de 2010, el diario Marca generó una infografía que permitía analizar con un simple click todos los datos relevantes del evento. Se podía consultar el calendario completo del mundial, todos los partidos que jugaba cada selección, los grupos con sus respectivos resultados, las ciudades y los estadios involucrados, y la evolución de la competición en cada fase. Un ejemplo magistral de visualización de una estructura de datos, prácticamente idéntica a un cubo OLAP, en un componente interactivo con una usabilidad impecable. No en vano se convirtió en el gráfico del mundial más visto de Internet en español.

Visualización mundial 2010 Diario Marca

Este trabajo fue llevado a cabo por Tomás Alhambra y su equipo, que ya tienen una larga trayectoria creando infografías para papel y gráficos interactivos para la web.

Correlación entre las selecciones y las ligas de fútbol

Otra referencia infográfica sobre el mismo acontecimiento la podemos extraer del diario brasileño Estadao. Concretamente, este periódico diseñó un componente interactivo que permitía visualizar los países (ligas) en los que jugaban los miembros de cada selección y, de manera inversa, los países de los que procedían los jugadores de cada liga. Con un simple click, este componente permitía obtener conclusiones asombrosas acerca de la potencia de las diferentes ligas y su correlación con los equipos nacionales que participaban en el mundial.

Análisis de jugadores por selección y por liga

Los pueblos, ciudades y países de todos los jugadores de la Liga

Un ejemplo equivalente aplicado a la liga española lo podemos extraer del diario La Información. En este caso, el periódico generó un mapa interactivo en el que se podía comprobar que jugadores había aportado cada ciudad española, y cada país del mundo, a la LFP. Además, mostraba de forma directa en qué equipos estaba jugando cada jugador.

Los pueblos de todos los jugadores de la Liga

Información en detalle acerca de todos los jugadores

Volviendo al mundial de Sudáfrica, a la hora de mostrar a nivel de detalle las características de cada jugador (de todos los jugadores titulares de todas las secciones) una infografía que sobresalió fue la publicada por el diario El Colombiano. Permitía navegar por grupo clasificatorio, por selección y dentro de cada selección especificar el jugador haciendo click en su posición en el terreno de juego. Otra manera ejemplar de resumir toda la información disponible.

Información en detalle acerca de todos los jugadores

La Web Semántica al servicio del mundial

Representando los datos en un formato estándar como RDF y complementándolos con otras fuentes de la web semántica y con sus propios contenidos, la BBC consiguió generar un proyecto de referencia en la semántica de los medios digitales con su Dynamic Semantic Publishing. No solamente se utilizó en el mundial de fútbol de 2010, sino también en los juegos olímpicos de 2012. Y esto es solo el principio de lo que se puede hacer con este tipo de tecnologías.

BBC Dynamic Semantic Publishing

La tecnología al servicio de la selección

Por hacer alguna refererencia a los trabajos infográficos en papel, un trabajo muy artístico y con un mérito especial fue el llevado a cabo por Miguel Ángel Fernández en sus diferentes infografías para la cobertura del mundial por parte del diario AS. En el siguiente ejemplo se muestra un resumen de las aplicaciones de la tecnología a la ropa y los complementos que utilizaban los jugadores de la roja. A la capacidad de síntesis de la infografía se una la espectacularidad de su diseño gráfico.

La tecnología al servicio de la roja

Ventajas y desventajas de las infografías interactivas

Si bien estas infografías son resultados ejemplares acerca de cómo es posible sintetizar mucha información en componentes muy usables y, en algunos casos, espectaculares, también es importante mencionar sus principales desventajas. En este sentido quizá el principal inconveniente es que suelen estar basadas en flash o javascript, lo que implica varias cosas:

  • Posicionamiento SEO: contenidos no rastreables por Google
  • Imposibilidad de linkar una pantalla concreta de información (a través de URI)
  • Métricas web: no se puede contabilizan indicadores como el ratio de páginas/visita
  • Baja rentabilidad publicitaria: poca segmentación y anuncios en la misma página

No obstante, ya existen diferentes soluciones para todas estas desventajas, que muchas veces vienen de la mano de HTML5 y de sus nuevas posibilidades para realizar métricas web, profiling de usuarios y gestión publicitaria.

Más información

Como en otras ocasiones, si te interesa conocer más información sobre este tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Cuenta con Classora Technologies para estar informado sobre componentes interactivos para visualizar datos de acontecimientos en medios digitales.

La publicidad nativa: un reto y una oportunidad para los medios digitales

2013 noviembre 16
por classora

La publicidad nativa es un nuevo formato de publicidad para Internet que todavía se está forjando entre empresas anunciantes, soportes publicitarios y markets de compra-venta de propaganda. En resumen, esta publicidad trata de encajar los objetivos de un anunciante (target de una determinada campaña publicitaria) con la experiencia de un usuario (a través de su navegación por la Red). Además, la publicidad nativa puede utilizar los contenidos como soporte publicitario, en lugar de los formatos gráficos o textuales habituales, y hacerlo con un estilo estético similar a los contenidos convencionales que aparecen en los medios, portales y blogs de Internet. Esta publicidad debería ser accesible de la misma forma que el resto de contenidos, es decir a través de la portada o de la cabecera de sección del medio digital. Además, siguiendo las leyes vigentes, es preciso comunicar al visitante que se trata igualmente de publicidad, es decir, que el contenido que va a consumir lo ofrece una empresa y no directamente el soporte web.

Publicidad nativa

En la actual coyuntura de crisis global que se está viviendo en el sector de los medios de comunicación, donde, cada vez más, los anunciantes buscan una verdadera rentabilidad y efectividad en las campañas que desarrollan, se ha establecido un profundo debate en el mundo digital sobre una alternativa publicitaria real y prometedora a la basada en los banners tradicionales. Gran parte del debate se ha centrado en cómo definir correctamente la publicidad nativa: ¿es un publirreportaje?, ¿es un patrocinio?, ¿es marketing de contenidos?, ¿es entretenimiento de marca?…

Este debate lleva tiempo removiendo el mercado. Ya el pasado septiembre de 2012 Mashable, presento un estudio titulado ¿Qué es la publicidad nativa? Depende de a quién se le pregunte y durante 2013 cada vez más marcas han comenzado a invertir en publicidad nativa: P&G, Unilever, Coca-Cola, Porsche… etc.

Según Ángel Leo-Revilla, en el sector hay un amplio consenso en que la publicidad nativa difiere principalmente de tres maneras en relación a la «tradicional» publicidad interruptiva:

  • Se adapta a la apariencia de la página web y/o de los contenidos en que aparece.
  • Pretende ser una parte integrada en los contenidos que consumen los usuarios.
  • Trata no sólo de no ser intrusiva, sino de no ser molesta, inoportuna o descontextualizada.

Entonces… ¿es la publicidad nativa una simple, pero necesaria, actualización de las formas de patrocinio tradicionales? La verdadera revolución radica en formatos publicitarios que realmente mejoran la experiencia de la audiencia, siendo más que simples anuncios que han sido disfrazados. Deben crear valor directamente y, sin ambigüedades, ayudar al usuario a lograr lo que se propone.

En este escenario, los medios digitales tienen el gran potencial de, conociendo previamente a su audiencia, poder desarrollar acciones de publicidad nativa para sus anunciante que se adapte a los gustos y formas de consumo que de sus contenidos hacen sus usuarios ¿serán capaces de aprovechar esta oportunidad que se les ofrece? En Classora Technologies estamos trabajando, conjuntamente con la empresa de Atlanta Audience Circles, para que así sea.

Sponsored views de Washington Post

Más información

Como en otras ocasiones, si te interesa conocer más información sobre este tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Cuenta con Classora Technologies para estar informado sobre publicidad nativa y las oportunidades de la prensa digital para obtener una mayor rentabilidad publicitaria de sus contenidos.

Conferencia de Classora durante la Asamblea General de la SIP en Denver

2013 octubre 28
por classora

La Sociedad Interamericana de Prensa (SIP) es una asociación de propietarios y altos ejecutivos de periódicos y agencias informativas de América. La SIP fue creada en La Habana en el año 1943, y actualmente la integran más de 1.300 empresas de todo el continente, incluyendo diarios, revistas, periódicos y agencias. Su principal objetivo es defender la libertad de prensa y los derechos de los periodistas, así como promover un mayor intercambio de información entre la sociedad. Junto con la WAN-IFRA, es la asociación de medios más importante de América.

Los miembros de la SIP se reúnen dos veces al año: en la Asamblea General y en la Reunión de Medio Año. La última asamblea general tuvo lugar del 18 al 22 de octubre en Denver, Colorado. Classora Technologies tuvo la oportunidad de participar en uno de los seminarios del evento. Concretamente, el seminario habló del impacto del Big Data en los medios de comunicación. La participación de Classora, de mano de nuestro compañero Iván Gómez, resumió como los medios pueden aumentar su rentabilidad y mejorar su imagen sacando provecho de las tecnologías semánticas y de la gran cantidad de datos disponibles hoy en día.

Impacto del Big Data en los medios de comunicación

En general, el seminario examinó el contexto del periodismo de datos (data journalism), la generación de noticias para el periodismo de investigación, el enriquecimiento de diarios digitales gracias a tecnologías semánticas y la posibilidad de los medios de identificar a sus audiencias y predecir su comportamiento online respecto a los contenidos y la publicidad.

Panel sobre el impacto del Big Data en los medios de comunicación

El seminario estuvo compuesto por los siguientes participantes:

Rosental Alves Rosental Alves (Moderador)

Brasil. Profesor en la Universidad de Texas (Austin, Texas).

Twitter: @rosental

Francisco Vasquez Francisco Vasquez (Ponente)

Chile. Fundador y CEO de Audience Circles Inc. (Atlanta, Georgia).

Twitter: @panchileno

Iván Gómez Iván Gómez (Ponente)

España. Fundador y CTO de Classora Technologies (La Coruña, España)

Twitter: @icaderno

Mariano Blejman Mariano Blejman (Ponente)

Argentina. Periodista y Knight Fellowship (Buenos Aires, Argentina)

Twitter: @blejman

La conferencia, que dispuso de traducción simultánea a inglés y portugués, fue seguida por decenas de personas en el Salón Onyx del Brown Palace Hotel de Denver, y por varios miles de personas en Internet vía streaming.

¿Cómo pueden los medios aprovechar toda esta información?

En Classora realizamos un repaso rápido al concepto de economía de la atención, para posteriormente referirnos a las grandes revoluciones de los datos que afectan hoy en día a Internet: el Big Data, el Linked Data y el Open Data. La principal pregunta que trató de responder nuestro compañero Iván Gómez fue: ¿cómo los medios de comunicación pueden unir las piezas de este inmenso puzzle (Big, Linked, Open Data) para sacar una mayor rentabilidad a sus diarios online?. La respuesta se articuló en los tres puntos siguientes:

  • Enriquecimiento semántico: consiguiendo elevar la calidad de la web de un diario varios peldaños por encima de su competencia, generando un valor diferencial y una ventaja competitiva sostenible en el tiempo. Se trata de enriquecer páginas de noticias, páginas de temas (topics, tags, etiquetas… etc.) y el propio buscador con datos externos relevantes.
  • Data-driven journalism: consiguiendo detectar de manera automática o semiautomática patrones y tendencias ocultos en grandes cantidades de datos. No es más que bucear, mediante redes neuronales y algoritmos de regresión lineal, en la gran marabunta de datos para localizar conocimiento útil y publicar titulares inéditos.
  • Segmentación de audiencias: consiguiendo conocer con mayor detalle las características de los usuarios que consumen la información que escriben y publican los medios (como hacen Google o Facebook). El objetivo no es otro que permitir mostrar contenidos más relevantes y alcanzar campañas publicitarias más rentables.

Iván Gómez durante la ponencia

Más información

Como en otras ocasiones, si te interesa conocer más información sobre este tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Cuenta con Classora Technologies para estar informado sobre tendencias semánticas y para estudiar las alternativas de modernización y rentabilización de medios digitales.

Data Mining y Data-Driven Journalism

2013 septiembre 3
por classora

El Data-Driven Journalism, a menudo abreviado como DDJ, es un proceso periodístico basado en el análisis y filtrado de grandes conjuntos de datos con el objetivo de generar una noticia inédita, o bien con la intención de respaldar, a través de hechos estadísticos, una serie de informaciones, hipótesis o conjeturas previas.

En los últimos años, el periodismo conducido por los datos está cobrando una gran importancia, especialmente en el contexto de la prensa digital. Esto se debe fundamentalmente a dos motivos: por un lado, al empuje de las tecnologías semánticas (muy asociadas a la comprensión del lenguaje natural por parte de las máquinas). Por otro lado, a las grandes revoluciones que afectan a los datos publicados en Internet, tanto desde un punto de vista técnico como desde un punto de vista filosófico: el Big Data, Linked Data y Open Data.

Esto ha provocado que se hayan editado cientos de libros sobre periodismo de datos, e incluso que se hayan creado unos premios a nivel mundial. Estos galardones, los Data Journalism Awards, están auspiciados por Google y promovidos por una institución internacional llamada GEN (Global Editors Network). Su objetivo consiste en reconocer públicamente el mérito de los periodistas e instituciones que han conseguidos los mejores trabajos de infografía, enriquecimiento de contenidos y DDJ.

Volumen de datos en Internet según su naturaleza

Como otros muchos proyectos, los trabajos de Data-Driven Journalism pueden llevarse a cabo, con un esfuerzo enorme, de manera manual. Esto implicaría que los promotores del proyecto recopilasen los datos y los analizasen pausadamente, buscando patrones guiados por su propia intuición, o bien que cruzasen todas las posibles combinaciones de variables para comprobar si existe o no algún tipo de correlación. En el fondo, así es como se llevaron a cabo la mayor parte de los proyectos de referencia del Data-Driven Journalism, apoyándose solo parcialmente en mayor o menor medida de algún tipo de soporte informático.

Afortunadamente, hoy en día, con las técnicas de Data Mining (Minería de datos) y con las tecnologías Big Data (soporte para grandes volúmenes de datos) cada vez resulta más sencillo y automático el descubrimiento de correlaciones y conclusiones inéditas entre la marabunta de datos desestructurados. ¿Cómo se consigue?

Arquitectura Data-Driven Jounalism basada en Data Mining

A continuación mostramos un esquema, muy simplificado y completamente genérico, que indica los pasos comunes que se suelen aplicar para conseguir proyectos exitosos de Data-Driven Journalism empleando las últimas tecnologías disponibles:

  • Recopilación de datos: se trata de decidir el conjunto de datos necesario, localizar las fuentes oportunas y analizar la cantidad y la calidad de la información disponible.
  • Integración de datos: casi siempre será necesario recurrir a más de una fuente de datos. Y en muchas ocasiones, los datos estarán desestructurados o no estarán integrados entre sí. Será necesario, por tanto, transformarlos para que tengan un formato homogéneo y se puedan cruzar. En definitiva, habrá que aplicar las valiosísimas tecnologías ETL (Extracción, Transformación y Carga) sobre el conjunto de datos inicial.
  • Operaciones data-mining: en este punto se trata de aplicar los algoritmos oportunos de minería de datos para conseguir detectar patrones o tendencias inéditas, así como llegar a conclusiones curiosas. En el siguiente apartado veremos algunas técnicas comunes.
  • Contraste de resultados: el descubrimiento de algunas tendencias puede hacernos llegar a suposiciones erróneas. Hay que recordar que correlación no implica causalidad. Será necesario comprobar empíricamente las hipótesis para validar los resultados obtenidos.

En cualquiera de estos pasos generales, si el volumen de datos a manejar es muy grande, estas operaciones pueden apoyarse en tecnologías Big Data, como los sistemas de archivos distribuidos, las bases de datos NoSQL o el software de procesado en cluster (MapReduce).

Ejemplo de trabajo sobre la deforestación en la Amazonia

Técnicas de Data Mining

Las técnicas de minería de datos no son más que algoritmos, más o menos sofisticados, que proceden de la inteligencia artificial y de la estadística. Según el objetivo del análisis, estas técnicas se clasifican en algoritmos supervisados o predictivos (capaces de extrapolar un dato desconocido a priori, a partir de otros datos conocidos) y algoritmos no supervisados (capaces de descubrir patrones y tendencias ocultas en los datos). Aunque en periodismo de datos los dos tipos de algoritmos son bienvenidos, en Data-Driven Journalism los algoritmos no supervisados suelen ser los más valorados. A continuación enumeramos las técnicas y herramientas de minería de datos más comunes:

  • Redes neuronales: son un paradigma de aprendizaje y procesamiento automático basado en la forma en que funciona el sistema nervioso de los seres humanos. Algunos ejemplos de red neuronal son el perceptrón, el perceptrón multicapa y las redes de Kohonen.
  • Regresión lineal: es una de las técnicas estadísticas más utilizadas para localizar relaciones entre datos. Es rápida y eficaz pero resulta insuficiente en espacios multidimensionales donde puedan surgir relaciones entre más de dos variables.
  • Árboles de decisión: dada una base de datos, se crean construcciones lógicas que sirven para representar y categorizar una serie de condiciones que ocurren de forma sucesiva y que van a permitir la resolución de un problema. Ejemplos: Algoritmos ID3 y C4.5.
  • Agrupamiento o clustering: se trata de agrupar vectores según criterios de distancia, de forma que al final se consiga que los vectores de entrada estén más cerca de aquellos que tengan características comunes. Ejemplos: Algoritmo K-means y algoritmo K-medoids.

Para finalizar este post introductorio, intentaremos mostrar algunos de los espectaculares resultados que se pueden conseguir en el periodismo de datos utilizando Data Mining.

Casos de éxito en Data-Driven Journalism

Uno de los casos más llamativos del Data-Driven Journalism fue el reportaje Do Not Harm (No hagan daño) llevado a cabo en el año 2010 por el diario Las Vegas Sun. Este reportaje analizaba la atención recibida por los pacientes en los distintos hospitales de la zona. Los periodistas del Sun examinaron más de 2.900.000 registros hospitalarios y llegaron a conclusiones impactantes:

  • Revelaron más de 3.600 lesiones, infecciones y errores quirúrgicos evitables.
  • Identificaron más de 300 casos en que los pacientes murieron por errores que pudieron haberse prevenido.

Web posterior del reportaje Do Not Harm, de Las Vegas Sun

El reportaje tuvo un impacto directo sobre la situación, ya que el gobierno de Nevada se vió obligado a modificar algunas leyes para mejorar la situación y acallar la voz de la ciudadanía.

Caso Wikileaks
Los periodistas Jonathan Stray y Julian Burgess realizaron un trabajo de investigación sobre los registros (logs) de la Guerra de Irak. Se trató de una llamativa incursión en el análisis de texto y la visualización, utilizando técnicas experimentales para comprender temas que vale la pena explorar, dentro de un gran conjunto de datos en formato texto.

Por medio de técnicas y algoritmos de analítica de textos, Jonathan y Julian crearon un método que muestra concentraciones de palabras clave contenidas en miles de informes del gobierno de Estados Unidos sobre la guerra de Irak, difundido por WikiLeaks, en un formato visual. El resultado es el que se muestra en la imagen siguiente.

Visualización de texto completo de los registros de la guerra de Irak, Associated Press

Más información

Como en otras ocasiones, si te interesa conocer más información sobre este tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Cuenta con Classora Technologies para estar informado sobre Data Mining y Data-Driven Journalism.

Tecnologías de Big Data: el ecosistema Hadoop

2013 agosto 30
por classora

Los grandes volúmenes de datos, generados por miles de millones de personas y por miles de millones de dispositivos, han encontrado en las tecnologías Big Data herramientas capaces de procesarlos e indagar sobre ellos para extraer información útil y conocimiento no evidente.

Las dificultades más habituales que nos encontrábamos ante cantidades demasiado grandes de datos se centraban en capturar, almacenar, buscar, analizar, compartir y visualizar la información subyacente. Las tecnologías Big Data se centran principalmente en proporcionar paliativos para estas dificultades, y para ello se apoyan en tres pilares:

  • Sistemas de archivos distribuidos: su objetivo principal es ofrecer alto rendimiento, escalabilidad y tolerancia a fallos para trabajar con infinidad de ficheros de manera simultánea. Algunos de estos sistemas ya los hemos visto: GFS (Google File System), HDFS (Hadoop File System), Amazon S3, IBM GPFS (General Parallel File System)… etc.
  • Bases de datos escalables: su objetivo es almacenar y procesar grandes volúmenes de datos con fiabilidad y bajos tiempos de respuesta. Como hemos visto en el post anterior, las bases de datos NoSQL basadas en clave-valor o en column-family han surgido especialmente para ello: Cassandra (Apache), Bigtable (Google), HBase (Hadoop)… etc.
  • Software de tratamiento masivo: su objetivo es conseguir repartir las necesidades computacionales para ejecutar un programa (realizar un cálculo… etc.) entre diversos servidores. En general, el macroalgoritmo de mayor éxito es el MapReduce, que no es más que una reedición del Divide y Vencerás (DYV), aplicado a computación distribuida.

MapReduce ha sido adoptado mundialmente con un desarrollo opensouce denominado Hadoop. Google fue la primera empresa en proponer el framework MapReduce. Años más tarde, Yahoo mandó a uno de sus trabajadores, Doug Cutting, analizar el artículo de Google y realizar una implementación. Tras el éxito obtenido y la liberalización del código generado se creó el proyecto Hadoop, que actualmente mantiene la fundación Apache.

Hadoop: la referencia en software libre

Apache Hadoop es una plataforma que permite el procesamiento de grandes volúmenes de datos a través de clusters, usando un modelo simple de programación. Además, su diseño permite pasar de pocos nodos a miles de nodos de forma ágil. Básicamente, Hadoop proporciona dos cosas: un sistema de archivos distribuido usando una arquitectura Master-Slave (HDFS, Hadoop Distributed File System) y un framework de MapReduce que permite dividir y paralelizar los cálculos complejos entre un número indefinido de ordenadores.

Logo de Hadoop

El modelo MapReduce de Hadoop simplifica el procesamiento en paralelo, abstrayéndonos de la complejidad que exite en los sistemas distribuidos. Básicamente las funciones map transforman un conjunto de datos a una lista de pares clave-valor, ordenando los elementos según su clave. La función reduce se utiliza para combinar los valores (con la misma clave o con un patrón común) en un único resultado.

Un programa MapReduce se suele conocer como Job, y la ejecución de un Job empieza cuando el cliente manda la configuración del Job al JobTracker. Esta configuración especifica las funciones Map, Combine (shuttle) y Reduce, además de la entrada y salida de los datos.

Alternativas a Hadoop

Hoy en día apenas existen alternativas importantes a Hadoop, si bien algunos foros se han hecho eco de que han encontrado cuellos de botella en su rendimiento, así como en la propuesta de paralelización MapReduce. En los siguientes enlaces puedes profundizar en esta información: Fatiga de Hadoop: alternativas emergentes y Alternativas a MapReduce y Hadoop.

Ecosistema de Hadoop en la fundación Apache

La fundación Apache dispone de un conjunto bastante amplio y variado de proyectos que se pueden integrar con Hadoop, o interactuar con él, para conseguir mayor potencia y capacidad de especialización en los proyectos de Big Data. A continuación enumeramos los más destacados.

Apache HBase: la base de datos
HBase es la base de datos oficial de Hadoop. Aunque Hadoop puede interactuar con otras bases de datos relacionales o NoSQL, como Cassandra o BigTable, HBase es el componente oficial/estándar NoSQL a utilizar. HBase está basada en BigTable (de Google) por lo que es una base de datos clave-valor orientada a columnas (column-family). Como hemos visto en el post anterior, eso quiere decir que no sigue el esquema relacional y no admite SQL. Sin embargo, es capaz de manejar grandes conjuntos de datos con operaciones simultáneas de lectura y escritura.

Apache Hive: el data warehouse
Hive es un sistema de Data Warehouse para Hadoop que facilita la agregación de los datos para realizar informes (reporting) y análisis de grandes datasets. Hive permite realizar consultas sobre los datos usando un lenguaje similar a SQL, llamado HiveQL. Además permite utilizar los tradicionales MapReduce cuando el rendimiento no es el correcto. Permite conexiones JDBC/ODBC, por lo que se integra fácilmente con otras herramientas de Business Intelligence.

Apache Sqoop: la herramienta de ETL
Sqoop significa SQL-to-Hadoop. Se trata de una herramienta diseñada para transferir de forma eficiente información entre Hadoop y bases de datos relacionales. Básicamente, Sqoop permite importar tablas individuales, o bases de datos enteras, a HDFS. Además, genera clases Java gracias a las cuales se puede interactuar fácilmente con los datos importados. Otra de sus funcionalidades principales es la importación desde bases de datos SQL directamente a Hive.

Apache Mahout: la plataforma de data mining
Mahout es una plataforma de aprendizaje autónomo y data mining construida sobre Hadoop. Uno de sus principales objetivos consiste en ayudar a descubrir patrones, de manera automática, en grandes volúmenes de datos. Conseguir detectar patrones reales y útiles en los datos sin intervención humana es uno de los grandes retos del Big Data, por eso Mahout todavía tiene diferentes clases sin implementar. En general, Mahout tiene algoritmos de recomendación, clustering y clasificación.

Apache Lucene: el motor de búsqueda
Lucene es un motor de búsqueda escrito en Java que permite indexar cualquier texto para luego buscar por palabras clave, o por cualquier otro criterio de búsqueda, en tiempo récord. Aunque en principio Lucene sólo funciona sobre texto plano, existen plugins que permiten la indexación y búsqueda de contenidos en documentos Word, PDF, XML o páginas HTML. El proyecto Apache Solr es una plataforma complementaria de la fundación Apache que aporta funcionalidades muy interesantes al software base de Lucene.

Apache UIMA: el framework para estructurar información
UIMA significa Unstructured Information Management Applications (Aplicaciones de gestión de información desestructurada). Se trata de un framework que permite analizar grandes volúmenes de datos no estructurados, como texto, vídeo, audio, etc… y obtener conocimiento que sea relevante para el usuario final. Por ejemplo a partir de un fichero plano es posible descubrir que entidades son personas, lugares u organizaciones. Apache UIMA tiene ciertas semejanzas con nuestro servicio Classora Media Support, aunque no está tan maduro ni especializado.

Apache Stanbol: la librería de componentes semánticos
Stanbol es un conjunto de librerías semánticas que permiten realizar operaciones de enriquecimiento de contenidos. En general, pueden utilizar el cruce con bases de conocimiento para complementar el texto de entrada con contenidos externos relevantes, como definiciones enciclopédicas, imágenes, vídeos o componentes de redes sociales. Un proyecto complementario a Apache Stanbol es Apache Jena, que permite construir aplicaciones utilizando los recursos de la web semántica, como las APIs de Linked Data.

Apache ZooKeeper: la herramienta de sincronización
Zookeeper significa el guardián del Zoo. Se trata de un proyecto que proporciona una infraestructura centralizada para servicios basados en cluster (es decir, que se ejecutan en paralelo) y que necesitan estar sincronizados. Por ejemplo, datos de configuración, jerarquías de nombres, detalles de procesado… etc. De esta forma, ZooKeeper ofrece un punto de acceso común a una gran variedad de objetos ampliamente utilizados en grandes entornos de cluster.

Apache Avro: el sistema de serialización
Avro es un sistema de serialización de datos, es decir, una plataforma para codificar y homogeneizar los datos de forma que se puedan transmitir de forma óptima por la red. Dado que los proyectos en Hadoop suelen mover cantidades descomunales de datos, es recomendable emplear serialización para procesarlos y almacenarlos. Esta serialización puede ser en texto plano, JSON, en formato binario… etc. Avro permite almacenar y leer datos fácilmente desde diferentes lenguajes de programación y está optimizado para minimizar espacio en disco.

Apache Pig: el helper para analizar grandes volúmenes de datos
Apache Pig es una plataforma que permite simplificar el análisis de grandes volúmenes de datos proporcionando un lenguaje de alto nivel. Su objetivo es que los usuarios de Hadoop se puedan centrar más en el análisis de los datos y menos en la creación de programas MapReduce. Su nombre viene de una analogía con los cerdos: al igual que los cerdos comen de todo, el lenguaje de programación Pig está pensado para poder trabajar en cualquier tipo de datos. Pig consta de dos componentes: el lenguaje PigLatin y su entorno de ejecución.

Apache Flume: el agregador de logs
Flume es un proyecto para capturar, analizar y monitorizar datos de ficheros de logs. En general, es capaz de agregar y mover grandes volúmenes de logs desde diferentes servidores a un repositorio central, simplificando así el proceso de recolección. También emplea las operaciones MapReduce de Hadoop para procesar los logs en paralelo. Otro proyecto de Apache muy parecido a Flume en cuanto a funcionalidad y objetivos es Apache Chukwa, la principal diferencia es que Chukwa está pensado para ser usado en batch.

Bases de datos NoSQL: Cassandra vs BigTable

2013 julio 30
por classora

Las bases de datos NoSQL son sistemas de almacenamiento de información que no cumplen con el modelo relacional propuesto por Codd a principios de los ochenta, y del que derivan la mayor parte de los RDBMS actuales. En general, el movimiento NoSQL ha surgido para intentar satisfacer necesidades que las bases de datos relacionales no conseguían, como manipular enormes cantidades de información (Big Data) de manera muy rápida.

Concretamente, las bases de datos NoSQL difieren con las bases de datos tradicionales (sistemas OLTP relacionales) en los siguientes puntos:

  • No usan SQL como lenguaje principal de consultas: una gran parte de las bases de datos NoSQL evitan este lenguaje estándar, o simplemente lo utilizan como lenguaje secundario o de apoyo. Por ejemplo, Cassandra utiliza CQL, MongoDB utiliza JSON, y BigTable utiliza GQL, una versión propia de Google basada en SQL. Por su parte, las bases de datos multidimensionales suelen utilizar MDX.
  • No requieren estructuras fijas como tablas para almacenar los datos: se trata de no imponer un esquema prefijado en forma de tablas y relaciones entre ellas, sino de ir más allá, permitiendo almacenar información en otros formatos como clave-valor (similar a tablas hash), objetos, cubos, documentos o grafos.
  • No suelen garantizar transacciones: las propiedades ACID (atomicidad, consistencia, aislamiento y durabilidad) son sacrificadas en las bases de datos NoSQL por una cuestión de rendimiento. En contraposición pueden implementar la llamada consistencia eventual, también conocida como BASE (Basically Available Soft-state Eventual Consistency) que garantiza que la base de datos es consistente sólo cuando no se hayan modificado los datos durante un lapso de tiempo suficientemente grande.
  • No suelen soportar operaciones JOIN: al disponer de un volumen de datos tan extremadamente grande suele resultar deseable evitar los JOIN. Esto se debe a que, cuando la operación no es la búsqueda de una clave, la sobrecarga puede llegar a ser tan costosa que no merece la pena (el servicio tiene que averiguar que nodos debe consultar, realizar consultas en paralelo y esperar las respuestas). Las soluciones más directas consisten en desnormalizar los datos, o bien realizar el JOIN mediante software, en la capa de aplicación.
  • Arquitectura distribuida: así como las bases de datos relacionales suelen centralizar los datos en grandes mainframes, o como mucho en esquemas master-slave (debido a la gran cantidad de bloqueos que se generarían al sincronizar un clúster de servidores), en el caso de las bases de datos NoSQL la información se suele compartir mediante mecanismos de tablas hash distribuidas (DHT) ya que en el fondo se asemejan, en muchos casos, a redes P2P.
  • Escalabilidad horizontal: como consecuencia directa de su arquitectura distribuida, las bases de datos NoSQL pueden escalar de manera flexible ante picos de tráfico o necesidades puntuales de procesamiento. Suelen funcionar bastante bien en hardware de bajo coste (PCs normales) y permiten añadir/retirar nuevas máquinas en caliente.

¿Cuándo utilizar una base de datos NoSQL? En general, cuando detectamos que una base de datos relacional, convenientemente optimizada, no responde adecuadamente a las necesidades de nuestro software. Por ejemplo, si pretendemos desarrollar una aplicación que requiera la lectura/escritura de cantidades gigantescas de datos y pueda dar servicio a millones de usuarios sin perder rendimiento, entonces debemos plantearnos el uso de una base de datos NoSQL. Las grandes redes sociales como Facebook y Twitter, o el propio Google, las utilizan como medio fundamental de almacenamiento de información.

Se puede utilizar una base de datos NoSQL para almacenar toda la información de una aplicación, aunque en la mayoría de los casos se recurre a sistemas mixtos que combinan las bases de datos relacionales (fácilmente manipulables e interrogables mediante SQL) con soluciones NoSQL para aquellas funcionalidades que requieren millones de consultas en tiempo real.

Tipos de bases de datos NoSQL

A continuación enumeramos los modelos de bases de datos NoSQL más populares. No son los únicos que existen, pero desde luego son los que más implantaciones y funcionalidades atesoran:

  • Bases de datos clave-valor: son probablemente el modelo de base de datos NoSQL más popular, representando así el buque insignia de este tipo de tecnologías. Cada pieza de información se obtiene a partir de una clave única. Es como manejar una sola tabla, muy grande y convenientemente indexada. Las bases de datos column-family son una variante que permite más de un valor (columna) por clave. Algunos ejemplos: Cassandra (Apache), BigTable (Google), Dynamo (Amazon), Voldemort (Linkedin), HBase (Hadoop) y Redis.
  • Bases de datos documentales: constituyen uno de las principales modelos dentro de las bases de datos NoSQL. Están diseñadas en torno a un concepto abstracto de documento. Los documentos se parecen, de algún modo, a registros, tuplas o filas en una base de datos relacional, pero son menos rígidos: no se les requiere ajustarse a un esquema estándar ni tener todos los mismos atributos o claves. Estas bases de datos permiten no sólo buscar por clave-valor, sino también por contenido del documento, respondiendo a queries más complejas. Algunos ejemplos: CouchDB, MongoDB, IBM Lotus Domino, Terrastore.
  • Bases de datos multidimensionales: como vimos en el post anterior, estas bases de datos se utilizan principalmente en data warehouses y datamarts, y son una variación del modelo relacional que utiliza cubos OLAP para organizar los datos y expresar las relaciones entre ellos. Esto les permite recuperar, filtrar y realizar cruces de ingentes cantidades de datos, con el fin de generar informes en tiempo récord. Algunos ejemplos: Oracle OLAP, OpenQM, Analysis Services (Microsoft), Mondrian (Pentaho).
  • Bases de datos orientadas a objetos: la información se representa mediante objetos, como los presentes en los lenguajes de programación orientada a objetos (POO): Java, C#, Visual Basic.NET, C++… etc. Un ODBMS (Object Database Management System) aporta funcionalidades de persistencia a estos lenguajes, consiguiendo que los objetos se almacenen en memoria/disco de forma transparente. Ejemplos: Zope, Gemstone, Db4o. Estas bases de datos han tenido un éxito moderado, siendo sustituidas en ocasiones por tecnologías ORM (Object-Relational Mapping) como Hibernate (Java), Propel o Doctrine (PHP).
  • Bases de datos en grafo: representan la información como nodos de un grafo y sus relaciones como las aristas del mismo, de manera que se pueda usar la teoría de grafos para recorrerla. Una base de datos orientada a grafos debe estar completamente normalizada, de forma que cada tabla tenga una sola columna y cada relación solamente dos. Con esto se consigue que cualquier cambio en la estructura de la información tenga efecto local. Algunos ejemplos: InfoGrid, InfiniteGraph, Neo4j, DEX, Virtuoso.

En los próximos apartados analizaremos por encima los orígenes y las características de dos referencias entre las bases de datos NoSQL clave-valor: Cassandra y BigTable.

Cassandra: la referencia Open Source de Apache

El desarrollo de Cassandra fue iniciado por Facebook para intentar solucionar los problemas de rendimiento en la comunicación entre usuarios (entre ellos, la inbox search). Estas características de Facebook combinaban un gran volumen de datos a almacenar con la necesidad de responder en tiempo real. Además, las perspectivas de crecimiento eran muy elevadas.

De esta forma, Cassandra nació con el objetivo de que el software y el hardware necesario para la búsqueda y comunicación entre usuarios fuese altamente escalable, horizontal y relativamente barato. Su éxito hizo que pronto asumiese más protagonismo dentro de la red social.

En el año 2008 Cassandra fue liberada por Facebook, pasando a ser de código abierto. Actualmente es la gente de Apache quien la mantiene. Esta característica hace de Cassandra una base de datos NoSQL realmente interesante, ya que aparte de combinar lo mejor de Dynamo (consistencia eventual) con lo mejor de BigTable (familias de columnas) es gratuita y de libre uso y distribución. Además, está desarrollada en Java, un lenguaje de programación cross-platform.

Las principales características del modelo de datos de Cassandra son las siguientes:

  • Una tabla de datos por cada instancia de Cassandra.
  • Cada familia de columnas puede contener o bien columnas o bien supercolumnas. Las supercolumnas son columnas son la agrupación de n-columnas.
  • Cada columna contiene elementos de la forma clave-valor-tiempo, donde el valor del campo tiempo es definible por el usuario.
  • Cada fila de una tabla puede tomar valores en columnas distintas de una familia de columnas que otra fila, es decir, puede (y suele) haber celdas vacías.

BigTable: la referencia de Google

Big Table es un SGBD que creó Google para gestionar sus bases de datos en el año 2004. Al igual que con Cassandra, el objetivo era conseguir un sistema que fuese fácilmente escalable, que funcionase de manera distribuida en multitud de máquinas y que fuese altamente eficiente.

Google puso en marcha este proyecto porque los sistemas de bases de datos tradicionales no le convencían para almacenar todos los datos que manejaban por aquel entonces. Además, la lentitud de estas bases de datos estaban suponiendo un cuello de botella en la velocidad de sus resultados.

En resumen, BigTable es un sistema que divide la información en columnas, y para almacenar la información utiliza tablas multidimensionales compuestas de celdas. Cada celda dispone de varias versiones para poder realizar un histórico de los valores que ha tomado a lo largo del tiempo. Podría entenderse como un mapa multidimensional dónde podemos ver las filas, las columnas y por último el tiempo. Un modelo muy parecido a Cassandra.

El sistema de archivos que utiliza BigTable es GFS (Google File System), que es un sistema de ficheros distribuido creado por Google bajo demanda (de hecho es un pilar tecnológico que le aporta ventajas competitivas). Una característica muy importante de este sistema es la compresión de los datos: BigTable utiliza dos algoritmos de compresión muy rápidos para reducir el tamaño de los archivos. Además, BigTable permite obtener parte de los datos sin tener que descomprimirlos en su totalidad. Esto le da cierta flexibilidad y velocidad frente a otros gestores de datos.

Como viene siendo habitual en Google, el API de BigTable es de acceso público, por lo que cualquier persona puede acceder al API y realizar cualquier prueba o desarrollo. No obstante, BigTable no se distribuye fuera de Google, aunque se puede acceder a ella a través de Google App Engine. El lenguaje de implantación que utiliza es el lenguaje C y/o lenguaje C++.

Si deseas o necesitas trabajar con alternativas a BigTable, la principal recomendación es HBase, un proyecto de software libre basado precisamente en BigTable, implementado en Java y soportado por la fundación Apache. Además, HBase forma parte del proyecto Hadoop.

Más información

Como en otras ocasiones, si te interesa conocer más información sobre este tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Cuenta con Classora Technologies para estar informado sobre bases de datos NoSQL.

Bases de datos OLAP vs OLTP

2013 junio 25
por classora

Las bases de datos multidimensionales son una variación del modelo relacional que utiliza cubos OLAP para organizar los datos y expresar las relaciones entre ellos. Las principales ventajas de este tipo de bases de datos son la versatilidad para cruzar información y la alta velocidad de respuesta. Esto las convierte en herramientas básicas para soluciones de Business Intelligence o de Big Data, donde el análisis de los datos resulta crucial.

En general, estamos acostumbrados a trabajar con bases de datos orientadas a transacciones (conocidas como bases de datos OLTP). A continuación veremos las principales diferencias con las bases de datos multidimensionales (conocidas como bases de datos OLAP).

OLTP – On-Line Transactional Processing

Los sistemas OLTP son bases de datos relacionales (RDBMS) orientadas a transacciones. Una transacción es una secuencia de operaciones llevada a cabo por una base de datos de manera atómica. Las operaciones pueden ser de cuatro tipos diferentes: SELECT, INSERT, DELETE y UPDATE. Al tratarse de un proceso atómico, cada transacción solo tiene dos posibles finales: commit (si se han llevado a cabo correctamente todas las operaciones) o rollback (cuando una operación de la secuencia ha fallado, en cuyo caso hay que deshacer los cambios producidos por el resto de las operaciones de la transacción y alertar del error). Las transacciones son el pilar de prácticamente cualquier programa de gestión o página web del mundo. Su necesidad se ve muy clara, por ejemplo, en el sector de la banca.

Garantizando las transacciones: las características ACID
Para que una base de datos OLTP pueda asegurar las transacciones es necesario que sea ACID compliant. ACID es un acrónimo de Atomicity, Consistency, Isolation and Durability:

  • Atomicidad: asegura que la operación se ha realizado correcta y completamente, de forma que no pueda quedar a medias en caso de que surja cualquier error.
  • Consistencia: asegura la integridad de la base de datos, es decir, que solo se ejecutan aquellas operaciones que no van a romper las reglas, restricciones y claves foráneas. La propiedad de consistencia sostiene que cualquier transacción llevará a la base de datos desde un estado válido a otro también válido.
  • Aislamiento: asegura que dos transacciones que afectan a la misma información (tabla, fila o celda) son independientes y no generan errores ni deadlocks. Existen cuatro posibles niveles de aislamiento: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READS y SERIALIZABLE, en función del tipo de bloqueos que se crean para proteger la información.
  • Durabilidad: asegura que una vez realizada la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema. Será almacenada en disco, no solo en memoria.

Propiedades de las bases de datos OLTP
Los sistemas OLTP son la versión tradicional de una base de datos: se diseñan utilizando un modelo entidad-relación, se implementan en los motores típicos de base de datos (Oracle, SQLServer, MySQL… etc.) y dan soporte a la mayor parte del software del mercado:

  • Optimizadas para lecturas y escrituras concurrentes: gracias a las propiedades ACID, el acceso a los datos está adaptado para tareas frecuentes de lectura y escritura.
  • Organizadas según la capa de aplicación: las tablas y los datos se estructuran según el software que los maneja: programa de gestión a medida, ERP, CRM, BPM… etc.
  • Adaptadas a cada empresa o departamento: dado que en muchas ocasiones se utiliza software no integrado, los formatos de los datos no suelen ser uniformes en los diferentes departamentos. Es común la falta de compatibilidad y la existencia de islas de datos.
  • Consultas realizadas en SQL, modificaciones en DML: el SQL (Standard Query Language) es el lenguaje de consulta universal para leer bases de datos relacionales (cláusula SELECT), mientras que DML (Data Manipulation Language) es el estándar para realizar modificaciones (cláusulas INSERT, UPDATE y DELETE).
  • Gestión de datos históricos inexistente: el historial de cambios suele limitarse a datos actuales o recientes. Salvo sistemas de backup, o que el software tenga una funcionalidad específica para ello, no se suelen manejar valores históricos para cada campo.

OLAP: On-Line Analytical Processing

Los sistemas OLAP son bases de datos orientadas al procesamiento analítico. Este análisis suele implicar, generalmente, la lectura de grandes cantidades de datos para llegar a extraer algún tipo de información útil: tendencias de ventas, patrones de comportamiento de los consumidores, elaboración de informes complejos… etc.

Representando la información: los cubos OLAP
Un cubo OLAP no es más que un vector de varias dimensiones. Desde un punto de vista relacional, puede verse como una tabla de hechos (fact table) que tiene dos tipos de columnas:

  • Indicadores: también denominados métricas o ratios, son los valores numéricos con los que se opera. Por ejemplo: nº de clientes, nº de proveedores, importe de las ventas, nº de ventas, importe de las compras, nº de compras… etc.
  • Dimensiones: son las características por las que se pueden filtrar y cruzar los indicadores. Por ejemplo: tiempo (fijando un determinado día, mes o año), geografía (fijando un determinado país, región o ciudad), proveedor, cliente, modo de pago… etc.

Las columnas correspondientes a las dimensiones tienen claves foráneas a tablas de dimensión, que generalmente son tablas de maestros con clave-valor (esquema en estrella) o tablas organizadas en jerarquías (esquema en copo de nieve) como: ciudad – provincia – país.

En general suele resultar necesario dimensionar la volumetría de los cubos para conseguir que generen los informes deseados, y monitorizar su tamaño para garantizar que los resultados se obtienen en el tiempo esperado. En este sentido suele resultar fundamental tener en cuenta dos características básicas: la cardinalidad del cubo, posibles combinaciones de todos los valores de todas las dimensiones, y la granularidad del cubo, nivel de detalle máximo de los datos, o lo que es lo mismo, nivel de agregación mínimo de la información.

Propiedades de las bases de datos OLAP
Así como los sistemas OLTP son típicos para bases de datos convencionales y data warehouses, los sistemas OLAP son propios de los datamarts.

  • Optimizadas para operaciones de lectura: dado que la acción más común es la consulta, estas bases de datos disponen de valores agregados y resultados precalculados que les permiten responder en tiempo récord. Evitar las restricciones ACID les da agilidad.
  • Organizadas según las necesidades analíticas: los datos están estructurados según las áreas de negocio, y los formatos de los datos están integrados de manera uniforme en toda la organización. Se busca evitar islas de datos.
  • Asíncronas: no siempre se actualizan en tiempo real, sino que se suelen alimentar con información procedente de las bases de datos relacionales mediante un proceso de extracción, transformación y carga (ETL).
  • Consultas realizadas en MDX: este lenguaje, MDX (MultiDimensional eXpressions) fue desarrollado inicialmente por Microsoft y adoptado posteriormente como estándar para leer cubos OLAP. Un cliente puede manipular el cubo de distintas formas: rotarlo, rebanarlo cortarlo en dados… etc.
  • Gestión de datos históricos a largo plazo: una de las exigencias analíticas consiste en realizar estudios de evolución a lo largo del tiempo, esto requiere que estas bases de datos mantengan un histórico a largo plazo, normalmente no inferior a cinco años.

Tipos de persistencia OLAP
En los orígenes de la tecnología OLAP la mayor parte de las compañías asumió que la única solución para una aplicación OLAP era un modelo de almacenamiento no relacional. Sin embargo, otras compañías no tardaron en descubrir que a través del uso de estructuras de base de datos (esquemas de estrella y de copo de nieve), índices y el almacenamiento de agregados, se podrían utilizar sistemas de administración de bases de datos relacionales (RDBMS) para el OLAP.

Estos vendedores llamaron a esta tecnología OLAP relacional (ROLAP). En consecuencia, las primeras compañías adoptaron entonces el término OLAP multidimensional (MOLAP). Ambos conceptos, MOLAP y ROLAP, se explican con más detalle en los siguientes párrafos. Las implementaciones MOLAP normalmente tienen mejor rendimiento y velocidad que la tecnología ROLAP, pero tienen problemas de escalabilidad. Por otro lado, las implementaciones ROLAP son más escalables y son frecuentemente atractivas a los clientes debido a que aprovechan las inversiones en tecnologías de bases de datos relacionales preexistentes.

Sistemas MOLAP: la información procedente de los sistemas operacionales se carga en el sistema MOLAP mediante una serie de rutinas por lotes. Una vez cargado el dato elemental en la Base de Datos multidimensional (MDDB), se realizan una serie de cálculos para obtener los datos agregados, a través de las dimensiones de negocio, rellenando la estructura MDDB.

Tras rellenar esta estructura, se generan unos índices y algoritmos de tablas hash para mejorar los tiempos de accesos a las consultas. Una vez que el proceso de compilación se ha acabado, la MDDB está lista para su uso. Los usuarios solicitan informes a través de la interfaz, y la lógica de aplicación de la MDDB obtiene el dato.

La arquitectura MOLAP requiere unos cálculos intensivos de compilación. Lee de datos precompilados, y tiene capacidades limitadas de crear agregaciones dinámicamente o de hallar ratios que no se hayan precalculados y almacenados previamente.

Sistemas ROLAP: los usuarios ejecutan sus análisis multidimensionales, a través del motor ROLAP, que transforma dinámicamente sus consultas a consultas SQL. Se ejecutan estas consultas SQL en las bases de datos relacionales, y sus resultados se relacionan mediante tablas cruzadas y conjuntos multidimensionales para devolver los resultados a los usuarios.

La arquitectura ROLAP es capaz de usar datos precalculados si estos están disponibles, o de generar dinámicamente los resultados desde los datos elementales si es preciso. Esta arquitectura accede directamente a los datos del datawarehouse, y soporta técnicas de optimización de accesos para acelerar las consultas. Estas optimizaciones son, entre otras, particionado de los datos a nivel de aplicación, soporte a la desnormalización y joins múltiples.

Sistemas HOLAP: un desarrollo un poco más reciente ha sido la solución OLAP híbrida (HOLAP), la cual combina las arquitecturas ROLAP y MOLAP para brindar una solución con las mejores características de ambas: desempeño superior y gran escalabilidad. Un tipo de HOLAP mantiene los registros de detalle (los volúmenes más grandes) en la base de datos relacional, mientras que mantiene las agregaciones en un almacén MOLAP separado.

Más información

Como en otras ocasiones, si te interesa conocer más información sobre este tema no dudes en contactar con nosotros para que te enviemos documentación adicional. Cuenta con Classora Technologies para estar informado sobre bases de datos multidimensionales.

Real Madrid vs FC Barcelona: análisis comparativo desde el principio de la historia

2013 mayo 13
por classora

Hoy vamos a escribir un post de análisis de datos, centrándonos en esta ocasión en los que son probablemente los dos equipos más laureados de la historia del fútbol: Real Madrid y FC Barcelona. Pero lo haremos desde una perspectiva diferente.

Cada día corren ríos de tinta en los principales medios deportivos que repasan la actualidad de ambos clubes. De modo que nosotros enfocaremos el análisis desde un punto de vista estrictamente imparcial e histórico. Pero no nos limitaremos a dar el nº final de puntos conseguido por cada equipo, sino que también facilitaremos herramientas para filtrar los datos por ventanas de tiempo, de tal manera que cada uno pueda sacar sus propias conclusiones. Y si lo desea, comparar los datos con los de otros equipos.

La hipótesis inicial es clara: el Real Madrid es el mejor equipo de la historia, mientras que el FC Barcelona es el mejor equipo de los últimos años. Pero… ¿te atreves a adentrarte en los datos?

Análisis Real Madrid - FC Barcelona a lo largo de la historia

Número de ligas ganadas

En el valor absoluto de este indicador existe una clara ventaja histórica por parte del Real Madrid. Como se muestra en la gráfica de evolución inferior, el equipo blanco consiguió superar al Barça y consolidar esa ventaja durante las décadas de 1960 y 1970. A partir de 1980 ambos equipos se igualaron de tal forma que la liga la conquistaba uno u otro. La única excepción visible en la gráfica fue a principios de los ochenta, con el dominio impuesto por los equipos vascos en la LFP. En 1950 el FC Barcelona tenía cuatro ligas más que el Madrid (máxima diferencia). Por su parte, en 1990 el Madrid tenía 15 ligas más que en FC Barcelona (máxima diferencia).


Para que puedas jugar con estos datos:
Ranking de equipos con más ligas »
Gráfica de evolución de equipos con más ligas »

Liga de fútbol (LFP). Clasificación histórica

Para tener una perspectiva más detallada de lo que sucede en la liga española se puede recurrir a la clasificación histórica. Esta clasificación suma los puntos conseguidos por cada equipo en cada temporada de primera división. Si un año un club desciende a segunda división, simplemente no puntúa. Los únicos equipos que se han mantenido siempre en primera división desde el inicio de la LFP son: Real Madrid, FC Barcelona y Athletic de Bilbao. Según este indicador, merengues y azulgranas están mucho más empatados entre sí. Y no solo eso, sino que le sacan mucha distancia al tercer clasificado: el Valencia. Esto se debe a que prácticamente en todas las temporadas ambos equipos han conseguido estar en el top 3 de la tabla. De hecho, el Real Madrid ha ocupado el segundo puesto en 21 ocasiones, y el tercer puesto en 7 ocasiones. Por su parte, el Barça ha ocupado en segundo puesto en 23 ocasiones, y el tercer puesto en 12 ocasiones.


Para que puedas jugar con estos datos:
Clasificación histórica de la LFP »
Gráfica de evolución de la clasificación histórica »

Copas del Rey ganadas

En el caso de la competición copera se cambian las tornas: el equipo que más títulos ha ganado en la historia es el FC Barcelona. Y lo curioso es que el Real Madrid no es el segundo del ranking, sino el tercero. Esto se debe al Athletic de Bilbao. El equipo vasco fue el club con más copas del Rey desde el inicio de la competición, en 1901, hasta el año 1997, en el que fue igualado por el Barça. Sobre la Copa del Rey cabe destacar (como se puede observar en la gráfica inferior) como parece que está siendo bastante ignorada por merengues y azulgranas durante los últimos años (la gráfica deja de crecer para ambos clubes). Es por ello que, a partir de mediados de los años 90, la copa del Rey empezó a ser asequible para el resto de equipos.


Para que puedas jugar con estos datos:
Ranking de equipos con más copas del Rey »
Gráfica de evolución de los equipos con más copas del Rey »

Champions League ganadas

Una vez más pasamos a manejar un indicador futbolístico dominado por el Real Madrid. Al igual que en la LFP, el equipo merengue consiguió su ventaja histórica sobre el FC Barcelona y sobre los demás titanes del fútbol europeo (Bayern, Manchester, Milan, Liverpool… etc.) durante los años 50 y 60. A partir de 1966 el Real Madrid sufrió una sequía de 30 años en esta competición, hasta que en 1997 consiguió volver a codearse con los grandes levantando la séptima copa. A día de hoy, con nueve títulos, es simplemente el equipo más laureado de Europa. Por su parte, al FC Barcelona se le resistió su primera Champions durante décadas, hasta que en 1991 consiguió romper la racha. Sin embargo, el milagro azulgrana despierta de nuevo a partir de 2005, cuando el equipo toma las riendas del fútbol europeo y encarrila tres nuevos títulos en apenas seis años.


Para que puedas jugar con estos datos:
Ranking de equipos con más Champions Leagues »
Gráfica de evolución de los equipos con más Champions Leagues »