✨swiftness

Усім привіт! Давно мене тут не було 🫶 За цей час сталося дуже багато всього! Головна зміна - я пішла з дата інжинірингу і увійшла у світ iOS-розробки. Щодо причин цього я якось розповім 👩‍💻 Тепер я створюю мобільні додатки. Та, звісно, не забуваю про свій минулий досвід і знання з роботи з даними. Ці зміни стосуються і мого каналу: 📱 Я писатиму контент з iOS, Swift, SwiftUI та інших фреймворків, закопуючись у технічні деталі. Мій досвід дата інжинірингу надасть цікавішу експертізу в iOS з точкі зору даних. 🇺🇦 Усі пости будуть українською мовою, але ви можете читати додатковий контент англійською в моєму іншому блозі в описі каналу. 🤝 Я також буду репостити ті пости, які я публікую в дружніх каналах. Як і раніше, я відкрита до співпраці 🤍 Для тих підписників, хто все ще цікавиться дата інжинірингом: - @datalearn_community - колись створений мною російськомовний чат для джунів залишається. - україномовний чат моїх друзів з корисними матеріалами, вакансіями та менторством. Якщо ви DE та вам цікаво дізнатися що робиться у інший індустріі - буду рада вам 🥰 А почну новий цикл постів з того що репостну статтю про дата сховища в iOS, яку я писала для дружнього каналу.

​​#Spark #BigData #Testing Вот и настал 2023! А вместе с ним появилось вдохновение снова писать посты. Напоминаю, что каждый из вас может поделиться своей экспертизой и стать автором поста в моем канале ✏️ Так что не стесняйтесь! Сегодня хотелось бы поговорить о тестировании Spark-приложений. Правильное использование тестов позволяет ускорить процесс разработки и дает уверенность в том, что ваш код будет корректно работать в прод-среде. Существует несколько подходов к тестированию приложений Spark, включая модульное тестирование (unit-тесты), интеграционное тестирование и тестирование производительности (performance-тесты). 📐 Использование unit-тестов подразумевает тестирование отдельных модулей или компонентов приложения изолированно от остального кода. Это можно сделать с помощью различных инструментов и библиотек, таких как ScalaTest, PyTest или JUnit. Целью модульного тестирования является проверка того, что каждый модуль приложения работает правильно сам по себе. Unit-тесты обычно ориентированы на небольшие автономные блоки кода, такие как отдельные функции или методы. Модульные тесты должны выполняться быстро и не должны иметь каких-либо внешних зависимостей, таких как база данных или сетевое подключение. 📐 Интеграционное тестирование включает в себя тестирование взаимодействия между различными компонентами приложения, чтобы убедиться, что они работают вместе должным образом. Это можно сделать, настроив тестовую среду, имитирующую прод, и запустив приложение в этой среде. Целью интеграционного тестирования является проверка того, что различные части приложения правильно интегрированы и корректно взаимодействуют при совместной работе. Интеграционные тесты обычно более сложны, чем unit-тесты, и могут включать настройку тестовых данных и фиктивных объектов для имитации среды, в которой будет выполняться приложение. 📐 Тестирование производительности подразумевает тестирование эффективности приложения, чтобы убедиться, что оно соответствует требуемым стандартам ресурсозатратности. Это можно сделать, запустив приложение с различными рабочими нагрузками и измерив различные показатели производительности, такие как время отклика, пропускная способность и использование ресурсов. Целью тестирования производительности является выявление и устранение любых узких мест или проблем, которые могут повлиять на эффективную работу приложения. Performance-тесты могут проводиться различными способами: ✂️ нагрузочное тестирование (подвергая приложение возрастающим уровням нагрузки, чтобы увидеть, как оно работает) ✂️ стресс-тестирование (подвергая приложение экстремальным уровням нагрузки, чтобы увидеть, как оно работает в экстремальных условиях) ✂️ тестирование масштабируемости (проверка того, как приложение работает при увеличении числа пользователей или рабочей нагрузки) Performance-тесты часто включают использование специализированных инструментов и могут потребовать запуска приложения в контролируемой среде. В идеале необходимо написать и поддерживать полный набор тестов для Spark-приложения, чтобы убедиться, что оно ведет себя корректно и эффективно работает в различных сценариях. Но учитывая, что культура тестирования Spark-приложений еще не сформировалась до конца, будет здорово, если вы просто начнете использовать тесты в своем рабочем процессе 🙌 Дополнительные полезные ресурсы: uTest spark-fast-tests chispa и testing PySpark testing Scala-Spark code 🔽 Напишите в комментариях или в чате, если хотите узнать подробнее про тесты для Spark-приложений, и я сделаю серию постов об этом.

