{"id":33630,"date":"2019-10-31T21:53:49","date_gmt":"2019-10-31T18:53:49","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-osobennogo-v-cloudera-i-kak-ee-gotovit\/"},"modified":"2019-10-31T21:53:49","modified_gmt":"2019-10-31T18:53:49","slug":"chto-osobennogo-v-cloudera-i-kak-ee-gotovit","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/chto-osobennogo-v-cloudera-i-kak-ee-gotovit","title":{"rendered":"\u00bfQu\u00e9 tiene de especial Cloudera y c\u00f3mo prepararla?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

El mercado de la computaci\u00f3n distribuida y los grandes datos, seg\u00fan los informes, estad\u00edsticas<\/a><\/noindex>, est\u00e1 creciendo entre un 18-19% al a\u00f1o. Esto significa que la pregunta sobre la elecci\u00f3n de software para estos fines sigue siendo relevante. En esta publicaci\u00f3n, comenzaremos explicando por qu\u00e9 son necesarias las computaciones distribuidas, detallaremos la elecci\u00f3n de software, hablaremos sobre la aplicaci\u00f3n de Hadoop a trav\u00e9s de Cloudera, y finalmente discutiremos la selecci\u00f3n de hardware y c\u00f3mo este influye en el rendimiento de diferentes maneras.<\/p>\n

\"\u00bfQu\u00e9<\/a><\/noindex>
\n\u00bfPor qu\u00e9 son necesarias las computaciones distribuidas en los negocios convencionales? Es sencillo y complicado al mismo tiempo. Sencillo porque, en la mayor\u00eda de los casos, realizamos c\u00e1lculos relativamente simples por unidad de informaci\u00f3n. Complicado porque hay mucha informaci\u00f3n. Much\u00edsima. Como resultado, hay que procesar terabytes de datos en 1000 flujos<\/a><\/noindex>. De esta forma, los escenarios de uso son bastante universales: los c\u00e1lculos pueden aplicarse en cualquier lugar donde sea necesario tener en cuenta un gran n\u00famero de m\u00e9tricas sobre un a\u00fan mayor conjunto de datos.<\/p>\n

Uno de los ejemplos recientes: la cadena de pizzer\u00edas Dodo Pizza determin\u00f3<\/a><\/noindex> en base al an\u00e1lisis de la base de datos de pedidos de clientes, que al elegir una pizza con cualquier relleno, los usuarios normalmente utilizan solo seis conjuntos b\u00e1sicos de ingredientes m\u00e1s un par de aleatorios. En consecuencia, la pizzer\u00eda ajust\u00f3 sus compras. Adem\u00e1s, logr\u00f3 recomendar mejor a los usuarios productos adicionales ofrecidos en el momento del pedido, lo que permiti\u00f3 aumentar las ganancias.<\/p>\n

Otro ejemplo: el an\u00e1lisis<\/a><\/noindex> de las posiciones de productos permiti\u00f3 a la tienda H&M reducir su surtido en ciertas tiendas en un 40%, manteniendo al mismo tiempo el nivel de ventas. Esto se logr\u00f3 eliminando los art\u00edculos que no vend\u00edan bien, teniendo en cuenta la estacionalidad.<\/p>\n

La elecci\u00f3n de la herramienta<\/h2>\n

\nEl est\u00e1ndar de la industria para este tipo de c\u00e1lculos es Hadoop. \u00bfPor qu\u00e9? Porque Hadoop es un excelente marco bien documentado (Habr publica muchos art\u00edculos detallados sobre este tema) que viene acompa\u00f1ado de un conjunto completo de utilidades y bibliotecas. Puede ingresar conjuntos de datos masivos, tanto estructurados como no estructurados, y el sistema los distribuir\u00e1 autom\u00e1ticamente entre los recursos computacionales. Adem\u00e1s, estos recursos se pueden ampliar o desactivar en cualquier momento: as\u00ed es como funciona la escalabilidad horizontal. <\/p>\n

En 2017, la influyente empresa de consultor\u00eda Gartner concluy\u00f3<\/a><\/noindex>, que Hadoop pronto quedar\u00e1 obsoleto. La raz\u00f3n es bastante banal: los analistas creen que las empresas comenzar\u00e1n a migrar masivamente a la nube, ya que all\u00ed podr\u00e1n pagar por el uso real de los recursos computacionales. Un segundo factor importante que supuestamente podr\u00eda \"enterrar\" a Hadoop es la velocidad de operaci\u00f3n. Porque opciones como Apache Spark o Google Cloud DataFlow funcionan m\u00e1s r\u00e1pido que MapReduce, que es la base de Hadoop.<\/p>\n

Hadoop se basa en varios pilares, siendo las tecnolog\u00edas m\u00e1s destacadas MapReduce (un sistema de distribuci\u00f3n de datos para c\u00e1lculos entre servidores) y el sistema de archivos HDFS. Este \u00faltimo est\u00e1 dise\u00f1ado espec\u00edficamente para almacenar informaci\u00f3n distribuida entre los nodos del cl\u00faster: cada bloque de tama\u00f1o fijo puede ubicarse en varios nodos, y gracias a la replicaci\u00f3n, se garantiza la resistencia del sistema a fallos de nodos individuales. En lugar de una tabla de archivos, se utiliza un servidor especial denominado NameNode.<\/p>\n

En la ilustraci\u00f3n a continuaci\u00f3n se presenta un esquema de trabajo de MapReduce. En la primera etapa, los datos se dividen seg\u00fan un criterio determinado; en la segunda, se distribuyen entre los recursos computacionales; y en la tercera, se realiza el c\u00e1lculo. <\/p>\n

\"\u00bfQu\u00e9
\nInicialmente, MapReduce fue creado por Google para sus necesidades de b\u00fasqueda. Luego, MapReduce se liber\u00f3 como c\u00f3digo abierto y Apache se encarg\u00f3 del proyecto. Mientras tanto, Google ha migrado gradualmente a otras soluciones. Un detalle interesante: actualmente, Google tiene un proyecto llamado Google Cloud Dataflow, que se posiciona como el siguiente paso despu\u00e9s de Hadoop, como su reemplazo r\u00e1pido.<\/p>\n

Al analizar detenidamente, se puede ver que Google Cloud Dataflow se basa en una variante de Apache Beam, que a su vez incluye un marco bien documentado de Apache Spark, lo que permite afirmar que la velocidad de ejecuci\u00f3n de las soluciones es pr\u00e1cticamente la misma. Adem\u00e1s, Apache Spark funciona excelentemente en el sistema de archivos HDFS, lo que permite desplegarlo en servidores Hadoop.<\/p>\n

Si a\u00f1adimos aqu\u00ed el volumen de documentaci\u00f3n y soluciones listas sobre Hadoop y Spark en comparaci\u00f3n con Google Cloud Dataflow, la elecci\u00f3n de la herramienta se vuelve obvia. Adem\u00e1s, los ingenieros pueden decidir qu\u00e9 c\u00f3digo ejecutar \u2014\u00bfHadoop o Spark?\u2014 dependiendo de la tarea, su experiencia y calificaci\u00f3n.<\/p>\n

Nube o servidor local<\/h2>\n

\nLa tendencia hacia la transici\u00f3n a la nube ha dado lugar a un t\u00e9rmino interesante como Hadoop-as-a-service. En este escenario, la administraci\u00f3n de los servidores conectados se vuelve muy importante. Desafortunadamente, a pesar de su popularidad, Hadoop puro es una herramienta bastante complicada de configurar, ya que mucho tiene que hacerse manualmente. Por ejemplo, configurar los servidores por separado, monitorear sus m\u00e9tricas y ajustar cuidadosamente una multitud de par\u00e1metros. En general, es un trabajo para entusiastas y existe un gran riesgo de cometer errores o pasar algo por alto.<\/p>\n

Por lo tanto, han ganado popularidad diversas distribuciones que inicialmente vienen con herramientas c\u00f3modas de despliegue y administraci\u00f3n. Una de las distribuciones m\u00e1s populares que apoya a Spark y simplifica todo es Cloudera. Tiene versiones de pago y gratuitas, y en esta \u00faltima est\u00e1 disponible toda la funcionalidad principal, sin l\u00edmite en el n\u00famero de nodos. <\/p>\n

\"\u00bfQu\u00e9
\n
\nDurante la configuraci\u00f3n, Cloudera Manager se conectar\u00e1 a sus servidores a trav\u00e9s de SSH. Un detalle interesante: al instalar, es mejor indicar que se realice mediante parcelas<\/i>: paquetes especiales, cada uno de los cuales contiene todos los componentes necesarios, configurados para trabajar entre s\u00ed. En esencia, es una versi\u00f3n mejorada de un gestor de paquetes.<\/p>\n

Despu\u00e9s de la instalaci\u00f3n, obtendremos un panel de control del cl\u00faster, donde podr\u00e1 ver la telemetr\u00eda del cl\u00faster, los servicios instalados, adem\u00e1s de que podr\u00e1 agregar\/eliminar recursos y editar la configuraci\u00f3n del cl\u00faster. <\/p>\n

\"\u00bfQu\u00e9
\n
\nComo resultado, se presenta ante usted el corte de ese cohete que lo llevar\u00e1 hacia un futuro brillante de BigData. Pero antes de decir 'vamos', traslad\u00e9monos al motor.<\/p>\n

Requisitos de hardware<\/h2>\n

\nEn su sitio web, Cloudera menciona diferentes configuraciones posibles. Los principios generales sobre los que se construyen se presentan en la ilustraci\u00f3n:<\/p>\n

\"\u00bfQu\u00e9
\nEste panorama optimista puede verse afectado por MapReduce. Si volvemos a observar el esquema de la secci\u00f3n anterior, queda claro que en casi todos los casos, la tarea de MapReduce puede enfrentar un 'cuello de botella' al leer datos desde el disco o la red. Esto tambi\u00e9n se menciona en el blog de Cloudera. Como resultado, para cualquier c\u00e1lculo r\u00e1pido, incluyendo aquellos a trav\u00e9s de Spark, que se usa frecuentemente para c\u00e1lculos en tiempo real, la velocidad de entrada\/salida es muy importante. Por lo tanto, al usar Hadoop, es crucial que el cl\u00faster cuente con m\u00e1quinas r\u00e1pidas y equilibradas, lo cual, dicho sea de paso, no siempre se garantiza en la infraestructura en la nube.<\/p>\n

El equilibrio en la distribuci\u00f3n de cargas se logra mediante el uso de virtualizaci\u00f3n Openstack en servidores con potentes CPU multin\u00facleo. Se asignan recursos de CPU espec\u00edficos y discos a los nodos de datos. En nuestra soluci\u00f3n Atos Codex Data Lake Engine<\/i> se logra una amplia virtualizaci\u00f3n, lo que nos beneficia tanto en rendimiento (minimizando la influencia de la infraestructura de red) como en TCO (eliminando servidores f\u00edsicos innecesarios).<\/p>\n

\"\u00bfQu\u00e9
\nEn el caso de usar servidores BullSequana S200, obtenemos una carga bastante uniforme, libre de algunos cuellos de botella. La configuraci\u00f3n m\u00ednima incluye 3 servidores BullSequana S200, cada uno con dos JBOD, m\u00e1s opcionalmente se pueden conectar S200 adicionales que contengan cuatro nodos de datos cada uno. Aqu\u00ed hay un ejemplo de carga en la prueba TeraGen:<\/p>\n

\"\u00bfQu\u00e9
\n
\nLas pruebas con diferentes vol\u00famenes de datos y valores de replicaci\u00f3n muestran resultados consistentes en cuanto a la distribuci\u00f3n de la carga entre los nodos del cl\u00faster. A continuaci\u00f3n se presenta un gr\u00e1fico de distribuci\u00f3n del acceso al disco en las pruebas de rendimiento.<\/p>\n

\"\u00bfQu\u00e9
\n
\nLos c\u00e1lculos se realizaron sobre la base de la configuraci\u00f3n m\u00ednima de 3 servidores BullSequana S200. Esta configuraci\u00f3n incluye 9 nodos de datos y 3 nodos principales, as\u00ed como m\u00e1quinas virtuales reservadas en caso de implementar protecci\u00f3n basada en OpenStack Virtualization. El resultado de la prueba TeraSort: bloque de tama\u00f1o 512 MB con un factor de replicaci\u00f3n de tres y cifrado es de 23.1 minutos.<\/p>\n

\u00bfC\u00f3mo se puede ampliar el sistema? Para Data Lake Engine est\u00e1n disponibles diferentes tipos de extensiones:<\/p>\n