Январь 2016

Том 31 номер 1

Большие данные - Анализ данных в реальном времени для .NET-разработчиков, использующих HDInsight

Омид Афнан | Январь 2016

Исходный код можно скачать по ссылке.

Продукты и технологии:

Microsoft Azure, Visual Studio, HDInsight, Apache Storm

В статье рассматриваются:

  • анализ данных в облаке;
  • анализ в реальном времени с помощью Apache Storm;
  • фильтрация потоков твитов с использованием .NET;
  • средства разработки HDInsight для Visual Studio.

Предприятия любых масштабов начали осознавать значимость собственных колоссальных массивов данных и потребность в использовании их преимуществ. Когда организации отправляются в свое путешествие по большим данным (Big Data), они обычно начинают с пакетной обработки наборов больших данных. Это могло означать сбор и агрегацию данных веб-журналов, информацию о действиях пользователей в приложениях, телеметрических данных от устройств Интернета вещей (Internet of Things, IoT) или массива других данных, генерируемых как человеком, так и машинами. Я уже рассматривал случай с базовым анализом веб-журналов, используя Hive в HDInsight в своей статье годовой давности (msdn.com/magazine/dn890370). Однако по мере реализации преимуществ пакетной обработки для извлечения уникальной информации из хронологических данных многие организации сталкиваются с проблемой работы с данными в реальном времени и вопросом по поводу того, как собирать, анализировать и обрабатывать непрерывные потоки данных в реальном времени.

Как вы, вероятно, догадались, в области больших данных имеются технологии, рассчитанные на такие потребности. Платформа Microsoft Azure предоставляет эффективные решения в области больших данных, в том числе Azure Data Lake и HDInsight. Существует и технология с открытым исходным кодом, которая обеспечивает высоко распределенный анализ, — Apache Storm. Она изначально поддерживается в HDInsight, которая является управляемым предложением в Azure для сервисов Apache Big Data. В этой статье я шаг за шагом рассмотрю простой, но эффективный сценарий, где приходится иметь дело с потоком твитов, используя Storm как ключевой инструмент для непрерывной аналитики в реальном времени.

Как вы увидите, Microsoft делает этот вид разработок значительно проще, чем другие предложения на рынке. Это достигается за счет мощных средств разработки и отладки в Visual Studio. HDInsight Tools for Visual Studio (доступен как часть Azure SDK) предоставляет привычную для .NET-разработчиков среду кодирования и отладки. Этот инструментарий облегчает работу с технологиями больших данных в гораздо большей мере, чем простые редакторы и утилиты командной строки, существующие в мире открытого исходного кода. Хотя Storm for HDInsight полностью поддерживает программирование на Java, Microsoft также позволяет .NET-программистам использовать C# для написания (и повторного использования) бизнес-логики. Эти возможности .NET демонстрируются примерами в данной статье.

Сценарий отслеживания настроений

Сценарий отслеживания и анализа нарождающихся тенденций вовсе не нов. Новостные сообщения, мониторинг погоды и обнаружение стихийных бедствий — примеры того, что предшествовало облачным вычислениям. Однако с наступлением эры облаков и их развитием спектр областей, где желательно обнаружение тенденций, и масштаб данных, доступных для анализа, невероятно увеличился. Социальные сети стали благодатной почвой для анализа настроений по тональности высказываний (sentiment analysis). Такие сервисы, как Twitter, которые делают данные из социальных сетей доступными через API, наряду с платформами больших данных с оплатой по мере использования вроде HDInsight сделали анализ настроений доступными как крупным организациям, так и малым.

Простейший вид анализа настроений с помощью Twitter — подсчет того, сколько людей пишет твиты по определенной теме или хэштегу (hashtag) за данный период времени. Конечно, выполнение такой операции только за один период, например за минуту, не столь интересен, как та же операция за сутки и поиск подъемов или провалов в частоте соответствующих твитов. Идентификация пиков в определенном показателе может быть полезна для обнаружения тенденции. Скажем, обнаружение показателей, относящихся к шторму или землетрясению, могло бы помочь очень быстро распознать области, затронутые стихийным бедствием, и степень его опасности.

