Por el personal de Techopedia, 2 de junio de 2016
Para llevar: El ecosistema de Hadoop se está utilizando en mainframes para procesar grandes datos de manera rápida y eficiente.
Actualmente no has iniciado sesión. Inicia sesión o regístrate para ver el video.
Eric Kavanagh: Bueno, damas y caballeros, son las cuatro en punto del este de un jueves, y en estos días eso significa que, por supuesto, es hora de Hot Technologies. Sí, de hecho, mi nombre es Eric Kavanagh. Seré su moderador para el seminario web de hoy. Es algo bueno, amigos, "Big Iron, Meet Big Data". Me encanta ese titular: "Liberando datos de mainframe con Hadoop y Spark". Vamos a hablar sobre lo viejo y lo nuevo. ¡Guauu! Estamos cubriendo el espectro de todo lo que hemos hablado en los últimos 50 años de TI empresarial. Spark se encuentra con mainframe, me encanta.
Hay un lugar sobre el tuyo verdaderamente y suficiente sobre mí. El año es caluroso. Hablamos de temas candentes en esta serie porque realmente estamos tratando de ayudar a la gente a comprender ciertas disciplinas, ciertos espacios. ¿Qué significa, por ejemplo, tener una plataforma analítica? ¿Qué significa liberar big data de mainframes? ¿Qué significa todo esto? Estamos tratando de ayudarlo a comprender tipos específicos de tecnologías, dónde encajan en la combinación y cómo puede utilizarlas.
Tenemos dos analistas hoy y luego, por supuesto, Tendü Yogurtçu de Syncsort. Es una visionaria en nuestro espacio, muy contenta de tenerla en línea hoy, con nuestro propio Dez Blanchfield y el Dr. Robin Bloor. Diré solo un par de palabras rápidas. Una es que, amigos, ustedes juegan un papel importante en este proceso, así que no sean tímidos al hacer algunas buenas preguntas. Nos gustaría llegar a ellos durante el componente de preguntas y respuestas de la transmisión web, que generalmente se encuentra al final del programa. Y todo lo que tengo que decir es que tenemos mucho contenido bueno, así que estoy emocionado de escuchar lo que estos chicos tienen que decir. Y con eso, se lo entregaré a Dez Blanchfield. Dez, el piso es tuyo, quítalo.
Dez Blanchfield: Gracias Eric y gracias a todos por asistir hoy. Así que me emociono mucho cuando tengo la oportunidad de hablar sobre una de mis cosas favoritas en el mundo, los mainframes. No reciben mucho amor en estos días. Mi opinión es que el mainframe era la plataforma original de Big Data. Algunos argumentarían que eran la única computadora en ese momento y ese es un punto justo que destacar, pero durante más de 60 años realmente han sido realmente la sala de máquinas de lo que los grandes datos han sido populares en los últimos tiempos. Y te llevaré a un pequeño viaje sobre por qué creo que ese es el caso.
Hemos visto un viaje en las pilas de hardware de tecnología en el contexto del cambio de mainframes desde la imagen que ves en la pantalla ahora. Este es un viejo mainframe de FACOM, uno de mis favoritos. Nos hemos trasladado a la gran fase de hierro, a finales de los noventa y al boom de las puntocom. Este es el Sun Microsystems E10000. Esta cosa era un monstruo absoluto con 96 CPU. Originalmente 64 pero podría actualizarse a 96 CPU. Cada CPU podría ejecutar 1.024 hilos. Cada hilo podría estar a la tasa de aplicación al mismo tiempo. Fue simplemente monstruoso y en realidad impulsó el boom de las puntocom. Estos son todos los grandes unicornios como los llamamos, ahora estamos en funcionamiento, y no solo las grandes empresas, algunos de los grandes sitios web.
Y luego terminamos con este modelo de PC común y común. Solo unimos muchas máquinas baratas y creamos un clúster y nos acercamos al gran desafío del hierro y lo que se convirtió en grandes datos, particularmente en la forma del proyecto Hadoop que surgió del motor de búsqueda de código abierto, Nutch. Y esencialmente recreamos el mainframe y muchas pequeñas CPU que se unieron y pudieron actuar como rutas en L y en la forma de ejecutar trabajos separados o partes de trabajos, y fueron bastante efectivos en muchos aspectos. Más barato si comenzaste más pequeño, pero invariablemente muchos de estos grandes grupos se han vuelto más caros que un mainframe.
Mi punto de vista sobre estas cosas es que en el apuro del auge de las punto com a través de lo que se convirtió en Web 2.0 y ahora persiguiendo unicornios, hemos olvidado que esta plataforma todavía está impulsando muchos de nuestros sistemas de misión crítica más grandes. Cuando pensamos en lo que se está ejecutando en las plataformas de mainframe. Es en gran medida el big data, particularmente el caballo de batalla de datos, pero ciertamente big data. Los sistemas empresariales y gubernamentales tradicionales, como la banca y la gestión del patrimonio y los seguros en particular, todos los utilizamos todos los días.
Sistemas de reserva de vuelos y gestión de vuelos, particularmente gestión de vuelos donde el tiempo real es crítico. Casi todos los gobiernos estatales y federales en algún momento han tenido un mainframe e invariablemente muchos todavía los tienen. Venta minorista y fabricación. Algunos de los viejos programas que han existido y que nunca desaparecieron. Simplemente continúa impulsando entornos de fabricación y, ciertamente, minorista a escala. Sistemas medicos. Sistemas de defensa, ciertamente sistemas de defensa.
En estas últimas semanas, he leído muchos artículos sobre el hecho de que algunos de los sistemas de control de misiles todavía se están ejecutando en mainframes antiguos para los que tienen dificultades para encontrar piezas. Están descubriendo cómo actualizarse a nuevos mainframes. Sistemas de transporte y logística. Puede que estos no suenen como temas sexys, pero estos son los temas que tratamos diariamente a través de las líneas. Y algunos entornos de telecomunicaciones muy grandes todavía se ejecutan en plataformas mainframe.
Cuando piensa en los tipos de datos que hay allí, todos son de misión crítica. Son plataformas realmente importantes y plataformas que damos por sentado todos los días y que, en muchos sentidos, hacen posible la vida. Entonces, ¿quién sigue usando un mainframe y quiénes son todas estas personas que se aferran a estas grandes plataformas y tienen todos estos datos? Bueno, como dije aquí, creo que es fácil dejarse engañar por el cambio de los medios de comunicación del gran hierro a los bastidores de clústeres comunes disponibles o PC baratas o máquinas x86, para pensar que la unidad central murió y se fue. Pero los datos dicen que el mainframe nunca desapareció y, de hecho, llegó para quedarse.
La investigación que he reunido aquí en las últimas semanas ha demostrado que el 70 por ciento de los datos de la empresa, especialmente de las grandes empresas, aún reside en una unidad central de alguna forma. El setenta y uno por ciento de los Fortune 500 todavía ejecutan sistemas comerciales centrales en mainframes en algún lugar. De hecho, aquí en Australia, tenemos una serie de organizaciones que tienen un centro de datos en el centro de una ciudad. Es una computadora subterránea real de manera efectiva, y la cantidad de mainframes simplemente ejecutándose allí, haciendo tictac y felizmente haciendo su trabajo. Y muy pocas personas saben que caminando por las calles, justo debajo de sus pies en una parte particular de la ciudad, hay un enorme centro de datos lleno de mainframes. Noventa y dos de cada 100 de los bancos de todo el mundo, los 100 bancos más importantes, todavía tienen sistemas bancarios en mainframes. Veintitrés de las 25 principales cadenas minoristas de todo el mundo utilizan mainframes para seguir ejecutando sus sistemas de gestión minorista en plataformas EIP y BI.
Curiosamente, 10 de las 10 principales aseguradoras aún ejecutan sus plataformas en mainframe, y en realidad potencian sus servicios en la nube en mainframe. Si está utilizando una interfaz web o una aplicación móvil en algún lugar donde hay una interfaz de middleware, eso realmente habla con algo realmente pesado y grande en la parte posterior.
Encontré más de 225 agencias gubernamentales estatales y locales en todo el mundo que todavía se ejecutan en plataformas mainframe. Estoy seguro de que hay muchas razones para eso. Tal vez no tienen el presupuesto para considerar un nuevo hierro, pero esa es una gran huella de entornos muy grandes que se ejecutan en mainframe con algunos datos muy críticos. Y como mencioné anteriormente, la mayoría de las naciones aún manejan sus sistemas de defensa clave en mainframe. Estoy seguro de que, en muchos sentidos, están tratando de bajar, pero ahí lo tienes.
En 2015, IDC realizó una encuesta y 350 de los CIO encuestados informaron que aún poseían y administraban grandes planchas en forma de mainframes. Y me llamó la atención que es probable que sea más que la cantidad de clústeres de Hadoop a gran escala que actualmente se ejecutan en todo el mundo en producción, una pequeña estadística interesante allí. Voy a seguir adelante y validar eso, pero fue un gran número. Trescientos cincuenta CIO informaron que todavía tienen uno o más mainframes en producción.
El año pasado, 2015, IBM nos dio el poderoso Z13, la 13ª iteración de su plataforma mainframe. Los medios se volvieron locos por esto porque estaban asombrados de que IBM todavía estuviera haciendo mainframes. Cuando levantaron el capó y observaron lo que había debajo de la cosa, se dieron cuenta de que en realidad estaba a la par con casi todas las plataformas modernas por las que nos habíamos entusiasmado en forma de big data, Hadoop y ciertamente los grupos. Esta cosa corrió Spark y ahora Hadoop de forma nativa. Podría ejecutar miles y miles de máquinas Linux en él y se veía y se sentía como cualquier otro clúster. Era toda una máquina asombrosa.
Varias organizaciones tomaron estas cosas y, de hecho, hice algunos datos sobre cuántas de estas máquinas están ocupando. Ahora tengo la opinión de que el terminal de texto 3270 ha sido reemplazado por navegadores web y aplicaciones móviles durante algún tiempo y hay muchos datos que lo respaldan. Creo que ahora estamos entrando en una era en la que nos hemos dado cuenta de que estos mainframes no van a desaparecer y que hay una gran cantidad de datos sobre ellos. Entonces, lo que estamos haciendo ahora es simplemente agregar lo que llamo herramientas de análisis estándar. Estas no son aplicaciones personalizadas. Estas son cosas que son personalizadas a medida. Estas son cosas que literalmente puedes comprar en una caja empaquetada per se y conectar a tu mainframe y hacer algunos análisis.
Como dije antes, el mainframe ha existido por más de 60 años, de hecho. Cuando pensamos en cuánto tiempo es, eso es más de lo que la mayoría de las carreras de los profesionales de TI viven. Y, de hecho, probablemente algunas de sus vidas, incluso. En 2002, IBM vendió 2, 300 mainframes. En 2013 eso creció a 2, 700 mainframes. Esas son 2.700 ventas de mainframes en un año en 2013. No pude obtener datos precisos sobre 2015, pero imagino que se está acercando rápidamente a las 3.000 unidades vendidas por año en 2015, 2013. Y espero poder confirmar eso.
Con el lanzamiento del Z13, la 13ª iteración de una plataforma mainframe, que creo que les costó alrededor de 1.2 o 1.3 mil millones de dólares desarrollar desde cero, IBM, es decir, aquí hay una máquina que se ve y se siente como cualquier otro clúster que tenemos hoy, y de forma nativa ejecuta Hadoop y Spark. Y ciertamente puede conectarse desde otras herramientas de análisis y big data o invariablemente conectarse a uno de sus clústeres de Hadoop existentes o nuevos. Tengo esta opinión de que es imprescindible incluir la plataforma mainframe en su estrategia de big data. Obviamente, si tienes uno, tienes muchos datos y quieres descubrir cómo sacarlos de allí. Y se les deja acumular polvo de muchas maneras, mental y emocionalmente en lo que respecta al mundo de los negocios, pero están aquí para quedarse.
La conectividad y las interfaces para todas sus herramientas de análisis a los datos alojados en el mainframe deberían ser una parte clave de su empresa y particularmente de los planes de big data del gobierno. E invariablemente, ahora el software los está notando, mirándolos detenidamente y dándose cuenta de lo que hay dentro de estas cosas y conectando las mentes que comienzan a tener un poco de información y una idea de lo que realmente está bajo el capó. Y con eso voy a entregar a mi querido colega, el Dr. Robin Bloor, y él agregará a ese pequeño viaje. Robin, llévatelo.
Robin Bloor: Bueno, gracias. De acuerdo, bueno, dado que Dez ha cantado la canción del mainframe, entraré en lo que creo que está sucediendo en términos del viejo mundo del mainframe y el nuevo mundo de Hadoop. Supongo que la gran pregunta aquí es, ¿cómo manejas todos esos datos? No es mi opinión que el mainframe esté siendo desafiado con respecto a su capacidad de big data: su capacidad de big data es extremadamente, como ha señalado Dez, es extremadamente capaz. De hecho, puede poner clústeres de Hadoop en él. Donde está siendo desafiado es en términos de su ecosistema y voy a dar más detalles sobre eso.
Aquí hay un posicionamiento de mainframe. Tiene un alto costo de entrada y lo que realmente sucedió en el pasado, desde mediados de los años 90, cuando la popularidad de los mainframes comenzó a caer, tendió a perder su bajo nivel, esas personas que compraron mainframes baratos y no fue así. No es realmente particularmente económico para esas personas. Pero más arriba, en realidad, en el rango medio y alto del mainframe, todavía era, y es demostrable en realidad, una informática increíblemente económica.
Fue, debe decirse, rescatado por Linux porque Linux implementado en un mainframe hizo posible, por supuesto, ejecutar todas las aplicaciones de Linux. Muchas aplicaciones de Linux fueron allí antes de que Big Data fuera incluso una palabra, o dos palabras, supongo. En realidad, es una plataforma bastante excelente para la nube privada. Por eso puede participar en implementaciones de nube híbrida. Uno de los problemas es que las habilidades de mainframe son escasas. Las habilidades de mainframe que existen en realidad están envejeciendo en el sentido de que las personas abandonan la industria para retirarse año tras año y solo están siendo reemplazadas en términos de la cantidad de personas. Entonces ese es un problema. Pero todavía es una informática económica.
El área donde ha sido cuestionada, por supuesto, es todo esto de Hadoop. Esa es una foto de Doug Cutting con el elefante Hadoop original. El ecosistema de Hadoop es, y seguirá siendo, el ecosistema dominante de big data. Ofrece una mejor escalabilidad que la que puede lograr el mainframe y es mucho más económico como almacén de datos. El ecosistema de Hadoop está evolucionando. La mejor manera de pensar sobre esto es una vez que una plataforma de hardware en particular y el entorno operativo con ella se vuelve dominante, luego el ecosistema simplemente cobra vida. Y eso sucedió con el mainframe de IBM. Bueno, más tarde sucedió con el VAX digital, sucedió con los servidores de Sun, sucedió con Windows, sucedió con Linux.
Y lo que sucedió es que Hadoop, que siempre pienso, o me gusta pensar, como una especie de entorno distribuido para datos, el ecosistema está evolucionando a un ritmo increíble. Quiero decir, si solo mencionas las diversas contribuciones impresionantes que son de código abierto, Spark, Flink, Kafka, Presto, y luego agregas a eso algunas de las bases de datos, las capacidades NoSQL y SQL que ahora se encuentran en Hadoop. Hadoop es el ecosistema más activo que existe en la actualidad, ciertamente en informática corporativa. Pero si desea tratarlo como una base de datos, no tiene comparación en este momento con lo que tiendo a considerar como bases de datos reales, especialmente en el espacio del almacén de datos. Y eso explica en cierta medida el éxito de varias de las grandes bases de datos NoSQL que no se ejecutan en Hadoop como CouchDB, etc.
Como lago de datos, tiene un ecosistema mucho más rico que cualquier otra plataforma y no va a ser desplazado de eso. Su ecosistema no es solo el ecosistema de código abierto. Ahora hay un número dramático de miembros de software que tienen productos que están diseñados fundamentalmente para Hadoop o que han sido importados a Hadoop. Y acaban de crear un ecosistema en el que no hay nada que pueda competir con él en términos de su amplitud. Y eso significa que realmente se ha convertido en la plataforma para la innovación de big data. Pero en mi opinión todavía es inmadura y podríamos tener largas discusiones sobre qué es y qué no es, digamos, operacionalmente maduro con Hadoop, pero creo que la mayoría de las personas que están mirando esta área en particular son conscientes de que Hadoop está décadas atrás del mainframe en términos de capacidad operativa.
El lago de datos en evolución. El lago de datos es una plataforma, por cualquier definición, y si piensa que hay una capa de datos en la informática corporativa ahora, es muy fácil pensar en términos de bases de datos fijas más el lago de datos que constituye la capa de datos. Las aplicaciones del lago de datos son muchas y variadas. Tengo un diagrama aquí que solo repasa los diversos problemas de datos que deben hacerse si usa Hadoop como área de preparación o Hadoop and Spark como área de preparación. Y usted tiene todo: linaje de datos, limpieza de datos, gestión de metadatos, descubrimiento de metadatos: puede usarse para ETL en sí, pero a menudo requiere que ETL traiga los datos. Gestión de datos maestros, definiciones comerciales de datos, gestión de servicios de qué está sucediendo en Hadoop, la gestión del ciclo de vida de los datos y ETL fuera de Hadoop, y también tiene aplicaciones de análisis directo que puede ejecutar en Hadoop.
Y es por eso que se ha vuelto muy poderoso y donde se ha implementado e implementado con éxito, normalmente tiene al menos una colección de este tipo de aplicaciones ejecutándose sobre él. Y la mayoría de esas aplicaciones, particularmente las que me han informado, simplemente no están disponibles en el mainframe en este momento. Pero podría ejecutarlos en el mainframe, en un clúster de Hadoop que se estaba ejecutando en una partición del mainframe.
El lago de datos se está convirtiendo, en mi opinión, en el área de preparación natural para el análisis rápido de bases de datos y para BI. Se convierte en el lugar donde toma los datos, ya sean datos corporativos o datos externos, lo manipula hasta que sea, digamos, lo suficientemente limpio como para usarlo y bien estructurado para usarlo y luego lo pasa. Y todo esto todavía está en su infancia.
La idea, en mi opinión, de la coexistencia de mainframe / Hadoop, lo primero es que es poco probable que las grandes empresas abandonen el mainframe. De hecho, las indicaciones que he visto recientemente implican que hay una creciente inversión en el mainframe. Pero tampoco van a ignorar el ecosistema de Hadoop. Veo cifras del 60 por ciento de las grandes empresas que usan Hadoop, incluso si muchas de ellas son solo prototipos y experimentos.
El enigma es: "¿Cómo haces que estas dos cosas coexistan?" Porque van a necesitar compartir datos. Los datos que se introducen en el lago de datos deben transferirse al mainframe. Los datos que se encuentran en el mainframe pueden necesitar ir al lago de datos o a través del lago de datos para unirse a otros datos. Y eso va a suceder. Y eso significa que requiere una rápida transferencia de datos / capacidad ETL. Es poco probable que las cargas de trabajo se compartan dinámicamente en, digamos, un entorno mainframe o con algo en un entorno Hadoop. Serán datos compartidos. Y la mayoría de los datos inevitablemente residirá en Hadoop simplemente porque es la plataforma de menor costo. Y el procesamiento analítico de extremo a extremo probablemente también residirá allí.
En resumen, en última instancia, debemos pensar en términos de una capa de datos corporativos, que para muchas empresas incluirá el mainframe. Y esa capa de datos debe administrarse de manera proactiva. De lo contrario, los dos no coexistirán bien. Puedo devolverte la pelota, Eric.
Eric Kavanagh: Nuevamente, Tendü, acabo de hacerte el presentador, así que quítatelo.
Tendü Yogurtçu: Gracias Eric. Gracias por tenerme. Hola a todos. Hablaré sobre la experiencia de Syncsort con los clientes en relación con la forma en que vemos los datos como un activo en la organización que se nivela desde mainframe a big data en plataformas de análisis. Y espero que también tengamos tiempo al final de la sesión para recibir preguntas de la audiencia, porque esa es realmente la parte más valiosa de estos webcasts.
Solo para las personas que no saben lo que hace Syncsort, Syncsort es una compañía de software. Hemos estado alrededor en realidad más de 40 años. Comenzó en el lado de mainframe y nuestros productos abarcan desde mainframe hasta Unix y plataformas de big data, incluidos Hadoop, Spark, Splunk, tanto en las instalaciones como en la nube. Nuestro enfoque siempre ha estado en productos de datos, procesamiento de datos y productos de integración de datos.
Nuestra estrategia con respecto a Big Data y Hadoop ha sido realmente formar parte del ecosistema desde el primer día. Como propietarios de proveedores que se han centrado realmente en el procesamiento de datos con motores muy livianos, pensamos que había una gran oportunidad para que Hadoop se convirtiera en una plataforma de procesamiento de datos y ser parte de esta arquitectura de almacenamiento de datos de próxima generación para la organización. Hemos contribuido a los proyectos de código abierto de Apache desde 2011, comenzando con MapReduce. He estado entre los diez primeros para Hadoop Versión 2, y participé realmente en múltiples proyectos que también incluyen paquetes de Spark, algunos de nuestros conectores se publican en paquetes de Spark.
Aprovechamos nuestro motor de procesamiento de datos muy liviano que es metadatos basados en archivos completamente planos, y se adapta muy bien a los sistemas de archivos distribuidos como Hadoop Distributed File System. Y aprovechamos nuestra herencia en el mainframe, nuestra experiencia con algoritmos a medida que presentamos nuestros productos de big data. Y nos asociamos muy de cerca con los principales proveedores, los principales actores aquí, incluidos Hortonworks, Cloudera, MapR, Splunk. Hortonworks anunció recientemente que revenderán nuestro producto para la incorporación de ETL con Hadoop. Con Dell y Cloudera tenemos una asociación muy estrecha que también está revendiendo nuestro producto ETL como parte de su dispositivo de big data. Y con Splunk en realidad, publicamos una telemetría de mainframe y datos de seguridad en los paneles de Splunk. Tenemos una asociación cercana.
¿Qué piensa cada ejecutivo de nivel C? Es realmente, "¿Cómo aprovecho mis activos de datos?" Todo el mundo está hablando de big data. Todos hablan de Hadoop, Spark, la próxima plataforma informática que puede ayudarme a crear agilidad empresarial y abrir nuevas aplicaciones transformadoras. Nuevas oportunidades de comercialización. Todos los ejecutivos piensan: "¿Cuál es mi estrategia de datos, cuál es mi iniciativa de datos y cómo me aseguro de no quedarme atrás de mi competencia, y todavía estoy en este mercado en los próximos tres años?" vea esto mientras hablamos con nuestros clientes, mientras hablamos con nuestra base global de clientes, que es bastante grande, como se puede imaginar, ya que hemos estado presentes por un tiempo.
Mientras hablamos con todas estas organizaciones, también vemos esto en la pila de tecnología en la interrupción que sucedió con Hadoop. Realmente es para satisfacer esta demanda de datos como un activo. Aprovechando todos los activos de datos que tiene una organización. Y hemos visto que la arquitectura del almacén de datos empresariales evoluciona de tal manera que Hadoop ahora es la nueva pieza central de la arquitectura de datos moderna. Y la mayoría de nuestros clientes, ya sean servicios financieros, ya sea seguros, la empresa de telecomunicaciones de venta minorista, las iniciativas generalmente son que Hadoop es un servicio o que los datos son un servicio. Porque todos están tratando de hacer que los activos de datos estén disponibles para sus clientes externos o internos. Y en algunas de las organizaciones vemos iniciativas como casi un mercado de datos para sus clientes.
Y uno de los primeros pasos para lograrlo es crear un centro de datos empresarial. A veces la gente lo llamará un lago de datos. La creación de este centro de datos empresariales en realidad no es tan fácil como parece porque realmente requiere acceder y recopilar prácticamente cualquier información en la empresa. Y esos datos ahora provienen de todas las nuevas fuentes, como sensores móviles y bases de datos heredadas, y están en modo por lotes y en modo de transmisión. Sin embargo, la integración de datos siempre ha sido un desafío, con la cantidad y variedad de fuentes de datos y los diferentes estilos de entrega, ya sea en lotes o en tiempo real, ahora es aún más desafiante en comparación con hace cinco años, hace diez años. A veces nos referimos a él como "ya no es el ETL de tu padre".
Entonces hablamos de los diferentes activos de datos. A medida que las empresas intentan dar sentido a los nuevos datos, los datos que recopilan de los dispositivos móviles, ya sean los sensores de un fabricante de automóviles o los datos de usuario de una empresa de juegos móviles, a menudo necesitan hacer referencia a los activos de datos más críticos en la empresa, que es información del cliente, por ejemplo. Estos activos de datos más críticos a menudo viven en el mainframe. La correlación de los datos de mainframe con estas nuevas fuentes emergentes, recopiladas en la nube, recopiladas a través de dispositivos móviles, recopilados en la línea de fabricación de una compañía automotriz japonesa o en aplicaciones de Internet de las cosas, tienen que dar sentido a estos nuevos datos haciendo referencia a sus conjuntos de datos heredados. Y esos conjuntos de datos heredados suelen estar en el mainframe.
Y si estas compañías no pueden hacer eso, no pueden acceder a los datos del mainframe, entonces hay una oportunidad perdida. Entonces, los datos como un servicio, o el aprovechamiento de todos los datos de la empresa, no están realmente aprovechando los activos más críticos de la organización. También está la parte de telemetría y datos de seguridad porque casi todos los datos transaccionales viven en el mainframe.
Imagínese que va a un cajero automático, creo que uno de los asistentes envió un mensaje a los participantes aquí para proteger el sistema bancario, cuando está deslizando su tarjeta que los datos transaccionales son más o menos globales en el mainframe. Y asegurar y recopilar los datos de seguridad y telemetría de los mainframes y ponerlos a disposición a través de paneles de Splunk u otros, Spark, SQL, se vuelve más crítico ahora que nunca, debido al volumen de datos y la variedad de datos.
Los conjuntos de habilidades son uno de los mayores desafíos. Debido a que, por un lado, tiene una pila de big data que cambia rápidamente, no sabe qué proyecto va a sobrevivir, qué proyecto no va a sobrevivir, ¿debería contratar desarrolladores de Hive o Pig? ¿Debo invertir en MapReduce o Spark? O lo siguiente, Flink, alguien dijo. ¿Debería invertir en una de estas plataformas informáticas? Por un lado, mantenerse al día con el ecosistema que cambia rápidamente es un desafío y, por otro lado, tiene estas fuentes de datos heredadas. Los nuevos conjuntos de habilidades realmente no coinciden y es posible que tengas un problema porque esos recursos podrían estar realmente retirándose. Hay una gran brecha en términos de los conjuntos de habilidades de las personas que comprenden esas pilas de datos heredados y que comprenden la pila de tecnología emergente.
El segundo desafío es la gobernanza. Cuando realmente está accediendo a todos los datos empresariales a través de plataformas, tenemos clientes que expresaron inquietudes que dicen: “No quiero que mis datos lleguen. No quiero que mis datos se copien en varios lugares porque quiero evitar las copias múltiples tanto como sea posible. Quiero tener acceso de extremo a extremo sin aterrizarlo en el medio allí ”. Gobernar estos datos se convierte en un desafío. Y la otra parte es que si está accediendo a datos que obstaculizan, si está recopilando la mayoría de sus datos en la nube y accediendo y haciendo referencia a datos heredados, el ancho de banda de la red se convierte en un problema, una plataforma de clúster. Existen muchos desafíos en términos de tener esta iniciativa de big data y plataformas de análisis avanzadas y, a la vez, aprovechar todos los datos empresariales.
Lo que ofrece Syncsort es que se nos conoce como "simplemente los mejores", no porque seamos simplemente los mejores, sino que nuestros clientes realmente se refieren a nosotros como simplemente los mejores para acceder e integrar datos de mainframe. Admitimos todos los formatos de datos de mainframe y los ponemos a disposición para el análisis de big data. Ya sea en Hadoop o Spark o en la próxima plataforma informática. Porque nuestros productos realmente aíslan las complejidades de la plataforma informática. Usted, como desarrollador, se está desarrollando potencialmente en una computadora portátil, enfocándose en la canalización de datos y cuáles son los preparativos de datos, los pasos para hacer que estos datos se creen para el análisis, la siguiente fase y tomar la misma aplicación en MapReduce o tomar eso misma aplicación en Spark.
Ayudamos a nuestros clientes a hacerlo cuando YARN estuvo disponible y tuvieron que mover sus aplicaciones de MapReduce versión 1 a YARN. Los estamos ayudando a hacer lo mismo con Apache Spark. Nuestro producto, la nueva versión 9, también se ejecuta con Spark y viene con una optimización dinámica que aislará estas aplicaciones para futuros marcos informáticos.
Por lo tanto, tenemos acceso a datos de mainframe, ya sean archivos VSAM, ya sea DB2 o si son datos de telemetría, como registros SMF o Log4j o syslogs, que deben visualizarse a través de paneles de Splunk. Y al hacerlo, debido a que la organización puede aprovechar su conjunto de habilidades de ingeniero de datos o ETL existente, el tiempo de desarrollo se reduce significativamente. De hecho, con Dell y Cloudera, hubo un punto de referencia independiente patrocinado, y ese punto de referencia se centró en el tiempo de desarrollo que se necesita si se realiza la codificación manual o se utilizan otras herramientas como Syncsort, y se redujo en un 60, 70 por ciento el tiempo de desarrollo . Reducir la habilidad crea una brecha entre los grupos, entre esos hosts de archivos de datos y también esos hosts de archivos de datos en términos de personas.
Por lo general, el equipo de big data, o el equipo de ingesta de datos, o el equipo que tiene la tarea de desarrollar estos datos como una arquitectura de servicio, no necesariamente hablan con el equipo de mainframe. Quieren minimizar esa interacción casi en muchas de las organizaciones. Al cerrar esa brecha hemos avanzado. Y la parte más importante es realmente asegurar todo el proceso. Porque en la empresa cuando se trata con este tipo de datos confidenciales hay muchos requisitos.
En industrias altamente reguladas como los seguros y la banca, nuestros clientes preguntan y dicen: "Ofrecen este acceso a datos de mainframe y eso es genial". ¿Me puede ofrecer también hacer que este formato de registro codificado con EBCDIC se mantenga en su formato original para que pueda satisfacer mis requisitos de auditoría? ”Entonces, hacemos que Hadoop y Apache Spark entiendan los datos de mainframe. Puede mantener los datos en su formato de registro original, hacer su plataforma informática de distribuidor de procesamiento y niveles y, si necesita volver a colocarlos, puede mostrar que el registro no ha cambiado y el formato de registro no ha cambiado, puede cumplir con los requisitos reglamentarios .
Y la mayoría de las organizaciones, a medida que crean el centro de datos o el lago de datos, también intentan hacerlo con un solo clic para poder asignar metadatos de cientos de esquemas en una base de datos Oracle a tablas Hive o archivos ORC o Parquet se hace necesario Enviamos herramientas y proporcionamos herramientas para que esto sea un acceso de datos en un solo paso, trabajos de generación automática o el movimiento de datos, y trabajos de generación automática para hacer el mapeo de datos.
Hablamos sobre la parte de conectividad, el cumplimiento, el gobierno y el procesamiento de datos. Y nuestros productos están disponibles tanto en las instalaciones como en la nube, lo que lo hace realmente muy simple porque las empresas no necesitan pensar en lo que sucederá en el próximo año o dos si decido ir completamente en la nube pública versus híbrido entorno, ya que algunos de los clústeres pueden ejecutarse en las instalaciones o en la nube. Y nuestros productos están disponibles en Amazon Marketplace, en EC2, Elastic MapReduce y también en un contenedor Docker.
Solo para concluir, para que tengamos tiempo suficiente para preguntas y respuestas, se trata realmente de acceder, integrar y cumplir con el gobierno de datos, y hacer todo esto más simple. Y a la vez que simplifica esto, "diseñe una vez e implemente en cualquier lugar" en un verdadero sentido debido a nuestras contribuciones de código abierto, nuestro producto se ejecuta de forma nativa en el flujo de datos de Hadoop y de forma nativa con Spark, aislando a las organizaciones del ecosistema que cambia rápidamente. Y proporciona una única canalización de datos, una única interfaz, tanto para lotes como para transmisión.
Y esto también ayuda a las organizaciones a evaluar estos marcos, ya que es posible que desee crear aplicaciones y simplemente ejecutarlas en MapReduce versus Spark y ver por usted mismo, sí, Spark tiene esta promesa y proporciona todo el avance en algoritmos iterativos para el mejor aprendizaje automático y las aplicaciones de análisis predictivo funcionan con Spark, ¿puedo hacer que mis cargas de trabajo de transmisión y lotes se realicen en este marco de computadora? Puede probar diferentes plataformas informáticas con nuestros productos. Y la optimización dinámica, ya sea que esté ejecutando en un servidor independiente, en su computadora portátil, en Google Cloud versus Apache Spark, es realmente una gran propuesta de valor para nuestros clientes. Y fue realmente impulsado por los desafíos que tuvieron.
Solo cubriré uno de los estudios de caso. Esta es la compañía de seguros de vida Guardian. Y la iniciativa de Guardian fue realmente centralizar sus activos de datos y ponerlos a disposición de sus clientes, reducir el tiempo de preparación de datos y dijeron que todo el mundo habla de que la preparación de datos toma el 80 por ciento de la tubería de procesamiento de datos en general y dijeron que en realidad estaba tomando aproximadamente 75 a 80 por ciento para ellos y querían reducir la preparación de datos, los tiempos de transformación y el tiempo de comercialización para proyectos de análisis. Cree esa agilidad a medida que agregan nuevas fuentes de datos. Y haga que ese acceso a datos centralizado esté disponible para todos sus clientes.
Su solución, incluidos los productos Syncsort, es que ahora tienen un mercado de datos similar al de Amazon Marketplace respaldado por un lago de datos, que es básicamente Hadoop, y la base de datos NoSQL. Y utilizan nuestros productos para llevar todos los activos de datos al lago de datos, incluido DB2 en mainframe, incluidos los archivos VSAM en mainframe y las fuentes de datos heredadas de la base de datos, así como las nuevas fuentes de datos. Y como resultado de eso, han centralizado los activos de datos reutilizables que son buscables, accesibles y disponibles para sus clientes. Y realmente pueden agregar las nuevas fuentes de datos y atender a sus clientes mucho más rápido y más eficiente que antes. Y las iniciativas de análisis también están progresando aún más en el lado predictivo. Así que haré una pausa y espero que esto haya sido útil, y si tiene alguna pregunta para mí sobre cualquiera de los temas relacionados, por favor, sea bienvenido.
Eric Kavanagh: Claro, y Tendü, voy a tirar uno. Recibí un comentario de un miembro de la audiencia que decía: "Me gusta este 'diseño una vez, desplegarlo en cualquier lugar'". ¿Puedes investigar cómo es verdad? Quiero decir, ¿qué has hecho para permitir ese tipo de agilidad y hay algún impuesto? Como cuando hablamos de virtualización, por ejemplo, siempre hay un pequeño impuesto sobre el rendimiento. Algunas personas dicen dos por ciento, cinco por ciento y 10 por ciento. Lo que ha hecho para habilitar el diseño una vez, implementarlo en cualquier lugar: ¿cómo lo hace y hay algún impuesto asociado en términos de rendimiento?
Tendü Yogurtçu: Claro, gracias. No, porque a diferencia de algunos de los otros proveedores, realmente no generamos Hive o Pig o algún otro código que no sea nativo de nuestros motores. Aquí es donde nuestras contribuciones de código abierto desempeñaron un papel importante, porque hemos estado trabajando muy de cerca con los proveedores de Hadoop, Cloudera, Hortonworks y MapR y debido a nuestras contribuciones de código abierto, nuestro motor de hecho está funcionando de forma nativa como parte del flujo, como parte del flujo de Hadoop, como parte de Spark.
Lo que eso se traduce también es que tenemos esta optimización dinámica. Esto fue algo que surgió como resultado de que nuestros clientes fueron desafiados con los marcos informáticos. Cuando entraron en producción con algunas de las aplicaciones, regresaron y dijeron: "Estoy estabilizando mi clúster Hadoop, estabilizándome en MapReduce YARN Versión 2, MapReduce Versión 2, y la gente habla de que MapReduce está muerto, Spark está Lo siguiente, y algunas personas dicen que Flink será lo próximo, ¿cómo voy a hacer frente a esto?
Y esos desafíos realmente se hicieron tan obvios para nosotros, que invertimos en tener esta optimización dinámica que llamamos ejecución inteligente. En tiempo de ejecución, cuando se realiza el trabajo, cuando se envía esta canalización de datos, en función del clúster, ya sea Spark, ya sea MapReduce o un servidor independiente de Linux, decidimos cómo ejecutar este trabajo, de forma nativa en nuestro motor, como parte de eso. Flujo de datos Hadoop o Spark. No hay gastos generales porque todo se hace a través de esta optimización dinámica que tenemos y también se hace porque nuestro motor está tan integrado gracias a nuestras contribuciones de código abierto. Eso responde tu pregunta?
Eric Kavanagh: Sí, eso está bien. Y quiero arrojar una pregunta más allí, y luego Dez, tal vez los atrapemos a usted y a Robin también. Acabo de recibir un comentario hilarante de uno de nuestros asistentes. Lo leeré porque realmente es bastante concisa. Él escribe: "Parece que en la historia de las cosas CALIENTES", ¿entiendes? Como IoT, "es que cuanto más intentas" simplificar "algo que es realmente complejo, la mayoría de las veces parece más simple hacer las cosas, Se suministra más cuerda colgante. Piense en la consulta de la base de datos, explosión, subprocesos múltiples, etc. ”¿Puede comentar sobre esta paradoja a la que hace referencia? Simplicidad versus complejidad, y básicamente ¿qué está pasando realmente debajo de las cubiertas?
Tendü Yogurtçu: Claro. Creo que es un punto muy válido. Cuando está simplificando las cosas y haciendo estas optimizaciones, de una manera encubierta, alguien necesita tomar esa complejidad de lo que debe suceder, ¿verdad? Si está paralizando algo o si está decidiendo cómo ejecutar un trabajo en particular con respecto al marco de la computadora, obviamente hay una parte del trabajo que se está impulsando, ya sea en el extremo del usuario, la codificación del menú o en la optimización del motor. Hay una parte de eso, al simplificar la experiencia del usuario, hay un gran beneficio en términos de poder aprovechar los conjuntos de habilidades que existen en la empresa.
Y puede mitigar esa paradoja, mitigar ese desafío de "Sí, pero no tengo control sobre todo lo que sucede debajo de la cubierta, debajo del capó en ese motor", exponiendo las cosas a los usuarios más avanzados si quiero tener ese tipo de control. Al invertir también en algunos de los tipos de cosas de servicio. Ser capaz de ofrecer más metadatos operativos, más datos operativos, como en el ejemplo que dio este asistente, para una consulta SQL, así como con el motor en funcionamiento. Espero que eso responda.
Eric Kavanagh: Sí, eso suena bien. Dez, llévatelo.
Dez Blanchfield: Tengo muchas ganas de conocer un poco más su huella en las contribuciones de código abierto y el viaje que ha tomado de su experiencia tradicional y de larga duración en mainframe y el mundo propietario y luego el cambio a contribuyendo al código abierto y cómo ocurrió eso. Y la otra cosa que quiero entender es la opinión que están viendo de que las empresas, no solo los departamentos de TI, sino también las empresas están tomando en cuenta los centros de datos o los lagos de datos, como dicen las personas ahora y si ven esta tendencia de ¿un solo lago de datos consolidado o si estamos viendo lagos de datos distribuidos y las personas están usando herramientas para unirlos?
Tendü Yogurtçu: Claro. Para el primero, fue un viaje muy interesante, como empresa propietaria de software, uno de los primeros después de IBM. Sin embargo, nuevamente, todo comenzó con nuestros clientes evangelistas mirando a Hadoop. Tuvimos compañías de datos como ComScore, fueron una de las primeras en adoptar Hadoop porque recopilaban datos digitales en todo el mundo y no podían mantener 90 días de datos a menos que invirtieran una caja de almacenamiento de datos de diez millones de dólares en su ambiente. Comenzaron a mirar a Hadoop. Con eso comenzamos también a mirar a Hadoop.
Y cuando tomamos una decisión y reconocimos que Hadoop realmente será la plataforma de datos del futuro, también entendimos que no podremos tener una jugada en esto, una jugada exitosa en esto, a menos que eran parte del ecosistema. Y estábamos trabajando muy de cerca con los proveedores de Hadoop, con Cloudera, Hortonworks, MapR, etc. Empezamos a hablar realmente con ellos porque la asociación se vuelve muy importante para validar el valor que un proveedor puede aportar y también nos asegura que podamos ir juntos a la empresa. y ofrecer algo más significativo. Se requirió mucha construcción de relaciones porque no conocíamos los proyectos de código abierto de Apache, sin embargo, teníamos un gran apoyo de estos vendedores de Hadoop, debo decir.
Comenzamos a trabajar juntos y a analizar el centro, cómo podemos aportar valor sin siquiera nuestro software propietario en el espacio. Eso fue importante. No se trata solo de poner algunas API en las que se pueda ejecutar su producto, es poder decir que invertiré en esto porque creo que Hadoop será una plataforma del futuro, por lo que al invertir en las fuentes que queríamos hacer Asegúrese de que madure y esté listo para la empresa. De hecho, podemos habilitar algunos de los casos de uso que no estaban disponibles antes de nuestras contribuciones. Eso beneficiará a todo el ecosistema y podemos desarrollar esas alianzas muy de cerca.
Tomó bastante tiempo. Comenzamos a contribuir en 2011 y el 21 de enero de 2013. Recuerdo la fecha porque esa fecha se comprometió nuestra mayor contribución, lo que significa que ahora podemos tener nuestros productos generalmente disponibles a partir de ese momento. Nos llevó bastante tiempo desarrollar esas relaciones., muestre el valor, los socios se convierten en socios de diseño con los proveedores y con los encargados de la comunidad de código abierto. Pero fue muy divertido. Como empresa fue muy gratificante para nosotros ser parte de ese ecosistema y desarrollar una gran asociación.
La segunda pregunta sobre el centro de datos / lago de datos, creo que cuando vemos estos datos como una implementación de servicio en la mayoría de los casos, sí, podrían ser grupos, físicamente únicos o múltiples, pero es más conceptual que convertirse en ese lugar único para todos los datos Debido a que en algunas organizaciones vemos grandes implementaciones de clúster en las instalaciones, sin embargo, también tienen clústeres, por ejemplo, en la nube pública porque algunos de los datos que se recopilan de las secciones en línea realmente se mantienen en la nube. Es ser capaz de tener una única tubería de datos que realmente pueda aprovechar, y usarlos como un solo centro de datos, un único lago de datos, se vuelve importante. No necesariamente solo el lugar físico, sino que tener ese centro de datos y lago de datos a través de clústeres, geografías y tal vez en las instalaciones y la nube será muy crítico, creo. Especialmente avanzando. Este año comenzamos a ver más y más implementaciones en la nube. Es asombroso. La primera mitad de este año hasta ahora hemos visto muchas implementaciones en la nube.
Eric Kavanagh: Bien, genial. Y Robin, ¿tienes alguna pregunta? Sé que solo nos quedan unos minutos.
Robin Bloor: Bueno, bueno, puedo hacerle una pregunta. Lo primero que se me ocurrió es que ha habido mucha emoción sobre Kafka y estaba interesado en su opinión sobre Kafka y cómo se integra con la forma en que las personas usan Kafka.
Tendü Yogurtçu: Claro. Sí, Kafka se está volviendo bastante popular. Entre nuestros clientes vemos que es una especie de capa de transporte de datos y vemos que los datos son un bus, más o menos. Por ejemplo, uno de nuestros clientes en realidad estaba utilizando una especie de datos de consumo que se introdujeron en este Kafka entre múltiples, como miles de usuarios en línea, y pudieron clasificar eso y avanzar.
Nuevamente, Kafka es un bus de datos para los diferentes consumidores de estos datos. Clasifique a algunos usuarios avanzados frente a usuarios no tan avanzados y haga algo diferente para avanzar en esa tubería de datos. Básicamente, la forma en que nos integramos con Kafka es que nuestro producto DMX-h se convierte en un consumidor confiable, un consumidor altamente eficiente y confiable para Kafka. Puede leer los datos y esto no es diferente a leer datos de cualquier otra fuente de datos para nosotros. Les damos a los usuarios la capacidad de controlar la ventana, ya sea en términos del requisito de tiempo que tienen o la cantidad de mensajes que podrían estar consumiendo desde el bus Kafka. Y luego también podemos enriquecer esos datos a medida que pasan por nuestro producto y vuelven a Kafka. Hemos probado esto. Lo hemos comparado en el sitio del cliente. También certificado por Confluent. Trabajamos en estrecha colaboración con los muchachos Confluent y es de muy alto rendimiento y fácil de usar. Una vez más, las API cambian, pero no tiene que preocuparse porque el producto realmente lo trata como otra fuente de datos, una fuente de transmisión de datos. Es bastante divertido trabajar con nuestro producto y Kafka, en realidad.
Robin Bloor: De acuerdo, tengo otra pregunta que es simplemente una pregunta comercial general, pero conozco a Syncsort desde hace mucho tiempo y siempre tuvo la reputación y entregó un software extraordinariamente rápido para ETL y el mundo de mainframe. ¿Es el caso que la mayor parte de su negocio ahora se transfiere a Hadoop? ¿Es el caso de que de una forma u otra has extendido tu negocio de manera bastante dramática desde el mundo de mainframe?
Tendü Yogurtçu: Nuestros productos de mainframe siguen ejecutando el 50 por ciento de los mainframes a nivel mundial. Por lo tanto, tenemos una línea de productos mainframe muy sólida además de lo que estamos haciendo en el big data y el extremo de Hadoop. Y todavía estamos en la mayoría de los proyectos de simplificación u optimización de TI porque hay un extremo que desea poder aprovechar sus datos de mainframe en las plataformas de Big Data Multex y aprovechar todos los datos empresariales, sin embargo, también hay cargas de trabajo transaccionales muy críticas. que aún continúa ejecutándose en el mainframe y ofrecemos a esos clientes las formas de hacer que esas aplicaciones sean más eficientes, ejecutarlas en el motor zIIP para que no consuman tantos ciclos de procesamiento y MIPS, haciéndolos rentables.
Continuamos invirtiendo en los productos de mainframe y, de hecho, jugamos en este espacio donde la gente pasa de big iron a main data de mainframe y abarca la línea de productos también a través de esas plataformas. Por lo tanto, no necesariamente cambiamos todo el negocio a un lado, seguimos teniendo negocios muy exitosos en ambos lados. Y las adquisiciones son un gran foco para nosotros también. A medida que evoluciona este espacio de gestión y procesamiento de datos para las plataformas de big data, también nos comprometemos a realizar bastantes adquisiciones complementarias.
Robin Bloor: Bueno, supongo que no puedo preguntarte cuáles son porque no podrías decirme nada. Me interesa saber si has visto muchas implementaciones de Hadoop o Spark en el mainframe o si es algo muy raro.
Tendü Yogurtçu: No hemos visto ninguno. Hay más preguntas sobre eso. Creo que Hadoop en mainframe no tenía mucho sentido debido al tipo de estructura central. Sin embargo, Spark en mainframe es bastante significativo y Spark realmente es muy bueno con el aprendizaje automático y el análisis predictivo, y poder tener algunas de esas aplicaciones con datos de mainframe es realmente, creo, bastante significativo. Todavía no hemos visto a nadie haciendo eso, sin embargo, es realmente el caso de uso que impulsa estas cosas. Si su caso de uso como empresa es más aportar datos de mainframe e integrarse con el resto de los conjuntos de datos en la plataforma de Big Data, esa es una historia. Requiere acceder a los datos del mainframe desde la plataforma de Big Data Multex porque es poco probable que traiga sus conjuntos de datos de los sistemas abiertos y vuelva a llamarlos al mainframe. Sin embargo, si tiene algunos datos de mainframe que desea explorar y hacer un poco de descubrimiento de exploración de datos, aplicar un poco de inteligencia artificial avanzada y análisis avanzados, entonces Spark podría ser una buena manera de hacerlo y ejecutarlo en ese mainframe.
Eric Kavanagh: Y aquí hay una pregunta más de la audiencia, en realidad dos más. Te daré una pregunta de equipo de etiqueta, luego terminaremos. Un asistente pregunta: "¿IBM está integrando sus contribuciones de código abierto en su ecosistema de nube pública, en otras palabras, el Bluemix?" Y otro asistente hizo una muy buena observación, señalando que Syncsort es excelente para mantener vivo el hierro grande para aquellos que ya lo tiene, pero si las empresas renuncian a los nuevos mainframes a favor de lo que él llama CE, nublan todo, eso probablemente disminuirá, pero señala que ustedes son realmente buenos para mover datos al evitar los sistemas operativos hasta un gigabyte por segundo. ¿Puede hablar sobre su fuerza central, como él mencionó, y si IBM está integrando o no sus cosas en Bluemix?
Tendü Yogurtçu: Con IBM, ya somos socios de IBM y tuvimos discusiones sobre sus servicios de nube de datos que ofrecen el producto. Nuestras contribuciones de código abierto están abiertas a todos los que quieran aprovecharlas. Parte de la conectividad de mainframe también está disponible en paquetes Spark, por lo que no solo IBM. Cualquiera puede aprovecharlos. En Bluemix todavía no hemos hecho nada específicamente al respecto. ¿Y te importa repetir la segunda pregunta?
Eric Kavanagh: Sí, la segunda pregunta fue sobre su área central de funcionalidad a lo largo de los años, que realmente estaba manejando cuellos de botella de ETL y obviamente eso es algo que ustedes todavía van a hacer como mainframes, bueno, en teoría, aléjate, aunque Dez El punto todavía está balanceándose y rodando por ahí. Pero el asistente solo señaló que Syncsort es muy bueno para mover datos al pasar por alto los sistemas operativos y hasta un gigabyte por segundo. ¿Puedes comentar sobre eso?
Tendü Yogurtçu: Sí, que la eficiencia general de los recursos ha sido nuestra fortaleza y la escalabilidad y el rendimiento han sido nuestra fortaleza. No nos comprometemos, simplificar tiene muchos significados, no nos comprometemos con ellos. Cuando la gente comenzó a hablar de Hadoop en 2014, por ejemplo, muchas de las organizaciones no estaban mirando el rendimiento inicialmente. Decían: "Oh, si sucede algo, puedo agregar otro par de nodos y estaré bien, el rendimiento no es mi requisito".
Si bien estábamos hablando de tener el mejor rendimiento porque ya estábamos funcionando de forma nativa, ni siquiera teníamos algunos de los problemas iniciales que Hive tenía con múltiples trabajos MapReduce y gastos generales al iniciarlos. La gente nos decía: "Oh, esa no es mi preocupación, no te preocupes por eso en este momento".
Cuando llegamos a 2015, ese panorama ha cambiado porque algunos de nuestros clientes ya excedieron el almacenamiento que tenían en sus clústeres de producción. Se volvió muy crítico para ellos ver lo que Syncsort puede ofrecer. Si está tomando algunos datos de una base de datos o mainframe y escribiendo en un formato Parquet en los clústeres, ya sea que aterrice y realice una nueva transformación o simplemente realice la transformación en vuelo y el formato de archivo de destino, marcó la diferencia porque está ahorrando de almacenamiento, está ahorrando del ancho de banda de la red, está ahorrando de la carga de trabajo en el clúster porque no está ejecutando trabajos adicionales. Parece que esas fortalezas que jugamos en términos de ser muy conscientes sentimos la eficiencia de los recursos bajo nuestra piel.
Así es como lo describimos. Es crítico para nosotros. No lo damos por sentado. Nunca lo dimos por sentado, así que seguiremos siendo fuertes con ese apalancamiento en Apache Spark o el próximo marco de la computadora. Ese seguirá siendo nuestro enfoque. Y en términos de la pieza de movimiento de datos y la pieza de acceso a datos, definitivamente es uno de nuestros puntos fuertes y estamos accediendo a datos de DB2 o VSAM en los mainframes en el contexto de Hadoop o Spark.
Eric Kavanagh: Bueno, esa es una excelente manera de finalizar la transmisión web, amigos. Muchas gracias por su tiempo y atención. Gracias a ti, Tendü y Syncsort, por entrar en la sala de reuniones y entrar en la ronda, como dicen. Muchas preguntas geniales de la audiencia. Es un ambiente siempre en movimiento, amigos. Archivaremos este Hot Tech como lo hacemos con todos los demás. Puede encontrarnos en insideanalysis.com y en techopedia.com. Por lo general, aumenta en aproximadamente un día. Y con eso, nos despediremos, amigos. Muchas gracias. Hablaremos contigo pronto. Cuídate. Adiós.
