Статья
02/19/2016

Январь 2016

Том 31, номер 1

Большие данные - Создание конвейеров больших данных с помощью Azure Data Lake и Azure Data Factory

Гаурав Малхотра | Январь 2016

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

Azure Data Lake, Azure Data Factory, U-SQL

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

сценарий анализа веб-журналов с помощью Azure Data Lake и Azure Data Factory;
перемещение данных в Azure Data Lake Store;
создание конвейера с действиями U-SQL;
мониторинг конвейеров больших данных.

В этом году предложения Microsoft Azure Big Data были пополнены сервисом Azure Data Lake (ADL) наряду с возможностью создания комплексных (end-to-end, E2E) конвейеров больших данных, используя ADL и Azure Data Factory (ADF). В этой статье я освещу применение ADF для планирования как разовых, так и повторяющихся задач перемещения и анализа больших данных.

ADL упрощает и делает более доступной обработку больших данных, предоставляя несколько ключевых технологий. Язык U-SQL является мощной комбинацией SQL и C# и поддерживает параллельное выполнение. Вы можете запускать U-SQL в облачном предложении ADL Analytics, где можно резервировать, использовать и освобождать сотни или тысячи контейнеров в течение жизненного цикла одного задания. Настройка этой облачной среды с помощью ADL не сложна. Используя портал Azure Management, можно легко и быстро создавать учетные записи ADL как для хранилищ, так и для анализа, и подготавливать ADF. В считанные минуты щелчком нескольких кнопок вы можете установить все необходимые учетные записи в своей подписке Azure.

По окончании подготовки учетных записей можно создавать комплексные конвейеры больших данных в ADF, используя Azure Management Portal, Windows PowerShell, C# SDK и средства Visual Studio. ADF — это облачный сервис интеграции данных, который координирует и автоматизирует перемещение и преобразование данных. Интеграция ADF и ADL позволяет:

перемещать данные из указанного источника в ADL Store;
создавать конвейеры больших данных ADF, выполняющих скрипты U-SQL как стадию обработки в сервисе ADL Analytics.

Существует ряд распространенных сценариев Big Data, на которые ориентированы ADL и ADF, в том числе анализ оттока клиентов (customer churn analysis), индивидуальные рекомендации по использованию продуктов (personalized product recommendations) и обработка страховой статистики (actuarial processing). Один из сценариев, интересный многим клиентам Azure, — анализ журналов веб-сервисов или приложений. В этой статье я покажу, как создать конвейеры фабрики данных для анализа веб-журналов, сначала переместив эти веб-журналы в ADL, а затем запустив скрипты U-SQL для их обработки.

Сценарий анализа веб-журналов

Распространенный сценарий в бизнесе — анализ веб-журналов для понимания объема и закономерности пользовательских запросов из разных регионов по всему миру. Такой анализ улучшает понимание потребностей клиентов, маркетинговых кампаний и дорожных карт выпуска продуктов, включая планы локализации. Журналы генерируются веб-приложениями, сетевыми устройствами, операционными системами и разнообразными интеллектуальными или программируемыми устройствами. Потоки данных, такие как журналы ошибок, сведений о посещениях (clickstream) и веб-серверов, могут легко накапливаться со скоростью порядка гигабайтов или терабайтов в неделю. Веб-журналы можно накапливать в хранилище любого вида, в том числе SQL Azure, Azure Blob Storage, Amazon Simple Storage Service (S3) и базах данных Oracle на предприятиях. Быстрый и эффективный анализ этих журналов для обнаружения закономерностей использования и системных проблем помогает компаниям лучше понимать характер использования их систем клиентами и в конечном счете способствует удовлетворению потребностей клиентов.

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

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

