Введение

Часто перед дата-инженерами ставится задача по миграции данных из какого-либо источника или системы в целевое хранилище. Для этого существует множество различных инструментов. Если говорить про платформу Big Data, то чаще всего у разработчиков на слуху Apache NiFi или ETL-задачи, написанные на Spark, ввиду универсальности этих инструментов. Но давайте предположим, что нам необходимо провести миграцию данных из РСУБД в Hadoop. Для подобного рода задач существует очень недооцененный пакетный ETL-инструмент – Apache Sqoop. Его особенность в следующем:

• Облегчает работу разработчиков, предоставляя интерфейс командной строки. Для работы с этим инструментом достаточно заполнить основную информацию: источник, место назначения и детали аутентификации базы данных;
• Автоматизирует большую часть процесса;
• Использует инфраструктуру MapReduce для импорта и экспорта данных, что обеспечивает параллельный механизм и отказоустойчивость;
• Для работы с этим инструментом требуется иметь базовые знания компьютерной технологии и терминологии, опыт работы с СУБД, с интерфейсами командной строки (например bash), а также знать, что такое Hadoop и обладать знаниями по его эксплуатации;
• Относительно простая установка и настройка инструмента на кластере.

Kafka нельзя назвать новым продуктом на рынке ПО. Прошло примерно 10 лет с того времени, как компания разработчик LinkedIn выпустила его в свет. И хотя к тому времени на рынке уже были продукты со схожей функциональностью, но открытый код и широкая поддержка экспертного сообщества прежде всего в лице Apache Incubator позволила ему быстро встать на ноги, а впоследствии составить серьезную конкуренцию альтернативным решениям.

Традиционно Kafka рассматривался как набор сервисов для приема и передачи данных, позволяющий накапливать, хранить и отдавать данные с крайне низкой задержкой и высокой пропускной способностью. Этакий надежный и быстрый (да и в общем-то наиболее популярный на данный момент) брокер сообщений по этой причине весьма востребован во множестве ETL процессов. Преимущества и возможности Kafka многократно обсуждались, в том числе и на Хабре. К тому же, статей на данную тематику весьма много на просторах интернета. Не будем повторять здесь достоинства Kafk-и, достаточно посмотреть на список организаций, выбравших этот продукт  базовым инструментом для технических решений. Обратимся к официальному сайту, согласно которому на данный момент Kafka используется тысячами компаний, в том числе более 60% компаний из списка Fortune 100. Среди них Box, Goldman Sachs, Target, Cisco, Intuit и другие [1].

На сегодняшний день Apache Kafkaне без оснований часто признается лучшим продуктом на рынке систем по передаче данных. Но Kafka не только интересен в качестве брокера сообщений. Огромный интерес он представляет и в силу того, что на его основе возникли и развиваются многие специфические программные продукты, которые позволяют Kafka существенным образом расширить возможности. А это свою очередь позволяет ему уверено продвигаться в новые области ИT рынка.

Oracle Apex – компонент для разработки конечных приложений, входящий в состав поставки СУБД Oracle, позволяющий быстро «доставать» данные из базы и доставлять их через веб-интерфейс конечному пользователю. Как правило, данные для просмотра и редактирования выдаются в табличном виде и Apex предоставляет богатые возможности для настраивания отчета: можно накладывать фильтры, делать сортировку и группировку, скрывать имеющиеся столбцы и добавлять расчетные новые, делать сводные отчеты, выгружать данные в формате csv, pdf и даже Excel. Каждый пользователь может сохранить предпочитаемые им настройки каждого отчета как индивидуально, так и для совместного использования. В таком формате Apex функционирует у большинства наших заказчиков.

Однако мало кто использует довольно широкие возможности Apex’а для построения графиков. Эта тема, на наш взгляд, довольно интересна и мало освещена в интернете.

В этой статье будем предполагать, что читатель имеет представление о разработке приложений с помощью Oracle Apex.

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

В статье будет рассмотрен процесс экспорта данных в Hadoop из различных РСУБД посредством фреймворка Spark. Для взаимодействия с фреймворком Spark будет использован язык программирования Python с применением api pySpark.

