#bigdata

Ниже ссылка на запись AWS re:invent Big Data Analytics Architectural Patterns and Best Practices. (Примеры архитектуры для кейсов Big Data и лучшие практики).
https://www.youtube.com/watch?v=ovPheIbY7U8
Любая система аналитики представляет собой следующую систему: Сырые данные -> Запись в область хранения -> Обработка-> Запись в область хранения -> Аналитика -> Инсайты

Согласно презентации, современные технологии, в частности AWS и его аналоги, позволяют нам для каждого элемента системы выбрать наиболее подходящую технологию. Выделяют следующие архитектурные принципы:
🙈Разделение системы – отдельно область хранения, отдельно вычислительные мощности
🙊Каждой задаче свой инструмент
🙉Максимально использовать managed или serverless сервисы, то есть сервисы, где нужна минимальная поддержка
🙊Храним все историю изменений и данных (озеро данных)
🙈Экономность – мы платим только за использование ресурса
🙉Машинное обучение – используем по возможности

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

Например, у меня сейчас есть задача, предоставить логи веб сервера маркетингу для аналитики. Вроде бы все просто, вот логи, и я могу взять один лог файл (access combined) и загрузить в Redshift. Время загрузки одного файла 1 минута. Но мне нужно загрузить 3 года данных, при этом за один день, у меня несколько тысяч файлов, то есть я только один день буду грузить несколько тысяч минут.

Поэтому мне необходимо воспользоваться системой класса Big Data, которая сможет быстро сделать эту работу. В данном случае это EMR (Hadoop)+Spark. Spark – задает логику для вычислительных мощностей Hadoop (EMR), а данные хранятся в S3 (файловое хранилище), то есть моя система разделена (хранение данных и вычислительные мощности). Это всего лишь один из вариантов решения задачи. Так же я могу использовать Redshift Spectrum и создать внешние таблицы поверх S3, или использовать serverless ETL AWS Glue, и загрузить и обработать файлы.

Выводов 3
1)Технологии так быстро развиваются, что мы не поспеваем за ними
2)Если у нас не получается решить задачу обычным способом с классическим ETL/DW, тогда мы можем смотреть в сторону Big Data решений
3)Cloud serverless and managed services are future for analytics.

Завтра в это же время будет супер ивент c data monsters. Будет 2 спикера:
- Irja Straus - расскажет на английском про Test Strategy in Data Driven World.

Затем я расскажу про 5 лет в Амазон (на русском)! Почти закончил презентацию, получилось интересно!

https://youtu.be/q5K-iUFg-kA

​​#Spark #Streaming #BigData #Structured

Spark Structured Streaming - это масштабируемый и отказоустойчивый механизм потоковой обработки данных на основе движка SparkSQL (см. официальную документацию Spark). Движок Spark SQL заботится о том, чтобы поток данных обрабатывался постепенно и непрерывно, обновляя конечный результат по мере поступления новых потоковых данных.

По итогу мы можем работать со стандартным инструментарием SQL-запросов через DataFrame API или операции Scala в DataSet API, чем Spark Structured отличается от Spark Streaming. Ключевая идея структурированной потоковой передачи состоит в том, чтобы обрабатывать поток данных в режиме реального времени как таблицу, которая постоянно обновляется - добавляются новые записи.

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

На вход Spark Structured Streaming принимает файлы или данные из Kafka. Вывод данных определяет то, что именно будет записано во внешнее хранилище. Существует несколько режимов в Spark Structured Streaming:

⚙️ Режим добавления: во внешнее хранилище будут записаны только новые строки, добавленные в таблицу результатов с момента последнего триггера. Это применимо только к запросам, в которых не предполагается изменение существующих строк в таблице результатов.

⚙️ Режим обновления: во внешнее хранилище будут записываться только те строки, которые были обновлены в таблице результатов с момента последнего триггера.

⚙️ Полный режим: вся обновленная таблица результатов будет записана во внешнее хранилище. Storage Connector должен решить, как обрабатывать запись всей таблицы.

Какие же основные достоинства у этого механизма по сравнению с обычным Spark Streaming?

📍Мы используем DataFrame/DataSet вместо RDD, что обеспечивает более высокий уровень абстракции и позволяет гибко манипулировать данными, включая поддержку всех этапов оптимизации SQL-запросов

📍Начиная со Spark 2.3, в Spark Structured Streaming вместо микропакетной обработки поддерживается непрерывная, которая работает с минимальной задержкой (до 1 миллисекунды), что существенно ускоряет обработку данных.

📍Повысилась надежность и отказоустойчивость за счет условий восстановления после любой (!) ошибки - например, через воспроизводимость источника данных в случае сбоя.

📍Обработка времени события - времени, когда событие действительно (вне Spark) произошло. Это позволяет повысить точность вычислений и обработать события, которые пришли в Spark с опозданием.

Таким образом, для полноценной отказоустойчивой потоковой обработки, на мой взгляд, лучше использовать Spark Structured Streaming.