Чтобы продемонстрировать основы того, как это делается, я подробно рассмотрю, как настроить топологию потоковых данных для сбора информации из Twitter, отбирать определенные твиты, вычислять показатели, сохранять все в хранилище и публиковать некоторые результаты. Для этого годится топология, изображенная на рис. 1. Для этой статьи я отбирал твиты, используя простой поиск на соответствие ключевому слову. Рассчитываемые показатели — количество твитов, совпадающих с критериями отбора. Выбранные твиты помещаются в базу данных SQL, а также публикуются на веб-сайте. Все это выполняется в облаке Azure, используя Storm, SQL Server и сервисы веб-сайтов, доступные сегодня. Пройдя этот пример, я расскажу о некоторых из других технологий, доступных для решения этого типа задачи анализа потоковых данных.

Топология анализа настроений
Рис. 1. Топология анализа настроений

Twitter Tweets Твиты из Twitter
Pull and Filter Tweet Stream Извлечение и фильтрация потока твитов
Aggregate Tweet Statistics Агрегация статистики твитов
Publish to Web Публикация в Web
Write to Database Запись в базу данных

 

Основы Storm

Storm — это проект Apache с открытым исходным кодом (storm.apache.org), обеспечивающий распределенные вычисления над потоками данных в реальном времени. Это часть экосистемы средств обработки больших данных Hadoop и прямо поддерживается в HDInsight. Задания Storm определяются как граф узлов обработки, соединенных потоками данных в форме кортежей (tuples). Такой граф называют в Storm топологией. Топологии не завершаются, как другие запросы, — они продолжают работать, пока не будут приостановлены или уничтожены.

На портале управления Azure можно создать новый кластер HDInsight и в качестве типа выбрать Storm. Это заставит Azure подготовить кластер машин с предварительно загруженными компонентами (ОС, Hadoop и Storm) в течение минут. Я могу выбрать нужное количество узлов, указать другое ядро (core) и размер памяти и в любой момент наращивать или уменьшать количество узлов. В плане упрощения работы с Hadoop это уже экономит мне значительное время и избавляет от головной боли приобретения и конфигурирования множества машин.

Компоненты топологии называют воронками (spouts) и ситами (bolts) . Воронки создают потоки кортежей, которые в основном представляют собой наборы пар «тип-значение». Иначе говоря, воронка — это блок кода, которому известно, как собирать или генерировать данные, а затем передавать их порциями. Сита являются единицами кода, которые способны потреблять поток данных. Они могут обрабатывать данные для их очистки или для расчета статистики. В таких случаях они чаще всего генерируют другой поток кортежей нижележащим ситам. Другие сита записывают данные в хранилище или в другую систему.

Каждый из этих компонентов может выполнять множество параллельных задач. Это ключ к масштабируемости и надежности Storm. Я могу указать степень параллелизма для каждого компонента, и Storm создаст соответствующее количество задач для выполнения логики в моей воронке или сите. Storm обеспечивает отказоустойчивость, управляя задачами и автоматически перезапуская сбойные задачи. Наконец, конкретная топология выполняется в наборе рабочих процессов, которые, по сути, являются контейнерами выполнения (execution containers). Рабочие процессы можно добавлять для наращивания возможностей топологии в обработке.

Топология может быть настолько сложной, насколько это необходимо, чтобы выполнить обработку всего сценария аналитики в реальном времени. Архитектура допускает повторное использование компонентов, но и создает весьма трудную проблему в управлении и развертывании по мере роста количества воронок и сит. Концепция проекта Visual Studio — полезный способ управления компонентами кода и конфигурации, необходимыми для создания экземпляра топологии. Поскольку сама идея топологии фактически является графической по своей природе, возможность визуализации топологии как при разработке, так и при эксплуатации системы очень полезна. Это хорошо видно в представлении HDInsight Tools for Visual Studio (рис. 2).

Представление мониторинга активной топологии Storm
Рис. 2. Представление мониторинга активной топологии Storm

Storm — это проект Apache с открытым исходным кодом, обеспечивающий распределенные вычисления над потоками данных в реальном времени.

Архитектура Storm базируется на Apache Thrift — инфраструктуре, которая обеспечивает разработку сервисов, реализуемых на нескольких языках. Хотя многие разработчики используют Java для написания воронок и сит, это не обязательное требование. С появлением пакета библиотек SCP.Net можно использовать C# для разработки воронок и сит. Этот пакет включается в HDInsight Tools for Visual Studio, но может быть загружен и через NuGet.

Фильтрация твитов почти в реальном времени

