Amazon EMR como plataforma Hadoop fácil de configurar

Recientemente ayudé a un cliente a realizar una evaluación de Actian Vector en Hadoop (VectorH) para ver si podía mantener un rendimiento de "unos pocos segundos" a medida que el tamaño de los datos crecía de uno a decenas de miles de millones de filas (cosa que hizo, pero ese no es el tema de esta entrada).

El cliente en cuestión sólo había invertido moderadamente en Hadoop, por lo que buscaba una forma de establecer el entorno sin tener que profundizar en los detalles de Hadoop. Esto encaja perfectamente con la visión de Actian para las versiones Hadoop de su software: permitir a los clientes ejecutar aplicaciones reales para usuarios empresariales en Hadoop sin tener que entrar en los aspectos "pesados para el desarrollador" que suele requerir Hadoop.

Actian ha lanzado una herramienta de aprovisionamiento llamada Actian Management Console (AMC) que instalará y configurará el sistema operativo, Hadoop y el software de Actian en un estilo de "pulsar un botón" que será ideal para este cliente. AMC actualmente es compatible con las nubes Amazon EC2 y Rackspace.

Sin embargo, en el momento de la evaluación, AMC no estaba disponible, así que buscamos otra cosa y pensamos en probar EMR (Elastic MapReduce) de Amazon, que es una forma rápida de poner en marcha un Cluster Hadoop con el mínimo esfuerzo. Esta entrada examina lo que encontramos y enumera los pros y los contras.

Ventajas e inconvenientes de Amazon EMR

EMR es muy fácil de configurar - sólo tienes que ir a la consola de Amazon, seleccionar los tipos de instancia que deseas, y el número de ellas, pulsar el botón y en pocos minutos tendrás un Cluster Hadoop funcionando. Esta parte sería más rápida de poner en marcha que usar el AMC para aprovisionar un cluster desde cero ya que EMR preconfigura algunos de estos pasos de instalación para acelerarlos por ti.

Por defecto, se obtiene el sabor Hadoop de Amazon, que es una forma de Apache Hadoop con la mayoría de los parches y ajustes recomendados aplicados. Sin embargo, es posible especificar Hortonworks, Cloudera y MapR para utilizarlos con EMR, y otros complementos como Apache Spark y Apache Zeppelin. En este caso, hemos utilizado la distribución por defecto de Apache Hadoop.

A los puristas de Hadoop puede que se les arrugue la frente con algunos de los términos utilizados: por ejemplo, los DataNodes se denominan nodos "core" en EMR, y el NameNode se denomina nodo "master" (los que no conozcan EMR ni VectorH deben saber que ambos utilizan el término "master" para cosas diferentes).

La configuración de determinados elementos se ajusta automáticamente en función del tamaño del clúster. Por ejemplo, el factor de replicación de HDFS se establece en uno para los clústeres de menos de 4 nodos y en dos para los clústeres de entre 2 y 10 nodos, y luego en los tres habituales para los clústeres de más de 10 nodos. Esta y otras propiedades pueden establecerse explícitamente en la secuencia de arranque mediante las opciones "bootstrap".

Esto nos lleva a lo más importante a tener en cuenta cuando se utiliza EMR - en EMR todo (incluyendo Hadoop) es transitorio; cuando se reinicia el clúster todo se borra y se reconstruye desde cero. Si quieres que la configuración persista, tienes que hacerlo en las opciones de arranque. Del mismo modo, si necesitas que los datos sean persistentes a través de los reinicios del clúster, entonces necesitas organizar los datos externamente en algo como S3. EMR puede leer y escribir S3 directamente, por lo que no es necesario copiar los datos en bruto de S3 en HDFS sólo para poder cargar los datos en VectorH - se puede cargar directamente desde S3 usando algo como el nuevo cargador Spark de Actian.

