No siempre ocurre que una entrevista tenga alto nivel conceptual y sea al mismo tiempo amena. Es lo que ocurrió con la conversación mantenida con Stephen Brobst, CTO de Teradata. Lectura recomendada. Brobst es de los que piensan que la expresión Big Data es un hallazgo eficaz pero merece reparos en lo que respecta a la comprensión de los problemas que trata de resolver. Se tiende a pensar más en el volumen que en la diversidad de los datos, pero es de reconocer que las herramientas de análisis de datos de alta diversidad está todavía en sus comienzos. En todo momento, el diálogo se centró en la tecnología, no en los productos del catálogo de Teradata, y sólo tangencialmente en su estrategia.

Stephen Brobst

Toda la industria de las TI parece girar en torno a unas pocas categorías que parecen marcar la agenda: Big Data, Cloud e Internet de las Cosas son tres de los más notorios. ¿Cómo ve usted la relación entre ellos?

No sólo están relacionados sino que, en mi opinión, IoT encarna la próxima generación de Big Data. Porque Big Data es un concepto que nombra la transición desde el análisis de las transacciones hacia el análisis de las interacciones. Por tanto, cuando decimos big, estamos hablando de bigness, indicamos el volumen de los datos, que no es realmente lo importante. Se trata de diferentes fuentes de datos, en distintos formatos. Los datos de las transacciones casi siempre vienen en un formato determinado por la fuente, como el sistema de un banco o un sistema de facturación, o de un log generado por un punto de venta en un retailer, esto es lo que quiero decir.

¿O sea que lo erróneo de la expresión está en el adjetivo big?

No es que sea erróneo, pero lo relevante es la diversidad. Tenga en cuenta que, por definición, los datos generados por interacciones son más voluminosos que los transaccionales, por lo que pienso que se ha puesto el foco en el factor equivocado: los big data de las interacciones con los clientes de una compañía pequeña pueden ser más pequeños que los… small data de una gran compañía. ¿Me explico? Big Data no implica que una compañía es grande, puede significar sólo que ha capturado un gran volumen de interacciones, con independencia del tamaño de la empresa. Y, sin embargo, hemos convenido en llamarlo Big Data… por ahora.

¿Por que son diferentes unos datos de otros?

Porque los datos generados por interacciones tienen una estructura diferente a los datos transaccionales. Son weblogs, tráfico de los social media… un texto en Twitter o un post en Facebook […] a lo que quiero ir: en IoT se trata de interacciones entre objetos sobre Internet. Pueden ser vehículos, o mejor aún la electrónica del hogar… cómo los individuos interactúan con la red eléctrica para que su consumo de energía sea más eficiente controlando la temperatura desde un smartphone. Para que las cosas estén conectadas entre sí, el requisito es que esos datos se recopilen, de otro modo yo no podría controlar mi gasto de electricidad o mi consumo de agua. Ya he dicho que para mí IoT es la próxima generación de Big Data.

De manera que el valor no está en el tamaño sino en la experiencia…

¡Exacto! Así deberíamos pensar en el problema. Las transacciones nos ayudan a entender el valor del cliente; las interacciones nos ayudan a entender la experiencia del cliente, y esto no tiene que ver con el tamaño de los datos. El punto clave es que estamos viviendo una transición de las transacciones a las interacciones.

Vale, pero la mayoría de los clientes de Big Data, las empresas, tienen un legacy de datos de estructura tradicional… ¿son útiles?, ¿qué hacer con ellos?