Рассмотрим создание топологии фильтрации потока твитов, чтобы понять, как на практике работают все эти части. Мой пример топологии состоит из одной воронки и трех сит. Вы можете увидеть графическое представление этой топологии на рис. 2, отображаемое HDInsight Tools for Visual Studio. Когда я передаю проект Storm для выполнения в Azure, Visual Studio показывает мне это графическое представление и со временем обновляет его количеством событий, проходящих через систему, а также сообщает о любых ошибках, возникающих на любом из узлов.

Здесь TwitterSpout отвечает за извлечение потока твитов, которые я хочу обрабатывать. Для этого он взаимодействует с Twitter API, чтобы собирать твиты и преобразовывать их в кортежи данных, которые можно передавать потоком через остальную часть топологии. TwitterBolt захватывает поток и может выполнять агрегацию, скажем, подсчитывая количество твитов или объединяя их с данными, извлекаемыми из других источников. Это сито генерирует новый поток, возможно, в новом формате на основе выполняемой им бизнес-логики. Компоненты AzureSQLBolt и SignalRBroadcastBolt потребляют этот поток и записывают порции данных в базу данных SQL Server, размещенную в Azure, и на веб-сайт SignalR соответственно.

Поскольку я создаю решение Storm, используя C#, я могу задействовать множество существующих библиотек, которые упрощают и ускоряют разработку. Два ключевых пакета для этого примера — библиотеки Tweetinvi в CodePlex (bit.ly/1kI9sqV) и библиотеки SCP.Net в NuGet (bit.ly/1QwICPj).

Инфраструктура SCP.Net устраняет многие сложности модели программирования в Storm и предоставляет базовые классы, инкапсулирующие большую часть работы, которую иначе мне пришлось бы выполнять самому. Я начинаю с наследования от базового класса Microsoft.SCP.ISCPSpout. Это дает мне три основных метода, необходимых для воронки: NextTuple, Ack и Fail. NextTuple выдает либо следующую порцию доступных данных для потока, либо вообще ничего. Этот метод вызывается Storm в коротком цикле и является подходящим местом для задания какого-то времени сна, если у вас нет кортежей, которые вы могли бы выдать. Это один из способов избежать 100%-ной загрузки процессора, так как топология выполняется постоянно.

Если нужно реализовать гарантированную обработку сообщений, например семантику «минимум один раз» для моих кортежей, я бы использовал методы Ack и Fail для реализации необходимого подтверждения установления связи между ситами. В этом примере я не использую никакие механизмы повторных попыток, поэтому реализую только метод NextTuple, используя код, который принимает твиты из закрытой очереди в классе TwitterSpout и передает их в топологию.

Потоки данных внутри топологии захватываются как схемы, публикуемые воронкой или ситом. Схемы используются в качестве контракта между компонентами в топологии, а также как правила сериализации и десериализации, используемые SCP.Net при передаче данных. Класс Context хранит конфигурационную информацию для каждого экземпляра воронки или сита. Схема кортежей, генерируемая воронкой, сохраняется в Context и используется SCP.Net для формирования соединений компонентов.

Давайте рассмотрим код для инициализации класса TwitterSpout (рис. 3).

Рис. 3. Инициализация класса 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));
  // Указываем удостоверения для Twitter
  TwitterCredentials.SetCredentials(
    ConfigurationManager.AppSettings["TwitterAccessToken"],
    ConfigurationManager.AppSettings["TwitterAccessTokenSecret"],
    ConfigurationManager.AppSettings["TwitterConsumerKey"],
    ConfigurationManager.AppSettings["TwitterConsumerSecret"]);
  // Подготавливаем поток твитов
  var stream = Tweetinvi.Stream.CreateFilteredStream();
  stream.MatchingTweetReceived += (sender, args) => { NextTweet(args.Tweet); };
  // Настраиваем критерии фильтра
  stream.AddTrack("China");
  stream.StartStreamMatchingAnyConditionAsync();
}

На рис. 3 показана инициализация контекста для данной воронки с передачей контекста при запуске топологии. Затем этот контекст обновляется добавлением определения схемы. Я создаю объект Dictionary, в который я добавляю идентификатор для типа потока (DEFAULT_STREAM) и список типов для всех полей в моем кортеже — в данном случае просто SerializableTweet. Теперь контекст содержит определение схемы, которому я должен следовать при генерации кортежей в этом классе, а также при их использовании в TwitterBolt.

