Almacenamiento de datos estructurados con Big Data

Cómo puede ayudar Big Data a extender su infraestructura actual de administración y análisis de datos

Las tecnologías basadas en Big Data han revolucionado la forma en que se almacenan, administran y analizan los datos. Conforme este fenómeno evoluciona, se han desarrollado casos de uso más allá de los relacionados con información originada en internet y datos no estructurados. Uno de los casos de uso con mayor potencial para muchas organizaciones es la administración y el análisis de datos estructurados. Este caso de uso abre la posibilidad de extender la infraestructura actual de Data Warehouses con nuevas capacidades de Big Data para optimizar las soluciones analíticas y reducir costos.

Alexander Ambriz Rivas, M. Sc., Client Technical Professional, IBM México

Alexander AmbrizAlexander Ambriz Rivas es especialista técnico para el área de Information Management de IBM Software Group México, desde enero de 2010. En este rol, Alexander se encarga de apoyar técnicamente en labores de preventa para soluciones de Master Data Management (MDM) y Big Data. Alexander cuenta con 12 años de experiencia en el desarrollo de sistemas de software empresariales. Antes de unirse a IBM, Alexander participó en proyectos de software basados en Java Enterprise Edition con Multipack, Banco Azteca, Metlife y Telcel entre otros. Además de las áreas de MDM y Big Data, Alexander está interesado en temas de Arquitectura Orientada a Servicios (SOA) y tecnologías Java. Alexander es Ingeniero en Computación por la Universidad Nacional Autónoma de México y Maestro en Ciencias con especialidad en Tecnología de Software, por la Hochschule für Technik Stuttgart, Alemania.



30-09-2013

Datos estructurados en Big Data

La característica de "variedad" utilizada para definir Big Data lleva muchas veces a pensar que solo es apropiado para el almacenamiento y análisis de información no estructurada. La expresión "información no-estructurada" se refiere típicamente a aquellos datos que no están organizados bajo el Modelo de Datos Relacional, definido por Edgar Codd en 1970. Algunos ejemplos comunes de información no estructurada son los archivos de texto, documentos (PDF, Word), imágenes, audio y video, entre otros.

No obstante, casi desde su concepción, se consideró el uso de Big Data para almacenar y analizar datos estructurados. Google fue el primero en implementar una tecnología con tal fin: Bigtable. Bigtable se utiliza para guardar datos de varios proyectos en Google, como por ejemplo los índices de búsqueda Google Earth y Google Finance. Asimismo, es capaz de escalar hasta petabytes, soporta desde procesamiento batch hasta acceso en tiempo real con baja latencia. Bigtable utiliza Google File System (precursor de Hadoop Distributed File System) para almacenar datos y bitácoras.

Bigtable es un "mapa ordenado, diperso, distribuido y persistente". El mapa se indexa por llaves de renglón, de columna y timestamp.

La Figura 1 muestra un ejemplo de cómo se puede usar Bigtable para almacenar páginas web, junto con referencias a las mismas. La llave de renglón es la URL (invertida) de la página en cuestión ("com.ibm.www"). Bigtable maneja el concepto de "familias de columnas", que son agrupaciones de llaves de columnas. Para este ejemplo, estas familias son contents y anchor. La familia anchor agrupa las llaves de columnas "asmarterplanet.com" y "www.developerworks.com". Una vez creada la familia de columnas, es posible usar cualquier llave para esa familia. En general, un buen diseño consiste en relativamente pocas familias de columnas que cambian poco una vez definidas. No obstante, el número de columnas no tiene límite. Finalmente, toda celda de la tabla mantiene un timestamp que sirve para guardar diferentes versiones del contenido a lo largo del tiempo.

Figura 1. Fragmento de una tabla que guarda páginas web y referencias
Alternative text for image

Para continuar con el ejemplo, si se quisiera recuperar el contenido de la página www.ibm.com en el instante t1, las llaves que son necesarias de referenciar son:

(row:"com.ibm.www", column:"contents:", time:"t1") -> "[html]..."

Para recuperar cómo se hace referencia a la página desde el sitio www.developerworks.com, en el mismo instante t1, se referenciaría de la siguiente forma:

(row:"com.ibm.www", column:"anchor:www.developerworks.com", time:"t1") -> "www.ibm.com"

La API de Bigtable pemite crear tablas y familias de columnas, así como manipular metadatos. Las aplicaciones cliente pueden escribir o borrar valores de una tabla, buscar valores en un renglón particular o bien iterar sobre un subconjunto de datos en una tabla. Bigtable también soporta transacciones a nivel renglón.

Bigtable está diseñado para escalar a nivel de petabytes distribuidos a lo largo de miles de servidores "commodity". Bigtable comprime los datos a nivel familia de columna, de manera similar a como lo haría una base de datos relacional organizada por columnas.