https://youtu.be/dJvr3Lv7Ybk Есть и на ютубе 😊

Новый эпизод подкаста уже тут💃🎙 В этом выпуске junior data engineer, автор канала Girl DataEng и создатель чата для начинающих дата инженеров DataYoungers Анна Строевская рассказывает о: - проблемах курсов - необходимом background - mindmaps и способах работы над сложной задачей - а также о менторах и community для новичков #datacoffee #data #podcast #данные #подкаст https://anchor.fm/data-coffee/episodes/47-S2E5--------community-e1i5ubm

Друзья, всем привет. Знаю, что меня давно не было, но оттого очень благодарна, что вы не отписываетесь и ждете новых материалов от меня. Я это ценю 🤍 Однако пока постов нет, я стараюсь активно участвовать в различных мероприятиях ИТ-комьюнити. И сегодня я выступала на митапе от центра IT-развития СМАРТ, где рассказывала про Data Engineering для джунов. Про то, в чем в принципе заключается работа дата-инженера, как проходить собеседования, какие есть варианты развития; про софт и хард скиллы. Кому давно было интересно не только читать меня, но и послушать, прикладываю запись трансляции. Она лежит на ютуб-канале "Центр IT-развития Смарт". ✨Буду рада вашим комментариям и обратной связи! ✨ Многие из вас про них уже в курсе, но все равно поделюсь материалами, которые упомянула на митапе: - Книга «Automatize boring stuff with Python» от Al Sweigart (2019) - Курс Data Engineering от DataLearn - Курсы Stepik (SQL, BigData) - Sql-ex (тренажер) - Книга «Learning SQL» от Alan Beaulieu 2020

​​#Spark #BigData #Python #PySpark Наконец-то я вернулась! 🤍 Сегодня хочу поделиться с вами обзорной информацией про PySpark - интерфейс для Apache Spark в Python. Если вы еще не знакомы со Spark как технологией, можете почитать мой предыдущий пост. PySpark позволяет писать Spark-приложения с использованием API-интерфейсов Python и предоставляет оболочку для распределенной обработки больших данных. PySpark поддерживает большинство функций Spark, таких как Spark SQL, DataFrame, Streaming, MLlib (машинное обучение) и Spark Core. PySpark взаимодействует со Spark через специальную библиотеку Py4J. Через нее программы Python обращаются к объектам Java в JVM, транслируя код Scala. Чтобы обеспечить большую совместимость со Scala, PySpark поддерживает функциональную парадигму программирования, тем самым позволяя лучше распараллеливать код. 💡Таким образом PySpark позволяет проводить параллельную обработку без необходимости использования каких-либо модулей Python для потоковой или многопроцессорной обработки. Точкой входа для создания датафрейма Spark и использования функций SQL является SparkSession, в которой определяются параметры конфигурации (название приложения, кластерный менеджер, количество выделяемых ядер и памяти). При перехода с Python на PySpark необходимо преобразовать локальный датафрейм Pandas в Spark Dataframe через Apache Arrow. 💡В целом, тем, кто работает с Pandas, не так сложно будет разобраться с PySpark, так как оба используют датафреймы и имеют схожие методы. Но есть существенное различие - в режиме выполнения. PySpark реализует lazy execution (ленивое выполнение), в то время как Pandas – eager execution (мгновенное выполнение). PySpark сохраняет всю последовательность необходимых операций и выполняет их лишь в том случае, когда данные понадобятся. Что еще важно знать про PySpark? 📍Поддерживаются такие форматы данных, как CSV, JSON, ORC, Parquet. 📍PySpark может взаимодействовать с SQL и NoSQL базами данных. 📍В PySpark возможно создание пользовательской функции (UDF, User Defined Function), аналогичной функции Python. Но тут возникает и недостаток PySpark - происходит двойное преобразование данных между приложением и UDF, так как Python чуждый язык для JVM, на которой работает Spark, и UDF выполняется вне ее. Это сказывается на скорости работы UDF. 📍PySparkSQL служит для создания датафреймов и помимо встроенных функций и типов данных поддерживает: - GroupedData (агрегационные методы, аналог GroupBy) - DataFrameNaFunctions (методы обработки Nan значений) - DataFrameStatFunctions (методы для статистической обработки данных) Подводя итог, можно сказать, что PySpark - это отличная обертка для использования всего функционала Spark на Python, если вам ближе этот язык программирования. PySpark не так сложно изучить, если у вас уже есть бэкграунд с Pandas, что особенно полезно аналитикам данных, которые хотят освоить компетенции DE. Для простых и распространенных задач PySpark с учетом простоты синтаксиса Python является мощнейшим инструментом в руках любого специалиста по работе с данными. Тем не менее важно понимать указанные недостатки PySpark, особенно если вам требуется писать UDF. И если использование PySpark существенно сказывается на производительности, предпочтительнее все же выбирать Scala/Java для работы со Spark.

