Enero de 2016

Volumen 31, número 1

Macrodatos: análisis de datos en tiempo real para los desarrolladores de .NET que usan HDInsight

Por Omid Afnan

Empresas de todo tamaño han comenzado a reconocer el valor de sus enormes colecciones de datos y la necesidad de sacar provecho de ellas. Cuando las organizaciones comienzan su camino hacia los macrodatos, suelen empezar por el procesamiento en lotes de sus activos de macrodatos. Esto podría implicar la recopilación y agregación de datos de registro web, clics de usuario de una aplicación, telemetría de dispositivos de Internet de las cosas (IoT) o una gran variedad de otros datos generados por personas o máquinas. Analicé el caso de hacer un análisis de registro web básico con Hive en HDInsight en un artículo hace un año (msdn.com/magazine/dn890370). Sin embargo, a medida que se consigan los beneficios del procesamiento en lotes para la minería de información sobre datos históricos, muchas organizaciones tendrán que hacer frente al problema de tratar los datos en tiempo real y cómo recopilar y analizar los flujos continuos en tiempo real, así como tomar medidas sobre ellos.

Como puede imaginar, existen tecnologías en el espacio de macrodatos para satisfacer estas necesidades. La Plataforma Microsoft Azure ofrece poderosas soluciones de macrodatos, como por ejemplo, Azure Data Lake y HDInsight. Hay una tecnología de código abierto que permite realizar análisis altamente distribuidos en tiempo real denominada Apache Storm. Se admite de manera nativa en HDInsight, que es la oferta administrada por Azure de los servicios de macrodatos de Apache. En este artículo, lo guiaré por un sencillo pero eficaz escenario que trata el flujo de tweets con Storm como la herramienta clave para habilitar los análisis continuos en tiempo real.

Como verá, Microsoft facilita significativamente este tipo de desarrollo en comparación con otras ofertas del mercado a través de eficaces herramientas de creación y depuración en Visual Studio. Las herramientas de HDInsight para Visual Studio (disponibles como parte del SDK de Azure) proporcionan un entorno de codificación y depuración que resultará familiar para los desarrolladores de .NET. Estas herramientas ofrecen una manera bastante más fácil de trabajar con las tecnologías de macrodatos que los editores sencillos y las herramientas de línea de comandos que están disponibles actualmente en el mundo del código abierto. Si bien Storm para HDInsight admite completamente el uso de programación Java, Microsoft también permite a los programadores de .NET usar C# para la redacción y reutilización de la lógica de negocios. En los ejemplos de este artículo se muestran estas capacidades de .NET.

Escenario de seguimiento de emociones

El escenario de seguimiento y análisis de las tendencias emergentes no es nuevo. Las noticias, el seguimiento del tiempo y la detección de desastres son ejemplos de escenarios que existen desde antes de la informática en la nube. Sin embargo, tanto las áreas de alcance en las que se desean detectar las tendencias, como la escala con la que los datos están disponibles para el análisis, crecieron de manera inconcebible con el progreso de la era de la nube. Las redes sociales fueron suelo fértil para el análisis de emociones. Los servicios como Twitter, por ejemplo, que ponen los datos sociales a disposición de usuarios a través de API, junto con las plataformas de macrodatos tipo pago por uso, como HDInsight, ponen el análisis de emociones al alcance de las organizaciones, tanto grandes como pequeñas.

El tipo más sencillo de análisis de emociones con Twitter es contar la frecuencia de tweets sobre un tema, o hashtag, concreto en un período de tiempo dado. Por supuesto, hacerlo durante un período, por ejemplo, un minuto, no es igual de interesante que si se hace de manera continua durante todos los minutos del día en busca de un incremento o disminución de la tasa. La identificación de picos del uso de un término concreto puede resultar útil para la detección de una tendencia. Por ejemplo, la detección de términos relacionados con una tormenta o terremoto podría proporcionar una indicación muy rápida de las zonas afectadas por un desastre natural y su gravedad.

Para demostrar los conceptos básicos de cómo se hace esto, lo guiaré por la configuración de una topología de streaming que recopila datos de Twitter, selecciona algunos de los tweets, calcula las métricas, guarda todo en el almacenamiento y publica algunos resultados. Podrá ver esta topología en la Figura 1. Para este artículo, seleccioné tweets con la coincidencia sencilla de palabras claves. Las métricas calculadas son recuentos de tweets que coincidían con los criterios de selección. Los tweets seleccionados se colocan en una base de datos SQL y se publican también en un sitio web. Todo se hace en la nube de Azure con Storm, SQL Server y los servicios de sitio web disponibles actualmente. Después de guiarlo por el ejemplo, analizaré algunas otras tecnologías disponibles para resolver este tipo de problema de análisis de datos de streaming.