Остальная часть этого фрагмента демонстрирует настройку Twitter-потока. Пакет Tweetinvi предоставляет абстракции как для REST API, так и для потоковых API от Twitter. После кодирования соответствующих удостоверений я просто создаю экземпляр источника нужного мне вида. В случае потоковых источников можно выбрать один из нескольких типов, включая фильтруемые, выборочные или пользовательские потоки. Они предоставляют упрощенные интерфейсы для фильтрации по ключевым словам всех твитов, случайной выборки общедоступных твитов и отслеживание событий, связанных с указанным пользователем. Здесь я использую фильтруемый поток, который позволяет отбирать твиты из всех открытых твитов, проверяя их на наличие любого из нескольких наборов ключевых слов.

В данном случае я выполняю фильтрацию твитов в воронке, поскольку Tweetinvi API упрощают эту задачу. Я мог бы также выполнять фильтрацию в компоненте TwitterBolt наряду с любыми другими необходимыми мне вычислениями и агрегацией. Фильтрация в воронке позволяет на ранних стадиях уменьшать объем данных, пропускаемых через топологию. Однако мощь Storm в том, что она дает возможность обрабатывать большие объемы в любом компоненте топологии за счет горизонтального масштабирования. Storm обеспечивает почти линейное масштабирование добавлением ресурсов, что позволяет использовать больше рабочих процессов, как только возникает узкое место. HDInsight поддерживает этот подход, разрешая выбирать размер кластера и типы узлов на этапе подготовки, а также добавлять узлы в сформированный кластер. Используя такой подход с горизонтальным масштабированием, можно формировать кластеры Storm, способные обрабатывать миллионы событий в секунду. Количество узлов в кластере влияет на оплату, поэтому не забывайте о балансе между стоимостью и масштабом.

Последнее, на что стоит обратить внимание на рис. 3, — регистрация обратного вызова, чтобы вызывать объект потока Tweetinvi, когда обнаруживается твит, отвечающий моим критериям. Метод NextTweet как раз и является этим обратным вызовом, который просто добавляет этот твит в ранее упомянутую закрытую очередь в классе TwitterSpout:

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

Сита в моей топологии кодируются аналогично. Они наследуются от класса Microsoft.SCP.ISCPBolt и должны реализовать метод Execute. Здесь кортеж передается как обобщенный тип SCPTuple и должен быть сначала преобразован в подходящий тип. Затем я могу написать код на C# для выполнения любой необходимой обработки. В данном случае я просто использую глобальную переменную для накопления счетчика кортежей, увиденных ситом, и записываю в журнал номер и текст твита. Наконец, я генерирую кортеж нового типа для потребления нижележащими ситами. Вот этот код:

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));
}

В случае сита еще на этапе подготовки я должен указать входную и выходную схемы. Формат является тем же, что и в предыдущем определении схемы для воронки. Я просто определяю другую переменную Dictionary с именем outputSchema и перечисляю целочисленные и строковые типы полей вывода, как показано на рис. 4.

Рис. 4. Задание входной и выходной схем для 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));
}

Остальные сита следуют тому же шаблону, но вызывают специфические API для SQL Azure и SignalR. Последний ключевой элемент — определить топологию перечислением компонентов и их соединений. Для этого есть другой метод, который должен быть реализован во всех воронках и ситах, — Get; он просто создает экземпляр объекта этого класса с переменной Context, вызываемой SCPContext при запуске задачи Storm. SCP.Net будет создавать дочерний C#-процесс, который запустит вашу C#-задачу воронки или сита, используя следующий метод-делегат:

return new TwitterSpout(context);

Закончив с воронками и ситами, можно создать топологию. SCP.Net предоставляет класс и вспомогательные функции для этого. Я создаю класс, производный от Microsoft.SCP.Topology.TopologyDescriptor и переопределяю метод GetTopologyBuilder. В этом методе я использую объект типа TopologyBuilder, который содержит методы SetSpout и SetBolt. Эти методы позволяют указывать имя, а также входную и выходную схемы компонента. Кроме того, они дают возможность задавать делегат Get, используемый при инициализации компонента, и, что важнее, указывать вышестоящий компонент, который надо соединить с текущим компонентом. Рис. 5 демонстрирует код, определяющий мою топологию.

Рис. 5. Создание Twitter AnalysisTopology

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;
    }
  }
}