Разбор и агрегация веб-журналов, основанных на определенных разделах, например по регионам, — это действия, допускающие высокую степень параллелизма. Идеальный случай — наличие поднаборов записей, которые передаются индивидуальным серверам, способным разобрать, преобразовать и дать обобщенное представление этих записей. Затем выполняется слияние таких частичных результатов во множестве параллельных стадий, пока не будет создан конечный, объединенный набор данных. Управление этим процессом вручную крайне затруднено и подвержено неоптимальному выполнению из-за неполной информации о системе и ежедневного изменения формы данных. Однако это как раз то, что ADL Analytics и язык U-SQL делают автоматически. U-SQL позволяет выражать ваши целевые агрегации на декларативном синтаксисе запросов, подобном SQL, которые не требуют указывать какие-либо директивы распараллеливания. Компилятор и планировщик сами определяют возможную степень параллелизма в данном задании и выделяют ресурсы на основе этой степени параллелизма и любых заданных ограничений по максимальному использованию ресурсов. С помощью ADF можно легко сформировать конвейер, определяя соответствующие задачи U-SQL, связывать их с другими сериями задач, добавлять действия для перемещения данных с ваших веб-серверов в ADL Store и создавать расписание для регулярной обработки данных. Простота создания конвейера и компонентов позволяет вам сосредоточиться на бизнес-логике, а не на том, как оптимизировать обработку и хранить большие наборы данных.

Подготовка

Вы начинаете с создания учетных записей ADL Store и аналитики и подготовки фабрики данных. Все это делается на Azure Management Portal. Учетная запись ADL Analytics — это сущность, которая помогает вам группировать и управлять запросами и программами, выполняемыми для анализа больших данных. Вы можете управлять оплатой услуг, связывая свою учетную запись с различными подписками Azure и выбирая тарифные планы. Существуют возможности группирования учетной записи с другими ресурсами для целей отслеживания. Вы можете даже выбрать тот региональный информационный центр, где находится ваша учетная запись, что полезно для управления близостью к корпоративным данным.

ADL Store — это сервис для хранения больших данных, к которому можно обращаться из HDFS-совместимых систем, включая инструменты бизнес-анализа (business intelligence, BI) и приложения на предприятии. Настройка очень проста, и от вас не требуется указывать никаких лимитов при настройке. Как и в случае сервиса аналитики, важный параметр — географический регион, где вы хотите разместить данные. В случае хранилища данных это может быть крайне важно, поскольку возможны бизнес-требования, связанные с соблюдением нормативно-правовых норм к тому, где хранятся данные о жителях определенного региона. Учетные записи ADL Store можно создавать раздельно и использовать с другими сервисами, но чаще всего учетная запись создается в тандеме с ADL Analytics. На рис. 1 показан экран создания учетной записи ADL. Вы указываете имя учетной записи и выбираете свою подписку, группу ресурсов и местонахождение. Команда Create New Data Lake Store позволяет одновременно создать новое хранилище с теми же параметрами, что и в вашей учетной записи Analytics.

Рис. 1. Создание учетных записей ADL на Azure Management Portal

В этом примере данные веб-журналов хранятся в Azure Storage, позволяющем хранить большие двоичные данные в Azure. Вы также можете создать Azure Storage через портал. Используете вы Azure Web App или веб-сайт, размещенный где-либо еще, получение данных в Azure Storage осуществляет очень легко; при этом подразумевается их высокая доступность и надежность хранения. Пример данных веб-журналов, используемых в моей статье, см. по ссылке bit.ly/1ONi8c5.

На рис. 2 показано, как подготовить фабрику данных Azure. Как видите, процесс подготовки этих облачных сервисов очень прост. Вам не нужно использовать тот же географический регион, что и для сервисов ADL, — фабрика данных может работать с сервисами в любом регионе.

Рис. 2. Подготовка фабрики данных Azure

Фабрики данных являются комбинацией хранилищ данных, связанных сервисов и конвейеров. Хранилища данных и связанные сервисы представляют собой определения внешних сущностей, которые обычно уже существуют вне ADF. Конвейеры — это логические группы действий в ADF. Они используются для группирования действий в единицу, которая выполняется какую-либо задачу. Вы увидите подробности, когда я буду пошагово описывать настройку фабрики данных для анализа веб-журналов.

Вы можете создать эти сущности с помощью Azure Management Portal или Visual Studio. На портале в представлении Data Factory параметр Author and Deploy позволяет выбрать индивидуальные компоненты фабрики данных по типу и предоставить JSON-фрагменты, которые можно редактировать напрямую и публиковать (рис. 3). В качестве альтернативы можно задействовать преимущества ADF Tools for Visual Studio и использовать формат проекта для идентификации и определения каждого из компонентов фабрики данных (рис. 4). Затем проект можно опубликовать, чтобы создать эти сущности в вашей фабрике данных в Azure.

Рис. 3. Создание и развертывание фабрики данных с помощью веб-редактора

