Contenido
Fuente: Jakub Jirsak / Dreamstime.com
Para llevar:
El anfitrión Eric Kavanagh discute el análisis de big data con expertos de la industria.
Eric: Damas y caballeros, es el final del año 2014, al menos, casi. ¡Es nuestra última transmisión web del año, amigos! ¡Bienvenido a TechWise! Si, de hecho! Me llamo Eric Kavanagh. Seré su moderador para una transmisión web increíble, amigos. Estoy muy, muy emocionado. Tenemos dos analistas increíbles en línea y dos grandes empresas: innovadores reales en todo este ecosistema de big data. Y vamos a hablar de que la clave para el análisis de big data es entender la diferencia. Entonces, vamos a sumergirnos, amigos.
Tenemos varios presentadores. Como puede ver, el suyo está realmente en la cima. Mike Ferguson está llamando desde el Reino Unido, donde tuvo que obtener privilegios especiales para permanecer en su edificio de oficinas tan tarde. Así de tarde es para él. Tenemos al Dr. Robin Bloor, nuestro propio Analista Jefe aquí en el Grupo Bloor. Y tendremos a George Corugedo, CEO y cofundador de RedPoint Global, y Keith Renison, Arquitecto de Soluciones Senior del Instituto SAS. Estas son compañías fantásticas, amigos. Estas son empresas que realmente están innovando. Y vamos a profundizar en algunas de las cosas buenas de lo que está sucediendo en este momento en todo el mundo de Big Data. Y seamos sinceros, los datos pequeños no han desaparecido. Y a eso, déjenme dar mi resumen ejecutivo aquí.
Entonces, hay una vieja expresión francesa: "Mientras más cambian las cosas, más permanecen igual". Y enfrentemos algunos hechos aquí: big data no va a resolver los problemas de datos pequeños. Los pequeños datos corporativos todavía están disponibles. Todavía está en todas partes. Es el combustible de las operaciones para la economía de la información de hoy. Y big data ofrece un complemento a estos llamados pequeños datos corporativos, pero no suplanta a los pequeños datos. Todavía va a estar por ahí. Me gustan muchas cosas sobre big data, especialmente cosas como datos generados por máquina.
Y hoy, probablemente hablaremos un poco sobre los datos de las redes sociales, que también son cosas muy poderosas. Y si piensa, por ejemplo, en cómo las redes sociales han cambiado los negocios, piense en tres sitios web rápidos aquí: LinkedIn y. Piensa en el hecho de que hace cinco años, nadie estaba haciendo ese tipo de cosas. Es un monstruo absoluto en estos días. , por supuesto, es enorme. Es gigantesco. Y luego, LinkedIn es el estándar de facto para las redes corporativas y la comunicación. Estos sitios son enormes, y para poder aprovechar los datos que están en ellos, revivirá algunas funcionalidades que cambian el juego. Realmente va a hacer mucho bien a muchas organizaciones, al menos a las que lo aprovechan.
Sin errores, sin estrés: su guía paso a paso para crear software que cambie su vida sin destruir su vida
No puede mejorar sus habilidades de programación cuando a nadie le importa la calidad del software.
Entonces, la gobernanza, la gobernanza sigue siendo importante. Una vez más, los grandes datos no anulan la necesidad de gobernanza. Francamente, hay una necesidad completamente nueva de centrarse en cómo gobernar el mundo de los grandes datos. ¿Cómo se asegura de tener sus procedimientos y políticas vigentes? que las personas adecuadas obtienen acceso a los datos correctos; que tienes contactos, tienes linaje involucrado aquí? Realmente sabes de dónde provienen los datos, qué le ha sucedido. Y todo eso está cambiando.
Francamente, estoy realmente impresionado por algo de lo que he visto en este nuevo mundo aprovechando el ecosistema Hadoop, que es, por supuesto, mucho más que almacenamiento en términos de funcionalidad. Hadoop es también un motor computacional. Y la compañía tiene que descubrir cómo aprovechar esa potencia computacional, esa capacidad de procesamiento paralelo. Van a hacer cosas realmente geniales. Aprenderemos sobre eso hoy.
Otra cosa a mencionar, esto es algo de lo que el Dr. Bloor ha hablado en el pasado reciente, es que la ola de innovación no ha terminado. Entonces, hemos visto mucha, por supuesto, atención alrededor de Hadoop. Hemos visto compañías como Cloudera y Hortonworks, ya sabes, realmente haciendo olas. Y están desarrollando alianzas con, bueno, empresas en la llamada hoy, francamente. Y están desarrollando alianzas con mucha gente. Pero la ola de innovación no ha terminado. Hay más proyectos derivados de la Fundación Apache que están cambiando no solo el punto final, si lo desea, las aplicaciones que usa la gente, sino la infraestructura en sí.
Entonces, todo este desarrollo de YARN, otro negociador de recursos, es realmente como un sistema operativo para big data. Y es un gran, gran problema. Entonces, vamos a aprender cómo eso también cambia las cosas. Entonces, solo un par de consejos obvios aquí, tenga cuidado con los contratos largos en el futuro, ya sabes, los contratos de cinco, diez años serán la ola, el camino que me parece. Querrá evitar el bloqueo a toda costa. Vamos a aprender sobre todo eso hoy.
Entonces, nuestro primer analista que habla hoy: nuestro primer orador de todo el programa es Mike Ferguson, que llama desde el Reino Unido. Con eso, te voy a entregar las llaves, Mike, y dejaré que te las lleves. Mike Ferguson, el piso es tuyo.
Mike, ¿estás ahí? Puede que estés mudo. No lo escucho Puede que tengamos que volver a llamarlo. Y saltaremos directamente a las diapositivas de Robin Bloor. Robin, voy a ponerle rango al pobre Mike Ferguson aquí. Voy a ir por un segundo.
¿Eres tú, Mike? ¿Puedes oirnos? Nah Creo que vamos a tener que seguir adelante e ir con Robin primero. Entonces, esperen un segundo, amigos. También extraeré algunos enlaces a las diapositivas aquí en un par de minutos. Entonces con eso, déjame entregarle las llaves a Robin Bloor. Robin, puedes ir primero en lugar de Mike, y llamaré a Mike en un segundo.
Robin: está bien.
Eric: Espera, Rob. Déjame seguir y traer tu tobogán aquí, Rob. Tomará un segundo.
Robin: está bien.
Eric: si. Sin embargo, puedes hablar de lo que estamos tratando aquí, en términos de gobernanza. Sé que vas a hablar sobre gobernanza. Por lo general, se piensa en la estafa de los datos corporativos pequeños. Así que ahora tengo la diapositiva hacia arriba, Robin. No muevas nada. Y aqui tienes. El piso es tuyo. Llevatelo.
Robin: está bien. Sí. Quiero decir, bueno, de alguna manera lo arreglamos de antemano: Mike hablaría sobre el lado analítico, y yo hablaré sobre el lado de la gobernanza. Hasta cierto punto, la gobernanza sigue los análisis en el sentido de que es una razón por la que está haciendo cosas de big data, y la razón por la que ensambla todo el software para hacer los análisis es, ahí es donde está el valor.
Hay un problema Y el problema es que, ya sabes, los datos tienen que ser modificados. Los datos tienen que ser ordenados. Los datos deben reunirse y administrarse de manera que permita que los análisis se lleven a cabo con total confianza. Supongo que esa es la palabra. Entonces, pensé que hablaría del lado de gobierno de la ecuación. Supongo que lo que hay que decir realmente es que, ya sabes, la gobernanza ya era un problema. La gobernanza ya era un problema, y comienza a convertirse en un problema en todo el juego del almacén de datos.
Lo que realmente sucedió es que se convirtió en un problema mucho mayor. Y la razón por la que se ha convertido en un problema mucho más grande, así como más datos, pero quiero decir, estas son las razones, realmente. El número de fuentes de datos se ha expandido dramáticamente. Anteriormente, las fuentes de datos que teníamos estaban definidas en general por lo que alimentaba el almacén de datos. El almacén de datos normalmente sería alimentado por sistemas RTP. Es posible un poco de datos externos, no muchos.
Ahora, nos hemos ido a un mundo donde, ya sabes, un mercado de datos está surgiendo en este momento y, por lo tanto, habrá intercambio de datos. Ya tiene montones y montones de fuentes de datos de transmisión diferentes que realmente puede aportar a la organización. Tenemos datos de redes sociales que los han tomado, quitados por su propia cuenta, por así decirlo. Quiero decir, una gran cantidad de, el valor en los sitios de redes sociales es en realidad la información que agregan y, por lo tanto, pueden poner a disposición de las personas.
También tenemos el descubrimiento de, ya sabes, es como si ya existieran. Ya teníamos esos archivos de registro, ya sabes, en el advenimiento de Splunk. Y pronto, se hizo evidente que hay un valor en un archivo de registro. Entonces, había datos dentro de la organización que eran, que podríamos llamar nuevas fuentes de datos, así como fuentes externas. Entonces, eso es una cosa. Y eso realmente significa que, sean cuales sean las reglas de gestión de datos que teníamos implementadas antes, tendrán que ampliarse, de una forma u otra, y continuarán necesitando ampliarse para gobernar realmente datos. Pero ahora estamos comenzando a armarnos de una forma u otra.
Y bajando esta lista tenemos la transmisión y la velocidad de llegada de datos. Creo que una de las razones de la popularidad de Hadoop es que se puede utilizar para capturar una gran cantidad de datos. También puede ingerir la velocidad de los datos, que si realmente no necesita usarlos de inmediato, es un agradable entorno paralelo, enorme y paralelo. Pero también tiene el hecho de que hay una buena cantidad de análisis de transmisión en curso ahora. Solía ser solo el sector bancario que estaba interesado en las aplicaciones de transmisión, pero ahora se ha vuelto algo global. Y todo el mundo está mirando las aplicaciones de transmisión de una forma u otra, un medio potencial para obtener valor de los datos y realizar análisis para la organización.
Tenemos los datos no estructurados. La estadística, que generalmente forma parte del 10% de los datos del mundo, estaba en bases de datos relacionales. Ahora, una de las principales razones de esto fue que en su mayoría no estaba estructurada, y lo era: una buena parte estaba en la Web, pero estaba bastante dispersa sobre varios sitios web. Esos datos han demostrado ser también analizables, también utilizables. Y con el advenimiento de la tecnología Symantec, que se está convirtiendo gradualmente en la situación, se está volviendo cada vez más.Por lo tanto, existe la necesidad de recopilar y administrar datos no estructurados, y eso significa que es mucho mayor de lo que era antes. Tenemos datos sociales que ya mencioné, pero el punto sobre eso, el punto principal sobre eso, es que probablemente necesita limpieza.
Tenemos datos de Internet de las cosas. Ese es un tipo de situación diferente. Es probable que haya mucho de eso, pero mucho tendrá que permanecer distribuido en algún lugar cerca del lugar donde se ejecuta. Pero también va a querer, de una forma u otra, sacarlo para hacer el análisis dentro de la organización sobre los datos. Entonces, eso se agregó otro factor más. Y esos datos se estructurarán de manera diferente, porque probablemente lo serán, probablemente se formatearán en JSON o en XML, para que se declare. Y no solo, de una forma u otra, que realmente estamos obteniendo datos y somos capaces de hacer una especie de esquema al leer ese dato en particular.
Tenemos el problema de la procedencia, y este es un problema de análisis. Los resultados en cualquier análisis que esté haciendo datos realmente no pueden ser, si lo desea, aprobados, considerados válidos, a menos que conozca la procedencia de los datos. Quiero decir, eso es solo profesionalismo en términos de la actividad de los científicos de datos. Pero ya sabes, para tener procedencia de datos, eso significa que en realidad tenemos que gobernar los datos y mantener una nota de su linaje.
Tenemos el problema de la potencia de la computadora y los paralelos y todo lo que hace es hacer que todo vaya más rápido. El problema es que, obviamente, ciertos procesos que hemos implementado pueden ser demasiado lentos para todo lo demás. Por lo tanto, posiblemente haya desajustes en términos de velocidad.
Tenemos la llegada del aprendizaje automático. El aprendizaje automático tiene el efecto, realmente, de hacer de la analítica un juego diferente al que era antes. Pero solo puedes usarlo si tienes el poder.
Hemos recibido el hecho de nuevas cargas de trabajo analíticas. Tenemos un mundo paralelo y algunos algoritmos analíticos deben ejecutarse en paralelo para obtener el máximo efecto. Y, por lo tanto, el problema es gobernar cómo usted, de una forma u otra, empuja los datos, crea los datos si están disponibles. Y donde realmente ejecuta las cargas de trabajo analíticas, porque puede estar haciendo eso dentro de la base de datos. Por lo tanto, puede estar haciéndolo dentro de las aplicaciones analíticas.
Entonces, hay toda una serie de desafíos de gobernanza. Lo que hicimos este año: la investigación que hicimos este año se centró realmente en la arquitectura de big data. Y cuando realmente tratamos de generalizarlo, la conclusión a la que llegamos: el diagrama que se nos ocurrió se parecía mucho a esto.
No voy a entrar en esto, especialmente porque Mike va a hacer una buena cantidad de arquitectura de datos para análisis. Pero en lo que realmente me gusta que la gente se centre es en esta área inferior donde estamos, de una forma u otra, reuniendo datos. Tenemos algo a lo que me gustaría referirme es la refinería de datos o el centro de procesamiento de datos. Y ahí es donde tiene lugar el gobierno. Entonces, ya sabes, si nos enfocamos en algo así, se ve así. Ya sabes, está siendo alimentado por datos de fuentes internas y externas. El centro debería, en teoría, tomar todos los datos que se están generando. Debe transmitirse y administrarse como se transmite si necesita realizar análisis y datos de transmisión, y luego pasar al centro. O bien, todo entra en el centro. Y hay una serie de cosas que están sucediendo, que están sucediendo en el centro. Y no puede tener una cierta cantidad de análisis y SQL en el centro. Pero también tiene la necesidad de virtualización de datos en cada celda para enviar datos a otras áreas. Pero antes de que algo de eso suceda, realmente necesita, de una forma u otra, refinar la preparación de los datos. Puedes llamarlo preparación de datos. Es mucho más grande que eso. Estas son las cosas que creo que incluye.
Tenemos la gestión del sistema y la gestión del servicio, en cierto sentido, que esta es la mayor parte de la capa de datos, entonces tenemos que aplicar todos los sistemas que gestionan el esfuerzo de gestión del sistema operativo que tradicionalmente hemos hecho a casi todos los sistemas operativos. Pero también necesitamos, de una forma u otra, monitorear otras cosas que suceden para asegurarnos de que se cumplan estos diversos niveles de servicio, ya que es probable que se definan niveles de servicio o cualquier tipo de análisis que se esté actuando, o que los datos de BI se cumplan. siendo actuado
Necesitamos monitoreo y gestión del desempeño. En todo caso, necesitamos eso para saber qué recursos informáticos adicionales podríamos asignar en varios momentos. Pero también, una gran parte de la carga de trabajo está aquí, de hecho, es bastante compleja y compite entre sí por los recursos. Hay algo bastante sofisticado que debe hacerse en esa área.
Ahora tenemos el ciclo de vida de los datos de una manera que nunca antes habíamos tenido. El acuerdo aquí realmente está por encima y más allá de cualquier otra cosa, que no reunimos datos y los descartamos antes. Tendemos a recopilar datos que necesitábamos y probablemente los guardamos, y luego los archivamos. Pero una gran parte de lo que haremos a partir de ahora es explorar datos. Y si no desea los datos, enterrémoslos. Por lo tanto, los ciclos de vida de los datos son diferentes dependiendo de la situación, pero también serán mucho más agregados de datos. Por lo tanto, ya sabes, de dónde viene un agregado de qué ... cuál es la fuente de la agregación, y así sucesivamente. Eso es todo lo necesario.
El linaje de datos se presta naturalmente. Sin él, debe conocer los problemas, por lo que los datos ... Tenemos que saber que los datos son válidos, pero con la fiabilidad que realmente tienen.
También tenemos mapeo de datos, porque muchos de los datos van a ser, de una forma u otra. Y esto es, si lo desea, esto se relaciona en cierta medida en MDM. Es solo que ahora es mucho más complicado, porque cuando tienes una gran cantidad de datos definidos por JSON o basados en nuestro esquema XML en lectura, entonces necesitarás, de una forma u otra, tener muy activos actividad de mapeo de datos en curso.
Hay una situación de gestión de metadatos que es más que MDM, porque existe la necesidad, de una forma u otra, de construir lo que me gustaría pensar ahora como una especie de almacén de metadatos de todo lo que le interesa. Hay metadatos descubrimiento, porque algunos de los datos no necesariamente tendrán sus metadatos declarados, y queremos usarlos de inmediato. Y luego, hay una limpieza de datos, que es una gran cosa como la serie de cosas que uno puede hacer allí. Y también hay seguridad de datos. Todos estos datos tienen que ser asegurados a un nivel aceptable, y eso podría significar en ciertos casos, por ejemplo, encriptar muchos de los valores.
Entonces, toda esta carga de trabajo es en realidad el imperio de gobernanza. Todo esto, de una forma u otra, tiene que estar sucediendo al mismo tiempo o antes, toda nuestra actividad analítica. Esta es una gran cantidad de aplicaciones coordinadas. Es un sistema en sí mismo. Y luego, aquellos que no lo hacen en varios momentos sufrirán una falta a medida que avanzan, porque muchas de estas cosas no son realmente opcionales. Terminas aumentando la entropía si no los haces.
Entonces, en términos de análisis de datos y gobernanza, lo que diría es que, en realidad, una mano lava la otra. Sin gobernanza, la analítica y el BI no fracasarán a tiempo. Y sin análisis y BI, no habría mucha necesidad de gobernar los datos de todos modos. Entonces, las dos cosas realmente caminan de la mano. Como dicen en Medio Oriente, "una mano lava la otra". Y eso es todo lo que tengo que decir. Espero, con suerte, ahora tenemos a Mike de vuelta.
Eric: lo hacemos. Mike, supongo que estás allí. Voy a empujar tu diapositiva hacia arriba.
Mike: lo estoy. Vale, ¿me oyes?
Eric: Sí, puedo oírte. Suenas maravilloso Entonces, déjame presentarte ... Ahí tienes. Y ahora eres el presentador. Llevatelo.
Mike: Muy bien, gracias! Buenos días, buenas tardes, buenas noches a todos. Perdona el hipo al principio. Por alguna razón, me quedé mudo y puedo ver a todos, pero no pudieron escucharme.
Bien. Entonces, lo que quiero hacer rápidamente es hablar sobre el ecosistema analítico de big data. Si desea hacerme preguntas, le diré que, en esta sesión o más tarde, puede comunicarse conmigo en mis datos de contacto aquí. Como dije, en medio de la noche aquí en el Reino Unido.
Bueno, déjame llegar a lo que quiero hablar. Claramente, en los últimos años, hemos visto la aparición de todo tipo de datos nuevos que las empresas ahora quieren analizar, todo, desde datos de flujo de clics para comprender comportamientos en línea, datos de redes sociales de los que Eric estaba hablando en el comienzo del programa aquí. Creo que Robin mencionó JSON, BSON, XML, por lo tanto, datos semiestructurados que se autodescriben. Por supuesto, también tenemos un montón de otras cosas, desde datos no estructurados, registros de infraestructura de TI, datos de sensores. Todas estas fuentes de datos relativamente nuevas en las que las empresas se han interesado ahora porque contienen información valiosa que podría profundizar lo que sabemos.
Entonces, eso básicamente significa que el panorama analítico ha ido más allá del almacenamiento de datos tradicional. Todavía estructuramos los datos en el mundo de una combinación de datos estructurados y multiestructurados, donde los datos multiestructurados podrían provenir del interior o del exterior de la empresa en muchos casos. Y como resultado de estos nuevos tipos de datos y nuevas necesidades de análisis, hemos visto la aparición de nuevas cargas de trabajo analíticas: todo, desde el análisis de datos en movimiento, que de alguna manera convierte la arquitectura tradicional de almacenamiento de datos en su cabeza, donde , en los círculos tradicionales, integrar datos, limpiarlos, transformarlos, almacenarlos y analizarlos. Pero al analizar los datos en movimiento, estamos capturando los datos, integrándolos, preparándolos a través del análisis y luego almacenándolos. Entonces, hay un análisis de datos antes de que se almacenen en cualquier lugar.
Realizamos análisis complejos de datos estructurados, quizás para el desarrollo de modelos, el desarrollo de modelos estadísticos y predictivos, que no es nada nuevo para algunas personas en un espacio de almacenamiento de datos tradicional. Tenemos un análisis exploratorio de los datos del modelo. Esa es la cantidad de datos estructurados allí. Tenemos nuevas cargas de trabajo en forma de análisis gráfico que para mis clientes en servicios financieros incluye cosas como fraude. También incluye seguridad cibernética. Incluye las redes sociales, por supuesto, la comprensión de personas influyentes y cosas por el estilo allí. Incluso lo dominé en administración, tengo algunos años de análisis gráfico.
Tenemos la optimización del almacén de datos o la descarga del procesamiento de ETL, que es más una especie de caso de uso de TI, el CIO podría financiar eso. E incluso archivar datos y almacenes de datos para mantenerlos en línea en cosas como Hadoop. Entonces, todas estas nuevas cargas de trabajo analíticas han agregado nuevas plataformas, nuevas plataformas de almacenamiento, al panorama analítico. Entonces, en lugar de tener simplemente almacenes de datos tradicionales, data marts, lo que ahora tenemos es Hadoop. Tenemos bases de datos NoSQL, como bases de datos de gráficos, que a menudo se utilizan para cargas de trabajo analíticas. Por supuesto, podemos hacer análisis de gráficos ahora en Hadoop, así como en un DBMS de gráfico NoSQL. Tenemos análisis de transmisión que Robin mencionó. Y tenemos, si lo desea, la construcción de modelos, quizás también en dispositivos de almacenamiento de datos analíticos. Pero todo eso ha complicado el panorama analítico, ahora se necesitan múltiples plataformas. Y supongo que el desafío, para cualquier negocio con una oficina principal o administrativa, o finanzas, adquisiciones, recursos humanos y algún tipo de operaciones, es descubrir qué proyectos analíticos están asociados con una escena tradicional de almacenamiento de datos. Y una vez que sepa que los proyectos analíticos están asociados con estas nuevas plataformas de big data y dónde ejecutar, ya sabe, qué carga de trabajo analítico, pero no perder de vista el negocio en el sentido de que es, ahora verá que es una combinación de grandes proyectos analíticos de datos y proyectos tradicionales de almacenamiento de big data que, juntos, son necesarios para fortalecer el entorno interno del cliente o las operaciones, el riesgo, las finanzas o la sostenibilidad. Y, por lo tanto, queremos que todo esto esté alineado con nuestras prioridades comerciales estratégicas, que nos mantenemos en el camino para, ya sabes, empujar las agujas que deben empujarse, ya sabes, para mejorar el rendimiento del negocio, reducir los costos, para reducir riesgos, etc., ya sabes, para nuestra empresa en general. Entonces, no es que uno reemplaza al otro aquí con big data y tradicional. Ambos se usan juntos. Y eso cambia dramáticamente la arquitectura, ya sabes.
Entonces, lo que tengo aquí es una arquitectura relativamente nueva que usaré con mis clientes. Y así, como puede ver ahora en la parte inferior, una amplia gama de fuentes de datos, ya no solo estructuradas. Algunos de ellos transmiten datos en vivo como sensores, como datos de mercados, ese tipo de cosas. Incluso podría ser datos de flujo de clics en vivo. Podrían ser datos de transmisión de video en vivo. Por lo tanto, no tenía que estar estructurado. Por lo tanto, podemos hacer un procesamiento continuo de esos datos para tomar acciones automáticas en tiempo real, y cualquier dato de interés podría filtrarse y pasarse a una herramienta de gestión de información empresarial que se pueda utilizar para poblar almacenes de datos analíticos. A menos que pueda ver en la mezcla aquí, ahora tenemos el almacenamiento tradicional de datos, las bases de datos Hadoop y NoSQL. También tenemos gestión de datos maestros en la mezcla. Y eso ejerce más presión sobre todo el conjunto de herramientas de administración de datos, no solo para llenar estos almacenes de datos, sino también para mover datos entre ellos.
Además de eso, tenemos que simplificar las herramientas de acceso. No podemos simplemente recurrir al usuario y decirle "obtenga todos estos almacenes de datos, mantenga estas API, su problema". Lo que tienes que hacer es simplificar el acceso. Entonces, en las líneas punteadas, verá que la virtualización y la optimización de datos ocultan la complejidad del almacenamiento de datos múltiples, intente facilitar el acceso de los usuarios finales. Y, por supuesto, hay una variedad de herramientas en la parte superior, ya sabes, todo, desde herramientas de BI tradicionales que han comenzado de nuevo en la parte superior del almacenamiento de datos, moviéndose gradualmente hacia la izquierda de su gráfico para conectarse a Hadoops y luego las bases de datos NoSQL del mundo.
Tenemos búsquedas que obtienen una nueva oportunidad de vida, especialmente en torno a los datos estructurados y no estructurados del cuerpo que a menudo se almacenan en Hadoop. Tenemos aplicaciones analíticas personalizadas para hacer en una plataforma Hadoop con MapReduce, por ejemplo, el marco de Spark. Tenemos herramientas de análisis de gráficos para, ya sabes, enfocarse en cargas de trabajo muy específicas allí. Por lo tanto, una gama de herramientas y los flujos de datos también son más complejos. Ya no es solo una calle de sentido único en el almacén de datos. Ahora son datos maestros, por supuesto.
Tenemos nuevas fuentes de datos, ya sea capturados en NoSQL, ya sabes, almacenes de datos como MongoDB, como Cassandra, como HBase. Tenemos datos que se llevan directamente a Hadoop para su análisis y preparación de datos allí. Tenemos nuevos conocimientos que salen de Hadoop y los almacenes de datos. Tenemos archivos que salen de los almacenes de datos en Hadoop. Ahora tenemos feeds de datos que van a, ya sabes, todas las bases de datos NoSQL y los data marts también. Entonces, lo que puede ver aquí es que hay mucha más actividad en la administración de datos. Y significa que está poniendo el software de gestión de datos bajo una presión considerable. Ya no es solo una calle de sentido único. Es un movimiento de datos bidireccional. Está sucediendo mucha más actividad y, por lo tanto, la escalabilidad es importante en el frente de la herramienta de administración de datos, así como en la fuente de datos.
Entonces, este gráfico se remonta a la arquitectura que mencioné hace un momento. Le muestra las diferentes cargas de trabajo analíticas que se ejecutan en diferentes partes de esta arquitectura. Más o menos en la parte inferior izquierda, tienes transmisión en tiempo real, procesamiento de transmisión continua de datos que salen, ya sabes, de cualquier tipo de almacén de datos en vivo. Tenemos análisis de clase en bases de datos de gráficos NoSQL. También puede suceder en Hadoop. Con el marco de Spark, por ejemplo, y GraphX allí, tenemos un análisis de investigación y la refinería de datos de la que Robin estaba hablando que sucedería en Hadoop. Todavía tenemos cargas de trabajo tradicionales y almacenamiento de datos, ya sabes, usuarios avanzados que crean modelos estadísticos y predictivos, tal vez en dispositivos de almacenamiento de datos. Y todavía estamos tratando de simplificar el acceso a todo esto para facilitar a los usuarios finales.
Entonces, el éxito en toda esta configuración es más que solo el lado analítico. Sabes, podemos poner las plataformas analíticas en su lugar, pero si no podemos capturar e ingerir, ya sabes, datos de alta velocidad y alto volumen, en la escala, no tiene mucho sentido. Sabes, no tengo nada que analizar. Y así, el éxito del análisis de Big Data requiere sistemas operativos para escalar. Eso significa, para poder soportar nuevas transacciones, ya sabes, picos. Ya sabes, cualquier información no transaccional que se capture allí podría ser, ya sabes, cualquier nueva tasa de llegada muy, muy alta, en datos de alta velocidad como sensores o cualquier ingesta. Tenemos que poder atender todo eso, poder capturar este tipo de datos y llevarlo para su análisis. También tenemos que escalar los análisis en sí mismos, simplificar el acceso a los datos que ya mencioné. Y luego, ata eso. Sabes, tenemos que ser capaces de refinarnos en esos sistemas operativos para darle un ciclo cerrado.
Entonces, escalar el lado operativo de la casa para capturar datos, ya sabes, lleva al mundo de la base de datos NoSQL. Quiero decir, aquí ves cinco categorías de bases de datos NoSQL. Esta categoría se modelará simplemente siendo una combinación de los otros cuatro anteriores. En general, ya sabe, sus valores clave, documentos almacenados y bases de datos de familias de columnas, los tres primeros allí, que se utilizan para la mayoría de los datos transaccionales y no transaccionales.
Algunas de esas bases de datos que dan soporte como propiedades; algunos de ellos no. Sin embargo, ya sabes, estamos viendo la introducción de aquellos para escalar ese tipo de aplicaciones. Y así, por ejemplo, a medida que nos alejamos de los empleados que ingresan transacciones en los teclados a los clientes actuales y a las masas que usan dispositivos novedosos para poder hacer eso. Hemos visto un tremendo aumento en el número de transacciones que se ingresan en las empresas. Y entonces, necesitamos escalar las aplicaciones transaccionales para hacer eso.
Ahora, en términos generales, eso se puede hacer en las bases de datos NewSQL como una base de datos relacional como NuoDB y VoltDB que se muestran aquí. O algunas de las bases de datos NoSQL que quizás admitan propiedades ACID que pueden garantizar el procesamiento de transacciones pueden estar en juego. Esto también se aplica a los datos no transaccionales, como los datos del carrito de compras antes de una transacción, ya sabes, antes de que la gente compre cosas, datos del sensor, ya sabes, ya que pierdo una lectura del sensor entre cientos de millones de lecturas del sensor. No es la gran cosa. Clics, ya sabes, en el mundo del flujo de clics: si uso un clic, no es gran cosa.Entonces, ya sabes, no necesitamos necesariamente tener propiedades ACID allí, y ahí es donde a menudo entran en juego las bases de datos NoSQL, allí estaba: esa capacidad de hacer un procesamiento muy alto y correcto a escala para capturar estos nuevos tipos de datos.
Al mismo tiempo, queremos que la analítica escale. Y así, extraer los datos de los almacenes de datos a las plataformas analíticas ya no los pirateará porque los datos son demasiado grandes. Lo que realmente queremos es llevar la analítica de la otra manera, al almacén de datos de la empresa en Hadoop, al procesamiento continuo para poder llevar la analítica a los datos. Sin embargo, el hecho de que alguien diga que está en el análisis de la base de datos o en el análisis de Hadoop no significa necesariamente que el análisis se ejecute en paralelo. Y, francamente, si va a invertir en estas nuevas tecnologías escalables masivamente paralelas como Hadoop, como los dispositivos de almacenamiento de datos y otras cosas, como los motores de procesamiento de flujo en clúster, necesitamos que los análisis se ejecuten en paralelo.
Entonces, esa es solo la salida. Sabes, si tenemos análisis para ayudar a predecir cosas para los clientes, para las operaciones, para el riesgo, etc., queremos que se ejecuten en paralelo, no solo en la plataforma. Queremos los dos. Y eso es porque, ya sabes, la tecnología es como estas nuevas herramientas de descubrimiento visual como SAS también. En realidad, es uno de nuestros patrocinadores aquí.
Una cosa que la gente quiere es al menos explotar en Hadoop y luego en el análisis de la base de datos. Y queremos que se ejecuten en paralelo para poder ofrecer el rendimiento necesario en volúmenes de datos tan altos. Al mismo tiempo, estamos tratando de simplificar el acceso a todo esto. Y así, SQL ahora está de vuelta en la agenda. Ya sabes, SQL es: SQL en Hadoop está de moda en este momento. Lo estoy rastreando en 19 iniciativas SQL y Hadoop en este momento. Además, como puede ver, podemos obtener estos datos, ya sabes, de varias maneras, de modo que al acceder directamente a SQL en Hadoop mismo, podemos llevar SQL a un índice de búsqueda. De esa manera, como, ya sabes, algunos de los proveedores de búsqueda en ese espacio, podemos tener acceso SQL a bases de datos relacionales analíticas que tienen tablas de Excel para Hadoop.
Ahora podemos tener acceso SQL a un servidor de virtualización de datos que luego puede conectarse a un almacén de datos en Hadoop. Incluso ahora estoy empezando a ver la aparición del acceso SQL a la transmisión de datos en vivo. Entonces, el acceso SQL a todo esto está creciendo rápidamente. Y parte del desafío es, simplemente porque el acceso SQL se comercializa por ahí. La pregunta es, ¿puede tratar SQL con datos complejos? Y eso no es necesariamente sencillo. Aquí hay todo tipo de complicaciones, incluido el hecho de que los datos JSON podrían estar anidados. Podemos tener registros de variantes de esquema. Entonces, el primer registro tiene un esquema. El segundo registro tiene un esquema diferente. Estas cosas son muy diferentes de lo que sucede en un mundo relacional.
Entonces, debemos hacer preguntas sobre qué tipo de datos es lo que estamos tratando de analizar y cuáles son las características analíticas. ¿Es, ya sabes, el panel que quieres hacer? ¿Es aprendizaje automático? ¿Es un análisis gráfico? ¿Puedes hacer eso desde SQL? Ya sabes, ¿eso es invocable desde SQL? ¿Cuántos usuarios concurrentes tenemos haciendo esto? Ya sabes, tenemos cientos de usuarios concurrentes. ¿Es eso posible en datos complejos? Ya sabes, todas estas cosas son preguntas clave. Entonces, hice una lista de algunos aquí que creo que deberías considerar. ¿Sabes qué tipo de formatos de archivo? ¿De qué tipo de tipos de datos estamos hablando? ¿Qué tipo de funciones analíticas podemos invocar desde SQL para obtener datos complejos? Y tipo de funciones se ejecutan en paralelo. Quiero decir, tienen que correr en paralelo si tenemos que poder escalar esto. ¿Y puedo unir datos en Hadoop hoy fuera de él, ya sabes, o eso no es factible? ¿Y qué haré con todos estos diferentes tipos de cargas de trabajo de consulta?
Y como veremos, por lo que he visto, hay muchas diferencias en la distribución de SQL y Hadoop. Estos son todos los que estoy rastreando. Y, por cierto, eso es SQL puro en Hadoop. Eso ni siquiera incluye la virtualización de datos en este momento. Y así, mucho por ahí y mucho espacio para la consolidación, lo que creo que va a suceder durante el próximo año, dieciocho meses más o menos. Pero también abre otra cosa, que es que puedo tener potencialmente múltiples motores SQL en los mismos datos en Hadoop. Y eso es algo que no podrías hacer en relación.
Por supuesto, eso significa que debe saber, ¿qué tipo de carga de trabajo de consulta estoy ejecutando? ¿Debo ejecutarlo en lote en una iniciativa de SQL en Hadoop en particular? ¿Debo ejecutar cargas de trabajo de consultas interactivas a través de otro SQL en la iniciativa Hadoop, etc., para saber a cuál conectarme? Idealmente, por supuesto, no deberíamos hacer eso. Deberíamos haber hecho una pregunta al respecto. Ya sabes, algunos optimizadores descubren la mejor manera de hacerlo. Pero todavía no estamos completamente allí, en mi opinión.
Sin embargo, también, la virtualización de datos, mencioné anteriormente, tiene un papel muy importante para simplificar el acceso a múltiples almacenes de datos. Y si creamos nuevas ideas sobre Hadoop, es ciertamente posible que nos unamos a esos almacenes de datos tradicionales y de datos a datos a través de la virtualización de datos, por ejemplo, sin necesariamente mover los datos de Hadoop a los almacenes de datos tradicionales. Por supuesto, tú también puedes hacer eso. También es plausible si archivo datos de almacenes de datos tradicionales en Hadoop. Todavía puedo obtenerlo y unirlo a las cosas que están en nuestro almacén de datos para la virtualización de datos. Entonces, para mí, creo que la virtualización de datos tiene un gran futuro en esta arquitectura general y simplifica el acceso a todos estos almacenes de datos.
Y no hay que olvidar que cuando creamos estas nuevas ideas, ya sea en sistemas relacionales o NoSQL, aún queremos llevar esas ideas a nuestras operaciones, para que podamos maximizar el valor de lo que hemos encontrado, para que podamos aproveche eso para tomar decisiones más efectivas y oportunas en ese entorno para optimizar nuestro negocio.
Entonces, para terminar, lo que estoy viendo es que necesitamos nuevas fuentes de datos. Tenemos nuevas plataformas en una arquitectura más complicada, si lo desea, para manejar eso. Y Hadoop se está volviendo muy, muy importante, lo suficiente para la preparación de datos para nuestras cajas de arena líquidas, para la consulta de archivos, el archivo del almacén de datos, la gestión de datos que extiende sus alas para ir más allá del almacenamiento de datos en la gestión de datos en todas estas plataformas, y nuevas herramientas para ser capaz de analizar y acceder a datos en estos entornos, poder tener tecnologías escalables para hacer una mejor ingesta de datos y escalar los análisis empujándolos hacia las plataformas para hacerlos más paralelos. Y luego, con suerte, también para simplificar el acceso a todo a través del SQL emergente que llega por encima. Entonces, te da una idea de hacia dónde nos dirigimos. Entonces, con eso, volveré a, supongo, Eric ahora, ¿verdad?
Eric: Bien, eso es fantástico. Y amigos, tengo que decir que, entre lo que acaba de obtener de Robin y Mike, es probable que sea tan completo y conciso en una visión general de todo el paisaje desde la observación como la que se puede encontrar en cualquier lugar. Permítanme seguir y poner en cola a George Corugedo primero. Y ahí está. Déjame tomar esto por un segundo rápido. Muy bien, George, estoy a punto de entregarte las llaves y llevártela. El piso es tuyo.
George: genial! Muchas gracias Eric y gracias Rob y Mike. Esa fue una gran información y muchas cosas con las que coincidimos. Entonces, volviendo a la discusión de Robin, porque, ya sabes, no es una coincidencia que RedPoint esté aquí y SAS esté aquí. Debido a RedPoint, realmente nos enfocamos en el lado de los datos en el gobierno, en el procesamiento de los datos y la preparación para su uso en análisis. Entonces, déjenme ir a través de estas dos diapositivas. Y realmente hable y capte el punto de Robin sobre MDM y lo importante que es, y lo útil que creo, y creemos, que Hadoop puede estar en el mundo de MDM y la calidad de los datos.
Sabes, Robin estaba hablando un poco sobre cómo se relaciona esto con el mundo del almacén de datos de la empresa y yo vengo. Sabes, he pasado varios años en Accenture. Y lo interesante allí es cuántas veces tuvimos que ir a las empresas y tratar de averiguar qué hacer con el almacén de datos que básicamente había sido abandonado. Y mucho de eso sucedió porque el equipo del almacén de datos realmente no alineó su construcción con los usuarios comerciales o con los consumidores de los datos. O bien, les llevó tanto tiempo que para cuando construyeron la cosa, el uso comercial o la justificación comercial para ello habían evolucionado.
Y una de las cosas que creo es que me entusiasma la idea de usar Hadoop para la gestión de datos maestros, la calidad de los datos y la preparación de datos, es el hecho de que siempre se puede volver a los datos atómicos en un Lago de datos de Hadoop o depósito de datos, o depósito de datos, o centro, o cualquier forma de zumbido que desee utilizar. Pero debido a que siempre conserva esos datos atómicos, siempre tiene la oportunidad de realinearse con los usuarios comerciales. Porque, como analista, porque en realidad comencé mi carrera como estadístico, ya sabes, nada es peor que, ya sabes, los almacenes de datos empresariales son maravillosos para conducir los informes, pero si quieres hacer análisis realmente predictivos, son realmente no es tan útil, porque lo que realmente desea es la información granular de comportamiento que de alguna manera se resumió y se agregó en el almacén de datos. Entonces, creo que esa es realmente una característica importante, y esa es una cosa en la que creo que no estoy de acuerdo con Robin, es que personalmente dejaría los datos en el lago de datos o en el centro de datos el mayor tiempo posible, porque mientras los datos están ahí y están limpios, puedes verlos desde una dirección, otra dirección. Puede fusionarlo con otros datos. Siempre tiene la oportunidad de volver y reestructurarse, y luego realinearse con una unidad de negocios y la necesidad que pueda tener esta unidad.
Una de las otras cosas interesantes acerca de esto es que, debido a que es una plataforma computacional tan poderosa, mucha de esa carga de trabajo de la que hemos estado hablando, vemos que todo llega directamente a Hadoop. Y aunque, creo, Mike estaba hablando de todas las diferentes tecnologías que existen en el mundo de, en este tipo de ecosistema de big data, creemos que Hadoop es realmente el caballo de batalla para hacer esa gran escala en el procesamiento computacionalmente intensivo que Se requieren datos maestros y calidad de datos. Porque si puede hacerlo allí, ya sabe, solo por la simple economía de mover datos de sus costosas bases de datos a bases de datos económicas, esto realmente está impulsando gran parte de la aceptación en este momento en las grandes empresas.
Ahora, por supuesto, hay algunos desafíos, ¿verdad? Hay desafíos en torno a las tecnologías. Muchos de ellos son muy inmaduros. Yo diría, ya sabes, no sé cuántas, pero varias de las tecnologías que Mike mencionó todavía están en lanzamientos de punto cero, ¿verdad? Entonces, estas tecnologías son muy jóvenes, muy inmaduras, todavía basadas en código. Y eso realmente crea un desafío para las empresas. Y realmente nos enfocamos en resolver problemas a nivel empresarial. Por lo tanto, creemos que tiene que haber una forma diferente, y eso es lo que proponemos es una forma diferente de abordar algunas de las cosas al usar algunas de estas tecnologías muy incipientes.
Y entonces, y luego el otro tema interesante aquí, que se ha mencionado anteriormente, que es, cuando tienes datos que estás capturando en un entorno Hadoop de cualquier tipo, ya sabes, generalmente es un esquema de lectura en lugar de un esquema de escritura con algunas excepciones Y esa lectura, muchos estadísticos están siendo realizados por estadísticos. Por lo tanto, los estadísticos deben tener herramientas que les permitan estructurar adecuadamente los datos con fines analíticos, porque al final del día, para que los datos sean útiles, deben estar estructurados de alguna forma para verlos o responder una pregunta o un negocio, algún tipo de negocio, crea valor comercial.
Entonces, donde entramos, es que tenemos una aplicación maestra de gestión y clave maestra de calidad de datos EPL, ELT muy amplia y madura. Ha estado en el mercado por muchos, muchos años. Y tiene toda la funcionalidad o gran parte de la funcionalidad que Robin enumeró en ese gráfico circular: todo, desde la simple captura de datos en bruto en una gran variedad de formatos y estructuras XML y otras cosas, hasta la capacidad de hacer toda la limpieza, el finalización de los datos, la corrección de los datos, los bits del núcleo geoespacial de los datos. Eso es algo que se está volviendo cada vez más importante en estos días con Internet de las cosas. Ya sabes, hay una geografía asociada a gran parte de lo que hacemos o gran parte de esos datos. Y así, todo el análisis, la tokenización, la limpieza, la corrección, el formateo, la estructuración, etc., todo eso se realiza en nuestra plataforma.
Y luego, y tal vez, pensamos que lo más importante es la idea de la deduplicación. Sabes, en el fondo, si observas cualquier definición de gestión de datos maestros, el núcleo es la deduplicación. Puede identificar entidades en diferentes fuentes de datos y luego crear un registro maestro para esa entidad. Y esa entidad podría ser una persona. La entidad podría ser parte de un avión, por ejemplo. La entidad podría ser un alimento como lo hemos hecho para uno de nuestros clientes del club de salud. Hemos creado una base de datos maestra de alimentos para ellos. Entonces, sean cuales sean las entidades con las que estamos trabajando, y, por supuesto, cada vez más, hay personas y representantes de sus identidades que son cosas como identificadores sociales o cuentas, cualquier dispositivo que esté asociado con personas, algunas cosas como automóviles y teléfonos, y cualquier otra cosa que puedas imaginar.
Ya sabes, estamos trabajando con un cliente que está poniendo todo tipo de sensores en ropa deportiva. Entonces, los datos provienen de todas las direcciones. Y de una forma u otra, es un reflejo o una representación de la entidad central. Y cada vez más, eso es la gente y la capacidad de identificar las relaciones entre todas estas fuentes de datos y cómo se relacionan con esa entidad central, y luego poder rastrear esa entidad central con el tiempo para que pueda analizar y comprender los cambios entre esa entidad y todos esos otros elementos que están en esas representaciones de esa entidad, un análisis realmente crítico para el análisis a largo plazo y longitudinal de las personas, por ejemplo. Y ese es realmente uno de los beneficios realmente importantes que, creo, que los grandes datos pueden brindarnos es una comprensión mucho mejor de las personas y, a largo plazo, comprender la estafa y cómo se comportan las personas cuando se comportan a través de qué dispositivos, etc. .
Entonces, déjame pasar por aquí rápidamente. Eric mencionó HILO. Sabes, lo lanzo solo por un momento, porque mientras YARN - la gente habla de YARN. Todavía hay mucha ignorancia, creo, sobre YARN. Y no mucha gente realmente: todavía hay muchos malentendidos sobre YARN. Y el hecho es que si su aplicación ha sido diseñada de la manera correcta y tiene el nivel adecuado o la paralelización en la arquitectura de su aplicación, entonces puede aprovechar YARN para usar Hadoop como su plataforma de escalado. Y eso es exactamente lo que hemos hecho.
Ya sabes, de nuevo, solo para señalar algunas de las definiciones en torno a YARN. Para nosotros, realmente lo que es YARN nos ha permitido a nosotros mismos y a otras organizaciones convertirnos en compañeros de MapReduce y Spark, y en todas las otras herramientas que existen. Pero el hecho es que nuestras aplicaciones conducen código optimizado directamente a HILAR en HADOop. Y hay un comentario realmente interesante que Mike ha mencionado, porque, ya sabes, la pregunta sobre análisis y nuestro análisis, solo porque están en el clúster, ¿realmente se están ejecutando en paralelo? Puede hacer la misma pregunta sobre muchas de las herramientas de calidad de datos que existen.
La mayor parte del día, las herramientas de calidad que existen tienen que extraer los datos o insertar código. Y en muchos casos, se trata de un flujo único de datos que se procesa debido a la forma en que debe hacerlo. comparar registros, a veces en actividades de calidad de datos. Y el hecho es que debido a que estamos utilizando YARN, hemos podido aprovechar realmente la paralelización.
Y solo para darle una visión general rápida, porque se hace otro comentario sobre la importancia de poder expandir las bases de datos tradicionales, las nuevas bases de datos, etc., que implementamos o instalamos fuera del clúster. Y empujamos nuestros binarios directamente al administrador de recursos, YARN. Y eso, y luego YARN lo distribuye a través de los nodos en el clúster. Y lo que eso hace es que YARN: permitimos que YARN administre y haga su trabajo, que es averiguar dónde están los datos y llevar el trabajo a los datos, el código a los datos y no mover los datos. Cuando escuchas herramientas de calidad de datos y te dicen que la mejor práctica es sacar los datos de Hadoop, correr por tu vida, porque esa no es la forma en que es. Desea llevar el trabajo a los datos. Y eso es lo que YARN hace primero. Lleva nuestros archivos binarios a los nodos donde residen los datos.
Y también porque estamos fuera del clúster, también podemos acceder a todas las bases de datos tradicionales y relacionales para que podamos tener trabajos que sean 100% de servidor de cliente en una base de datos tradicional, 100% de Hadoop o trabajos híbridos que atraviesen el servidor de cliente de Hadoop , Oracle, Teradata: lo que sea que desee y todo en el mismo trabajo, porque esa única implementación puede acceder a ambos lados del mundo.
Y luego, volviendo a la idea de la naciente de las herramientas, ves aquí, esto es solo una representación simple. Y lo que estamos tratando de hacer es simplificar el mundo. Y la forma en que lo hacemos es al brindar un conjunto muy amplio de funcionalidades en torno a HDFS para hacerlo ... Y no es porque estemos tratando de eliminar todas las tecnologías innovadoras que existen. Es solo que las empresas necesitan estabilidad, y no les gustan las soluciones basadas en código. Por lo tanto, lo que estamos tratando de hacer es proporcionar a las empresas un entorno de aplicaciones familiar, repetible y consistente que les brinde la capacidad de construir y procesar datos de una manera muy predecible.
Rápidamente, este es el tipo de impacto que tenemos con nuestra aplicación. Verá MapReduce vs. Pig vs. RedPoint: no hay líneas de código en RedPoint. Seis horas de desarrollo en MapReduce, tres horas de desarrollo en Pig y 15 minutos de desarrollo en RedPoint. Y ahí es donde realmente tenemos un gran impacto. El tiempo de procesamiento también es más rápido, pero el tiempo de las personas, el tiempo de productividad de las personas, aumenta significativamente.
Y mi última diapositiva aquí, quiero volver a esta idea, porque esta es nuestra opinión sobre el uso de un lago de datos o un centro de datos, o una refinería de datos como el punto central de ingestión. No podría estar más de acuerdo con esa idea. Y actualmente estamos en conversaciones con muchos de los directores de datos de los principales bancos mundiales, y esta es la arquitectura elegida.La ingestión de datos de todas las fuentes realiza el procesamiento de la calidad de los datos y la gestión de los datos maestros dentro del lago de datos, y luego empuja los datos a donde necesita ir para admitir aplicaciones, para admitir BI, sea lo que sea. Y luego, si tiene análisis en BI, pueden ejecutarse directamente dentro del lago de datos, donde mejor aún, eso puede comenzar de inmediato. Pero muy a bordo con esta idea. Esta topología aquí es una, que estamos descubriendo que está ganando mucha tracción en el mercado. Y eso es.
Eric: Ok, bien. Avancemos por aquí. Seguiré y se lo entregaré a Keith. Y, Keith, tienes unos 10, 12 minutos para sacudir la casa aquí. Nos tomamos un poco de tiempo en estos shows. Y anunciamos 70 minutos para este. Entonces, solo adelante y haga clic en cualquier lugar de esa diapositiva y use la flecha hacia abajo y quítela.
Keith: claro. No hay problema, Eric. Lo aprecio. Voy a seguir adelante y trataré solo un par de piezas sobre SAS, luego pasaré, directamente a las arquitecturas tecnológicas de donde SAS se cruza con el mundo de los grandes datos. Hay mucho que explicar en todo esto. Podríamos pasar horas revisándolo con gran detalle, pero diez minutos: debería poder alejarse con solo una breve comprensión de dónde SAS ha llevado las tecnologías de análisis, gestión de datos e inteligencia empresarial en este mundo de big data.
Primero, solo un poco sobre SAS. Si no está familiarizado con esta organización, durante los últimos 38 años, hemos estado haciendo análisis avanzados, inteligencia de negocios y gestión de datos no solo con datos grandes, sino también con datos pequeños y riqueza de datos durante los últimos 38 años. Tenemos una enorme base de clientes existentes, alrededor de 75,000 sitios en todo el mundo, trabajando con algunas de las principales organizaciones que existen. Somos una organización privada con aproximadamente 13,000 empleados y $ 3 mil millones de ingresos. Y realmente, supongo, la parte importante es que tradicionalmente hemos tenido una larga historia de reinvertir cantidades significativas de nuestros ingresos en nuestra organización de I + D, lo que realmente ha aportado muchas de estas increíbles tecnologías y plataformas. vamos a ver hoy
Entonces, voy a saltar directamente a estos diagramas de arquitectura realmente aterradores. Trabajaremos de izquierda a derecha en mis diapositivas. Entonces, hay cosas familiares que verás dentro de esta plataforma. En el lado izquierdo, todas esas fuentes de datos de las que estamos hablando de ingerir en estas plataformas de big data. Y luego, tienes esta plataforma de Big Data.
No acabo de poner la palabra Hadoop allí en la parte superior, porque en última instancia, los ejemplos que voy a dar hoy están específicamente relacionados con todas las tecnologías en las que nos cruzamos con estas plataformas de big data. Resulta que Hadoop es uno de los que tenemos algunas de las opciones de implementación más sólidas, pero también nos cruzamos un poco y hemos desarrollado muchas de estas tecnologías durante algún tiempo con algunos de nuestros otros socios de almacenamiento de datos empresariales como Teradata, Oracle, Pivotal y similares. Por lo tanto, no puedo entrar en grandes detalles sobre todas las diferentes tecnologías que se admiten en cada plataforma, pero tenga la seguridad de que todas las que describo hoy son en su mayoría todo lo que Hadoop y una gran cantidad de ellas se cruza con otros socios tecnológicos que tenemos. Entonces, tenemos esa gran plataforma allí sentada.
El siguiente a la derecha, tenemos nuestro servidor analítico SAS LASR. Ahora, eso es esencialmente un servidor de aplicaciones analíticas de memoria masivamente paralelo. Queremos aclarar que no es una base de datos en memoria. Realmente está diseñado desde cero. No es el motor de consultas, sino que está diseñado para atender solicitudes analíticas a escala masiva de una manera masivamente paralela. Entonces, esas son las aplicaciones clave de servicio que ves allí en el lado derecho.
Entraremos un poco más en cómo, la gente, implementa estas cosas. Pero, esencialmente, la aplicación, ¿ve usted? La primera, es nuestra analítica de alto rendimiento SAS. Eso va a ser: estoy usando una gran cantidad de nuestra tecnología y plataformas existentes como Enterprise Miner o solo un SAS, y no solo haciendo subprocesos múltiples con algunos de esos algoritmos que hemos incorporado en esas herramientas que hemos hecho para años, pero también para paralelos masivos de esos. Por lo tanto, para mover los datos de esa plataforma de big data al espacio de memoria a ese Servidor analítico LASR, para que podamos ejecutar algoritmos analíticos, ya sabes, gran parte del nuevo aprendizaje automático, redes neuronales, regresiones forestales aleatorias, ese tipo de cosas, de nuevo, los datos que están en la memoria. Entonces, deshacerse de ese cierto cuello de botella del paradigma de MapReduce donde nos archivamos en esas plataformas, esa no es la forma en que desea hacer el trabajo analítico. Entonces, queremos poder levantar los datos una vez en el espacio de memoria e iterar a través de ellos, ya sabes, a veces miles de veces. Entonces, ese es el concepto de usar ese servidor LASR analítico de alto rendimiento.
También, las otras aplicaciones debajo, el análisis visual, que nos permite mantener esos datos en la memoria y servir a una población más grande en los mismos datos. Entonces, permitir que las personas hagan una exploración de big data. Entonces, antes de hacer nuestro trabajo de desarrollo de modelos, estamos explorando datos, entendiéndolos, ejecutando correlaciones, haciendo pronósticos o tendencias de árboles de decisión, ese tipo de cosas, pero de una manera muy visual e interactiva en los datos que están almacenados en la memoria plataforma. Eso también sirve a nuestra comunidad de BI en lo que respecta a tener una base muy amplia de usuarios que pueden acceder a esa plataforma para hacer tipos de grabación estándar que verías, que prácticamente cualquier proveedor de BI que hay.
El siguiente paso, pasamos al servicio. Y para ayudar a nuestros estadísticos y a nuestra gente de análisis a poder hacer ese tipo de modelado ad-hoc con datos almacenados en la memoria, eliminados del análisis visual y la exploración en nuestra aplicación de estadísticas visuales. Esta es una oportunidad para que la gente aproveche, para no ejecutar estadísticas en lotes que solían iterar, ejecutar los modelos, ver los resultados. Entonces, eso puede ejecutar el modelo, ver los resultados. Esto es para arrastrar y soltar visualmente en el modelado estadístico interactivo. Por lo tanto, esto les sirve a nuestros estadísticos y a nuestros científicos de datos para que hagan mucho de ese trabajo exploratorio temprano de estadística visual.
Y luego, no nos hemos olvidado de nuestros codificadores: la gente que realmente quiere tener, poder pelar las capas de la interfaz opuesta, es escribir aplicaciones y escribir su propia base de código en SAS. Y esas son nuestras estadísticas en memoria para Hadoop. Y esa es, esencialmente, la capa de código que nos permitió interactuar con ese servidor LASR analítico para emitir comandos directamente y personalizar esas aplicaciones en función de nuestra solicitud. Esa es la pieza analítica.
Cómo se configuran estas cosas ... Oops, lo siento chicos. Aquí vamos.
Entonces, hay realmente un par de formas en que hacemos esto. Una es hacerlo con big data, en este caso, con Hadoop. Y ahí es donde tenemos ese servidor analítico SAS LASR ejecutándose en un grupo separado de máquinas que están optimizadas para análisis hardcore. Esto está ubicado agradable y cerca de la plataforma de Big Data, lo que nos permite escalarlo por separado de la plataforma de Big Data. Entonces, vemos que las personas hacen esto cuando no quieren tener algo de lo que yo caracterizo como un software de vampiro carcomiendo cada uno de los nodos en su grupo de Hadoop. Y no necesariamente escalan esa plataforma de big data apropiada para realizar análisis pesados en memoria. Por lo tanto, puede tener 120 nodos de su clúster Hadoop, pero pueden tener 16 nodos de servidores analíticos diseñados para hacer ese tipo de trabajo.
Todavía se nos permite mantener ese paralelismo de la plataforma de big data para extraer los datos en la memoria. Entonces, realmente se trata de usar SAS con la plataforma Hadoop. Un modelo de cita diferente es decir, bueno, también podemos usar esa plataforma de productos básicos e impulsar eso, esencialmente ejecutar el servidor analítico LASR en las plataformas Hadoop. Entonces, ahí es donde estamos ... estás operando dentro de la plataforma de Big Data. También son algunos de nuestros otros proveedores de electrodomésticos. Entonces, eso nos ha permitido usar esencialmente esa plataforma de productos básicos para hacer ese trabajo.
Vemos que más a menudo con cosas como análisis de alto rendimiento donde se trata de una ejecución analítica de una sola porción o de un solo uso, más tipo de lote orientado a donde estás: no necesariamente quieres consumir el espacio de memoria en Hadoop plataforma. Somos muy flexibles en este tipo de modelo de implementación, definitivamente en nuestro trabajo con YARN en muchos de estos casos para asegurarnos de que estamos jugando buenos clústeres.
Bien, ese es el mundo analítico, solo para que quede claro con la aplicación analítica. Pero mencioné que SAS desde el principio también es una plataforma de gestión de datos. Y hay cosas que son apropiadas para impulsar la lógica en esa plataforma cuando sea apropiado. Entonces, hay un par de formas en que hacemos eso. Una es en el mundo de la integración de datos, hacer un trabajo de transformación de datos en los datos puede no tener sentido retirarlos como lo hemos escuchado antes, ejecutando rutinas de calidad de datos que son importantes. Definitivamente queremos impulsar cosas como rutinas de calidad de datos en esa plataforma. Y luego, cosas como el modelo de puntuación. Entonces, tengo mi modelo desarrollado. No quiero volver a escribir esa cosa en MapReduce y hacer que sea difícil y me tome mucho tiempo volver a hacer ese trabajo en la plataforma de base de datos nativa.
Entonces, si observa, por ejemplo, nuestro acelerador de puntuación para Hadoop, eso nos permite esencialmente tomar un modelo y empujar la lógica matemática SAS hacia esa plataforma Hadoop y ejecutarla allí, utilizando el paralelismo que está dentro de esa plataforma de big data. Luego tenemos nuestro acelerador de código para varias plataformas, incluido Hadoop, y eso nos permite ejecutar esencialmente el código de paso de datos SAS dentro de la plataforma de una manera masivamente paralela, por lo que hacemos trabajos de transformación de datos en la plataforma. Y luego nuestro acelerador de calidad de datos SAS que nos permite tener una base de conocimiento de calidad que puede hacer cosas como la coincidencia de género, el código de coincidencia de estandarización, todas las diferentes cosas de calidad de datos que ya ha escuchado hoy.
Y luego, la última pieza, está el Cargador de datos. Sabemos que los usuarios de nuestra empresa tendrán que ser capaces de no tener que escribir código, realizar trabajos de transformación de datos en estas plataformas de big data. Data Loader es una buena GUI WYSIWYG que nos permite agrupar esas otras tecnologías. Es como un asistente de recorrido para, por ejemplo, ejecutar una consulta de Hive o ejecutar una rutina de calidad de datos y no tener que escribir código en ese caso.
Lo último que mencionaré es esta pieza frontal. Tenemos, como mencioné antes, un enorme pie SAS en el mundo. Y esto, no podemos hacer necesariamente todas esas plataformas que están ahí fuera para estar en este espacio de inmediato. Por lo tanto, definitivamente tenemos un grupo existente de usuarios que necesitan obtener datos en estas plataformas de big data, como extraer datos de Teradata y volver a colocarlos en Hadoop, y viceversa. Ejecutando los modelos que ya sé cómo ejecutar en mis servidores SAS, pero necesito obtener datos que ahora se están colocando en la plataforma Hadoop. Entonces, hay este otro pequeño ícono llamado "desde", y que nos permite conectarnos usando nuestros motores de acceso SAS: motores de acceso a Hadoop a Cloudera en Pola, a Teradata, a Greenplum para ... Y la lista continúa. Esto nos permite utilizar nuestras plataformas SAS maduras existentes que ya están en su lugar para obtener datos de estas plataformas, hacer el trabajo que tenemos que hacer e impulsar los resultados nuevamente en estas áreas.
Lo último que mencionaré es que todas estas tecnologías que ves están regidas por los mismos metadatos comunes estándar. Por lo tanto, hablamos de hacer que la transformación funcione, la regla de calidad de los datos en el trabajo, moverla a la memoria para poder realizar análisis, desarrollar modelos en la puntuación. Llegamos allí al estilo de vida analítico completo, el ciclo de vida se rige por metadatos comunes, por la gobernanza, por la seguridad, por todas las cosas de las que hablamos hoy.
Entonces, solo una recapitulación, realmente hay esas tres grandes cosas para llevar allí. Una es que podemos tratar la plataforma de datos como cualquier otra fuente de datos, extrayéndolos, empujándolos cuando sea apropiado y conveniente. Podemos trabajar con esas grandes plataformas de datos, enumerando datos en una plataforma analítica avanzada especialmente diseñada en memoria. Entonces, ese es el servidor LASR.
Y luego, por último, podemos trabajar directamente en esas plataformas de big data, aprovechando sus capacidades de procesamiento distributivo sin mover los datos.
Eric: Bueno, eso es algo fantástico, amigos. Sí, esto es genial! Entonces, veamos algunas preguntas. Por lo general, pasamos unos 70 minutos o un poco más en estos eventos. Entonces, veo que todavía tenemos una gran audiencia sentada allí. George, supongo que te enviaré nuestra primera pregunta. Si habla acerca de insertar su sonido binario en Hadoop, creo que eso me parece que realmente ha optimizado el flujo de trabajo computacional. Y esa es la clave para poder hacer este tipo de gobierno de datos en tiempo real, logros de estilo de calidad de datos, porque ese es el valor que desea obtener, ¿verdad? Si no desea volver al viejo mundo de MDM, donde es muy engorroso y requiere mucho tiempo, y realmente tiene que obligar a las personas a actuar de ciertas maneras, lo que casi nunca funciona. Entonces, lo que has hecho es condensar el ciclo de lo que fue. Digámoslo días, semanas, a veces incluso meses o segundos, ¿verdad? ¿Es eso lo que está pasando?
George: Eso es exactamente correcto, porque la escala que obtenemos y el rendimiento que obtenemos de un clúster es realmente asombroso en términos de, solo, ya sabes, siempre dudo un poco sobre los puntos de referencia. Pero solo por el orden de magnitud, cuando ejecutamos mil millones, 1.2 mil millones de registros y hacemos una estandarización de direcciones completa, digo máquina de HP de rango medio, tomaría, como, ya sabes, ocho máquinas de procesador, ya sabes , 2 gigas de RAM por núcleo, ya sabes, eso tomaría 20 horas en ejecutarse. Podemos hacerlo en aproximadamente ocho minutos ahora en un clúster de 12 nodos. Y así, la escala del procesamiento que podemos hacer ahora es tan dramáticamente diferente que va muy bien con la idea de que tiene todos estos datos a su disposición. Por lo tanto, no es tan arriesgado hacer el procesamiento. Si lo hiciste mal, puedes rehacerlo. Tienes tiempo, ya sabes. Realmente cambió la escala de esto donde, ya sabes, ese tipo de riesgos realmente se convirtieron en verdaderos problemas comerciales para las personas cuando intentaban operar soluciones MDM. Debe tener 30 personas en el exterior que se encarguen de la gobernanza de datos y todo. Y así, todavía tiene que tener algo de eso, pero la velocidad y la escala a la que puede procesarlo ahora, realmente le da mucho más espacio para respirar.
Eric: Sí, ese es un muy, muy buen punto. Me encanta ese comentario Entonces, tienes tiempo para rehacerlo de nuevo. Eso es fantástico.
George: si.
Eric: Bueno, cambia la dinámica, ¿verdad? Cambia tu forma de pensar sobre lo que vas a intentar. Quiero decir, recuerdo esto hace 18 años en la industria de hacer efectos especiales, porque tenía un cliente que estaba en ese espacio. Y presionarías los botones para renderizarlo y volverías a casa. Y volverías, tal vez el sábado por la tarde, para ver cómo te iba. Pero si te equivocaste, eso fue muy, muy, muy doloroso. Y ahora, no está cerca, ni siquiera está cerca de ser tan doloroso, así que tienes la oportunidad de probar más cosas. Tengo que decir que creo que es un muy, muy buen punto.
George: Eso es exactamente correcto. Sí, y te vuelas la pierna extra. Ya sabes, te encuentras a mitad de un trabajo en los viejos tiempos y si falla, has volado tu SOS. Eso es.
Eric: bien. Y estás en un gran problema, sí. Eso es correcto.
George: Eso es correcto. Eso es correcto.
Eric: Keith, déjame arrojarte uno. Recuerdo haber hecho una entrevista con tu CIL, Keith Collins, creo que, creo que en 2011 quizás. Y habló mucho sobre la dirección que SAS estaba tomando específicamente con respecto al trabajo con los clientes para integrar los análisis derivados de SAS en los sistemas operativos. Y, por supuesto, escuchamos a Mike Ferguson hablar sobre la importancia de recordar. La idea aquí es que quieras poder vincular estas cosas a tus operaciones. No desea un análisis en el vacío, desconectado de la empresa. Eso no tiene ningún valor.
Si desea un análisis que pueda impactar directamente y optimizar las operaciones. Y si miro hacia atrás, y tengo que decir que pensé que era una buena idea en ese entonces, parece una idea muy, muy inteligente en retrospectiva. Y supongo que es una verdadera ventaja que ustedes tienen. Y, por supuesto, este gran legado, esta enorme base de instalación y el hecho de que se haya centrado en integrar estos análisis en los sistemas operativos, lo que significa que ahora, y concedido, tomará algo de trabajo, estoy seguro de que ' Lo he estado trabajando bastante duro. Pero ahora, puede aprovechar todas estas nuevas innovaciones y realmente está en términos de poder poner en práctica todo eso con sus clientes. ¿Es esa una evaluación justa?
Keith: Sí, absolutamente. El concepto es que se obtiene esta idea del diseño de decisiones o de las ciencias de decisión, que es, en cierta medida, algo que es exploratorio y científico. A menos que pueda hacer ingeniería en el proceso para realmente ... Si piensa en desarrollar un automóvil, tiene diseñadores que fabrican este hermoso automóvil, pero no es hasta que los ingenieros ponen en práctica ese plan y hacen un producto viable real antes que usted en realidad puede poner las cosas en su lugar, y eso es esencialmente lo que ha hecho SAS. Ha fusionado las decisiones: el proceso de diseño de decisiones con el proceso de ingeniería de decisiones juntos, de modo que cuando habla sobre los aceleradores, los aceleradores de puntuación específicamente, ya sabe, si toma un modelo que desarrolló y podrá sacarlo a Teradata, o enviarlo a Oracle o Hadoop, con cero tiempo de inactividad para el desarrollo del modelo, para la implementación del modelo. Esa es la clave, porque los modelos se degradan con el tiempo, la precisión de esos modelos. Por lo tanto, cuanto más tarde en tomarlo y ponerlo en producción, eso es pérdida de precisión del modelo.
Y luego, la otra parte es que desea poder monitorear y administrar ese proceso a lo largo del tiempo. Desea desaprobar modelos cuando se vuelven viejos e inexactos. Desea verlo, verificar la precisión de ellos con el tiempo y reconstruirlos. Y así, también tenemos herramientas de gestión de modelos que se encuentran encima de eso, que realmente siguen los metadatos en torno al proceso modelado. Y la gente ha dicho que modelar, ya sabes, ese tipo de concepto es como una fábrica de modelos, o como quieras llamarlo. La cuestión es que está poniendo en proceso los metadatos y la gestión y ahí es donde nos encontramos con las tres cosas más importantes: ayudamos a las personas a ganar dinero, ahorrar dinero y mantenerlos fuera de la cárcel.
Eric: Ese último también es bastante grande. Estoy buscando evitar todo eso. Entonces, hablemos de ...Estoy dando una última pregunta, tal vez ambos puedan saltar sobre esto. Me parece que la heterogeneidad de nuestro mundo solo aumentará. Creo que definitivamente vamos a ver cristalización en entornos de nube híbrida. Pero, no obstante, verás a muchos de los principales jugadores quedarse. IBM no va a ninguna parte. Oracle no va a ninguna parte. SAP no va a ninguna parte. Y hay muchos otros proveedores que participan en este juego.
Además, en el lado operativo, donde tiene literalmente miles y miles de diferentes tipos de aplicaciones. Y escuché: la mayoría de ustedes habla de esto, pero creo que ambos estarían de acuerdo con lo que he estado diciendo. Hemos visto esta tendencia ahora en términos de potencia computacional en motores analíticos, arquitectura. Las empresas han estado hablando durante años sobre la posibilidad de aprovechar los otros motores y dar servicio a una especie de punto de orquestación. Y supongo, George, que te lo arrojaré primero. Me parece que eso es algo que no va a cambiar. Vamos a tener este entorno heterogéneo, lo que significa que hay cosas como CRM en tiempo real y calidad de datos y gobernanza de datos. Necesitará, como proveedor, interactuar con todas esas herramientas diferentes. Y eso es lo que los clientes van a querer. No van a querer algo que funcione bien con estas herramientas y no con esas herramientas. Van a querer la Suiza de MDM y CRM, ¿verdad?
George: Eso es correcto. Y es interesante, porque lo hemos aceptado mucho. Parte de esto es la historia que tuvimos en el espacio. Y obviamente, ya estábamos trabajando en todas las otras bases de datos, las Teradatas y las piezas del mundo. Y luego, en el proceso de implementación, específicamente en la forma en que lo hicimos, solo para que tengas esa capacidad en todas estas bases de datos. Una de las cosas que me parece interesante es que tenemos algunos clientes que están decididos a eliminar todas las bases de datos relacionales. Y eso es interesante. Sabes, quiero decir, está bien. Es interesante. Pero no veo que realmente suceda a gran escala empresarial. No veo que suceda por mucho tiempo. Entonces, creo que el híbrido está aquí por mucho tiempo y en el otro lado de nuestra aplicación, donde tenemos nuestra plataforma de mensajería en nuestra plataforma de gestión de campañas. De hecho, lo hemos diseñado específicamente. Ahora, hemos lanzado una versión que hace eso y que puede conectarse ahora al entorno de datos híbrido y consultar Hadoop, o consultar cualquier base de datos, cualquier base de datos analítica. Entonces, creo que esa es solo la ola del futuro. Y estoy de acuerdo en que la virtualización sin duda jugará un papel importante en esto, pero simplemente estamos yendo directamente a los datos de todas nuestras aplicaciones.
Eric: Está bien, genial. Y, Keith, te lo arrojaré. ¿Qué opinas sobre el mundo heterogéneo que enfrentamos al actuar como una especie de pie?
Keith: Sí, es realmente fascinante. Creo que lo que encontramos más, no solo en el lado de la gestión de datos, sino que lo que es realmente fascinante en este momento es la naturaleza de código abierto de la base de análisis. Entonces, vemos organizaciones como, o tecnologías como Spark, y personas que usan Python y R y todas estas otras tecnologías de código abierto. Creo que podría interpretarse como una especie de conflicto o amenaza hasta cierto punto. Pero la realidad es que tenemos algunos cumplidos realmente maravillosos con todas esas tecnologías de código abierto. Quiero decir, por un lado, estamos operando sobre plataformas de código abierto, por el amor de Dios.
Pero también, como poder integrar, por ejemplo, un modelo R en un paradigma SAS le permite usar lo mejor de ambos mundos, ¿verdad? Por ejemplo, sabemos que algunas de las cosas experimentales en el mundo académico y parte del trabajo de desarrollo del modelo son extraordinarias y muy útiles en el proceso de desarrollo del modelo. Pero también, si pudieras emparejar eso con una herramienta de clase de producción, hace una gran cantidad de limpieza y calidad, y verifica y se asegura de que los datos que se entregan al modelo se hayan preparado correctamente para que no falle en ejecución. Y luego, poder hacer cosas como modelos campeones desafiantes con modelos de código abierto. Esas son las cosas que estamos buscando para habilitar, y como parte de este ecosistema realmente heterogéneo de todas estas tecnologías. Sí, es más, para nosotros, se trata más de adoptar esas tecnologías y buscar los cumplidos.
Eric: Bueno, esto ha sido algo fantástico, amigos. Pasamos un poco largo aquí, pero nos gustaría llegar a la mayor cantidad de preguntas posible. Hoy enviaremos el archivo de preguntas y respuestas a nuestros presentadores. Entonces, si alguna pregunta que hizo no fue respondida, nos aseguraremos de que se responda. Y amigos, esto lo concluye para 2014. Sinceramente en el DM Radio mañana y la próxima semana, y luego todo está hecho y es un descanso de vacaciones.
Muchas gracias a todos por su tiempo y atención, por seguir estos maravillosos webcasts. Tenemos un gran año para el 2015. Y hablaremos pronto, amigos. Gracias de nuevo. Bien, ten cuidado. Adiós.