Полный проект анализа Twitter можно создать в Visual Studio, используя тип проекта Storm. Этот проект удобно размещает различные необходимые вам компоненты и позволяет легко и привычно просматривать их в Solution Explorer (рис. 6). Вы можете добавлять компоненты вроде воронок и сит через Add | New Item из контекстного меню проекта. Выбрав один из типов элементов Storm, вы добавите новый файл и включите заготовки для всех требуемых методов. С помощью проекта Visual Studio Storm можно добавлять ссылки на библиотеки наподобие Tweetinvi напрямую или через NuGet. Передача топологии на выполнение в Azure требует всего одного щелчка в контекстом меню Solution Explorer. Все необходимые компоненты загружаются в выбранный кластер HDInsight Storm, и ему передается топология.

Передача топологии из Solution Explorer
Рис. 6. Передача топологии из Solution Explorer

После передачи я вижу Topology View, как на рис. 2, где могу отслеживать состояние своей топологии. Storm допускает несколько состояний топологии, включая activated (активировано), deactivated (деактивировано) и killed (уничтожено), а также поддерживает повторную балансировку задач между рабочими процессами на основе параметров масштабируемости. Переходами между всеми этими состояниями можно управлять из Visual Studio, а также наблюдать за текущим потоком кортежей. Для отладки можно углубляться в индивидуальные компоненты вроде SqlAzureBolt, который показывает ошибку (красный контур и маркер в Topology View). Дважды щелкнув это сито, вы увидите более детальную статистику по потоку кортежей, а также сводку ошибок этого сита. Можно даже щелкнуть ссылку Error Port, чтобы перейти к полным журналам индивидуальных задач, не покидая Visual Studio.

Код и проект для простой топологии, рассмотренной в этой статье, находится на GitHub под репозитарием MicrosoftBigData. Найдите папку HDInsight и проект-пример TwitterStream. Дополнительные статьи и примеры вы найдете по ссылке bit.ly/1MCfsqM.

Переходим к более сложному анализу

Я представил пример простой топологии Storm. Существует много способов, с помощью которых я могу нарастить мощь и сложность обработки реального времени в Storm.

Как уже упоминалось, количество ресурсов, назначаемых кластеру Storm в HDInsight, можно при необходимости масштабировать. Я могу наблюдать за производительностью своей системы по данным в представлении выполнения (runtime view) топологии в Visual Studio (рис. 2). Здесь видно количество генерируемых кортежей, число исполняющих процессов, задач, а также задержки. На рис. 7 показано представление Azure Management Portal, которое предоставляет дополнительные детали о количестве узлов, их типе и основных показателях работы этих узлов. На основе этого я могу решить масштабировать свой кластер и добавить больше управляющих (рабочих) узлов в кластер. Такое вертикальное масштабирование не требует перезапуска и происходит в течение минут, когда я инициирую повторную балансировку из представления топологии в Visual Studio или с портала управления.

Представление Azure Management Portal кластера Storm
Рис. 7. Представление Azure Management Portal кластера Storm

Большинство аналитических приложений будет оперировать несколькими неструктурированными потоками больших данных. В этом случае топология должна включать несколько воронок и сит, способных считывать данные более чем из одной воронки. Это легко выразить в конфигурации топологии, указав несколько входов при вызове метода SetBolt. Однако бизнес-логика, имеющая дело с несколькими источниками в одном сите, будет сложнее, так как индивидуальные кортежи поступают под идентификаторами разных потоков. По мере роста сложности бизнес-задачи весьма вероятно, что при обработке также потребуются источники реляционных или структурированных данных. Хотя воронки идеальны для источников данных, подобных очередям, реляционные данные с большей вероятностью будут использоваться ситом. И вновь гибкая реализация сит и использование C# или Java делают возможным легко обращаться из кода к базе данных, используя устоявшиеся API или языки запросов. Здесь сложность вытекает из того факта, что эти вызовы будут выдаваться к серверу базы данных удаленно из контейнеров Storm в кластере. SQL Azure и HDInsight работают в одной и той же инфраструктуре Azure и легко взаимодействуют, но для облачных сервисов можно использовать и другие варианты.