​​#Airflow #Executors #BigData Автор: Алексей Мелолян Предполагается, что вы знакомы с основами Apache Airflow, озвученными в посте, в ином случае настоятельно рекомендуем ознакомиться. Executor - механизм, посредством которого Apache Airflow запускает экземпляры задач (Task). В один момент времени Airflow может использовать только один вид Executor’a. Executor может быть стандартным или кастомным, конкретный вид Executor’a присваивается в файле airflow.cfg переменной executor. Список встроенных локальных Executor’ов: - Debug Executor - Local Executor - Sequential Executor Executor’ы, запускаемые удаленно: - Celery Executor - CeleryKubernetes Executor - Dask Executor - Kubernetes Executor Рассмотрим каждый из них: 📍Sequential Executor. Используется Airflow по умолчанию после установки, может запускать только одну задачу в один момент времени и, как следствие, совместим с SQLite. Подходит только для теста Airflow, для продакшена рекомендуется использовать другие виды Executor’ов. 📍Debug Executor. Аналог Sequential Executor, но используется соответственно для отладки DAG’ов. Позволяет запускать DAG’и из командной строки. 📍Local Executor. Единственный более-менее полноценный локальный Executor. Может запускать несколько задач одновременно, требует для работы полноценной БД (PostgreSQL, MySQL прости Господи). При низких нагрузках - неплохой вариант, однако, с ростом количества одновременно запущенных DAG’ов, начинает лагать. Также не позволяет перезапускать DAG с произвольного места при падении, для этого необходимы Executor’ы, запускаемые удаленно. 🧷Celery Executor. Работает с помощью Celery - асинхронной очереди задач, которая управляет воркерами - экземплярами сервиса, в данном случае Airflow, которые уже исполняют задачи. Для использования требует бэкенда в виде брокера сообщений, например, RabbitMQ или Redis. Данный Executor уже легко используется в продакшене, позволяет масштабировать работу Airflow на несколько машин, таким образом увеличивает устойчивость сервиса. 🧷Kubernetes Executor. Исходя из названия, работает с кластером k8s. Имеет смысл только если вы уже используете кластер k8s, позволяет эффективнее использовать ресурсы по сравнению с Celery, а за счет использования контейнеров разработка новых задач становится более гибкой. 🧷CeleryKubernetes Executor. Используется, когда необходимо иметь как распределенную высокую нагрузку, управляемую Celery, так и изолированные среды, создаваемые k8s. 🧷Dask Executor. Используется на кластерах Dask - библиотеки Python для параллельных вычислений. Используется мало, очереди не поддерживает. tl;dr: Сразу после установки переключайтесь на Local Executor, подключайте БД. Если количество DAG’ов растет - поднимайте брокер сообщений и переключайтесь на Celery Executor. Поднимаете Airflow на кластере k8s - Kubernetes Executor ваш выбор. Полезные ссылки: https://airflow.apache.org/docs/apache-airflow/stable/index.html - документация Airflow https://www.bigdataschool.ru/news/airflow - статьи по Airflow на русском @ruairflow - русское комьюнити Airflow

