WEBVTT 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.