Рис. 4. Создание и развертывание фабрики данных с помощью плагина Visual Studio

Перемещение данных в Azure Data Lake Store

Первый шаг в анализе веб-журналов — перемещение данных в ADL Store. Для этого можно использовать действие Copy в конвейере ADF. Чтобы выполнить операцию копирования, вы должны создать связанные сервисы, наборы данных и конвейеры ADF. Связанные сервисы в ADF определяют информацию, необходимую для подключения к внешних ресурсам. Связанные сервисы используются для двух целей в фабрике данных. Первая — представление хранилища данных, в частности расположенные на предприятии SQL Server, база данных Oracle, общий файловый ресурс или учетная запись Azure Blob Storage. Вторая — представление обрабатывающего ресурса, который может быть хостом для выполнения какого-либо действия. Например, действие Hive в HDInsight выполняется в кластере HDInsight Hadoop. В данном случае вы должны создать два связанных сервиса, один из которых соответствует учетной записи Azure Storage, а второй представляет ADL Store.

Действие Copy в ADF очень эффективно и позволяет копировать данные между источниками и приемниками на предприятиях или в облаке, которые могут иметь разные схемы.

Вам также нужны два набора данных ADF. Наборы данных являются логическими ссылками на данные по учетной записи Azure Storage или ADL Store. В самой ADF никакие пользовательские данные не хранятся, поэтому ADF нужны определения наборов данных, чтобы идентифицировать структуру данных во внешних хранилищах данных, включая таблицы, файлы, папки и документы. Поскольку ADF не известна структура этих данных, вы должны определить ее здесь, чтобы система знала, какие столбцы и типы следует ожидать. В нашем случае надо создать один набор данных, соответствующий местонахождению учетной записи Azure Storage, которая содержит данные веб-журналов (источник), и второй набор данных, соответствующий ADL Store, куда вы хотите переместить веб-журналы (приемник).

Наконец, чтобы произошло копирование данных, вы должны создать ADF-конвейер, содержащий действие Copy. ADF-конвейер — это логические группы действий, таких как копирование данных, которые можно выполнять через разные интервалы, а также действия скриптов Hive, Pig или U-SQL, которые можно выполнять регулярно — через каждые 15 минут, ежечасно, ежедневно или ежемесячно. Действие Copy в ADF очень эффективно и позволяет копировать данные между источниками и приемниками на предприятиях или в облаке, которые могут иметь разные схемы. Вы можете указать несколько параметров или согласиться с их значениями по умолчанию. Вам предоставляется высокий уровень контроля, и вы можете настраивать такие вещи. как расписание и политики обработки ошибок.

Хотя конвейер может работать по повторяющемуся расписанию, в текущем примере он запускается лишь раз, чтобы переместить данные в ADL Store. JSON-фрагмент на рис. 5 показывает определение конвейера EgressBlobToDataLakePipeline. В этом конвейере есть действие Copy, которое перемещает данные из Azure Blob Storage в Azure Data Lake Store. Оно запланировано на разовое выполнение 08/08/2015 (значения свойств start и end для активного периода конвейера одинаковы).

Рис. 5. Определение конвейера-примера EgressBlobToDataLakePipeline

{
  "name": "EgressBlobToDataLakePipeline",
  "properties": {
    "description": "Egress data from blob to azure data lake",
    "activities": [
      {
        "type": "Copy",
        "typeProperties": {
          "source": {
            "type": "BlobSource",
            "treatEmptyAsNull": true
          },
          "sink": {
            "type": "AzureDataLakeStoreSink",
            "writeBatchSize": 10000,
            "writeBatchTimeout": "00:10:00"
          }
        },
        "inputs": [
          {
            "name": "RawBlobDemoTable"
          }
        ],
        "outputs": [
          {
            "name": "DataLakeTable"
          }
        ],
        "policy": {
          "timeout": "10:00:00",
          "concurrency": 1,
          "executionPriorityOrder": "NewestFirst",
          "retry": 1
        },
        "scheduler": {
          "frequency": "Day",
          "interval": 1
        },
        "name": "EgressDataLake",
        "description": "Move data from blob to azure data lake"
      }
    ],
    "start": "2015-08-08T00:00:00Z",
    "end": "2015-08-08T01:00:00Z",
    "isPaused": false
  }
}