Figura 1 Topología de análisis de emociones

Conceptos básicos de Storm

Storm es un proyecto de código abierto de Apache (storm.apache.org) que permite realizar cálculos distribuidos en tiempo real sobre flujos de datos. Forma parte del ecosistema de Hadoop de herramientas de procesamiento de macrodatos y se admite directamente en HDInsight. Los trabajos de Storm se definen como un gráfico de nodos de procesamiento conectados por flujos de datos en forma de tuplas. En Storm, este tipo de gráfico se conoce como “topología”. Las topologías no terminan como otras consultas, se siguen ejecutando hasta que se suspenden o detienen.

En el Portal de administración de Azure, puede crear un nuevo clúster de HDInsight y elegir Storm como tipo. De este modo, Azure configurará un clúster de máquinas precargadas con todos los componentes necesarios del sistema operativo, Hadoop y Storm en tan solo unos minutos. Puedo elegir el número de nodos que quiere, elegir un núcleo y tamaños de memoria diferentes, y aumentar o reducir el número de nodos en cualquier momento. Desde el punto de vista de la simplificación de la experiencia de Hadoop, esto ya me ahorró una cantidad importante de tiempo y los problemas asociados con la adquisición y configuración de varias máquinas.

Los componentes de una topología se llaman spouts y bolts. Spouts producen flujos de tuplas, que básicamente son conjuntos de pares de tipo y valor. Es decir, un spout es un fragmento de código que sabe cómo recopilar o generar datos y luego emitirlos en bloques. Bolts son unidades de código que pueden consumir un flujo de datos. Pueden procesar los datos para limpiarlos o para calcular estadísticas. En este tipo de casos, es más probable que emitan otro flujo de tuplas a los bolts descendentes. Otros bolts escriben datos en el almacenamiento o en otro sistema.

Cada uno de estos componentes puede ejecutar varias tareas en paralelo. Esto es clave para la estabilidad y confiabilidad de Storm. Puedo especificar un grado de paralelismo para cada componente y Storm asignará ese número de tareas para ejecutar la lógica de mi spout o bolt. Storm proporciona tolerancia a errores con la administración de tareas y el reinicio automático de las tareas con error. Por último, una topología dada se ejecuta en un conjunto de procesos de trabajo que son, esencialmente, contenedores de ejecución. Los trabajos se pueden agregar para aumentar la capacidad de procesamiento de una topología. Estas funcionalidades proporcionan características esenciales que permiten el escalado y la tolerancia a errores para Storm.

Una topología puede ser lo compleja que haga falta para realizar el procesamiento que necesita el escenario global de análisis en tiempo real. La arquitectura permite la reutilización de componentes, pero también crea un problema desafiante en cuanto a la administración e implementación a medida que crece el número de spouts y bolts. El concepto de proyecto de Visual Studio es una manera útil de administrar los componentes de código y configuración que se necesitan para crear instancias de la topología. Dado que la naturaleza de propia misma de una topología es esencialmente gráfica, también tiene sentido que poder visualizar la topología es de gran utilidad durante el desarrollo y funcionamiento del sistema. Esto se puede observar en la vista de ejecución de las herramientas de HDInsight para Visual Studio que se muestra en la Figura 2.

Figura 2 Vista de supervisión de una topología de Storm activa

La arquitectura de Storm se basa en Apache Thrift, un marco que permite el desarrollo de servicios implementados en varios lenguajes. Si bien muchos desarrolladores usan Java para escribir spouts y bolts, no es un requisito. Con la introducción del paquete SCP.Net de bibliotecas, puedo usar C# para desarrollar mis spouts y bolts. Este paquete se incluye en la descarga de las herramientas de HDInsight para Visual Studio, pero también se puede descargar a través de NuGet.

Filtrar tweets en casi tiempo real