• Заполни заявку на сайте;
• Получи подтверждение от рекрутера;
• Пройди техническое собеседование;
• Прими оффер в течение 48 часов и получи welcome-бонус!

Lightbend Cloudflow - open-source фреймворк для построения конвейеров потоковой обработки данных, объединивший в себе тройку популярных сред: Akka, Flink и Spark.

Под катом: demo-проект и обзор фреймворка с точки зрения общей концепции и разработки.

Apache Spark – фреймворк для обработки больших данных, который давно уже стал одним из самых популярных и часто встречаемых во всевозможных проектах, связанных с Big Data. Он удачно сочетает в себе скорость работы и простоту выражения своих мыслей разработчиком.

Разработчик работает с данными на достаточно высоком уровне и, кажется, что нет ничего сложного в том, чтобы, например, соединить два набора данных, написав всего одну строку кода. Но только задумайтесь: что происходит в кластере при соединении двух наборов данных, которые могут и не находится целиком на каком-либо из узлов кластера? Обычно Spark со всем справляется быстро, но иногда, а особенно, если данных действительно много, необходимо все-таки понимать – что происходит уровнем ниже и использовать это знание, чтобы помочь Spark работать в полную силу.

1. Загрузить таблицу из Oracle;
2. Посчитать в ней сумму по какого-нибудь полю, сгруппировав по ключу;
3. Результат сохранить в витрину в Hive.

• Oracle
• Apache Sqoop
• Oozie
• Apache Spark
• Hive

• SH управляющие файлы;
• Sqoop скрипты;
• набор Airflow Dag или Oozie Workflow;
• SQL скрипты собственно преобразований;
• Исходники на PySpark или Scala Spark;
• DDL скрипты создания объектов.

Привет! В этой статье мы рассмотрим важнейший аспект практически любого потокового приложения – работу со стейтом. Сегодня в роли подопытного выступит фреймворк Apache Flink.

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

Небольшой дисклеймер

Подавляющая часть информации, представленной в этой статье, справедлива для всех релизов Apache Flink, начиная с версии 1.8. В версии 1.13 (последняя на момент выхода этой статьи) произошли небольшие правки API, которые в некоторой мере изменили видимую пользователю «оболочку» хранения стейта, но общие принципы остались прежними. Подробнее об этом можно прочитать здесь.

Если вы только начинаете знакомство с Apache Flink, то рекомендую посмотреть наш YouTube-митап по основам этого замечательного фреймворка.

В одном из исследовательских проектов нам с коллегами пришла идея совместить Akka Stream, Akka event sourcing (typed persistence) и Akka cluster sharding для реализации stateful stream processing. На мой взгляд, получилось достаточно интересное и лаконично решение, которым я бы и хотел с вами поделиться.

Привет! Сегодня мы поговорим и попробуем на практике реализацию паттерна Change Data Capture (далее – CDC) в Apache Flink. 

Статья разделена на несколько частей: в первой мы рассмотрим теоретические основы Change Data Capture, варианты реализации и сферы применения. Во второй – обратимся к особенностям CDC-коннекторов экосистемы Apache Flink, а также выделим самые интересные фичи (а заодно и немного расскажем об Apache Flink для тех, кто раньше с ним не сталкивался). В третьей части – перейдем к практике, закатаем рукава и реализуем несложный сценарий захвата изменений из WAL PostgreSQL, приправленный объединениями, агрегацией, стеком ELK и целым кластером Flink, правда в миниатюре.

• Масштабируемость. Предложенные методы способны использовать агрегированные данные (например, записи Netflow), что делает возможным использование в сколь угодно сложных и высоконагруженных сетях.
• Чувствительность к изменениям распределений характеристик трафика. Энтропийный подход помогает среагировать на аномалию, и в тех случаях, когда такие классические характеристики трафика, как packets rate (rps) не обнаруживают значимого аномального поведения (т.о., способен выявлять атаки с низким относительным packets rate).
• Легкость реализации и доступная интерпретация. Быстрая готовность к работе, отсутствие необходимости в данных для обучения и способность находить атаки zero-day.

Сетевые потоки

Что такое AWS Control Tower?

{source: "app1", error_code: ""}

{source: "app1", error_code: "error", description: "Network error"}