Исполняющая среда Storm позволяет устанавливать или настраивать многие тонкости поведения системы. Большинство таких настроек появляется как конфигурационные параметры, которые можно применять к топологии или на уровне задач. Они доступны в классе Microsoft.SCP.Topology.StormConfig и используются для настройки общей рабочей нагрузки Storm. К примерам относятся настройки для максимального количества ждущих кортежей в каждой воронке, метки кортежей и стратегия режима сна для воронки. Другие изменения в топологию можно вносить в средстве формирования топологии (topology builder). В моем примере топологии потоковая передача между всеми компонентами установлена в режим группирования с перетасовкой (shuffle grouping). Для любого конкретного компонента система выполнения Storm может создать и создаст множество индивидуальных задач. Эти задачи независимы от рабочих потоков (worker threads), способных выполняться параллельно разными ядрами или контейнерами для распределения рабочей нагрузки сита по набору ресурсов. Я могу контролировать то, как работа передается от одного сита другому. Выбирая группирование с перетасовкой, я сообщаю, что любой кортеж может быть отправлен в любой рабочий процесс (worker process) в следующем сите. Я также могу выбрать другие варианты вроде группирования по полю (field grouping), что заставит передавать кортежи одному и тому же рабочему процессу на основе значения конкретного поля в кортеже. Этот вариант подходит для управления потоком данных в операциях, имеющих состояние, например при вычислении количества случаев употребления заданного слова в потоке твитов.

Наконец, система анализа в реальном времени может быть частью большего конвейера аналитики в организации. Например, система анализа веб-журналов скорее всего имеет большую пакетно-ориентированную часть, которая обрабатывает журналы для какого-то веб-сервиса на ежедневной основе. Это давало бы сводки по трафику веб-сайта и предоставляло бы данные с небольшой степенью агрегации, подходящие для обнаружения закономерностей специалистами в области анализа информации. На основе этого анализа группа могла бы решить создать триггеры реального времени для определенных поведений, скажем, для обнаружения системных сбоев или злонамеренного использования. Эта вторая часть потребовала бы анализа журналов или телеметрических потоков, но, по-видимому, зависела бы от справочных данных (reference data), обновляемых ежедневно пакетной системой (batch system). Такие более крупные конвейеры требуют применения какого-либо средства управления рабочим процессом, обеспечивающего синхронизацию задач между самыми разнообразными моделями и технологиями вычислений. Azure Data Factory (ADF) предоставляет систему управления рабочим процессом, которая изначально поддерживает сервисы аналитики и хранения в Azure и позволяет координировать задачи на основе доступности входных данных. ADF поддерживает HDInsight и Azure Data Lake Analytics, а также перемещение данных между Azure Storage, Azure Data Lake Storage, Azure SQL Database и локальными источниками данных (на предприятиях).

Другие потоковые технологии

В этой статье я ознакомил вас с основами потоковой аналитики в реальном времени с применением Storm в HDInsight. Конечно, Storm можно подготовить на собственном кластере машин в вашем информационном центре или лаборатории. Дистрибутив Storm можно получить через Hortonworks, Cloudera или напрямую от Apache. Установка и конфигурирование в этих случаях потребует значительно больше времени, но концепции и артефакты кода останутся прежними.

Spark (spark.apache.org) — еще один проект Apache, который можно использовать для аналитики реального времени и который завоевал широкую популярность. Он поддерживает универсальную обработку больших данных, но его поддержка обработки в памяти и библиотек потоковых функций делает его интересным выбором для высокопроизводительной обработки в реальном времени. HDInsight предлагает типы кластеров Spark, где вы можете поэкспериментировать с этой технологией. Сервис включает Zeppelin и Jupyter Notebooks, которые являются интерфейсами, позволяющими создавать запросы на этих языках и видеть интерактивные результаты. Они идеальны для исследования данных и разработки запросов к наборам больших данных.

Интерес к потоковой аналитике реального времени определяется тем, что организации сталкиваются со все более сложными сценариями анализа больших данных. В то же время технологии в этой области продолжают развиваться и взрослеть, обеспечивая новые возможности в извлечении знаний из больших данных.


Омид Афнан (Omid Afnan) — главный менеджер программ в группе Azure Big Data, работающей над реализациями распределенных вычислительных систем и соответствующего инструментария для разработчиков. Живет и работает в Китае. С ним можно связаться по адресу omafnan@microsoft.com.

Выражаю благодарность за рецензирование статьи экспертам Асаду Хану (Asad Khan) и Рави Тандону (Ravi Tandon).

1 Эти своеобразные термины в Storm не имеет устоявшихся эквивалентов на русском языке. В ряде блогов и статей они как только ни называются, однако на официальном сайте Microsoft (azure.microsoft.com/ru-ru/documentation/articles/hdinsight-apache-storm-tutorial-get-started) они называются воронками и ситами, так что будем придерживаться этой версии терминов. — Прим. ред.