Son absolutamente útiles. Es más, creo que un error que se comete es minimizar su utilidad diciendo ´bah, son sólo datos transaccionales`. De hecho la densidad del valor de esos datos es más alta que la de lo que ahora llamamos Big Data: la comprensión que obtenemos de los datos transaccionales puede ser de altísima densidad… y puede que tuviéramos que analizar cientos de miles de logs para obtener el mismo valor que reside en el registro de una transacción. Y la realidad es que necesitamos ambos: los datos de interacciones no sustituyen los datos de las transacciones, los aumentan, nos ayudan a entender el valor de un cliente en el contexto de la experiencia. Por eso es un tremendo error sacrificar los datos de estructura tradicional porque se piensa que van a ser reemplazados con Big Data; me consta que hay gente que lo está haciendo. Pierden la oportunidad de combinarlos y obtener más valor del que podrán obtener por separado.

Al mismo tiempo, hay una evolución de los conceptos de base de datos: hay alternativas a las relacionales, incluso una batalla entre alternativas. La irrupción de Hadoop, la discusión sobre SQL y NoSQL […] ¿Cuál es su visión?

Vengo del Silicon Valley, y sé muy bien que allá algunas discusiones se plantean como guerras de religión. Los fanáticos de Hadoop le dirán que Hadoop es el futuro, y en la acera opuesta están los defensores de las bases de datos relacionales. Unos increpan a los otros: «eh, vosotros, chalados de SQL, sois dinosaurios, como los tíos de Cobol. Hadoop – es decir, nosotros – es el camino verdadero, la salvación…»

[risas] ¿Acaso es una cuestión de fe?

Se lo creen. Han pasado por Yahoo o Google, ahora están en una startup bien financiada, ¿cómo no van a creerlo? Pero en Silicon Valley también son cantidad los fanáticos de las bases de datos relacionales. Oracle se inventó en el Silicon Valley, como Informix o System R – que se convertiría en DB2 – lo mismo que Sybase o Ingres, la primera base de datos open source… Ni unos son dinosaurios ni los otros son farsantes. A mí, las guerras de religión me parecen estúpidas, los buenos ingenieros no se enrolan en esas guerras, simplemente cogen ideas de aquí y de allá.

Le preguntaba por SQL y NoSQL…

Para mi gusto NoSQL no debería significar ´nunca-SQL`, sino ´no-sólo-SQL`. Lo que creo es que vamos a una convergencia entre los conceptos de SQL y NoSQL, que las bases de datos relacionales van a integrar las nuevas tecnologías. Después de un periodo de reinado absoluto, alguien las dio por muertas por ineficientes.

¿Por qué no murieron? ¿Por la base instalada?

En parte, pero lo importante fue que las buenas ideas de un lado se mezclaron con las buenas ideas del otro lado. Tanto Oracle como DB2 o Teradata, todos tenemos extensiones de objetos, y lo mismo pasa con Hadoop… es un sistema de ficheros, que no ha sido diseñado para hacer lo mismo que una base de datos relacional. Algunas cosas pueden hacerse en SQL y otras no. Algunos proyectos, básicamente, buscan añadir capacidades SQL al sistema distribuído de Hadoop, en esto consiste la convergencia.

¿Qué piensa de otro nuevo concepto, in-memory?

Yo no diría que in-memory es un nuevo concepto, ha estado dando vueltas por mucho tiempo, pero ahora se ha construído una moda. SAP lo ha puesto de moda, y si usted presta atención al marketing de SAP, que lo promueve intensamente, verá que el coste baja, baja y sigue bajando. Es verdad, y esta es la lógica de SAP: almacena más datos en memoria y tus problemas de performance desaparecerán. Pero la lógica de ingeniero me dice que las ecuaciones tienen dos lados, que si el coste de la memoria cae un 30% cada 18 meses, al otro lado tengo que ver cuál es el crecimiento de los datos, y de esto se habla menos. Mi argumento es que el volumen de los datos crece más rápido de lo que baja el coste de la memoria, por lo que es irracional poner todos mis datos en memoria, no es sostenible desde un punto de vista económico.

¿Es falso el argumento de SAP?

No. Lo que digo que en la mentalidad de SAP sólo cabe el ERP, y los datos de un ERP crecen lentamente. ¿Cuántos clientes nuevos incorpora un negocio estable? ¿Cuántas nuevas cuentas? ¿Cuántas transacciones añade cada año? Un ERP no puede generar ese crecimiento de los datos al que estamos asistiendo. Los datos de interacciones, sí. Si lo que se pretende es incorporar los datos tradicionales y no tradicionales, ambos, in-memory, mi opinión es que no tiene sentido.

¿Por qué no?

Si observamos el acceso a un data warehouse en producción, vemos que el 90% del input-ouput equivale al 20% de los datos, y para ese 20% es lo que da sentido a in-memory, no el 80% restante. Y si lo que quiero es almacenamiento barato de los datos a los que accedo con más frecuencia, lo que necesito es el precio más bajo por IO, mientras que para los datos a los que accedo menos frecuentemente, u ocasionalmente, necesito el precio más bajo por terabyte. Mi cabeza de ingeniero me dice que lo que hay que hacer es meter el 20% de los datos en memoria, sea en flash o en DRAM, y reservar el 80% para el almacenamiento low cost.

Sin embargo, otras empresas, además de SAP, están usando in-memory como extensión.. Incluso Oracle, que ya es decir […]

Así es, pero hay que ver cómo lo están haciendo. Oracle no le dice a nadie que reemplace su base de datos por otra in-memory; lo que está haciendo es usar in-memory esencialmente como cache. En ningún caso propone, ni creo que vaya a proponerlo alguna vez, 100% in-memory. Sólo SAP propone una base de datos completamente in-memory, porque no tiene otra que proponer.

Volvamos al comienzo: IoT. Los sensores generan un volumen enorme de datos, que son interacciones. Pero los sensores no tienen experiencia, sólo envían datos…

Sí claro, pero nosotros recogemos la experiencia en nuestros repositorios analíticos. Por tanto, los sensores crean datos, pero para crear valor hace falta procesarlos y analizarlos; esto es lo que hacemos. Los sensores son la materia prima para la capacidad analítica que suministra Teradata. Es lo que hacen nuestros clientes en la industria de automoción, las compañías de seguros… capturamos datos de los motores de aviación para descubrir el mejor momento para proceder a intervenciones proactivas. Capturamos datos de las líneas de fabricación, por tanto ayudamos a crear valor a partir de los datos de los sensores.

¿Cuál es el papel de Teradata, además de suministrar sus sistemas?

Según los casos, tenemos alianzas significativas. Por ejemplo, un joint venture con Siemens para iniciativas de smart cities. Los sensores capturan los datos, por ejemplo de la red eléctrica, Siemens los recopila en su infraestructura e instrumentos, los envía a Teradata y nosotros hacemos el análisis.

¿Qué otros acuerdos tienen desde el punto de vista tecnológico?

Tenemos varios en distintas áreas. Uno de ellos con Hortonworks, que es la distribución de Hadoop con la que trabajamos e integramos en nuestros appliances. Otro ejemplo es SAS Institute, con quienes tenemos acuerdos de I+D para hacer procesos analíticos avanzados dentro de la base de datos de Teradata, y esto les permite multiplicar por 50 la velocidad de un proceso serial en un servidor convencional, porque Teradata lo hace con una arquitectura masivamente paralela: nosotros creamos el modelo analítico que se llama PMML [Predictive Modelling Markup Language] que se ejecuta en la base de datos de Teradata.

¿Esos acuerdos son una garantía para que Teradata permanezca como empresa independiente?

Creo que sí. Estamos entre las diez compañías de software líderes en Estados Unidos, y nuestro objetivo no es ser la más grande del mundo ni formar parte de una compañía gigantesca, sino hacer bien lo que sabemos hacer, analytics. Además, estamos viendo lo que pasa con las compañías gigantescas.