Echemos un vistazo a la creación de la topología de filtrado de flujos de tweets para ver cómo estas partes funcionan en la práctica. Mi ejemplo de topología está compuesto por un spout y tres bolts. Puede ver la vista gráfica de esta topología en la Figura 2, tal como se muestra en las herramientas de HDInsight para Visual Studio. Cuando envío un proyecto Storm para su ejecución en Azure, Visual Studio me muestra esta vista gráfica y, a medida que pasa el tiempo, la actualiza con el número de eventos que fluyen por el sistema, así como las condiciones de error que se producen en cualquiera de los nodos.

Aquí, TwitterSpout es responsable de extraer el flujo de tweets que quiero procesar. Para ello, interactúa con las API de Twitter para recopilar tweets y los convierte en tuplas de datos que fluyen por el resto de la topología. TwitterBolt recoge el flujo y puede hacer agregaciones, como contar tweets o combinarlos con otros datos extraídos de otros orígenes de datos. Este bolt emite un flujo nuevo, con un posible formato nuevo, según la lógica de negocios que ejecutó. Los componentes AzureSQLBolt y SignalRBroadcastBolt consumen este flujo y escriben partes de los datos en una base de datos de SQL Server hospedada en Azure y un sitio web de SignalR, respectivamente.

Dado que uso C# para crear mi solución Storm, puedo usar varias bibliotecas existentes para ayudar a simplificar y acelerar el trabajo de desarrollo. Dos paquetes clave para este ejemplo son las bibliotecas Tweetinvi en CodePlex (bit.ly/1kI9sqV) y las bibliotecas SCP.Net en NuGet (bit.ly/1QwICPj).

El marco SCP.Net reduce mucha de la complejidad del tratamiento con el modelo de programación de Storm y proporciona estas clases base para encapsular gran parte del trabajo que, de otro modo, tendría que hacer manualmente. Comienzo por heredar de la clase base Microsoft.SCP.ISCPSpout. Esto me da tres métodos base que se necesitan para un spout: NextTuple, Ack y Fail. NextTuple emite el siguiente fragmento de datos disponibles para el flujo, o no emite nada. En Storm, este método se llama bucle cerrado y es el lugar justo para insertar tiempo de suspensión si no hay tuplas para emitir. Esta es una manera de asegurarme de que no termine consumiendo el 100 % de los ciclos de CPU, ya que la topología se ejecuta continuamente.

Si quiero implementar un procesamiento de mensajes garantizado, tal como semántica tipo “al menos una vez” para mis tuplas, usaría los métodos Ack y Fail para implementar los protocolos de enlace necesarios entre bolts. En este ejemplo, no uso ningún mecanismo de reintento, por lo que se implementa el método, con código que obtiene los tweets de un miembro de cola privada en la clase TwitterSpout y los envía a la topología.

Los flujos en la topología se capturan como esquemas publicados por un spout o bolt. Estos se usan como el contrato entre componentes de la topología y también como las reglas de serialización y deserialización que SCP.Net usa al transferir los datos. La clase Context se usa para almacenar la información de configuración por instancia de spout o bolt. El esquema de las tuplas que emite el spout se almacena en el objeto Context y SCP.Net la usa para crear conexiones de componente.

Echemos un vistazo al código para la inicialización de la clase TwitterSpout, que se muestra parcialmente en la Figura 3.

Figura 3 Inicializar la clase TwitterSpout

public TwitterSpout(Context context)
{
  this.context = context;
  Dictionary<string, List<Type>> outputSchema =
    new Dictionary<string, List<Type>>();
  outputSchema.Add(Constants.DEFAULT_STREAM_ID,
    new List<Type>() { typeof(SerializableTweet) });
  this.context.DeclareComponentSchema(new ComponentStreamSchema(
    null, outputSchema));
  // Specify your Twitter credentials
  TwitterCredentials.SetCredentials(
    ConfigurationManager.AppSettings["TwitterAccessToken"],
    ConfigurationManager.AppSettings["TwitterAccessTokenSecret"],
    ConfigurationManager.AppSettings["TwitterConsumerKey"],
    ConfigurationManager.AppSettings["TwitterConsumerSecret"]);
  // Setup a Twitter Stream
  var stream = Tweetinvi.Stream.CreateFilteredStream();
  stream.MatchingTweetReceived += (sender, args) => { NextTweet(args.Tweet); };
  // Setup your filter criteria
  stream.AddTrack("China");
  stream.StartStreamMatchingAnyConditionAsync();
}