Когда действие Copy в ADF-конвейере завершается успешно, веб-журналы оказываются перемещенными из Azure Blob Storage в Azure Data Lake Store. Узнать больше о действиях для перемещения данных в Azure Data Factory можно по ссылке bit.ly/1MNbIqZ, а подробнее о применении коннектора AzureDataLakeStore в ADF — по ссылке bit.ly/1MRwvVZ. Теперь вы готовы к обработке и анализу веб-журналов.

Создание конвейера с помощью действий U-SQL

Теперь, поместив данные в ADL Store, можно запускать скрипты U-SQL в сервисе ADL Analytics для обработки и анализа веб-журналов. Вы можете создать конвейеры, которые будут потреблять данные из ADL Store, выполнять скрипты U-SQL в сервисе ADL Analytics как стадию обработки и отправлять вывод в ADL Store. Затем нижестоящие приложения могут потреблять обработанный вывод напрямую из ADL Store или, если вы предпочтете, копировать данные из ADL Store в хранилище Azure SQL, если ваши BI-приложения используют в качестве серверного хранилища базу данных SQL.

Для обработки веб-журналов вам нужно снова создать связанные сервисы, наборы данных и конвейеры ADF. Вы можете повторно использовать связанные сервисы ADL Store, созданные на предыдущей стадии, если хотите создать последовательность конвейеров, которые сначала перемещают данные, а затем выполняют анализ, запуская скрипты U-SQL в одной ADF. Или создать новую фабрику данных, которая выполняет только анализ данных. ADF-конвейер в этом случае содержит действие Azure Data Analytics U-SQL и выполняет скрипт U-SQL, чтобы определить все события для Великобритании (локализующий идентификатор «en-gb») с датами до «2012/02/19». На рис. 6 приведено JSON-определение для ComputeEventsByEnGbRegionPipeline, которое задает такой конвейер с действием U-SQL для обработки веб-журналов.

Рис. 6. Определение конвейера-примера ComputeEventsByEnGbRegionPipeline

{
  "name": "ComputeEventsByEnGbRegionPipeline",
  "properties": {
    "description": "This is a pipeline to compute events
      for en-gb locale and date less than 2012/02/19.",
    "activities": [
      {
        "type": "DataLakeAnalyticsU-SQL",
        "typeProperties": {
          "scriptPath": "scripts\\usql\\
            SearchLogProcessing.txt",
          "scriptLinkedService": "StorageLinkedService",
          "degreeOfParallelism": 3,
          "priority": 100,
          "parameters": {
            "in": "/datalake/input/SearchLog.tsv",
            "out": "/datalake/output/Result.tsv"
          }
        },
        "inputs": [
          {
            "name": "DataLakeTable"
          }
        ],
        "outputs": [
          {
            "name": "EventsByEnGbRegionTable"
          }
        ],
        "policy": {
          "timeout": "06:00:00",
          "concurrency": 1,
          "executionPriorityOrder": "NewestFirst",
          "retry": 1
        },
        "scheduler": {
          "frequency": "Day",
          "interval": 1
        },
        "name": "EventsByRegion",
        "linkedServiceName":
          "AzureDataLakeAnalyticsLinkedService"
      }
    ],
    "start": "2015-08-08T00:00:00Z",
     "end": "2015-08-08T01:00:00Z",
    "isPaused": false
  }
}

Вы можете создать конвейеры, которые будут потреблять данные из ADL Store, выполнять скрипты U-SQL в сервисе ADL Analytics как стадию обработки и отправлять вывод в ADL Store.

Скрипт U-SQL на рис. 7, выполняемый конвейером, находится в папке scripts/usql (scriptPathproperty в JSON-конвейере на рис. 5) по учетной записи Azure Blob Storage, соответствующей развернутому StorageLinkedService. Значения параметров @in и @out в скрипте динамически передаются из ADF, используя раздел parameters в JSON-конвейере (рис. 6). Кроме того, можно задать другие свойства, например degreeOfParallelism или приоритет в вашем определении конвейера для заданий, выполняемых в сервисе ADL Analytics. Этот скрипт U-SQL обрабатывает веб-журналы и возвращает все события для локализующего идентификатора (locale) «en-gb» с датами до «2012/02/19».

Рис. 7. Скрипт U-SQL SearchLogProcessing.txt