En muchos sentidos Bigtable es similar a un manejador relacional de base de datos. Sin embargo, Bigtable no soporta el modelo relacional en su totalidad. ¿Por qué, entonces, fue necesario crear Bigtable? Además de la necesidad de escalar a niveles de petabytes, provee un modelo de datos simple que puede controlarse dinámicamente. Esto es especialmente útil cuando se maneja información sin esquema o con esquemas que cambien rápidamente (algo muy usual en el mundo de Big Data). El modelo de Bigtable permite también acceso aleatorio en tiempo real para lectura y escritura, una capacidad originalmente no considerada en las soluciones de Big Data.

Si bien Bigtable es una tecnología propietaria de Google, fue precursor de tecnologías open source como HBase y Cassandra. Estas implementaciones de Bigtable son solo un par de ejemplos de lo que actualmente se conoce como tecnologías NoSQL. Ambas han probado su escalabilidad en aplicaciones ampliamente conocidas: Yahoo! utiliza HBase para detectar documentos (páginas web) potencialmente duplicadas; Cassandra es utilizado por sitios como Netflix, eBay y Twitter entre otros.


NoSQL

No existe una definición universalmente aceptada de"NoSQL. En general, se refiere a aquellas bases de datos con modelos de consistencia más laxos que los establecidos por las bases de datos relacionales, con el fin de tener una mejor escalabilidad al trabajar con altos volúmenes de información cuando la naturaleza de los datos no requiere un modelo relacional. En un principio, el término se malinterpretó como si el movimiento NoSQL tuviera por objetivo el reemplazar eventualmente a los manejadores de bases de datos relacionales. A pesar de los beneficios de las bases de datos NoSQL, también tienen desventajas respecto a las bases de datos relacionales, por ejemplo:

  • Poco soporte a JOINs: Los JOINs en general son caros desde el punto de vista de procesamiento. Por eso la mayoría de las bases de datos NoSQL no implementan JOINs, y así logran un mejor desempeño. Para solventar ese problema en una base de datos NoSQL, típicamente se duplican ciertos datos, lo cual, dependiendo del tipo de solución puede ser un inconveniente.
  • Dificultad para manejo de transacciones: Las bases de datos NoSQL tienen pobre soporte a transacciones, a lo mucho, las soportan a nivel de "registro" en la mayoría de los casos. Tampoco soportan, en general, transacciones que involucren múltiples entidades. Esto es un problema en el caso de aplicaciones que necesiten mantener la consistencia a lo largo de grupos de registros y múltiples entidades.
  • Nula estandarización: Cada base de datos NoSQL tiene su propio lenguaje y/o API para acceder y manipular los datos. En muchos casos solo se proporcionan APIs que requieren de programación con el uso de lenguajes imperativos. En contraposición, las bases de datos relacionales utilizan el lenguaje estándar SQL, que es declarativo, ampliamente conocido y de rápido aprendizaje.
  • La flexibilidad del esquema puede ser un problema: En "malas manos" la flexibilidad en el esquema puede hacer que se lleven a cabo cambios con poco control y a la duplicación de atributos.

Al considerar lo anterior, en el caso de aplicaciones que utilizan transacciones complejas y tienen un modelo de datos claramente relacional, no es una buena opción una base de datos NoSQL. Un ejemplo típico de una aplicación para la que una base de datos relacional aún es la mejor opción es un "Core Banking System".

Una definición más apropiada de NoSQL es "Not Only SQL", es decir, no se trata de descartar el paradigma del modelo relacional, sino de reconocer que existen diferencias en la naturaleza de la información y que, de acuerdo a las características de la misma, así como al uso que se haga de ella, es preferible un paradigma o el otro.

Ahora bien, ¿no sería muy bueno tener "lo mejor de dos mundos" en una misma solución? Conforme han evolucionado las soluciones de Big Data se ha buscado emular los beneficios de las bases de datos relacionales al mismo tiempo que se logra escalabilidad a niveles de petabytes en clústers formados por nodos de hardware "commodity". Hive y BigSQL son tecnologías que abordan el problema de implementar (al menos hasta cierto nivel) una base de datos relacional utilizando el paradigma de Big Data.


Hive y BigSQL

Apache Hive es un software de Data Warehouse basado en Hadoop. Tiene funciones para sumarizar datos, ejecutar consultas ad-hoc y analizar grandes conjuntos de datos almacenados en Hadoop. Provee un lenguaje de consulta semejante a SQL, conocido como HiveQL. Internamente, HiveQL utiliza MapReduce para ejecutar las consultas. HiveQL es también extensible, en caso de ser necesario un análisis no incluido en el lenguaje, es posible conectar trabajos de MapReduce que implementen la funcionalidad deseada. Hive puede acceder directamente a archivos almacenados en HDFS o, incluso, a "tablas" en HBase.