En la Figura 3 se muestra la inicialización del contexto pasado durante el inicio de la topología. Este contexto luego se actualiza con la adición de una definición de esquema. Creé un objeto Dictionary al que agrego un identificador para el tipo de flujo (DEFAULT_STREAM) y una lista de tipos para todos los campos de mi tupla; en este caso, simplemente un objeto SerializableTweet. El contexto ahora contiene la definición de esquema que debo seguir al emitir tuplas en esta clase, así como cuando las consumo en el objeto TwitterBolt.

En el resto de este fragmento se muestra la configuración del flujo de Twitter. En el paquete Tweetinvi se proporcionan abstracciones para las API de REST y de streaming de Twitter. Después de codificar las credenciales adecuadas, simplemente creo una instancia del tipo de origen que quiero usar. En el caso de orígenes de streaming, puedo elegir entre varios tipos, por ejemplo, flujos filtrados, de muestreo o de usuario. Estos proporcionan interfaces simplificadas para el filtrado de palabras clave entre todos los tweets, el muestreo de tweets públicos aleatorios y el seguimiento de eventos asociados con un usuario específico. Aquí, uso el flujo filtrado, lo que permite la selección de tweets de entre todos los tweets públicos comprobando la existencia de cualquier conjunto múltiple de palabras clave.

Aquí, aplico el filtrado deseado de tweets en el spout, porque las API de Tweetinvi facilitan esta tarea. También podría hacer el filtrado en el componente TwitterBolt, junto con cualquier otro cálculo o agregación que quiera hacer para manipular los tweets. El filtrado en el spout me permite reducir el volumen de streaming de datos a través de la topología en una etapa temprana. Sin embargo, el poder de Storm es que me permite manipular volúmenes de gran tamaño en cualquier componente de la topología mediante el escalado horizontal. Storm ofrece un escalado casi lineal con recursos agregados, lo que me permite usar más trabajos para agregar escala siempre que se produzca un cuello de botella. HDInsight admite este método al permitirme seleccionar el tamaño del clúster y los tipos de nodos durante la configuración, y agregarle nodos más adelante. Con este método de escalado horizontal, puedo crear clústeres de Storm que procesan millones de eventos por segundo. Cobro por número de nodos en ejecución del clúster, por lo que debo tener en cuenta el equilibrio entre costo y escala.

La única otra parte que hay que destacar de la Figura 3 es el registro de una devolución de llamada para el objeto de flujo Tweetinvi que se debe llamar cuando encuentra un tweet que coincide con mis criterios. El siguiente método NextTweet es esa devolución de llamada, que simplemente agrega el tweet proporcionado a la cola privada mencionada anteriormente en la clase TwitterSpout:

public void NextTweet(ITweet tweet)
{
  queue.Enqueue(new SerializableTweet(tweet));
}

Los bolts de mi topología se codifican de manera similar. Se derivan de la clase Microsoft.SCP.ISCPBolt y deben implementar el método Execute. Aquí, la tupla se pasa como un tipo genérico del objeto SCPTuple y se debe convertir primero en el tipo correcto. Luego, puedo escribir el código C# para ejecutar el procesamiento detallado que necesite. En este caso, simplemente uso una variable global para acumular un recuento del número de tuplas según detecte el bolt. Luego registro el recuento y el texto del tweet. Por último, emito un nuevo tipo de tupla para que los bolts descendentes lo consuman. Este es el código:

public void Execute(SCPTuple tuple)
{
  var tweet = tuple.GetValue(0) as SerializableTweet;
  count++;
  Context.Logger.Info("ExecuteTweet: Count = {0}, Tweet = {1}", count, tweet.Text);
  this.context.Emit(new Values(count, tweet.Text));
}

En el caso de un bolt, durante su configuración tengo que especificar esquemas tanto de entrada como de salida. El formato es exactamente igual que la definición de esquema anterior para un spout. Simplemente defino otra variable Dictionary llamada outputSchema y enumero el entero y los tipos de cadena de los campos de salida, tal como se muestra en la Figura 4.

Figura 4 Especificar los esquemas de entrada y salida para TwitterBolt

public TwitterBolt(Context context, Dictionary<string, Object> parms)
{
  this.context = context;
  Dictionary<string, List<Type>> inputSchema =
    new Dictionary<string, List<Type>>();
  inputSchema.Add(Constants.DEFAULT_STREAM_ID,
    new List<Type>() { typeof(SerializableTweet) });
  Dictionary<string, List<Type>> outputSchema =
    new Dictionary<string, List<Type>>();
  outputSchema.Add(Constants.DEFAULT_STREAM_ID,
    new List<Type>() { typeof(long), typeof(string) });
  this.context.DeclareComponentSchema(
    new ComponentStreamSchema(inputSchema,
    outputSchema));
}