​​Всем привет! Я приболела, а потому посты выходят реже, чем мне бы хотелось. Но сейчас речь не об этом. У нас тут сложилась определенная аудитория, а потому я решила давать возможность другим начинающим специалистам проявить свою экспертность. Сегодня будет пост от одного из них - Алексея, в прошлом бэкендера, а сейчас - начинающего дата инженера, уже имеющего опыт в работе с определенными технологиями. Именно своими знаниями он и будет делиться. А потому запасайтесь свободным временем! Если среди вас есть еще желающие проявить себя и поделиться с аудиторией интересной информацией о мире биг даты - велком в мою личку.

​​Привет всем новеньким 👋 Для вашего удобства закрепляю пост с самыми главными хэштегами на канале: #SQL - хэштег с постами, посвященными SQL. Теория, функции, все-все, что мне кажется интересным и важным для запоминания. #Python - посты по питону. #Linux - полезные команды и bash. #BigData - инструменты биг даты, теория. Здесь много хэштегов внутри, можете искать по названиям технологий. Также планируется хэштег #Scala для постов от моей внутренней скалистки. И добро пожаловать! Буду рада любым комментариям и замечаниям. Спасибо, что вы со мной 💛

​​#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.

​​#AWS #Cloud #BigData #Не_техническое Всем хорошего воскресенья, друзья! Завтра вас ждет обещанный мной пост про Spark Structured Streaming. А сейчас мне хотелось бы поделиться забавной историей, которая случилась на заре моего джунства. Начитавшись канал Инжиниринг Данных, я решила изучить AWS. Для тех, кто не знает, это Amazon Web Services - лидер на рынке облачных вычислений. Недолго думая, я взяла пробный период и привязала свою карту, понимая, что перед окончанием пробного периода я ее отвяжу. После изучения тарифов (за запросы, память и пр.), интерфейса и возможностей деплоя, я как-то подзабила и вернулась к более популярным в России технологиям. Для тех, опять же, кто не в курсе, в России, в отличие от всего остального мира, очень мало компаний пользуется облаками. Связано это с законом о персональных данных. Так что на тот момент знания AWS мне показались избыточными. Однако каково же было мое удивление, когда на почту стали приходить чеки на оплату AWS с хоть и небольшими, но существенными для меня суммами в долларах. Запаниковав, я зашла в консоль AWS и попыталась разобраться, что произошло. Меня встретила задолженность в размере 16 долларов за уже прошедший месяц (т.е., не оплатить ее я не могла, т.к. она была за уже использованный ресурс). В панике побежав отвязывать карту, я увидела, что на Амазоне этой возможности нет. Натурально, привязав карту единожды, ты навечно попадаешь в кабалу лично Джеффу Безосу. Причем, не понимая, за какие конкретно услуги деньги списались, я могла обречь себя на ежемесячное списание средств. Однако острый ум инженера пришел мне на помощь. Оказалось, что хоть удалить карту нельзя, но вот заменить карту на нерабочую очень просто. Таким образом, обнаружив брешь в хитрой системе Амазона, я смогла спасти себя от финансового рабства. Так что, джуны, когда вам говорят, что войти в IT легко, помните, что на пути вас может ожидать очень много опасностей... p.s. к слову, тот платеж у меня все-таки списался, но в размере 16 рублей, хотя в AWS сумма явно указывалась в долларах. Магия да и только. p.p.s. ситуация так меня шокировала, что мне еще некоторое время снилось, как злополучные 16 долларов уходят с моего счета прямиком в Пало-Альто.