Si bien es una aproximación a implementar el modelo relacional sobre Hadoop, Hive comparte algunas limitantes con las soluciones NoSQL discutidas anteriormente:

  • HiveQL no cumple al 100% con el estándar de ANSI SQL.
  • No está diseñado para cargas OLTP.
  • No es apropiado para queries que requieran una respuesta con baja latencia.
  • No soporta transacciones a nivel de registro.

A cambio, Hive privilegia la eficiencia en el procesamiento por lotes de trabajos analíticos sobre grandes conjuntos de datos, escalabilidad, extensibilidad y bajo acoplamiento con los formatos de entrada de información. Hive proporciona conectores JDBC y ODBC, aunque con limitaciones.

IBM InfoSphere BigInsights 2.1 introduce una tecnología conocida como BigSQL, una interfaz nativa de acceso a datos que cumple con el estándar ANSI SQL 92+. BigSQL soporta multitud de fuentes de datos: tablas de HBase, Hive e incluso archivos planos (CSV, JSON). Los conectores JDBC y ODBC proporcionados para BigSQL cumplen completamente los estándares correspondientes.

BigSQL incorpora un mecanismo de optimización para ejecutar queries con baja latencia: en caso de queries simples BigSQL no utiliza MapReduce, sino que accede a los datos directamente; los queries complejos que no requieren baja latencia (por ejemplo para fines analíticos) continúan ejecutándose vía MapReduce.

Claramente BigSQL es un avance importante en el intento de llevar las ventajas del modelo relacional a las soluciones basadas en Hadoop, especificamente para implementar Data Warehouses.

Si buena parte de las organizaciones han hecho fuertes inversiones en Data Warehouses basados desde un origen en el paradigma relacional (incluso mediante "appliances" que simplifican la implementación del Data Warehouse), ¿qué caso tiene incluir estas capacidades en una solución basada en Hadoop?

Si bien tratar de sustituir por completo un Data Warehouse existente con una solución basada en Hadoop podría ser caro y/o riesgoso, lo que sí tiene caso es considerar el uso de Hadoop para extender un Data Warehouse existente, tal como se describe a continuación.


Extensión al Data Warehouse

Muchos Data Warehouses adolecen de un mal rendimiento debido a que se acercan al límite de cantidad de información que pueden almacenar. Mucha de ella consiste en datos fríos, es decir, aquellos que son accedidos con poca frecuencia. Para colmo, almacenar toda esa información impacta en altos costos de licenciamiento y hardware. Una posible solución consiste en "purgar" los datos fríos, dejándolos respaldados fuera del Data Warehouse. Sin embargo, esa aproximación tiene el inconveniente de que, en caso de necesitarse los datos para algún análisis en particular, sería necesario restaurarlos del respaldo, lo cual retrasaría el análisis y recargaría el Data Warehouse con los datos fríos, que posteriormente tendrían que volver a archivarse.

Una solución basada en Hadoop puede utilizarse para "descargar" ahí los datos fríos del Data Warehouse. A diferencia de una solución de respaldo, los datos almacenados en Hadoop podrían accederse vía SQL (en el caso de utilizar BigSQL provisto por BigInsights 2.1 ), lo cual mantiene disponibles todos los datos en cualquier momento. Típicamente, el costo por registro es menor en una solución basada en Hadoop que en un Data Warehouse tradicional así que, este tipo de solución en general implica costos menores en licenciamiento respecto a adquirir más licencias para un Data Warehouse existente. Finalmente, en caso de necesitarse más almacenamiento para el componente de Hadoop, es posible extenderlo usando nodos de hardware "commodity", generalmente más baratos que el hardware para Data Warehouse.

La Figura 2 esquematiza esta solución con base en productos IBM. La interfaz de BigSQL de InfoSphere BigInsights permite mover los datos fríos del Data Warehouse (PureData for Analytics) a Hadoop. Cognos BI Server puede acceder a ambas fuentes mediante SQL, teniendo así disponibles todos los datos para fines analíticos.

Figura 2. Extensión a un Data Warehouse utilizando el stack de productos IBM
Alternative text for image

Conclusiones

Conforme las soluciones de Big Data basadas en Hadoop, se han descubierto casos de uso que van más allá de las aplicaciones originalmente consideradas para Big Data. Del procesamiento de datos no-estructurados se ha evolucionado a la capacidad de administrar datos estructurados en soluciones basadas en Hadoop. Uno de los casos de uso que mejor demuestran la sinergia que se puede lograr al unir el paradigma del modelo relacional con Hadoop es la extensión a Data Warehouses, en particular para optimizar el almacenamiento y análisis de los datos accedidos con poca frecuencia.


Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=Information mgmt,
ArticleID=946954
ArticleTitle=Almacenamiento de datos estructurados con Big Data
publish-date=09302013