Esto puede parecer un inconveniente, y de hecho lo es para algunos casos de uso, sin embargo, en realidad sólo refleja el propósito de EMR. EMR nunca fue pensado para ser un hogar de larga duración para un DataLake persistente, sino más bien un entorno transitorio "spin up, process, then shutdown" para ejecutar trabajos de estilo MapReduce. Amazon probablemente afirmaría que S3 debería ser la ubicación para los datos persistentes.

En nuestro caso estábamos probando una base de datosde haute performance - definitivamente un servicio de "larga vida" con requisitos de datos persistentes - por lo que en ese sentido EMR no era tal vez una buena opción. Sin embargo, aunque tuvimos que recargar la base de datos un par de veces después de querer reconfigurar el clúster, nos adaptamos rápidamente al aprovisionamiento desde cero mediante la creación de un script de aprovisionamiento rudimentario (ayudado aquí por la rápida velocidad de carga de VectorH y el hecho de que no necesita índices), por lo que en realidad funcionó bastante bien como entorno de pruebas.

La segunda cosa a tener en cuenta con EMR, especialmente para aquellos acostumbrados a Hadoop, es que (al menos con el Hadoop por defecto que estábamos utilizando) algunas de las instalaciones normales no están allí. Lo que más notamos fue la ausencia de los controles habituales de inicio/parada para los demonios de Hadoop. Estábamos tratando de reiniciar los DataNodes para permitir lecturas de cortocircuito y nos resultó un poco difícil - al final tuvimos que reiniciar el clúster de todos modos y así poner esto en las opciones de arranque.

Otro aspecto sobre el que no tienes control con EMR es el uso de un AWS Placement Group. Normalmente en AWS si quieres un clúster de alto rendimiento intentarías asegurarte de que los diferentes nodos estuvieran "cerca" en términos de ubicación física, minimizando así la latencia de la red. Con EMR no parece haber ninguna manera de especificar eso. Puede ser que EMR sea un poco inteligente y haga esto por ti. O puede ser que, cuando se trata de clusters más grandes, los Grupos de Colocación sean poco prácticos. De cualquier manera (o no) nuestra configuración no utilizó ningún Grupo de Colocación especificado. Incluso sin ellos, el rendimiento fue bueno.

De hecho, el rendimiento fue lo suficientemente bueno como para que el cliente informara de que los resultados eran mejores que sus pruebas comparables en Amazon Redshift.

En resumen, este ejercicio demostró que se puede utilizar Amazon EMR como un entorno Hadoop de "inicio rápido" incluso para servicios de larga vida como Actian VectorH. Aparte de la ausencia de algunos aspectos - la mayoría de los cuales pueden ser tratados a través de opciones de arranque - EMR se comporta como una distribución Hadoop regular. Debido a su naturaleza transitoria, EMR sólo debe considerarse para casos de uso que sean transitorios (incluyendo pruebas de servicios de larga duración).

Los clientes que deseen un aprovisionamiento de Hadoop al estilo de "pulsar un botón" para la producción en cosas como Amazon EC2 deberían considerar la instalación con la consola de gestión de Actian, disponible ahora en http://esd.actian.com.

Acerca de Actian Corporation

Actian hace que los datos sean fáciles. Nuestra plataforma de datos simplifica el modo en que las personas conectan, gestionan y analizan los datos en entornos en la nube, híbridos y locales. Con décadas de experiencia en gestión de datos y análisis, Actian ofrece soluciones de alto rendimiento que permiten a las empresas tomar decisiones basadas en datos. Actian cuenta con el reconocimiento de los principales analistas y ha recibido premios del sector por su rendimiento e innovación. Nuestros equipos comparten casos de uso probados en conferencias (por ejemplo, Strata Data) y contribuyen a proyectos de código abierto. En el blog de Actian, tratamos temas que van desde la ingesta de datos en tiempo real hasta el análisis basado en IA. Conozca al equipo directivo https://www.actian.com/company/leadership-team/