​​#Airflow #BigData #ETL Apache Airflow - инструмент, чтобы удобно и быстро разрабатывать и поддерживать batch-процессы обработки данных (прим. Хабр). Это набор библиотек для разработки, планирования и мониторинга рабочих процессов. Базируется на языке Python, а потому любой выполняемый ETL - это Python-проект, который можно организовать наиболее удобным для вас способом. Основные сущности рабочего процесса Airflow: ✔️ Направленные ациклические графы (DAG) ✔️ Планировщик (Scheduler) ✔️ Операторы (Operators) ✔️ Задачи (Tasks) ⛓ DAG: файл конфигурации, описывающий набор задач, которые необходимо выполнить в строго определенной последовательности по определенному расписанию. Он задается функцией или декоратором. Разработчик, проектируя DAG, закладывает набор операторов, на которых будут построены задачи внутри DAG’а. ⚙️ Операторы: это сущность, на основании которой создаются экземпляры заданий, где описывается, что будет происходить во время исполнения каждого экземпляра задания. Иными словами, это шаблон для предопределенной задачи, которая декларативно задается внутри DAG-а. По умолчанию их существует несколько: - BashOperator: для выполнения bash-скрипта - PythonOperator: для выполнения python-скрипта - EmailOperator: для отправки email-а - HTTPOperator: для работы с http-запросами - SqlOperator: для выполнения SQL-кода И некоторые другие операторы. Задача/оператор обычно не существует в единичном виде; он может зависить от других задач (тех, что выше него), а другие задачи зависят от него (тех, что ниже). Объявление этих зависимостей между задачами и составляет структуру DAG (ребра направленного ациклического графа). ⏰ Планировщик: построен на Celery (Python-библиотека, позволяющая организовать очередь, а также асинхронное и распределенное исполнение задач). Планировщик Airflow отслеживает все задачи и DAG, а затем запускает экземпляры задач после завершения их зависимостей. За кулисами планировщик запускает подпроцесс, который отслеживает и синхронизирует все DAG-и в указанном каталоге DAGs. По умолчанию один раз в минуту планировщик собирает результаты синтаксического анализа DAG и проверяет, можно ли запустить какие-либо активные задачи. Планировщик использует настроенный Executor для запуска готовых задач. 📝 Задачи: со стороны Airflow все задачи делятся на пулы. Пулы создаются вручную. Как правило, их цель — ограничить нагрузку на работу с источником или типизировать задачи внутри DWH. Пул, заданный на уровне DAG-а, можно переопределить на уровне задачи. Прежде чем попасть на исполнение, задача проходит следующие этапы: - В DAG-е выполнены все предыдущие задачи, так что можно поставить новую на очередь - Очередь сортируется в зависимости от приоритета задач (приоритетами тоже можно управлять), и, если в пуле есть свободный слот, задачу можно взять в работу - Если есть свободный worker celery, задача направляется в него Мы поговорили про основные сущности Airflow, но на этом тема себя не исчерпала. Думаю, я создам цикл постов, посвященных этому инструменту, чтобы лучше закрепить преимущества его использования.

​​#Spark #Streaming #BigData Раз уж заговорили о Spark, время поговорить и о Spark Streaming. Как написано в официальной документации и на Хабре: Spark Streaming — это расширение Core Apache Spark для масштабируемой, высокопроизводительной и устойчивой к сбоям обработки потоков данных в режиме реального времени. Эта библиотека оперирует с дискретизированным потоком DStream, предлагающим API для отказоустойчивой структуры RDD - базовой абстракции в Spark, представляющей собой неизменяемую секцеонированную коллекцию JVM-объектов, с которыми можно работать параллельно. RDD работает со структурированными и неструктурированными данными и включает в себя такие функциональные операции, как filter и map. Несмотря на то, что Spark Streaming используется как инструмент для потоковой обработки, по факту он реализует микропакетный подход, интерпретируя поток данных как непрерывную последовательность небольших пакетов информации через регулярные интервалы времени. Эти интервалы времени называются интервалами пакетной обработки (batch interval). Пользователь задает batch interval, в ходе которого необработанные данные собираются в набор RDD. По окончанию интервала создается новый набор RDD, содержащий данные из предыдущего набора. Таким образом обеспечивается своего рода потоковая обработка. Непрерывный набор RDD собирается в DStream. В течение заданного интервала DStream выдает по одному пакету RDD, который обрабатывается Spark Streaming. Spark опрашивает источник с периодичностью, заданной длительностью пакета в конкретном приложении, а затем создает пакет из полученных данных. DStreams и RDD отказоустойчивые. Пока доступна копия входных данных, Spark может повторно вычислить любое состояние из них, используя наследование RDD (сохранение информации о "родителе"). По умолчанию данные реплицируются на двух узлах. В результате Spark Streaming может выдерживать сбои отдельных рабочих процессов. Spark Streaming включает в себя статистическую и динамическую часть: 📍Статическая часть определяет источник данных, способ их обработки и то, куда отправляются данные. 📍Динамическая часть запускает приложение на неопределенный срок, ожидая сигнал об остановке. Обработка данных начинается только после запуска приложения. Обычно приложение создается локально в JAR-файл и затем развертывается на кластере. В рамках своей работы я использую Spark Structured Streaming - его фундаментальное отличие в том, что он работает с датафреймами, в то время как Spark Streaming поддерживает только RDD. Хотите отдельный пост про это?