@searchlog =
  EXTRACT UserId          int,
          Start           DateTime,
          Region          string,
          Query           string,
          Duration        int?,
          Urls            string,
          ClickedUrls     string
  FROM @in
  USING Extractors.Tsv(nullEscape:"#NULL#");

@rs1 =
   SELECT Start, Region, Duration
   FROM @searchlog
WHERE Region == "en-gb";

@rs1 =
  SELECT Start, Region, Duration
  FROM @rs1
  WHERE Start <= DateTime.Parse("2012/02/19");

OUTPUT @rs1
  TO @out
    USING Outputters.Tsv(quoting:false, dateTimeFormat:null);

Мониторинг конвейеров больших данных

Сервис Data Factory предоставляет надежное, полное представление о хранении, обработке и перемещении данных. Он помогает быстро обращаться к показателям работоспособности комплексных конвейеров данных, выявлять проблемы и при необходимости предпринимать корректирующие меры. Кроме того, можно визуально отслеживать операционный журнал преобразований (operational lineage) и связи между данными в любом из ваших источников, а также просматривать полные хронологические сведения о выполнении заданий, работоспособности системы и зависимостях с единой информационной панели. Режим просмотра Diagram в ADF (рис. 8) на портале управления отображает операционный журнал преобразований для фабрики данных. Вы видите два конвейера и соответствующие наборы данных: EgressBlobToDataLakePipeline (копирует данные из Azure Blob Storage в Azure Data Lake Store) и ComputeEventsByEnGbRegionPipeline (получает все события для локализующего идентификатора «en-gb» с датами до «2012/02/19»).

Рис. 8. Режим просмотра Diagram в Azure Data Factory

ADF-конвейер копирования на рис. 8 запустит выполнение 08/08/2015, так как для наборов данных задано ежедневное обновление, а параметры start и end в определении конвейера установлены одинаковыми — «08/08/2015». Поэтому конвейеры будут запущены только в этот день и выполнят скрипт U-SQL лишь один раз. Узнать больше о планировании ADF-конвейеров можно по ссылке bit.ly/1lEVjuM. Щелкните EventsByEnGbRegionTable в режиме просмотра Diagram, чтобы увидеть выполнение соответствующего действия и его состояние (рис. 9).

Рис. 9. Режим просмотра действия в Azure Data Factory

Как видите, действие U-SQL в ADF ComputeEventsByEnGbRegionPipeline было успешно выполнено и создало файл Result.tsv (/datalake/output/Result.tsv) по учетной записи AzureDataLakeStore. Result.tsv содержит все события веб-журналов для локализующего идентификатора «en-gb» с даты «2012/02/19». Кроме того, вы можете войти на портал управления и использовать Azure Data Lake Data Explorer для визуализации файла Result.tsv, сгенерированного на стадии обработки в ADL Store (вернитесь к рис. 4).

Подробную документацию по действию AzureDataLakeAnalyticsU-SQL в Azure Data Factory см. по ссылке bit.ly/1WWtxuy.

Сервис Data Factory предоставляет надежное, полное представление о хранении, обработке и перемещении данных.

Заключение

Следуя описанным шагам, вы сможете создать комплексный конвейер больших данных с помощью Azure Data Factory, который позволит перемещать данные в Azure Data Lake Store. Затем используйте скрипт U-SQL в сервисе Azure Data Lake Analytics для обработки веб-журналов. Полученная система будет динамически масштабироваться под ваши потребности, и ее можно расширить для выполнения на регулярной основе. Кроме того, вы можете выполнять дальнейшую обработку вывода и помещать его в другое серверное хранилище, чтобы результаты использовались Power BI или любым другим BI-приложением, применяемым в вашей организации. Более того, при желании можно задействовать командлеты ADF PowerShell, C# SDK и плагин Visual Studio для создания E2E-конвейеров больших данных с помощью ADL. Azure Data Lake совместно с Azure Data Factory исключает сложности, обычно связанные с большими данными в облаке, обеспечивая текущие и будущие потребности вашего бизнеса.

Гаурав Малхотра (Gaurav Malhotra) — менеджер программ в группе Azure Data Factory. Живет и работает в Редмонде (штат Вашингтон). С ним можно связаться по адресу gamal@microsoft.com.

Выражаю благодарность за рецензирование статьи экспертам Microsoft Омиду Афнану (Omid Afnan), Хариш Кумару (Harish Kumar) и Сачину Шету (Sachin Sheth).