Los otros bolts siguen el mismo patrón, pero llaman a las API específicas para SQL Azure y SignalR. El último elemento clave es definir la topología enumerando los componentes y sus conexiones. Para ello, hay otro método que se debe implementar en todos los spouts y bolts; el método Get, que simplemente crea una instancia de un objeto de esta clase con una variable Context a la que el objeto SCPContext llama durante el lanzamiento de la tarea de Storm. SCP.Net creará una instancia de un proceso C# secundario, que iniciará el spout o bolt de C# con el siguiente método de delegado:

return new TwitterSpout(context);

Con los spouts y bolts establecidos, ahora puedo crear la topología. Nuevamente, SCP.Net proporciona una clase y funciones auxiliares para ello. Creo una clase derivada del objeto Microsoft.SCP.Topology.Topology­Descriptor e invalido el método GetTopologyBuilder. En este método, uso un objeto de tipo TopologyBuilder que proporciona los métodos SetSpout y SetBolt. Estos métodos me permiten especificar el nombre y los esquemas de entrada y salida del componente. También me permiten especificar el delegado Get que se debe usar para inicializar el componente y, lo que es más importante, especificar el componente ascendente que se conectará con el componente actual. En la Figura 5 se muestra el código que define mi topología.

Figura 5 Crear el objeto AnalysisTopology de Twitter

namespace TwitterStream
{
  [Active(true)]
  class TwitterTopology : TopologyDescriptor
  {
    public ITopologyBuilder GetTopologyBuilder()
    {
      TopologyBuilder topologyBuilder = new TopologyBuilder(
        typeof(TwitterTopology).Name + DateTime.Now.ToString("-yyyyMMddHHmmss"));
      topologyBuilder.SetSpout(
        typeof(TwitterSpout).Name,
        TwitterSpout.Get,
        new Dictionary<string, List<string>>()
        {
          {Constants.DEFAULT_STREAM_ID, new List<string>(){"tweet"}}
        },
        1);
      topologyBuilder.SetBolt(
        typeof(TwitterBolt).Name,
        TwitterBolt.Get,
        new Dictionary<string, List<string>>()
        {
          {Constants.DEFAULT_STREAM_ID, new List<string>(){"count", "tweet"}}
        },
        1).shuffleGrouping(typeof(TwitterSpout).Name);
      topologyBuilder.SetBolt(
        typeof(SqlAzureBolt).Name,
        SqlAzureBolt.Get,
        new Dictionary<string, List<string>>(),
        1).shuffleGrouping(typeof(TwitterBolt).Name);
      topologyBuilder.SetBolt(
        typeof(SignalRBroadcastBolt).Name,
        SignalRBroadcastBolt.Get,
        new Dictionary<string, List<string>>(),
        1).shuffleGrouping(typeof(TwitterBolt).Name);
      return topologyBuilder;
    }
  }
}

El proyecto de análisis completo de Twitter se puede crear en Visual Studio con el tipo de proyecto de Storm. Convenientemente, este proyecto establece los distintos componentes que se necesitan de manera simple y familiar, y que se puede visualizar en el Explorador de soluciones, tal como se muestra en la Figura 6. Puede agregar componentes, como bolts y spouts, con la opción Agregar | Nuevo elemento del menú contextual de un proyecto. La elección entre los tipos de un elemento Storm agrega un archivo nuevo e incluye el esquema para todos los métodos necesarios. Usando el proyecto Storm de Visual Studio, puede agregar referencias a bibliotecas, como Tweetinvi, directamente o a través de NuGet. Para enviar la topología para su ejecución en Azure solo necesita hacer clic en el menú contextual del Explorador de soluciones. Todos los componentes necesarios se cargan al clúster de HDInsight Storm que yo elijo y la topología se envía.

Figura 6 Enviar una topología desde el Explorador de soluciones