​​#Spark #BigData Еще кое-что, без чего я с трудом представляю себе биг дату - это Apache Spark. Мне нравится такое определение: Apache Spark - платформа параллельной обработки данных для исполнения крупномасштабных аналитических приложений на кластерах. Спарк может обрабатывать как пакетные данные (batch), так и данные в реальном времени (stream). Spark Core, центр проекта, который обеспечивает распределенную передачу задач, планирование и функциональность ввода-вывода, предоставляет разработчикам потенциально более быструю и гибкую альтернативу MapReduce - фреймворка, к которому были привязаны ранние версии Hadoop. Разработчики Spark говорят, что он может выполнять таски в 100 раз быстрее, чем MapReduce при обработке в памяти, и в 10 раз быстрее на диске. Apache Spark может обрабатывать данные из различных хранилищ данных, включая HDFS, базы данных NoSQL и реляционные хранилища данных, такие как Apache Hive. Spark поддерживает обработку в памяти для повышения производительности приложений аналитики больших данных, но он также может выполнять обычную обработку на диске, когда наборы данных слишком велики, чтобы поместиться в доступную системную память. Spark состоит из нескольких элементов: 📍Spark SQL - для выполнения операций с данными, таких как традиционные задания SQL в RDBMS. Spark SQL предлагает API и SQL для управления данными. 📍Spark Streaming и, в частности, Spark Structured Streaming для анализа потоковых данных. Унифицированный API Spark поможет обрабатывать данные аналогичным образом, независимо от того, являются ли они потоковыми или пакетными. 📍Spark MLlib для машинного обучения и расширений в глубоком обучении. 📍GraphX для использования графовых структур данных. Spark - это отличный инструмент для дата инженеров, который можно использовать на всех этапах стандартного сценария работы с биг датой: 1) Загрузка данных (ingestion) - бронзовый слой данных (raw data) 2) Повышение качества данных (DQ) - серебряный слой данных (pure data) 3) Трансформация - золотой слой данных (rich data) 4) Публикация - загрузка данных в хранилище, использование BI-инструментов, вызов API или сохранение данных в файле. Со Спарком можно работать на Java, Scala и Python (PySpark).

