1 00:00:22,373 --> 00:00:24,975 [Orador 1]: Hola, ¿se me oye bien? 2 00:00:25,317 --> 00:00:26,860 Bueno, buenos días a todos. 3 00:00:27,060 --> 00:00:33,060 Gracias lo primero por asistir y también muchas gracias a los organizadores por 4 00:00:33,060 --> 00:00:36,154 permitirnos estar en este evento. 5 00:00:36,354 --> 00:00:41,765 Vamos a hablar de arquitecturas en tiempo real, en Big Data. 6 00:00:41,965 --> 00:00:47,744 No está en el título de la presentación, pero todas las tecnologías que vamos a ver 7 00:00:47,744 --> 00:00:53,390 son open source, no vamos a ver ninguna tecnología comercial, para que lo sepáis. 8 00:00:53,590 --> 00:00:57,733 El objetivo de la presentación es que conozcáis un poco la problemática de este 9 00:00:57,733 --> 00:01:00,185 tipo de escenarios, de soluciones en tiempo real. 10 00:01:00,385 --> 00:01:01,408 Primero vamos a ver 11 00:01:01,608 --> 00:01:07,174 básicamente a repasar por qué las empresas, por qué las corporaciones cada 12 00:01:07,174 --> 00:01:13,075 vez necesitan este tipo de soluciones con una necesidad muy acuciante y también 13 00:01:13,075 --> 00:01:18,975 vamos a hacer un repaso de todas las tecnologías que habitualmente suelen estar 14 00:01:18,975 --> 00:01:24,409 presentes en una arquitectura de referencia Big Data en tiempo real, con 15 00:01:24,409 --> 00:01:27,176 tecnologías de lo más novedoso. 16 00:01:27,376 --> 00:01:32,693 Bueno, para los que no me conozcáis, soy David Morales, trabajo en Estratio como 17 00:01:32,693 --> 00:01:33,744 arquitecto. 18 00:01:33,944 --> 00:01:38,738 Estratio es una compañía americana, aunque fundamentalmente estamos el core del 19 00:01:38,738 --> 00:01:41,935 desarrollo del producto, está aquí ubicado en Madrid. 20 00:01:42,135 --> 00:01:47,247 He participado en la incepción y el desarrollo de muchos de los módulos de la 21 00:01:47,247 --> 00:01:52,826 arquitectura que tenemos en Estratio, del producto, especialmente los que tienen que 22 00:01:52,826 --> 00:01:57,872 ver con visualización, tiempo real, streaming y proceso complejo de eventos. 23 00:01:58,072 --> 00:02:02,963 Bueno, vamos a la materia. 24 00:02:03,368 --> 00:02:08,693 Primero, como os comentaba, lo que quiero es explicaros cuál es la problemática del 25 00:02:08,693 --> 00:02:09,693 tiempo real. 26 00:02:09,800 --> 00:02:15,644 muchas de las empresas que conocemos en todos los sectores, tanto banca, retail, 27 00:02:15,644 --> 00:02:20,622 seguros, etcétera, tienen un funcionamiento basado en procesamiento 28 00:02:20,622 --> 00:02:22,201 batch. 29 00:02:22,401 --> 00:02:26,091 Casi todos los procesos que os podéis imaginar en una empresa grande, 30 00:02:26,091 --> 00:02:29,891 consolidación de movimientos, transferencias, movimiento de datos entre 31 00:02:29,891 --> 00:02:33,039 diferentes data warehouse, etcétera, son procesos que están 32 00:02:33,239 --> 00:02:37,529 normalmente programados para ejecutarse con una periodicidad, bien sea diaria, 33 00:02:37,529 --> 00:02:38,965 semanal, mensual, la que sea. 34 00:02:39,165 --> 00:02:43,589 Entonces, en este primer punto lo que quiero es que entendáis por qué es 35 00:02:43,589 --> 00:02:48,699 necesario este cambio hacia arquitecturas en tiempo real, por qué es necesario para 36 00:02:48,699 --> 00:02:52,936 las empresas, si quieren seguir compitiendo en el mercado, por qué es 37 00:02:52,936 --> 00:02:57,984 necesario que empiecen a pensar cada vez más en cómo dar respuestas en tiempo real 38 00:02:57,984 --> 00:02:58,984 a este tipo de... 39 00:02:59,024 --> 00:03:00,948 de necesidades de la empresa. 40 00:03:01,148 --> 00:03:06,634 Entonces, lo primero, doy por hecho que casi todos conocéis, prácticamente todos 41 00:03:06,634 --> 00:03:12,386 conoceréis este tipo de infografías, cada año suele salir una con datos cada vez más 42 00:03:12,386 --> 00:03:17,939 apabullantes sobre cuál es el movimiento que se genera, en este caso cada minuto, 43 00:03:17,939 --> 00:03:18,939 en Internet. 44 00:03:19,139 --> 00:03:24,780 Como podéis ver hay más de 600.000 logis en Facebook, 67.000 fotos se suben a 45 00:03:24,780 --> 00:03:29,355 Instagram, 433.000 tweets se envían en un minuto en el mundo. 46 00:03:29,555 --> 00:03:34,824 Estos son datos de 2014 y como os digo cada año suele sacar una infografía nueva 47 00:03:34,824 --> 00:03:39,560 donde estos datos suelen incrementarse en un orden de magnitud al menos. 48 00:03:39,760 --> 00:03:41,741 ¿Por qué? 49 00:03:42,164 --> 00:03:43,927 ¿Qué tipo de compañías veis aquí reflejadas? 50 00:03:44,127 --> 00:03:47,132 Casi todas están relacionadas con el social media. 51 00:03:47,332 --> 00:03:52,530 Como veis, Facebook, Instagram, Twitter, Pinterest, todas ellas están relacionadas 52 00:03:52,530 --> 00:03:53,622 con social media. 53 00:03:53,822 --> 00:03:58,390 Pero si os dais cuenta, casi todas ellas tienen un modelo de negocio detrás. 54 00:03:58,590 --> 00:04:02,156 Y las que no lo tienen, seguramente lo empezarán a tener dentro de poco. 55 00:04:02,356 --> 00:04:03,356 ¿Vale? 56 00:04:02,997 --> 00:04:08,997 Entonces, toda esta cantidad tan importante de información que está 57 00:04:08,997 --> 00:04:14,997 circulando en tiempo real no solamente es tráfico de red, no solamente son tweets 58 00:04:14,997 --> 00:04:20,997 por minuto, sino que detrás hay negocios que están funcionando con facturaciones, 59 00:04:20,997 --> 00:04:26,997 con impresiones, con pagos, etc. que se están ejecutando en tiempo real en estas 60 00:04:26,997 --> 00:04:30,354 empresas. 61 00:04:30,554 --> 00:04:36,154 Lo bueno que tienen estas empresas es que de vez en cuando publican este tipo de 62 00:04:36,154 --> 00:04:41,489 visualizaciones, de infografías, como queramos llamarlo, que nos permiten de 63 00:04:41,489 --> 00:04:47,290 alguna manera tangibilizar esa información que ocurre en tiempo real, porque muchas 64 00:04:47,290 --> 00:04:49,271 veces es difícil imaginarnos 65 00:04:49,471 --> 00:04:51,434 tanta información, no en qué se traduce. 66 00:04:51,634 --> 00:04:55,530 Esta infografía que veis aquí, por ejemplo, son los deseos que expresa la 67 00:04:55,530 --> 00:04:57,501 gente en Twitter cuando arranca el año. 68 00:04:57,701 --> 00:05:01,964 Pues quiero dejar de fumar, quiero ir al gimnasio, en fin. 69 00:05:02,246 --> 00:05:08,774 Seguramente el día siguiente haya un hashtag de lo dejo, pero bueno. 70 00:05:08,974 --> 00:05:14,556 Esto es una infografía que hizo Twitter sobre qué es lo que habitualmente, qué 71 00:05:14,556 --> 00:05:17,825 propósitos hacía la gente al principio de año. 72 00:05:18,025 --> 00:05:19,025 Bueno, 73 00:05:18,125 --> 00:05:22,559 Estamos acostumbrados a ver este tipo de infografías que normalmente están 74 00:05:22,559 --> 00:05:27,539 cocinadas, tienen un proceso en el que los datos se recogen, se filtran, se agregan 75 00:05:27,539 --> 00:05:31,852 para tener un dibujo muy específico que normalmente es una imagen, no es 76 00:05:31,852 --> 00:05:32,835 interactivo. 77 00:05:33,035 --> 00:05:38,329 Entonces, es bastante llamativo, a todo el mundo le gusta ver este tipo de datos, 78 00:05:38,329 --> 00:05:39,322 ¿no? 79 00:05:39,522 --> 00:05:43,755 Pero lo interesante en este tipo de empresas, como os decía antes, es que 80 00:05:43,755 --> 00:05:48,636 detrás de estas visualizaciones, detrás de todas estas infografías y estos datos que 81 00:05:48,636 --> 00:05:50,401 son apabullantes, hay negocio. 82 00:05:50,601 --> 00:05:55,870 Y todas estas empresas parten con un negocio anclado en el tiempo real. 83 00:05:56,070 --> 00:05:59,876 Ninguna de ellas tiene más de 10, de 15 años. 84 00:06:00,076 --> 00:06:03,649 Creo que el dominio de YouTube se compró en el 2004 o algo así, no tengo el dato 85 00:06:03,649 --> 00:06:04,827 exacto, pero creo que fue así. 86 00:06:05,027 --> 00:06:08,274 Entonces, estas empresas no tienen más de 10 años, muchas de ellas. 87 00:06:08,474 --> 00:06:12,443 Los modelos de negocio probablemente arrancaron hace 1, 2, 3 años como mucho. 88 00:06:12,643 --> 00:06:15,610 Entonces, todo su modelo de negocio está basado en tiempo real. 89 00:06:15,810 --> 00:06:17,274 Todos los servicios con los que ellos trabajan, 90 00:06:17,474 --> 00:06:23,474 facturan a los que se anuncian en la red social, por ejemplo, todas las promociones 91 00:06:23,474 --> 00:06:29,474 que hacen en las redes sociales, todo eso tiene una facturación detrás y todo está 92 00:06:29,474 --> 00:06:32,275 montado en tiempo real. 93 00:06:33,775 --> 00:06:39,128 En cambio, las compañías más clásicas, como os comentaba, los bancos, los 94 00:06:39,128 --> 00:06:44,614 seguros, etc., son compañías que tienen 30, 20, 25 años y todas ellas están 95 00:06:44,614 --> 00:06:50,434 construidas sobre una base tecnológica que, como os digo, puede tener fácilmente 96 00:06:50,434 --> 00:06:51,767 25 años. 97 00:06:51,967 --> 00:06:57,289 Entonces, aquí nos encontramos con un choque, podríamos decir, generacional 98 00:06:57,289 --> 00:07:03,012 entre empresas muy importante, dado que las compañías orientadas al social media, 99 00:07:03,012 --> 00:07:08,802 digamos, o compañías digitales, nativas digitales, están ofreciendo a sus clientes 100 00:07:08,802 --> 00:07:11,325 servicios en tiempo real, ¿vale? 101 00:07:11,525 --> 00:07:16,037 tenemos por el otro lado una gran cantidad de compañías que tienen una media de 20-25 102 00:07:16,037 --> 00:07:19,099 años que no tienen este tipo de soluciones en tiempo real. 103 00:07:19,299 --> 00:07:23,947 Entonces, cada vez hay un choque más fuerte porque estas compañías digitales 104 00:07:23,947 --> 00:07:28,410 van canibalizando más sectores o más parcelas de las compañías que no son 105 00:07:28,410 --> 00:07:29,376 digitales. 106 00:07:29,576 --> 00:07:30,765 Por ejemplo, Google... 107 00:07:30,965 --> 00:07:35,819 Tiene servicios de pago, Amazon ofrece cada vez más compra, por ejemplo, de 108 00:07:35,819 --> 00:07:40,805 productos frescos incluso, entonces van canibalizando parcelas de sectores de 109 00:07:40,805 --> 00:07:43,067 retail, de bancas, de seguros, etc. 110 00:07:43,267 --> 00:07:46,714 Entonces, ¿qué tienen que hacer estas compañías que no son digitales, no son 111 00:07:46,714 --> 00:07:48,873 nativas digitales, para seguir siendo competitivas? 112 00:07:49,073 --> 00:07:53,490 Tienen que cambiar sus paradigmas, tienen que cambiar todos sus sistemas para dejar 113 00:07:53,490 --> 00:07:57,745 de ser empresas estáticas que producen resultados al final del día o al final de 114 00:07:57,745 --> 00:08:01,888 la semana o al final del mes y tienen que empezar a producirlos en tiempo real. 115 00:08:02,088 --> 00:08:06,941 Este es el cambio y este es el gran, podríamos decir, drama incluso, porque 116 00:08:06,941 --> 00:08:12,123 realmente lo es, al que se enfrentan las compañías que tienen, como os digo, una 117 00:08:12,123 --> 00:08:13,238 media de 20 años. 118 00:08:13,844 --> 00:08:19,844 y habitualmente en una compañía de este tipo podemos empezar a dar soluciones en 119 00:08:19,844 --> 00:08:26,098 tiempo real de dos maneras o bien coger procesos existentes 120 00:08:26,315 --> 00:08:31,281 y llevarlos a una solución en tiempo real, romper los esquemas, patch de procesos 121 00:08:31,281 --> 00:08:36,124 diarios, nocturnos, etc., y llevarlos a una arquitectura en tiempo real, o bien 122 00:08:36,124 --> 00:08:39,974 coger información que ahora mismo la compañía no esté tratando. 123 00:08:40,174 --> 00:08:43,669 Coger esas parcelas de información que no están cubiertas en la compañía y meterlas 124 00:08:43,669 --> 00:08:44,981 ya en arquitecturas en tiempo real. 125 00:08:45,181 --> 00:08:46,803 Esas son las dos estrategias. 126 00:08:47,003 --> 00:08:51,594 con las que habitualmente empiezan este tipo de compañías a trabajar en tiempo 127 00:08:51,594 --> 00:08:52,594 real. 128 00:08:52,509 --> 00:08:56,012 Entonces, es lo que nosotros, por contraponerlo con el Business 129 00:08:56,012 --> 00:09:00,419 Intelligence, que es una disciplina que todos conocéis y que posiblemente tiene 130 00:09:00,419 --> 00:09:04,262 20-25 años desde que más o menos establecieron las bases del Business 131 00:09:04,262 --> 00:09:08,047 Intelligence, que siguen teniendo vigencia, nosotros llamamos a esta 132 00:09:08,047 --> 00:09:12,229 necesidad del tiempo real y a cómo se desarrollan los procesos en el tiempo 133 00:09:12,229 --> 00:09:15,795 real, lo llamamos Operational Intelligence, por contraponerlo con... 134 00:09:15,995 --> 00:09:20,944 con las áreas de Business Intelligence que son departamentos súper necesarios en 135 00:09:20,944 --> 00:09:24,390 todas las empresas y que están presentes en todas ellas. 136 00:09:24,590 --> 00:09:27,396 ¿Qué podemos empezar a escuchar? 137 00:09:27,596 --> 00:09:31,745 ¿En dónde podemos poner la oreja, por así decirlo, dentro de los procesos y los 138 00:09:31,745 --> 00:09:33,547 canales que tiene una empresa offline? 139 00:09:33,747 --> 00:09:36,212 ¿Qué información podemos recoger para empezar a trabajar en tiempo real? 140 00:09:36,412 --> 00:09:38,095 Pues aquí tenéis un ejemplo. 141 00:09:38,295 --> 00:09:42,793 Podemos escuchar desde lo que ocurre en los TPVs, podemos escuchar lo que ocurre 142 00:09:42,793 --> 00:09:47,349 en las redes sociales también, podemos escuchar transacciones en tiempo real, por 143 00:09:47,349 --> 00:09:51,961 ejemplo, los logs de aplicación que hay en cualquier banco, por ejemplo, que tiene 144 00:09:51,961 --> 00:09:56,118 muchos sistemas, podemos ir recogiendo todos los logs e ir montando poco a 145 00:09:56,118 --> 00:09:57,118 poco... 146 00:09:57,068 --> 00:10:02,110 una arquitectura de tiempo real que permita pivotar a la empresa desde, como 147 00:10:02,110 --> 00:10:06,953 os digo, soluciones más ancladas en el batch a soluciones en tiempo real. 148 00:10:07,153 --> 00:10:10,115 Por tanto, ¿la conclusión cuál es? 149 00:10:10,315 --> 00:10:14,887 el real time, el procesamiento en tiempo real parece que es como muy novedoso, 150 00:10:14,887 --> 00:10:19,459 llama la atención, todas las empresas parece que quieren empezar a hacer cosas 151 00:10:19,459 --> 00:10:23,141 con tiempo real, todos estamos acostumbrados a visualizaciones, 152 00:10:23,141 --> 00:10:27,772 infografías, sistemas de monitorización así con gráficas, con muchas pantallas, 153 00:10:27,772 --> 00:10:31,175 todo eso es muy bonito, pero la realidad es que estas empresas 154 00:10:31,375 --> 00:10:35,619 dependen de este cambio para seguir siendo competitivas. 155 00:10:35,819 --> 00:10:36,861 Esto es muy importante. 156 00:10:37,061 --> 00:10:43,061 Probablemente dentro de cinco años, si estas empresas no cambian su forma de 157 00:10:43,061 --> 00:10:49,061 operar en sus procesos core, es muy probable que terminen en el olvido, porque 158 00:10:49,061 --> 00:10:55,061 las empresas digitales irán, como os digo, canibalizando cada vez más parcelas de las 159 00:10:55,061 --> 00:10:59,863 que tienen las empresas tradicionales. 160 00:11:00,063 --> 00:11:02,206 Por lo tanto, hay dos conclusiones. 161 00:11:02,406 --> 00:11:07,163 Necesitamos en este tipo de empresas repensar los procesos que tiene la 162 00:11:07,163 --> 00:11:12,120 compañía para hacer una entrega al cliente mucho más rápida y mucho mejor. 163 00:11:12,320 --> 00:11:16,394 Y por entrega no significa llevarte a tu casa un paquete de Amazon, sino entregar 164 00:11:16,394 --> 00:11:20,112 cualquier tipo de servicio, desde información que tienes en el banco hasta 165 00:11:20,112 --> 00:11:24,186 contrataciones, pasando por información que actualmente, como os digo, no se está 166 00:11:24,186 --> 00:11:27,955 teniendo en cuenta la compañía, pero que le puede dar un valor añadido a la 167 00:11:27,955 --> 00:11:28,955 empresa. 168 00:11:28,902 --> 00:11:33,580 Y por otro lado, crear nuevas oportunidades, como os comentaba antes, 169 00:11:33,580 --> 00:11:38,726 hacer uso de piezas que todavía la compañía no tiene contempladas para ganar 170 00:11:38,726 --> 00:11:40,338 ventajas competitivas. 171 00:11:40,538 --> 00:11:45,414 De alguna manera posicionarse o diferenciarse en un mercado que cada vez 172 00:11:45,414 --> 00:11:46,624 está más reñido. 173 00:11:47,166 --> 00:11:50,032 Bueno, y hasta aquí la problemática, como os digo... 174 00:11:50,232 --> 00:11:54,328 Yo creo que es interesante que entendáis por qué es necesario el tiempo real más 175 00:11:54,328 --> 00:11:57,957 allá de todo lo bonito que es ver gráficas en movimiento, infografías y 176 00:11:57,957 --> 00:11:58,957 visualizaciones. 177 00:11:59,001 --> 00:12:03,183 Esto realmente es un problema para las empresas. 178 00:12:03,585 --> 00:12:10,470 Vamos a ver ahora una arquitectura de referencia en tiempo real. 179 00:12:11,293 --> 00:12:14,947 Podemos añadir más piezas, podemos quitarlas, pero más o menos una 180 00:12:14,947 --> 00:12:19,276 arquitectura de referencia es lo que tiene, que más o menos intenta contemplar 181 00:12:19,276 --> 00:12:20,272 el caso estándar. 182 00:12:20,472 --> 00:12:25,188 Como veis aquí no hay tecnologías, no estamos poniendo apenas ninguna 183 00:12:25,188 --> 00:12:30,637 tecnología, son todo necesidades, luego vamos a ver cómo encajan las tecnologías 184 00:12:30,637 --> 00:12:35,753 en esta foto, pero es importante que entendáis cuál es el end to end de una 185 00:12:35,753 --> 00:12:37,316 solución en tiempo real. 186 00:12:37,516 --> 00:12:41,126 Una solución en tiempo real, por lo menos tal y como la entendemos nosotros en 187 00:12:41,126 --> 00:12:44,409 Estratio, empieza siempre en las fuentes de información y termina en la 188 00:12:44,409 --> 00:12:45,347 visualización. 189 00:12:45,547 --> 00:12:50,430 Es muy importante, especialmente en Big Data, que todos los resultados de todo lo 190 00:12:50,430 --> 00:12:54,460 que hagáis, pruebas de concepto, proyectos, etc., siempre tengan un 191 00:12:54,460 --> 00:12:55,620 resultado tangible. 192 00:12:55,820 --> 00:12:58,815 Porque muchas veces... 193 00:12:59,015 --> 00:13:05,487 los objetivos de un proyecto Big Data no son tangibles hasta que no los visualizas. 194 00:13:05,687 --> 00:13:10,621 Siempre contemplamos un end-to-end, como veis, desde las fuentes, pasando por la 195 00:13:10,621 --> 00:13:13,682 ingesta, almacenamiento, consulta y visualización. 196 00:13:13,922 --> 00:13:18,288 Así pensamos nosotros que se deberían afrontar los proyectos en tiempo real. 197 00:13:18,488 --> 00:13:22,850 Como veis hay necesidades más o menos claras, reflejadas, tenemos una primera 198 00:13:22,850 --> 00:13:27,500 pieza de data stream, ahora veremos qué tecnologías encajan y cuál es la necesidad 199 00:13:27,500 --> 00:13:32,207 que tiene, hay una pieza de transporte que nos permite conectar la parte del stream 200 00:13:32,207 --> 00:13:36,226 de datos con diferentes tipos de procesamiento, desde el almacenamiento 201 00:13:36,226 --> 00:13:40,302 RAW, que ahora os explico la importancia que tiene, también agregación y 202 00:13:40,302 --> 00:13:41,289 correlación. 203 00:13:41,489 --> 00:13:46,751 Podemos añadir más, podemos añadir más piezas, pero bueno, fundamentalmente en 204 00:13:46,751 --> 00:13:51,946 una arquitectura de tiempo real se requieren estas cuatro grandes cajas, data 205 00:13:51,946 --> 00:13:55,742 stream, almacenamiento en row, agregación y correlación. 206 00:13:55,942 --> 00:13:59,475 Respecto al almacenamiento de Big Data, estoy convencido de que todos vosotros 207 00:13:59,475 --> 00:14:03,285 conocéis las bases de datos relacionales, también conocéis las bases de datos NoSQL, 208 00:14:03,285 --> 00:14:06,314 seguramente conoceréis algún almacenamiento distribuido tipo HDFS o 209 00:14:06,314 --> 00:14:07,314 similar. 210 00:14:07,272 --> 00:14:11,276 Aquí no hay ninguna pegatina, como veis, es simplemente almacenamiento Big Data. 211 00:14:11,476 --> 00:14:15,790 Una cuestión interesante, que si me gustaría, luego lo vamos a ver, pero si me 212 00:14:15,790 --> 00:14:20,386 gustaría dejarlo claro ya, es que nosotros el almacenamiento Big Data en Stratio al 213 00:14:20,386 --> 00:14:23,020 menos lo consideramos que es híbrido totalmente. 214 00:14:23,220 --> 00:14:27,328 Es decir, no hay una solución que te permita resolver todas las problemáticas 215 00:14:27,328 --> 00:14:29,433 que tienes en el almacenamiento de Big Data. 216 00:14:29,633 --> 00:14:34,307 Como sabéis las bases de datos relacionales son de propósito general, te 217 00:14:34,307 --> 00:14:39,838 permiten a través de las formas normales y el modelado te permiten diseñar un caso de 218 00:14:39,838 --> 00:14:43,197 uso específico y luego el nuevo GSQL te da el resto. 219 00:14:43,397 --> 00:14:48,097 Te costará más o menos hacer una SQL pero prácticamente tienes asegurado que puedes 220 00:14:48,097 --> 00:14:51,995 extraer los datos de cualquier manera si el modelo está bien pensado. 221 00:14:52,195 --> 00:14:55,743 Las bases de datos no SQL son un poco diferentes porque son de propósito 222 00:14:55,743 --> 00:14:59,241 específico, no pretenden resolver cualquier caso de uso, sino que están 223 00:14:59,241 --> 00:15:02,890 pensadas para resolver bien uno, dos o tres casos de uso, muy específicos. 224 00:15:03,090 --> 00:15:08,266 Entonces es muy raro que consigas resolver una problemática de tiempo real con 225 00:15:08,266 --> 00:15:11,843 suficiente entidad solo con una base de datos, no SQL. 226 00:15:12,043 --> 00:15:17,464 Es raro, a lo mejor lo podéis hacer, pero habitualmente necesitas combinar al menos 227 00:15:17,464 --> 00:15:19,316 dos tipos de almacenamiento. 228 00:15:19,516 --> 00:15:24,566 Luego tenemos una capa de consulta que también veremos por qué es importante 229 00:15:24,566 --> 00:15:27,772 hablar de ella y también la parte de visualización. 230 00:15:27,972 --> 00:15:32,647 Si ponemos pegatinas encima de esta foto, hablando de tecnologías, podemos también 231 00:15:32,647 --> 00:15:37,322 cambiar las tecnologías y poner cualquier otra, pero aquí vamos a hablar de estas. 232 00:15:37,522 --> 00:15:42,169 En el caso del Data Stream podemos hablar de Flume, todos los proyectos que estáis 233 00:15:42,169 --> 00:15:46,645 viendo aquí son Apache, Apache Flume, Apache Kafka para la parte de transporte, 234 00:15:46,645 --> 00:15:50,891 almacenamiento en tiempo real que es simplemente una capa intermedia, Spark 235 00:15:50,891 --> 00:15:55,309 como pieza fundamental en la parte de procesamiento en tiempo real, tanto para 236 00:15:55,309 --> 00:15:59,957 agregación como para correlación y también para la parte de consulta, todo esto lo 237 00:15:59,957 --> 00:16:02,482 vamos a ver ahora con un poco más de detalle. 238 00:16:02,682 --> 00:16:08,682 El almacenamiento de Big Data, como veis, aquí hay cuatro pegatinas puestas, cuatro 239 00:16:08,682 --> 00:16:13,940 tecnologías, HDFS, Cassandra, Mongo y Elastic, para el estatio. 240 00:16:14,140 --> 00:16:18,265 Digamos que esto sería como la santísima trinidad del almacenamiento de Big Data. 241 00:16:18,465 --> 00:16:22,539 Podemos ir a cualquier caso de uso con estas cuatro piezas que prácticamente lo 242 00:16:22,539 --> 00:16:24,473 vamos a resolver sin ningún problema. 243 00:16:24,673 --> 00:16:28,803 Podemos añadir todas las que queráis porque ha habido una explosión de bases de 244 00:16:28,803 --> 00:16:32,383 datos no secure tremendas y que aquí podemos añadir todo lo que queráis. 245 00:16:32,583 --> 00:16:38,110 Pero bueno, estas cuatro más o menos reflejan los cuatro tipos de 246 00:16:38,110 --> 00:16:42,172 almacenamiento que podéis usar en Big Data. 247 00:16:42,372 --> 00:16:44,274 Vale, creo que nada más. 248 00:16:44,474 --> 00:16:49,366 Vamos a ir viendo ahora punto por punto, como veis hay una pequeña miga de pan 249 00:16:49,366 --> 00:16:53,941 arriba a la derecha donde vamos a ir evaluando desde las fuentes hasta el 250 00:16:53,941 --> 00:16:59,087 almacenamiento al menos, cuáles son las tecnologías y la problemática técnica a la 251 00:16:59,087 --> 00:17:02,392 que nos enfrentamos en una arquitectura de este tipo. 252 00:17:02,592 --> 00:17:08,030 Bueno, respecto a las fuentes, aquí hay un paradigma que es el de ETL, seguro que lo 253 00:17:08,030 --> 00:17:09,030 conocéis, ¿vale? 254 00:17:09,099 --> 00:17:11,041 Extraer información, transformarla y cargarla. 255 00:17:11,241 --> 00:17:12,564 Este es un paradigma que viene... 256 00:17:12,764 --> 00:17:16,369 ya dado desde el Business Intelligence, de la carga de los Data Warehouse, etc. 257 00:17:16,569 --> 00:17:21,218 Estos son disciplinas que están súper establecidas, pero en el caso del tiempo 258 00:17:21,218 --> 00:17:25,867 real tienen algunas particularidades, porque los datos los estamos cogiendo en 259 00:17:25,867 --> 00:17:30,879 tiempo real, no puedo hacer una extracción masiva de las transacciones que ha habido 260 00:17:30,879 --> 00:17:35,407 hoy en el día, digerirlas, transformarlas un poquito y guardarlas en un Data 261 00:17:35,407 --> 00:17:36,999 Warehouse, no puedo hacer eso. 262 00:17:37,199 --> 00:17:40,532 Los datos me están llegando en tiempo real, me están llegando las transacciones 263 00:17:40,532 --> 00:17:41,687 según se están produciendo. 264 00:17:41,887 --> 00:17:47,616 Entonces esto tiene unas particularidades técnicas, pero la necesidad es la misma. 265 00:17:47,816 --> 00:17:49,699 El ETL, como veis, sigue estando presente. 266 00:17:49,899 --> 00:17:55,301 Entonces para nosotros es muy importante en esta etapa del procesamiento, que es la 267 00:17:55,301 --> 00:18:00,638 etapa más temprana donde te enganchas a la fuente de datos, que se siga respetando 268 00:18:00,638 --> 00:18:05,382 las tres necesidades fundamentales de extracción, transformación y carga. 269 00:18:05,650 --> 00:18:10,761 Respecto a la parte de extracción, bueno, fuentes, aquí hemos puesto algunas, que 270 00:18:10,761 --> 00:18:15,808 son bastante clásicas en un escenario de tiempo real, pero bueno, obviamente hay 271 00:18:15,808 --> 00:18:16,800 bastantes más. 272 00:18:17,000 --> 00:18:21,274 Respecto a la extracción, podéis imaginaros que los datos no siempre vienen 273 00:18:21,274 --> 00:18:25,780 estructurados, es posible que estemos escuchando logs de aplicación, logs de un 274 00:18:25,780 --> 00:18:29,131 sistema, transacciones bancarias que vienen sin estructura. 275 00:18:29,331 --> 00:18:33,548 Entonces aquí tenemos que soportar los dos tipos de información que nos puede llegar, 276 00:18:33,548 --> 00:18:35,437 de datos estructurados y no estructurados. 277 00:18:35,637 --> 00:18:40,037 En la parte de transformación es muy relevante porque en lugar de hacer una 278 00:18:40,037 --> 00:18:44,557 transformación masiva de los datos necesitas hacer transformaciones al vuelo, 279 00:18:44,557 --> 00:18:49,374 que normalmente pasan por hacer un data cleaning, por ejemplo, de los datos, si me 280 00:18:49,374 --> 00:18:50,962 viene un log de aplicación, 281 00:18:51,162 --> 00:18:55,612 Puedo limpiar la fecha, puedo normalizarla, puedo aplicar un formato 282 00:18:55,612 --> 00:18:56,609 estándar. 283 00:18:56,809 --> 00:18:59,332 También la parte de enriquecimiento es muy importante. 284 00:18:59,532 --> 00:19:03,851 Te llega un log de aplicación, imaginaros, con una IP que ha hecho una petición y a 285 00:19:03,851 --> 00:19:07,433 través de una base de datos de GeoIP, por ejemplo, puedo averiguar la 286 00:19:07,433 --> 00:19:08,803 geolocalización de esa IP. 287 00:19:09,003 --> 00:19:13,174 Lo que estoy haciendo es añadir un campo al dato que me ha llegado originalmente 288 00:19:13,174 --> 00:19:14,174 enriqueciéndolo. 289 00:19:14,281 --> 00:19:17,769 Este proceso es bastante clásico, ya no solo en logs, sino por ejemplo en 290 00:19:17,769 --> 00:19:21,693 transacciones normalmente la transacción que te llega no tiene todos los datos del 291 00:19:21,693 --> 00:19:22,693 cliente, te llega un ID. 292 00:19:22,876 --> 00:19:27,000 Y a lo mejor para hacer otro tipo de cuestiones necesitas saber la provincia 293 00:19:27,000 --> 00:19:28,000 del cliente. 294 00:19:27,964 --> 00:19:32,729 Pues vas enriqueciendo el dato según te va llegando y le vas aplicando estas 295 00:19:32,729 --> 00:19:37,622 transformaciones orientadas o bien al data clearing o bien al enriquecimiento. 296 00:19:37,822 --> 00:19:45,236 Respecto a la carga, aquí tenemos tres tipos fundamentales de almacenamiento. 297 00:19:45,436 --> 00:19:50,186 El almacenamiento RAW, es decir, guardar exactamente el dato que me ha llegado de 298 00:19:50,186 --> 00:19:53,512 la fuente y ahora vamos a explicar por qué es importante. 299 00:19:53,712 --> 00:19:58,108 Guardar información para el procesamiento a largo plazo, ¿vale? 300 00:19:58,308 --> 00:20:01,642 orientado al batch processing, tened en cuenta que las fuentes en tiempo real 301 00:20:01,642 --> 00:20:04,889 pueden dar soporte a procesos, pero también son una entrada de información, 302 00:20:04,889 --> 00:20:08,531 una entrada de información que a lo mejor queremos explotar después en procesamiento 303 00:20:08,531 --> 00:20:09,409 batch. 304 00:20:09,609 --> 00:20:14,194 Entonces hay que almacenarlo orientado a ese tipo de explotación posterior y luego 305 00:20:14,194 --> 00:20:18,667 normalmente suelen utilizarse técnicas de indexación para hacer una analítica en 306 00:20:18,667 --> 00:20:21,328 tiempo real, por ejemplo en el caso de los logs, 307 00:20:21,528 --> 00:20:27,271 pues es muy habitual utilizar técnicas de indexación para hacer luego búsquedas de 308 00:20:27,271 --> 00:20:29,215 texto libre o similares. 309 00:20:34,203 --> 00:20:39,629 ¿Qué tecnología se podría usar en cuanto a la pieza de Data Stream? 310 00:20:39,829 --> 00:20:43,792 Nosotros habitualmente, en un gran porcentaje de los casos, utilizamos Apache 311 00:20:43,792 --> 00:20:44,792 Flume. 312 00:20:44,695 --> 00:20:46,758 Aquí hay otras tecnologías. 313 00:20:46,958 --> 00:20:51,902 No sé si conocéis Fluenty o Logestash, por ejemplo, Heca creo que también, Scoop, 314 00:20:51,902 --> 00:20:56,537 bueno, hay muchas tecnologías que te permiten hacer este tipo, resolver este 315 00:20:56,537 --> 00:20:57,903 tipo de problemas, ¿vale? 316 00:20:58,103 --> 00:21:01,912 De coger datos de una fuente en tiempo real y hacer un procesamiento con ellos. 317 00:21:02,112 --> 00:21:08,112 Flume es una tecnología bastante usada porque es muy estable, tiene ya varios 318 00:21:08,112 --> 00:21:12,270 años de desarrollo y es bastante flexible. 319 00:21:12,470 --> 00:21:16,719 No requiere codificación, todo va por programación declarativa, simplemente 320 00:21:16,719 --> 00:21:21,427 defines en un fichero cuál es tu fuente, qué transformaciones quieres aplicar, cuál 321 00:21:21,427 --> 00:21:25,217 es el destino de los datos y no hace falta a priori programar nada. 322 00:21:25,417 --> 00:21:29,485 Lo bueno que tiene Flume es que te garantiza la entrega punto a punto, ¿vale? 323 00:21:29,685 --> 00:21:34,631 Es decir, en el momento en el que el dato entra en el sistema, digamos, te garantiza 324 00:21:34,631 --> 00:21:36,658 que se va a llevar al sync, ¿vale? 325 00:21:36,858 --> 00:21:41,417 Esta garantía tiene obviamente letra pequeña, pero es fácil preparar un sistema 326 00:21:41,417 --> 00:21:45,742 productivo donde se asegure que no hay pérdida de eventos en ninguno de los 327 00:21:45,742 --> 00:21:47,087 puntos de Flume, ¿vale? 328 00:21:47,287 --> 00:21:53,287 La estructura de Flum es básicamente como veis la de un ETL, fuentes, 329 00:21:53,287 --> 00:21:58,354 transformaciones y los sinks son la parte de carga. 330 00:21:58,554 --> 00:22:03,827 Aquí hay un ejemplo de cuál es el catálogo que tiene Flum para cada uno de los casos. 331 00:22:04,027 --> 00:22:08,563 Como veis, por ejemplo, en las fuentes podemos cargar datos desde, por ejemplo, 332 00:22:08,563 --> 00:22:10,596 un spooling, que es bastante clásico. 333 00:22:10,796 --> 00:22:15,364 Spooling es engancharte a un directorio de un sistema operativo y ir recorriendo 334 00:22:15,364 --> 00:22:19,528 todos los ficheros que hay en ese directorio procesándolos línea a línea. 335 00:22:19,728 --> 00:22:25,728 En fin, podemos también engancharnos a buses tipo JMS, en fin, puedes engancharte 336 00:22:25,728 --> 00:22:27,992 a un montón de fuentes. 337 00:22:28,192 --> 00:22:31,837 En la parte de transformación, aquí tenéis un catálogo de las posibilidades que tiene 338 00:22:31,837 --> 00:22:34,138 Flume respecto a transformar los datos en tiempo real. 339 00:22:34,338 --> 00:22:36,681 Como veis, muchos de ellos están orientados a parseo. 340 00:22:36,881 --> 00:22:41,586 Me llega un dato bruto y quiero parsearlo, quiero aplicarlo a una estructura. 341 00:22:41,786 --> 00:22:45,999 Otros son para enriquecer el evento, por ejemplo, el de GeoIP o el de Add Current 342 00:22:45,999 --> 00:22:46,999 Time, por ejemplo. 343 00:22:47,031 --> 00:22:52,687 Cualquiera de ellos lo que te permiten es ensanchar el dato para añadir información 344 00:22:52,687 --> 00:22:53,687 nueva. 345 00:22:53,858 --> 00:22:58,323 Hay por ejemplo una pieza, la de Grok, que es para aplicar expresiones regulares. 346 00:22:58,523 --> 00:23:04,264 Normalmente se utiliza también para extraer datos del dato RAW que te ha 347 00:23:04,264 --> 00:23:06,272 llegado. 348 00:23:06,472 --> 00:23:11,554 Y en cuanto a los destinos, como podéis ver, hay diferentes opciones para grabar 349 00:23:11,554 --> 00:23:12,520 los datos. 350 00:23:12,720 --> 00:23:18,026 MongoDB, Elastic, HBase, HDFS, Cassandra, en fin, hay bastante variedad. 351 00:23:18,226 --> 00:23:22,986 Lo bueno que tiene Flume es que puedes grabar en syncs en paralelo, es decir, 352 00:23:22,986 --> 00:23:28,247 puedes grabar a la vez en Cassandra y a la vez en HDFS o puedes grabar todo en HDFS y 353 00:23:28,247 --> 00:23:32,631 solo los eventos que tengan una expresión regular concreta se graban en 354 00:23:32,631 --> 00:23:33,631 Elasticsearch. 355 00:23:33,744 --> 00:23:38,628 Es una pieza bastante potente en ese sentido y como os digo se utiliza 356 00:23:38,628 --> 00:23:41,712 muchísimo en cuanto a la captura de datos. 357 00:23:41,914 --> 00:23:46,022 Bueno, no me voy a entretener mucho más. 358 00:23:46,222 --> 00:23:51,333 En cuanto al transporte de datos, ¿qué necesidades fundamentales tenemos en el 359 00:23:51,333 --> 00:23:52,329 transporte? 360 00:23:52,651 --> 00:23:58,560 Lo primero es que de alguna manera haya una especie de especificación en lo que 361 00:23:58,560 --> 00:24:01,003 está circulando en el bus. 362 00:24:01,203 --> 00:24:04,689 Esto no es totalmente obligatorio, pero sí es recomendable. 363 00:24:04,889 --> 00:24:10,559 Que soporte esquemas o que soporte alguna forma de definir lo que el consumidor está 364 00:24:10,559 --> 00:24:13,697 enviando y lo que el receptor está recibiendo. 365 00:24:13,897 --> 00:24:17,100 No obstante, como os digo, no es algo obligatorio. 366 00:24:17,300 --> 00:24:22,872 Hay diferentes formas de solucionar este tipo de desacople entre productor y 367 00:24:22,872 --> 00:24:24,445 consumidor. 368 00:24:25,267 --> 00:24:29,898 Lo que sí es interesante es esto, que tenga muy alto rendimiento y que sea 369 00:24:29,898 --> 00:24:32,373 bastante escalable la solución de base. 370 00:24:32,594 --> 00:24:33,955 Y esto es importante. 371 00:24:34,155 --> 00:24:38,676 Hay algunos buses del mercado que seguro que conocéis, RabbitMQ, ActiveMQ, Hornet, 372 00:24:38,676 --> 00:24:40,240 Apollo, cualquiera de ellas. 373 00:24:40,440 --> 00:24:42,333 Cualquiera de ellos son tecnologías que 374 00:24:42,533 --> 00:24:47,351 ya posiblemente tengan 8 o 10 años y que no nacen con la necesidad de la 375 00:24:47,351 --> 00:24:48,903 escalabilidad de base. 376 00:24:49,103 --> 00:24:53,766 Entonces lo que han hecho es ir añadiendo diferentes parches para soportar 377 00:24:53,766 --> 00:24:58,557 escalabilidad, lo cual no está mal, pero no nacen con esta solución de base. 378 00:24:58,757 --> 00:25:03,218 Entonces ahora vamos a ver alguna tecnología que sí que nos permite una 379 00:25:03,218 --> 00:25:05,768 escalabilidad y un rendimiento muy alto. 380 00:25:05,968 --> 00:25:09,941 Y el último punto quizás es el más importante de todos en una arquitectura de 381 00:25:09,941 --> 00:25:10,852 Big Data. 382 00:25:11,052 --> 00:25:14,040 poder desacoplar productores y consumidores. 383 00:25:14,240 --> 00:25:20,240 Esto es bastante interesante, yo creo que es de las cuestiones más novedosas que se 384 00:25:20,240 --> 00:25:25,668 están viendo en el último año, año y medio en las tecnologías de Big Data. 385 00:25:25,868 --> 00:25:30,636 Por ejemplo, LinkedIn propone una arquitectura en la que todas sus fuentes 386 00:25:30,636 --> 00:25:35,079 de información están totalmente desacopladas de los que los consumen. 387 00:25:35,279 --> 00:25:40,065 Ahora vamos a ver cómo esta pieza te ayuda a desacoplar un productor y un consumidor. 388 00:25:40,265 --> 00:25:45,009 Los buses tradicionales están pensados para comunicar punto a punto. 389 00:25:46,272 --> 00:25:49,209 La calidad del servicio, por ejemplo, depende de que el productor emita un 390 00:25:49,209 --> 00:25:50,578 mensaje y el consumidor lo reciba. 391 00:25:50,778 --> 00:25:54,963 Si no lo recibe, entran en juego unas políticas de reintentos, etcétera. 392 00:25:55,163 --> 00:25:57,685 En este caso, esta comunicación no existe. 393 00:25:57,926 --> 00:26:00,388 El productor produce y el consumidor consume. 394 00:26:00,588 --> 00:26:04,186 El productor produce y no sabe quién lo va a consumir y el consumidor consume y no 395 00:26:04,186 --> 00:26:05,473 sabe quién le ha enviado el dato. 396 00:26:05,673 --> 00:26:11,664 Esto es muy interesante para especialmente el rendimiento y también para garantizar 397 00:26:11,664 --> 00:26:17,522 que los evolutivos que se vayan haciendo sobre la arquitectura se soporten mejor. 398 00:26:18,205 --> 00:26:23,235 La pieza que habitualmente utilizamos en esta fase, en la fase de transporte, es 399 00:26:23,235 --> 00:26:24,191 Kafka. 400 00:26:24,391 --> 00:26:27,761 Seguro que habéis oído hablar o lo conocéis. 401 00:26:27,961 --> 00:26:33,818 Es un bus liberado por LinkedIn, ya forma parte de la Apache Software Foundation. 402 00:26:34,018 --> 00:26:37,685 La verdad es que es una maravilla, a mí es una de las piezas que más me gustan de 403 00:26:37,685 --> 00:26:38,923 este tipo de arquitecturas. 404 00:26:39,123 --> 00:26:42,965 El concepto la verdad es que es muy sencillo, el concepto base de Kafka es muy 405 00:26:42,965 --> 00:26:43,870 sencillo. 406 00:26:44,070 --> 00:26:49,111 Rompen con el esquema tradicional de un bus y logran escalabilidad en base a un 407 00:26:49,111 --> 00:26:54,347 clúster de brokers, replicación y hay una pieza muy interesante en la arquitectura 408 00:26:54,347 --> 00:26:59,712 de Kafka que es el offset, el concepto de offset, que eso en los buses tradicionales 409 00:26:59,712 --> 00:27:00,712 no existe. 410 00:27:00,672 --> 00:27:06,232 El offset es básicamente el mecanismo que tiene el consumidor para saber por dónde 411 00:27:06,232 --> 00:27:07,547 está leyendo, ¿vale? 412 00:27:07,747 --> 00:27:11,177 El productor está enviando una pila de mensajes, imaginaros 100 mensajes y el 413 00:27:11,177 --> 00:27:13,800 consumidor aparece y empieza a leer desde un punto concreto. 414 00:27:14,000 --> 00:27:18,150 Puede empezar a leer desde el principio o puede empezar a leer desde el momento en 415 00:27:18,150 --> 00:27:20,047 el que se levanta el consumidor, ¿no? 416 00:27:20,247 --> 00:27:25,100 A partir de ese momento el consumidor empieza a guardar un registro del punto en 417 00:27:25,100 --> 00:27:29,893 el que se encuentra, en qué mensaje se encuentra para que en caso de que pare y 418 00:27:29,893 --> 00:27:34,624 vuelva a empezar a leer, por algún motivo, sepa continuar desde donde lo dejó. 419 00:27:34,824 --> 00:27:40,791 Este concepto en los buses tradicionales no existe y es una de las piezas clave en 420 00:27:40,791 --> 00:27:46,625 la arquitectura de Kafka porque te permite desacoplar, como os digo, la parte de 421 00:27:46,625 --> 00:27:50,860 producción de datos de la parte de consumición de datos. 422 00:27:51,854 --> 00:27:56,624 Bueno, respecto a la parte de agregación en tiempo real, que esto es una 423 00:27:56,624 --> 00:28:02,128 problemática bastante usada, prácticamente todos los datos que consumís en Twitter, 424 00:28:02,128 --> 00:28:05,072 por ejemplo, o en Facebook son datos agregados. 425 00:28:05,272 --> 00:28:08,918 Nunca hay una consulta a una base de datos para hacer un group buy. 426 00:28:09,118 --> 00:28:14,559 Normalmente se hace una consulta donde tú tienes una foto estática de lo que hay en 427 00:28:14,559 --> 00:28:15,667 tu muro de Facebook. 428 00:28:15,867 --> 00:28:18,130 Son datos que están preagregados. 429 00:28:18,330 --> 00:28:22,071 En ningún caso, como os digo, a Facebook por volumen de datos se le ocurre ir a la 430 00:28:22,071 --> 00:28:23,877 base de datos cada vez a hacer un group buy. 431 00:28:24,077 --> 00:28:25,559 Son datos que están preagregados. 432 00:28:25,759 --> 00:28:29,303 Y es una problemática que, como os digo, está presente en muchos sectores. 433 00:28:29,503 --> 00:28:33,780 No solo en Facebook, sino que el hacer agregación en tiempo real es un problema 434 00:28:33,780 --> 00:28:34,780 bastante clásico. 435 00:28:34,790 --> 00:28:39,005 ¿Qué necesidades hay en cuanto a una agregación en tiempo real? 436 00:28:39,205 --> 00:28:44,313 Habitualmente tener este tipo de estadísticas y KPIs que están calculados 437 00:28:44,313 --> 00:28:49,281 con antelación te permite, por ejemplo, tomar información en tiempo real. 438 00:28:49,481 --> 00:28:54,368 No solo es un tema de rendimiento, de no machacar la base de datos para hacer el 439 00:28:54,368 --> 00:28:59,441 mismo group by n veces, sino que también es un tema de conseguir KPIs que no tienes 440 00:28:59,441 --> 00:29:00,420 actualmente. 441 00:29:00,620 --> 00:29:05,781 También la parte de agregación multidimensional es una necesidad, 442 00:29:05,781 --> 00:29:11,781 necesitas, por ponerse un ejemplo, los tweets, podemos medir tweets por minuto, 443 00:29:11,781 --> 00:29:17,610 los tweets que tiene una persona por minuto, pero también podemos medir los 444 00:29:17,610 --> 00:29:23,505 tweets que hay en un hashtag concreto por minuto, por hora y por día, ¿vale? 445 00:29:23,705 --> 00:29:29,002 Podemos agregar toda la actividad que se está produciendo en un banco concreto, en 446 00:29:29,002 --> 00:29:34,365 un cajero concreto, en una cuenta concreta de un cliente, agregar transacciones por 447 00:29:34,365 --> 00:29:36,998 tarjeta de crédito o transferencia habitual. 448 00:29:37,198 --> 00:29:41,274 Este tipo de agregaciones multidimensionales son muy clásicas. 449 00:29:41,474 --> 00:29:44,444 Como os digo, te permiten tener información actualizada en tiempo real. 450 00:29:44,644 --> 00:29:49,458 Que el banco pueda saber en este minuto preciso cuáles son la cantidad de 451 00:29:49,458 --> 00:29:54,805 transacciones que han ocurrido por minuto en tal provincia o en tal sucursal o en 452 00:29:54,805 --> 00:29:55,820 tal cajero. 453 00:29:56,020 --> 00:30:00,040 Y luego respecto a la flexibilidad y recuperación de los datos, la agregación 454 00:30:00,040 --> 00:30:03,108 lo que te permite es poder jugar con los datos mucho mejor. 455 00:30:03,308 --> 00:30:07,786 En lugar de matarte haciéndote consultas con GroupBytes uniendo 17 tablas para 456 00:30:07,786 --> 00:30:12,439 conseguir este KPI concreto, defines los KPIs que necesitas de entrada y el motor 457 00:30:12,439 --> 00:30:16,662 de agregación o la solución de agregación te permite tenerlos ya calculados. 458 00:30:16,862 --> 00:30:21,812 Con lo cual tienes que hacer únicamente una consulta para decir dame la situación 459 00:30:21,812 --> 00:30:24,288 que había en el minuto 33 de la hora 10. 460 00:30:24,488 --> 00:30:29,436 Entonces esto te da una flexibilidad y una rapidez en cuanto al consumo de datos que 461 00:30:29,436 --> 00:30:30,436 es tremenda. 462 00:30:30,415 --> 00:30:34,420 Es un cambio totalmente diferente y os voy a poner un ejemplo. 463 00:30:34,620 --> 00:30:39,392 Para que ahora mismo alguien de negocio en un banco solicite un KPI nuevo, quiero 464 00:30:39,392 --> 00:30:44,224 saber cuántas transacciones se hacen por minuto por sucursal bancaria, a partir de 465 00:30:44,224 --> 00:30:48,878 esa petición tan sencilla arranca un proceso de business intelligence, de carga 466 00:30:48,878 --> 00:30:53,769 de datos, etcétera, que puede tardar días y no meses hasta que por fin esta persona 467 00:30:53,769 --> 00:30:54,765 tiene ese dato. 468 00:30:54,965 --> 00:31:00,383 De esta manera es fácil hacer agregaciones en tiempo real si tienes los datos de las 469 00:31:00,383 --> 00:31:03,648 transacciones y conseguir ese KPI mucho más rápido. 470 00:31:03,848 --> 00:31:09,463 ¿Qué soluciones solemos utilizar para las agregaciones en tiempo real? 471 00:31:09,663 --> 00:31:12,246 A ver cómo voy de tiempo. 472 00:31:12,515 --> 00:31:18,515 Bueno, habitualmente solemos utilizar Spark, Apache Spark es un nuevo paradigma 473 00:31:18,515 --> 00:31:24,515 de procesamiento que viene a reemplazar MapReduce, Hadoop MapReduce, tiene la 474 00:31:24,515 --> 00:31:28,515 ventaja de que es mucho más... 475 00:31:28,715 --> 00:31:33,188 más potente, más rico en cuanto a las operaciones que te permite hacer y tiene 476 00:31:33,188 --> 00:31:37,831 otra ventaja que es que soporta estas tres vertientes de procesamiento y alguna más. 477 00:31:38,031 --> 00:31:42,627 Mínimo es para que se cuele consulta interactiva, procesamiento en tiempo real 478 00:31:42,627 --> 00:31:43,762 y machine learning. 479 00:31:43,962 --> 00:31:48,073 También tiene otras capacidades, por ejemplo, procesamiento orientado a grafos. 480 00:31:48,273 --> 00:31:52,193 Y esto te permite desarrollar proyectos con una única tecnología, pero que te 481 00:31:52,193 --> 00:31:56,010 permiten aplicar Machine Learning o procesamiento en tiempo real o consulta 482 00:31:56,010 --> 00:31:58,066 interactiva sabiendo solo una tecnología. 483 00:31:58,266 --> 00:32:02,933 Voy a ir un poco rápido para intentar cubrir todos los slides. 484 00:32:03,133 --> 00:32:06,377 Apache Spark, seguro que lo conocéis. 485 00:32:06,577 --> 00:32:10,683 Este es un benchmark bastante clásico de ordenación de registros. 486 00:32:10,883 --> 00:32:15,950 Este es el último récord de Hadoop en 2013 y este es el de 2014 de Spark. 487 00:32:16,150 --> 00:32:20,656 Veis que la infraestructura que se necesita es bastante menor y el 488 00:32:20,656 --> 00:32:23,097 procesamiento es mucho más rápido. 489 00:32:24,842 --> 00:32:29,938 Como os digo, Spark tiene una vertical específica para procesamiento en tiempo 490 00:32:29,938 --> 00:32:35,432 real con la que podríamos desarrollar una solución de agregación como la que estamos 491 00:32:35,432 --> 00:32:36,690 viendo ahora mismo. 492 00:32:36,890 --> 00:32:41,378 Bueno, en cuanto a la correlación, esta es una necesidad bastante interesante, 493 00:32:41,378 --> 00:32:44,119 especialmente para detectar patrones de eventos. 494 00:32:44,319 --> 00:32:48,117 Por ejemplo, imaginad que estoy escuchando las transacciones que ocurren en un cajero 495 00:32:48,117 --> 00:32:49,566 automático y quiero detectar fraude. 496 00:32:49,766 --> 00:32:51,749 Bueno, pues es muy sencillo, o no tan sencillo. 497 00:32:51,949 --> 00:32:52,949 A mí se me ocurre una. 498 00:32:52,710 --> 00:32:56,683 Por ejemplo, detectar el uso de la misma tarjeta de crédito en dos cajeros 499 00:32:56,683 --> 00:32:57,616 diferentes. 500 00:32:57,816 --> 00:33:01,942 Uso un cajero aquí, uso otro cajero en Segovia, en un rango de tiempo de 15 501 00:33:01,942 --> 00:33:03,624 minutos, pues puede haber fraude. 502 00:33:03,824 --> 00:33:06,407 Alguien me ha clonado la tarjeta y la está usando en otro sitio, ¿no? 503 00:33:06,607 --> 00:33:11,190 Ese tipo de patrones es el que habitualmente se resuelve con ese tipo de 504 00:33:11,190 --> 00:33:13,966 procesamiento, con Complex Event Processing. 505 00:33:14,166 --> 00:33:19,329 No está presente en Spark como tal, pero sí se puede hacer alguna regla de Complex 506 00:33:19,329 --> 00:33:22,134 Event Processing como tal en Spark Streaming. 507 00:33:22,334 --> 00:33:26,470 Respecto al almacenamiento RAW, solo deciros que es muy importante en cualquier 508 00:33:26,470 --> 00:33:30,395 arquitectura de tiempo real guardar el dato que te ha llegado tal cual, sin 509 00:33:30,395 --> 00:33:31,375 transformación. 510 00:33:31,575 --> 00:33:36,807 Y es muy importante especialmente por el punto central, el del reprocesamiento. 511 00:33:37,007 --> 00:33:41,220 ¿Qué ocurre si el proceso que yo he hecho en tiempo real tiene un bug, por ejemplo? 512 00:33:41,420 --> 00:33:44,163 ¿Cómo voy a la fuente otra vez a decirle, oye, dame las transacciones de ayer? 513 00:33:44,363 --> 00:33:46,545 No puedo, es una fuente en tiempo real. 514 00:33:46,745 --> 00:33:51,150 Entonces, es muy importante guardar el row y prever mecanismos de reprocesamiento 515 00:33:51,150 --> 00:33:55,666 para que en caso de que haya un bug o en caso de que te venga el usuario de negocio 516 00:33:55,666 --> 00:33:59,410 a pedirte un nuevo KPI, puedas recalcularlo desde hace uno, dos, tres 517 00:33:59,410 --> 00:34:00,410 meses o un año. 518 00:34:00,419 --> 00:34:02,041 Eso es muy importante. 519 00:34:02,241 --> 00:34:07,416 Aquí hay tecnologías, seguro que las conocéis todas ellas, HDFS como 520 00:34:07,416 --> 00:34:10,059 almacenamiento a largo plazo, 521 00:34:10,259 --> 00:34:15,083 MongoDB, Elasticsearch, Cassandra, todas ellas te pueden servir para este tipo de 522 00:34:15,083 --> 00:34:16,016 solución. 523 00:34:16,216 --> 00:34:21,022 Respecto a la consulta, aquí solo comentaros una cuestión. 524 00:34:21,222 --> 00:34:24,605 Habitualmente, como os digo, un lago Big Data no se conforma solo con una 525 00:34:24,605 --> 00:34:25,868 tecnología de almacenamiento. 526 00:34:26,068 --> 00:34:28,812 No te vale solo HDFS, solo Cassandra, solo Mongo. 527 00:34:29,012 --> 00:34:35,300 Normalmente tendrás dos o más piezas unidas para dar una solución. 528 00:34:35,500 --> 00:34:38,936 Entonces, una capa de consulta que te permita atacar a los dos fuentes 529 00:34:38,936 --> 00:34:42,821 simultáneamente y que puedas hacer un join, por ejemplo, entre datos que tienes 530 00:34:42,821 --> 00:34:45,092 en Mongo y datos que tienes en HDFS es fundamental. 531 00:34:45,292 --> 00:34:50,397 Para ello, habitualmente, nos apoyamos en Cassandra, en Mongo, en Elastic, voy a 532 00:34:50,397 --> 00:34:54,405 pasarlo un poco rápido, pero la pieza fundamental es Spark SQL. 533 00:34:54,646 --> 00:34:59,429 Spark SQL sí que te permite, a través de las abstracciones que tiene DataFrames, te 534 00:34:59,429 --> 00:35:03,454 permite hacer este tipo de joins, de agregaciones, etc., entre fuentes 535 00:35:03,454 --> 00:35:04,421 diferentes. 536 00:35:04,621 --> 00:35:09,465 Bueno, y ahora voy a pasar rápido por la demo que traía, no es una demo real, 537 00:35:09,465 --> 00:35:11,952 simplemente es contaros un caso de uso. 538 00:35:12,152 --> 00:35:14,455 Row, que es una compañía que me he inventado, 539 00:35:14,705 --> 00:35:19,475 Es una compañía de retail, no vamos a ponerle nombre, podéis imaginaros 540 00:35:19,475 --> 00:35:24,845 cualquiera, que debido a la aparición de diferentes actores digitales que están, 541 00:35:24,845 --> 00:35:30,015 como os decía antes, canibalizándole sus parcelas, necesita mejorar todos sus 542 00:35:30,015 --> 00:35:34,073 tiempos de respuesta y procesos para ganar ventaja competitiva. 543 00:35:34,273 --> 00:35:36,316 ¿Cuál es la situación actual de ROW? 544 00:35:36,516 --> 00:35:41,268 Pues tiene procesamientos nocturnos, tiene inteligencia estática basada en reporting 545 00:35:41,268 --> 00:35:42,365 mensual, por ejemplo... 546 00:35:42,565 --> 00:35:48,174 Tiene sistemas complejos, es una compañía que suele tener 20 años, como os decía, 547 00:35:48,174 --> 00:35:51,718 15, 20 años, son muchos años de deuda tecnológica. 548 00:35:51,918 --> 00:35:54,803 Y habitualmente algunas de ellas han lanzado a un canal online, pero no han 549 00:35:54,803 --> 00:35:55,583 hecho bien. 550 00:35:55,783 --> 00:35:57,326 Lo han hecho como un silo más. 551 00:35:57,526 --> 00:36:01,551 Entonces tienen su canal offline y el canal online normalmente con departamentos 552 00:36:01,551 --> 00:36:02,551 totalmente duplicados. 553 00:36:02,693 --> 00:36:06,999 ¿Cómo aplicamos una solución de tiempo real en una compañía como esta? 554 00:36:07,199 --> 00:36:09,703 Pues fijaros que partiendo desde un... 555 00:36:09,903 --> 00:36:14,226 una premisa tan sencilla como dame los tickets digitales simplemente déjame 556 00:36:14,226 --> 00:36:18,374 escuchar los tickets de compra en formato digital que eso es algo que ya 557 00:36:18,374 --> 00:36:23,223 prácticamente todos tienen podemos empezar a montar una solución en tiempo real para 558 00:36:23,223 --> 00:36:27,547 darle muchas ventajas a este tipo de compañía ahí veis un ticket en formato 559 00:36:27,547 --> 00:36:31,987 jason con la fecha el cliente que ha comprado qué método de pago ha usado qué 560 00:36:31,987 --> 00:36:35,201 centro comercial ha comprado el cajero etcétera etcétera 561 00:36:35,401 --> 00:36:40,106 Bueno, si empezamos a utilizar todas las tecnologías que hemos estado viendo hasta 562 00:36:40,106 --> 00:36:44,928 ahora, utilizamos Flume para capturar los datos, hacer un enriquecimiento del ticket 563 00:36:44,928 --> 00:36:47,300 añadiendo la ciudad, por ejemplo, el canal. 564 00:36:47,500 --> 00:36:50,443 cualquier otra información relevante. 565 00:36:50,643 --> 00:36:55,911 Podemos pasar a la correlación de datos en la que podemos averiguar, por ejemplo, si 566 00:36:55,911 --> 00:37:00,926 hay compras fraudulentas o cuáles son los niveles de stock o cuál es el canal de 567 00:37:00,926 --> 00:37:05,941 actividad que está fallando, por ejemplo, si te dejan de llegar peticiones de un 568 00:37:05,941 --> 00:37:10,384 canal concreto, pues puedes saber que puede haber un fallo en ese canal 569 00:37:10,384 --> 00:37:11,384 concreto. 570 00:37:11,513 --> 00:37:15,202 Podemos hacer agregaciones para calcular KPIs, por ejemplo, de la actividad que 571 00:37:15,202 --> 00:37:19,129 está ocurriendo diariamente, o a la hora, o al minuto, la actividad de cada cliente, 572 00:37:19,129 --> 00:37:22,582 el rendimiento por producto, por centro comercial, por método de pago y el 573 00:37:22,582 --> 00:37:24,409 comportamiento del cliente en tiempo real. 574 00:37:24,609 --> 00:37:27,293 Todo esto son cosas que habitualmente estas empresas no tienen. 575 00:37:27,513 --> 00:37:33,224 Tienen que esperar un día entero o si no un mes para tener un informe que les diga 576 00:37:33,224 --> 00:37:38,335 cuáles son las ventas que se han producido, cuáles son los hábitos de sus 577 00:37:38,335 --> 00:37:39,647 clientes, ¿no? 578 00:37:39,847 --> 00:37:45,110 En cuanto al almacenamiento, como veis podemos usar cualquiera de las tecnologías 579 00:37:45,110 --> 00:37:49,913 que hemos hablado, en consulta Spark SQL es la pieza clave para poder unir 580 00:37:49,913 --> 00:37:54,518 especialmente el mundo Big Data con las bases de datos existentes en la 581 00:37:54,518 --> 00:37:57,720 corporación, Oracle o Postgres o cualquiera de ellas. 582 00:37:57,920 --> 00:37:58,920 ¿Y cuál es el resultado? 583 00:37:59,062 --> 00:38:03,133 Pues podríamos tener una visualización de este tipo, podríamos tener un rendimiento 584 00:38:03,133 --> 00:38:06,014 de lo que está ocurriendo por minuto en mi compañía entera. 585 00:38:06,254 --> 00:38:09,839 Quiero saber dentro de ROW, quiero saber qué está ocurriendo, las transacciones que 586 00:38:09,839 --> 00:38:11,283 están ocurriendo en este momento. 587 00:38:11,483 --> 00:38:16,274 Podría hacer un drill down para llegar a saber por minuto cómo está rindiendo el 588 00:38:16,274 --> 00:38:19,185 centro comercial que está situado en Guadalajara. 589 00:38:19,385 --> 00:38:23,576 O podría llegar incluso a saber cuál es el rendimiento por método de pago o cualquier 590 00:38:23,576 --> 00:38:24,494 otra cosa. 591 00:38:24,694 --> 00:38:28,898 Este tipo de información la tienes ya calculada en tiempo real y preagregada, 592 00:38:28,898 --> 00:38:31,947 con lo cual este tipo de visualizaciones son súper rápidas. 593 00:38:32,147 --> 00:38:37,269 No tienes que ir a la base de datos, hacer agregaciones, pasar por procesos de tele, 594 00:38:37,269 --> 00:38:39,738 procesos nocturnos de carga masiva, etc. 595 00:38:39,938 --> 00:38:44,455 También podríamos tener paneles de monitorización donde puedas ver en forma 596 00:38:44,455 --> 00:38:49,095 de mapa geolocalizado cuál es la actividad que está ocurriendo en tus centros 597 00:38:49,095 --> 00:38:51,113 comerciales o en tus canales online. 598 00:38:51,313 --> 00:38:54,950 Los centros comerciales quizás serían los puntos más gruesos, pero un canal online 599 00:38:54,950 --> 00:38:57,001 te puede llegar una venta desde cualquier punto. 600 00:38:57,201 --> 00:39:01,869 Este sería un mapa bastante real de una empresa que tiene esa mezcla entre canal 601 00:39:01,869 --> 00:39:03,009 offline y canal online. 602 00:39:03,209 --> 00:39:07,938 O cuáles son los hábitos de tu cliente, por ejemplo, si compra más alimentación, o 603 00:39:07,938 --> 00:39:12,785 si ha gastado más dinero en electrónica, o si suele pagar con tarjeta de crédito, si 604 00:39:12,785 --> 00:39:17,690 el volumen de compras que hace normalmente es bajo, medio o alto, por ejemplo, en qué 605 00:39:17,690 --> 00:39:21,836 centros comerciales suele comprar, toda esta información la podéis tener 606 00:39:21,836 --> 00:39:23,413 actualizada en tiempo real. 607 00:39:23,613 --> 00:39:28,380 Y esta es la gran diferencia que hay respecto a las arquitecturas que hay 608 00:39:28,380 --> 00:39:32,287 montadas en cualquier empresa que os encontréis ahora mismo. 609 00:39:32,487 --> 00:39:35,293 Bueno, pues nada más. 610 00:39:35,493 --> 00:39:37,578 Creo que de tiempo vamos bien. 611 00:39:37,778 --> 00:39:41,706 Sí. 612 00:39:41,906 --> 00:39:46,099 Bueno, como os digo, nosotros tenemos en Statio algunas soluciones desarrolladas ya 613 00:39:46,099 --> 00:39:47,099 sobre Spark. 614 00:39:47,077 --> 00:39:49,807 Por ejemplo, tenemos un motor de agregación en tiempo real, totalmente open 615 00:39:49,807 --> 00:39:50,546 source. 616 00:39:50,746 --> 00:39:52,821 Tenemos una capa también de acceso a datos, tenemos herramientas de 617 00:39:52,821 --> 00:39:53,450 visualización. 618 00:39:53,670 --> 00:39:56,214 Os animo a que echéis un vistazo a nuestro GitHub. 619 00:39:56,414 --> 00:40:01,604 Tenemos repositorios open con licencia Apache 2, donde tenemos nuestros módulos 620 00:40:01,604 --> 00:40:02,604 publicados. 621 00:40:02,623 --> 00:40:06,826 Podéis echar un vistazo a nuestra página web, a nuestro Twitter. 622 00:40:08,050 --> 00:40:14,050 Necesitamos a gente para sacar todo esto adelante, así que os animo también a que 623 00:40:14,050 --> 00:40:18,285 echéis un vistazo a las oportunidades que tenemos. 624 00:40:18,485 --> 00:40:20,168 Y nada más. 625 00:40:20,368 --> 00:40:22,168 Muchas gracias. 626 00:40:34,840 --> 00:40:42,621 Si queréis hacer alguna pregunta, disparad ahora. 627 00:40:50,855 --> 00:40:52,198 [Orador 3]: Buenas. 628 00:40:52,398 --> 00:40:57,758 La pregunta es sobre todo cuando le dais la solución a una empresa, lo primero es, 629 00:40:57,758 --> 00:41:02,920 si ellos ya tienen servidores o un sistema propio interno, ¿vosotros lo alojáis 630 00:41:02,920 --> 00:41:06,182 siempre dentro de eso o le dais una solución externa? 631 00:41:06,382 --> 00:41:11,430 Y lo segundo es, a la gente que está allí que normalmente toda esta tecnología no la 632 00:41:11,430 --> 00:41:14,718 conoce, ¿lo formáis vosotros o cómo solucionáis ese tema? 633 00:41:14,918 --> 00:41:16,239 [Orador 1]: Vale. 634 00:41:16,439 --> 00:41:17,439 Bueno, respecto a tu primera... 635 00:41:17,100 --> 00:41:18,100 Muchas gracias. 636 00:41:17,420 --> 00:41:19,102 Respecto a tu primera pregunta, gracias a ti. 637 00:41:19,302 --> 00:41:22,909 Respecto a tu primera pregunta, la verdad es que es una problemática que va más allá 638 00:41:22,909 --> 00:41:23,909 de dónde lo despliego. 639 00:41:23,886 --> 00:41:28,051 Va más allá de si tengo máquinas compradas o no las tengo, porque eso normalmente es 640 00:41:28,051 --> 00:41:31,012 una cuestión, pues eso, de hacer una orden de compra, ¿vale? 641 00:41:31,212 --> 00:41:34,723 La problemática va más allá, es, vale, yo tengo esto en mi casa ahora montado, 642 00:41:34,723 --> 00:41:35,723 ¿quién lo mantiene? 643 00:41:35,656 --> 00:41:38,960 ¿Quién se encarga de cuando Kafka tenga un problema? 644 00:41:39,160 --> 00:41:40,461 ¿Quién mira, no? 645 00:41:40,661 --> 00:41:43,575 Porque habitualmente los departamentos de sistemas de las empresas... 646 00:41:43,775 --> 00:41:47,466 Tienes especialistas en sistemas, especialistas en bases de datos, 647 00:41:47,466 --> 00:41:51,708 especialistas en aplicaciones web, pero no tienes especialistas en Big Data. 648 00:41:51,908 --> 00:41:55,600 Entonces, cuando vas a una empresa a contar una solución de este tipo, suele 649 00:41:55,600 --> 00:41:59,489 haber preguntas de, oye, vale, me encanta, lo necesito, sé que lo necesito, pero 650 00:41:59,489 --> 00:42:03,378 quiero saber al día siguiente de que me lo pongas en producción, ¿quién mantiene 651 00:42:03,378 --> 00:42:04,378 esto? 652 00:42:04,342 --> 00:42:07,525 Bueno, pues para eso, obviamente hay empresas que te dan soporte, ¿no? 653 00:42:07,725 --> 00:42:12,331 Nosotros somos una de ellas, también tienes Cloudera, Hortonworks, cualquier 654 00:42:12,331 --> 00:42:17,367 proveedor de Big Data, no solo te provee la tecnología, sino que también te ayuda a 655 00:42:17,367 --> 00:42:19,333 mantenerla en producción, ¿vale? 656 00:42:19,533 --> 00:42:23,958 Obviamente, igual que pasa con Oracle, por ejemplo, tienes que pagar una licencia. 657 00:42:24,158 --> 00:42:25,158 Oracle no se mantiene solo. 658 00:42:25,179 --> 00:42:30,035 Tienes que pagar una licencia anual para tener soporte, para poder hacer uso de esa 659 00:42:30,035 --> 00:42:31,987 tecnología en un entorno productivo. 660 00:42:32,187 --> 00:42:37,177 Lo primero, que sepas que hay empresas que te pueden ayudar a montar esto en 661 00:42:37,177 --> 00:42:38,175 producción. 662 00:42:38,375 --> 00:42:42,931 Respecto a la infraestructura, la verdad es que normalmente se utiliza 663 00:42:42,931 --> 00:42:44,582 infraestructura dedicada. 664 00:42:44,782 --> 00:42:48,426 No se suele reutilizar infraestructura que ya tenga la compañía. 665 00:42:48,642 --> 00:42:52,589 Especialmente porque las necesidades de Big Data son muy particulares. 666 00:42:52,789 --> 00:42:56,921 Igual que un Teradata, por ejemplo, o un Exadata o un Oracle, igual tienen 667 00:42:56,921 --> 00:42:58,157 infraestructura dedicada. 668 00:42:58,357 --> 00:43:03,305 Normalmente un banco no tiene un Oracle instalado en una máquina cualquiera. 669 00:43:03,505 --> 00:43:07,921 Tiene una Playams, una máquina que va enracada y que tiene un hardware 670 00:43:07,921 --> 00:43:11,518 específico para que esa base de datos corra como un demonio. 671 00:43:11,718 --> 00:43:15,636 Entonces, habitualmente tiene sentido que si vas a invertir en una solución de Big 672 00:43:15,636 --> 00:43:16,636 Data, 673 00:43:16,486 --> 00:43:21,361 inviertas a su vez en un hardware específico que te permita también sacar el 674 00:43:21,361 --> 00:43:23,442 máximo provecho a la tecnología. 675 00:43:23,642 --> 00:43:27,566 Y la segunda pregunta que me has hecho, no me acuerdo, así que no me la voy a 676 00:43:27,566 --> 00:43:29,735 inventar, si me la puedes hacer otra vez... 677 00:43:29,935 --> 00:43:34,021 [Orador 3]: Era sobre todo lo de la formación, pero ya me lo has dicho luego al principio. 678 00:43:34,221 --> 00:43:39,380 [Orador 1]: Sí, la formación va acompañada, es decir, cuando una empresa se aventura a arrancar 679 00:43:39,380 --> 00:43:43,353 procesos de Big Data, normalmente hay una formación, efectivamente. 680 00:43:43,553 --> 00:43:48,336 Nosotros damos formación, por ejemplo, en Stratio a nuestros partners y también a 681 00:43:48,336 --> 00:43:52,999 compañías finales en las que conocen estas tecnologías, aprenden a hacer uso de 682 00:43:52,999 --> 00:43:57,842 ellas, no tanto en desarrollo, que también lo que busca una compañía como Stratio, 683 00:43:57,842 --> 00:43:59,655 como Cloudera, como Horton, es que 684 00:43:59,855 --> 00:44:05,165 esa empresa sea autónoma para poder desarrollar sus soluciones pero también se 685 00:44:05,165 --> 00:44:10,342 les forma en la explotación tengo mi sistema montado si se cae a las 5 de la 686 00:44:10,342 --> 00:44:15,785 mañana no quiero llamarte a ti quiero tener a mi equipo de explotación que igual 687 00:44:15,785 --> 00:44:21,429 que me mantiene un Oracle o la aplicación web quiero que mantenga mi sistema de Big 688 00:44:21,429 --> 00:44:27,073 Data así que sí, el proceso va acompañado de normalmente infraestructura dedicada y 689 00:44:27,073 --> 00:44:30,450 en todo caso de formación específica ¿Alguna más? 690 00:44:38,819 --> 00:44:44,819 [Orador 2]: Bueno, mi pregunta va más al tiempo real, la latencia, porque siempre todos los 691 00:44:44,819 --> 00:44:50,456 sistemas de tiempo real tienen una latencia. 692 00:44:50,656 --> 00:44:55,363 ¿Qué soluciones o dentro de la arquitectura cuál está más enfocada a 693 00:44:55,363 --> 00:44:57,738 minimizar el tiempo de latencia? 694 00:44:57,938 --> 00:45:03,679 [Orador 1]: Bueno, todas ellas, todas las soluciones que os he comentado, desde Flum hasta la 695 00:45:03,679 --> 00:45:08,621 capa de consulta, te garantiza que la latencia es mínima, de entrada. 696 00:45:08,821 --> 00:45:13,024 Es cierto que, te voy a hablar por mi experiencia, en mi experiencia la latencia 697 00:45:13,024 --> 00:45:16,217 normalmente viene más por la fuente que por el procesamiento. 698 00:45:16,433 --> 00:45:20,893 estamos en ese punto donde las fuentes todavía no son lo suficientemente rápidas 699 00:45:20,893 --> 00:45:25,466 hablo de entornos corporativos clásicos y la solución de Big Data está todavía muy 700 00:45:25,466 --> 00:45:29,983 por delante quizás en el futuro cuando tengamos unas fuentes mucho más rápidas es 701 00:45:29,983 --> 00:45:34,387 posible que empecemos a encontrar aquí ciertos cuellos de botella pero a día de 702 00:45:34,387 --> 00:45:39,017 hoy lo normal es que la latencia esté más en la fuente que en la capa que tú montas 703 00:45:39,017 --> 00:45:43,477 en cualquier caso hay mecanismos para reducir la latencia pasando obviamente por 704 00:45:43,477 --> 00:45:45,849 el propio despliegue que hagas, garantizar 705 00:45:46,049 --> 00:45:50,514 que la localidad del dato, por ejemplo, esté garantizada y también por cómo 706 00:45:50,514 --> 00:45:55,101 configuras los diferentes elementos que forman parte de la ecuación completa. 707 00:45:55,301 --> 00:46:00,905 Puedes mejorar la comunicación entre Flum y Kafka, por ejemplo, o entre Spark y 708 00:46:00,905 --> 00:46:02,310 Kafka. 709 00:46:02,510 --> 00:46:05,812 Spark Streaming, supongo que si lo conocéis lo sabéis seguro, el 710 00:46:05,812 --> 00:46:08,358 procesamiento en tiempo real está basado en ventanas. 711 00:46:08,558 --> 00:46:11,195 Tú especificas cuál es el tamaño de la ventana. 712 00:46:11,395 --> 00:46:15,715 Una ventana es una fracción de tiempo en la que tú te quedas escuchando la fuente 713 00:46:15,715 --> 00:46:19,982 para recopilar todos los eventos que se han producido en esa ventana de tiempo y 714 00:46:19,982 --> 00:46:21,387 pasarlos al procesamiento. 715 00:46:21,587 --> 00:46:25,431 Si esa ventana obviamente la pones en 5 minutos y tú esperas tener los datos 716 00:46:25,431 --> 00:46:27,815 actualizados cada minuto, pues va a ser complicado. 717 00:46:28,015 --> 00:46:31,858 Siempre tienes que adaptar la ventana un poco a las necesidades que también tengan 718 00:46:31,858 --> 00:46:33,993 las personas que están consumiendo esos datos. 719 00:46:34,193 --> 00:46:36,677 También influye la verbosidad que tenga la fuente. 720 00:46:36,877 --> 00:46:42,411 Si tienes una fuente muy verbosa, a lo mejor es preferible hacer una ventana más 721 00:46:42,411 --> 00:46:46,613 pequeña para no saturar todo el pipeline que tienes montado. 722 00:46:46,813 --> 00:46:47,813 Es un tema delicado. 723 00:46:47,714 --> 00:46:48,714 Hay una receta mágica. 724 00:46:48,636 --> 00:46:52,685 En muchos casos tienes que adaptar algunas piezas para asegurar que la latencia sea 725 00:46:52,685 --> 00:46:53,685 pequeña. 726 00:46:53,604 --> 00:46:58,251 [Orador 2]: ¿Alguna más? 727 00:46:58,451 --> 00:47:00,452 [Orador 1]: ¿Alguna más? 728 00:47:04,484 --> 00:47:06,630 Bueno, pues muchas gracias a todos.