Después del envío, veo la vista de topología de la Figura 2, donde puedo supervisar el estado de mi topología. Storm permite varios estados de topología, por ejemplo, activada, desactivada y detenida, así como un reequilibrio de las tareas entre todos los trabajos según parámetros de escalabilidad. Puedo administrar todas estas transiciones de estado desde Visual Studio, así como observar el flujo actual de tuplas. Para investigar detalladamente los componentes y hacer la depuración de los problemas, puedo explorar en profundidad los componentes individuales, como SqlAzureBolt, que muestra una condición de error (el contorno rojo y marcador en la vista de topología). Si hago doble clic en este bolt, se muestran las estadísticas detalladas sobre el flujo de tuplas, así como el resumen de errores del bolt. Incluso puede hacer clic en el vínculo de puerto de error para ir a los registros completos de las tareas individuales sin tener que abandonar Visual Studio.

El código y proyecto para la topología simple que se cubre en este artículo se encuentra en GitHub, en el repositorio MicrosoftBigData. Busque la carpeta HDInsight y el proyecto de ejemplo TwitterStream. Encontrará artículos y ejemplos adicionales en bit.ly/1MCfsqM.

Pasar a análisis más complejos

El ejemplo de topología de Storm que presenté es un ejemplo simple. En Storm, hay varias maneras de aumentar el poder y la complejidad del procesamiento en tiempo real.

Como ya mencioné, el número de recursos asignados a un clúster Storm en HDInsight se puede escalar verticalmente según sea necesario. Puedo observar el rendimiento de mi sistema a partir de los datos que se proporcionan en la vista de runtime de Visual Studio de la topología en la Figura 2. Aquí, puedo ver el número de tuplas que se emiten, el número de ejecutores y tareas, y las latencias. En la Figura 7 se muestra la vista del Portal de administración de Azure, en la que se proporcionan detalles adicionales sobre el número de nodos, su tipo y el número de núcleos que están en uso. Basándome en esta información, decido escalar mi clúster y agregarle más nodos de supervisor (trabajo). Este escalado vertical no requiere un reinicio y se producirá en tan solo unos minutos después de desencadenar un reequilibrio desde la vista de topología de Visual Studio o del Portal de administración.

Figura 7 Vista del clúster de Storm en el Portal de administración de Azure

La mayoría de las aplicaciones de análisis funcionarán en varios flujos de macrodatos no estructurados. En este caso, la topología debería contener varios spouts y bolts que pueden leer desde más de un spout. Esto se puede expresar fácilmente en la configuración de la topología al especificar varias entradas en la invocación del método SetBolt. Sin embargo, la lógica de negocios de la gestión de los múltiples orígenes en el mismo bolt será más compleja a medida que lleguen tuplas individuales bajo distintos identificadores de flujo. A medida que aumente la complejidad del problema de negocios, es probable que durante el procesamiento también se necesiten orígenes de datos relacionales o estructurados. Si bien los spouts son ideales para los orígenes de datos de tipo cola, es más probable que un bolt inserte datos relacionales. Nuevamente, la implementación flexible de bolts y el uso de C# o Java permiten codificar fácilmente el acceso a una base de datos mediante API establecidas o lenguajes de consulta. Aquí, la complejidad surge del hecho de que estas llamadas se harán de manera remota desde contenedores de Storm en un clúster al servidor de base de datos. SQL Azure y HDInsight funcionan en el mismo tejido de Azure e interactúan fácilmente. Sin embargo, existen otras opciones para los servicios basados en la nube que también se pueden usar.

El runtime de Storm me permite establecer o retocar muchos comportamientos de granularidad fina del sistema. Muchas más opciones de configuración aparecen como parámetros de configuración que se pueden aplicar en el nivel de la topología o tarea. Estos son accesibles desde la clase Microsoft.SCP.Topology.StormConfig y se usan para ajustar la carga de trabajo general de Storm. Entre los ejemplos se incluye opciones de configuración para el número máximo de tuplas pendientes por spout, tuplas de tick y la estrategia de suspensión de spouts. Otros cambios en la topología se pueden hacer en el generador de topologías. En mi topología de ejemplo, el streaming entre todos los componentes se estableció en “agrupación aleatoria”. Para cualquier componente dado, el sistema de ejecución de Storm puede crear muchas tareas individuales y lo hará. Estas tareas son independientes de los subprocesos de trabajo que se pueden ejecutar en paralelo en todos los núcleos o contenedores para distribuir la carga de trabajo para el bolt entre varios recursos. Puedo controlar la manera en que el trabajo se pasa de un bolt al siguiente. Al elegir la agrupación aleatoria, indico que cualquier tupla puede ir a cualquier proceso de trabajo del bolt siguiente. También puedo elegir otras opciones, como “agrupación por campos”, que haría que las tuplas se envíen al mismo trabajo en función del valor de un campo concreto de la tupla. Esta opción se puede usar para controlar el flujo de datos de las operaciones que tengan un estado, como un recuento móvil de una palabra concreta del flujo de tweets.