#HDFS #BigData HDFS - объектное хранилище и распределенная файловая система, входящая в экосистему Hadoop. Характеризуется тем, что данные хранятся в исходном виде, без схем и типов данных, только сырой файл (объект) и путь до него. Это помогает избежать некоторых недостатков, которыми обладают структурированные хранилища. Распределенная файловая система - это файловая система, которая может поддерживаться несколькими компьютерами, что отличает ее от локальной ФС. Данные в ней объединены одним сервисом, который отвечает за разыменование пути к необходимому файлу. Архитектура HDFS выглядит следующим образом: ☎️ NameNode (Master) - главная нода, которая выполняет операции по обслуживанию namespace (открытие, закрытие, переименование файлов и директориев), выдает доступы на файлы и директории, определяет маппинг блоков данных на DataNodes. Хранит метадату файловой системы. ☎️ DataNodes (Slave) - отвечают за чтение и запись запросов от клиентов, создают, удаляют и реплицирую блоки данных под управлением NameNode. Хранят данные в блоках в локальной файловой системе. 📕Для чтения данных в HDFS клиент обращается прежде всего к NameNode, чтобы получить данные о местоположении блоков. Затем, зная конкретный блок, в котором расположены нужные данные, обращается к DataNode с этим блоком. 📝Чтобы произвести запись в HDFS, клиент создает запрос в NameNode. После этого отправляется пакет записи на DataNode и совершается репликация записи на другие ноды (по дефолту репликация совершается на трех нодах, можно увеличить или уменьшить количество). После этого ноды, на которых совершалась репликация, отправляют пакет подтверждения, и он с первоначальной DataNode отправляется назад, чтобы произошло завершение процесса на NameNode. 🖇 Структура хранения NameNode: - информация о версии HDFS - журнал изменений - контрольная точка метаданных (последний маппинг блогов и свойства файлов, чтобы очистить журнал изменений и в случае чего восстановить данные) - время создания контрольной точки 🖇 Структура хранения DataNode: хранятся блоки данных. Ничего не знают о HDFS файлах, хранят каждый блок данных в разных файлах. Не хранят все в одной папке. На основе определенных эвристик определяется необходимое количество файлов для оптимизации производительности поиска по файловой системе. 📍Репликация: NameNode периодически собирает HearBeat (информацию о состоянии) и blockreport (список всех блоков со всех DataNode) с каждой DataNode. Минимальный блок репликации - 1, максимальный - 512. По дефолту, как уже было упомянуто, репликация совершается на трех нодах. Может ли быть вторая NameNode❓ Да, и ее роль - получить от первой журнал изменений и контрольную точку метаданных, слить их в один файл и вернуть на первичный узел, где этот файл заменяет контрольную точку метаданных первой NameNode. Это позволяет снизить нагрузку на первичный узел, а также сохранить эту важную информацию, если диск первой NameNode сгорит. Но может быть и несколько полноценных NameNode, которые будут находиться в неактивном режиме все время, пока первая работает. Переключение между ними осуществляется с помощью ZooKeeper. С помощью этого обеспечивается постоянная доступность HDFS для клиента.

​​А вот и снова я! Решила в новом году походить по собесам, чтобы проверить свои скиллы и обозначить новую финансовую границу для себя, а это значит, что пора снова готовиться к тех.интервью. Сегодня поговорим про data processing и стэк, который для этого используется. Data processing/Обработка данных - процесс сбора и манипулирования данными для получения необходимой информации. Он включает в себя преобразование необработанных данных в машиночитаемую форму, поток данных через CPU и память в устройства вывода, форматирование и преобразование аутпута. В мире биг даты существуют пакетная (batch) и поточная (streaming) обработка данных. Их различие фундаментально: в рамках пакетной обработки данные собираются в пакеты с течением времени и затем передаются в аналитическую систему, а в рамках стриминговой модели данные передаются инструментам аналитики по частям в режиме реального времени. Остановимся на этом подробнее. Batch чаще всего используется, когда мы имеем дело с очень большими объемами данных и/или когда источниками данных являются устаревшие системы, не способные в стриминговую обработку. Пример: данные, сгенерированные на мейнфреймах, так как доступ к ним и их интеграция в современные аналитические среды требуют большого количества времени, что делает стриминг невозможным. Пакетная обработка хорошо работает в ситуациях, когда не нужны результаты аналитики в реальном времени, и когда обработка больших объемов информации важнее, чем получение быстрых результатов аналитики (хотя стриминг также отлично работает с биг датой). Тем не менее, у нее есть свои челленджи: затруднение дебаггинга (требуются особые специалисты) и затраты на обучение и программное обеспечение. Потоковая же обработка является ключевым фактором, если необходимо получать результаты аналитики в режиме реального времени. Создавая потоки данных, возможно передавать данные в инструменты аналитики сразу после их создания и получать почти мгновенные аналитические результаты с помощью таких платформ, как Spark Streaming. У потоковой обработки также есть свои челленджи: проблемы со скоростью инпута и аутпута, огромный объем данных и немедленное реагирование на них. #Batch #Streaming #DataProcessing