Por último, un sistema de análisis en tiempo real podría formar parte de una canalización más amplia de análisis en una organización. Por ejemplo, es probable que un sistema de análisis de registros web tenga una gran parte orientada a los lotes y que procesa diariamente los registros de un servicio web. Esto produciría resúmenes de tráfico del sitio web y proporcionaría datos ligeramente agregados que serían adecuados para la detección de patrones por parte de un científico de datos. Basándose en este análisis, el equipo podría decidir crear desencadenadores en tiempo real para determinados comportamientos, como la detección de errores del sistema o uso malintencionado. Esta segunda parte necesitaría un análisis en tiempo real de los flujos de registros o telemetría, pero es probable que dependa de los datos de referencia que el sistema de procesamiento en lotes actualiza cada día. Estas canalizaciones de mayor tamaño requieren una herramienta de administración de flujos de trabajo que permita la sincronización de tareas entre una variedad de modelos y tecnologías informáticas. La Factoría de datos de Azure (ADF) proporciona un sistema de administración de flujos de trabajo que admite, de forma nativa, los servicios de análisis y almacenamiento de Azure, y permite la coordinación entre tareas según la disponibilidad de los datos de entrada. ADF admite los análisis de HDInsight y Azure Data Lake, así como el desplazamiento de datos entre el Almacenamiento de Azure, Almacenamiento de Azure Data Lake, Base de datos SQL de Azure y orígenes de datos locales.

Otras tecnologías de streaming

En este artículo, presenté los conceptos básicos de los análisis de streaming en tiempo real con Storm en HDInsight. Por supuesto, Storm también se puede configurar en un clúster propio de máquinas en un centro de datos o laboratorio propio. La distribución de Storm se puede lograr a través de Hortonworks, Cloudera o directamente desde Apache. La instalación y configuración de estos casos llevan bastante más tiempo, pero los conceptos y los artefactos de código son los mismos.

Spark (spark.apache.org) es otro proyecto de Apache que se puede usar para los análisis en tiempo real y se hizo muy popular. Admite el procesamiento general de macrodatos, pero su compatibilidad con el procesamiento en memoria y una biblioteca de funciones de streaming lo convierten en una opción interesante para el procesamiento en tiempo real de alto rendimiento. HDInsight ofrece tipos de clúster de Spark donde puede experimentar con esta tecnología. El servicio incluye cuadernos de Zeppelin y Jupyter, que son interfaces que permiten generar consultas en estos lenguajes y ver resultados interactivos. Estos son ideales para la exploración de datos y el desarrollo de consultas sobre conjuntos de macrodatos.

El interés en los análisis de streaming en tiempo real crece a medida que las organizaciones experimentan escenarios cada vez más complejos para los análisis de macrodatos. Al mismo tiempo, las tecnologías que se tratan en este espacio siguen creciendo y madurando, proporcionando nuevas oportunidades para obtener información valiosa de los macrodatos. Consulte estas páginas para leer artículos futuros sobre el uso de tecnologías, como Spark y análisis de Azure Data Lake.

Omid Afnanes gerente principal de programación en el equipo de macrodatos de Azure que trabaja en las implementaciones de sistemas informáticos distribuidos y cadenas de herramientas para desarrolladores relacionadas. Vive y trabaja en China. Su dirección de correo electrónico de contacto es omafnan@microsoft.com.

Gracias a los siguientes expertos técnicos por revisar este artículo: Asad Khan y Ravi Tandon
Ravi Tandon (Microsoft), Asad Khan (Microsoft)

Asad Khan es gerente principal de programación en el grupo de macrodatos de Microsoft que se centra en las experiencias impulsadas por Hadoop en la nube a través del servicio HDInsight de Azure. Actualmente, se centra en Spark y en los análisis en tiempo real a través de Apache Storm. Ha pasado los últimos años trabajando en la próxima generación de tecnologías de acceso a datos de Microsoft, como por ejemplo, Hadoop, OData y BI, sobre macrodatos. Asad tiene un Máster de la Universidad de Stanford.

Ravi Tandon es ingeniero de software sénior del equipo HDInsight de Microsoft Azure. Trabaja en las ofertas Apache Storm y Apache Kafka sobre HDInsight de Microsoft Azure.