​​#Python #String В Python есть встроенные методы для строки - последовательности односимвольных строк. Эти методы возвращают каждый раз новое значение, не меняя исходную строку. Python String Methods: count() - возвращает число раз, когда указанное значение встречается в последовательности encode() - кодирует строку в байты endswith() - возвращает значение true, если последовательность заканчивается указанным значением find() - поиск указанного значения в последовательность и возврат положения, в котором оно было найдено format() и format_map() - форматирует заданную строку и возвращает ее. Разница между ними в том, что format() создает при этом новый словарь значений, а format_map() нет. index() - ищет указанное значение и возвращает его позицию в строке join() - возвращает строку, собранную из элементов указанного объекта, поддерживающего итерирование. partition() - возвращает кортеж, в котором строка разделена на три части replace() - возвращает последовательность, в которой указанное значение заменяется другим указанным значением split() - разделяет последовательность в указанном разделителе и возвращает список strip() - возвращает усеченную версию строки title() - преобразует первый символ каждого слова в верхний регистр translate() - осуществляет пакетную замену символов данной строки, используя указанную таблицу замены zfill() - заполняет строку указанным числом значений 0, начиная со старта строки Это далеко не все встроенные методы, которые существуют для строки. Я не упоминаю такие очевидные, как lower(), upper() и многие другие, имеющие дело с регистром и сокращением строки. Перечисленные методы кажутся мне самыми интересными. Но если вы считаете, что какому-то методу незаслуженно не уделили внимание, напишите в комментариях 📝 Есть ли что-то, что вам особенно интересно в работе со строкой?

​​#Python #List Как уже было сказано, list - это изменяемая и упорядоченная коллекция из объектов произвольных типов. Сейчас мы освежим в памяти встроенные методы, позволяющие нам работать с этим типом данных: Python List Methods: append() - добавляет элемент в конец листа clear() - убирает все элементы из листа copy() - возвращение копии листа count() - возвращает число элементов с указанным значением extend() - добавляет несколько элементов в конец листа index() - возвращение индекса первого элемента с указанным значением insert() - добавляет элемент на указанную позицию в листе pop() - убирает элемент указанной позиции в листе remove() - удаление первого элемента с указанным значением reverse() - изменение порядка списка на противоположный sort() - сортирует лист Повторим теорию: 1) Элементы листа упорядочены и допускают повторяющиеся значения (!) 2) Проиндексированы, начиная с 0 3) Если добавляется новый элемент в список, он будет помещен в конец списка (при условии, что мы не используем insert()) 4) Список изменяем - и потому мы можем изменять содержание списка уже после того, как он создан Поговорим и про методы других типов данных в Python. Информация общеизвестная, но хочется всегда иметь ее под рукой, если вдруг что-то вылетит из головы 😌

#SQL #Представления Представления (views) - это виртуальные таблицы, содержание которых определяется запросом. Как и таблица, представление состоит из набора именованных столбцов и строк. Если представление не проиндексировано, оно не существует как сохраненный набор данных в БД. Строки и столбцы берутся из таблицы, к которой адресуется запрос, и создаются динамически при обращении к представлению. Представление работает как фильтр для существующих таблиц. Запрос, определяющий представление, может быть адресован к одной или нескольким таблицам, а также к существующим представлениям, в текущей или других БД. Также можно использовать запросы, адресуемые к разным источникам данных, например, если мы хотим объединить данные с одинаковой структурой с разных серверов. Преставления обычно используются для упрощения восприятия БД каждым пользователям. При этом они занимают меньше места, т.к. не хранят данные в физическим виде (не считая материализованных представлений). 🖍 Материализованные представления - это индексированные представления, сохраненные в новой таблице. Индексируя представление, мы создаем для него уникальный кластерный индекс (подробнее - в другом посте). Материализованные представления отлично подходят для повышения производительности запросов, которые объединяют много строк, но плохо подходят для базовых наборов данных, которые часто обновляются. Функции: CREATE VIEW AS SELECT CREATE OR REPLACE VIEW AS SELECT DROP VIEW Материализованное представление в PostgreSQL: CREATE MATERIALIZED VIEW [IF NOT EXISTS] name_table [(name_column, ...)] WITH (параметр хранения = [значение]) TABLESPACE (табличное пространство, в котором будет создано представление) (default_tablespace) AS запрос WITH [NO] DATA (будет ли наполняться в момент создания)