Apache *

Привет! Меня зовут Саша Шутай, я тимлид в AGIMA. В прошлой статье я рассказывал, что делать, если на проекте Bitrix сожительствует с Vue.js и поисковые боты не видят контента сайта. А в этой помогу разобраться, как на Bitrix-проекте произвести интеграцию с брокером очередей Apache Kafka, почему этот вариант кажется мне более удобным, чем привычная система очередей в RabbitMQ, и как это можно подвязать на автотесты, не отправляя тестовые сообщения в продюсера.

Это важное событие для всех пользователей Apache Spark Structured Streaming. RocksDB теперь доступен как state store бэкенд, поддерживаемый ванильным Spark!

Как сделать из ненужного что-то нужное.

Как отмечено в статье Survey shows huge popularity spike for Apache Spark:

«Apache Spark - это Тейлор Свифт программного обеспечения в мире больших данных. Технология с открытым исходным кодом существует и популярна в течении нескольких лет. Но 2015 год стал важной вехой, когда Spark прошел путь от перспективной технологии до настоящей суперзвезды. 

Одна из причин, по которой Apache Spark стал таким популярным, заключается в том, что Spark предоставляет саентистам и инженерам данных мощный унифицированный движок, который является одновременно быстрым (в 100 раз быстрее, чем Apache Hadoop), так и простым в использовании. Это позволяет различным специалистам по данным решать разнообразные проблемы, например, задачи машинного обучения, вычисление графов, потоковая обработка и выполнение в режиме реального времени различных запросов в гораздо большем масштабе. 

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

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

Поймал как-то программист золотую рыбку, а она ему и говорит человеческим голосом: «Отпусти меня в синее море, я исполню любое твоё желание». Программист ЦПУшечкой поскрипел, да и выдал техзадание. «Построй мне», – говорит, – «систему обработки неидемпотентных запросов, да чтоб она была высокопроизводительной, масштабируемой, гибкой и отказоустойчивой!». Охнула сперва золотая рыбка, но взяла себя в плавники и молвила: «Не печалься, ступай себе домой, код написан, система развёрнута. Отпускай меня уже». Удивился программист: «Да ладно? Ну, сейчас проверю и отпущу». «Нет», – возражает рыбка – «пока ты проверяешь, я уж засохну, и всё волшебство исчезнет». Программист задумался: «Что же делать: сначала отпустить, а потом проверить, или сначала проверить, а потом сушёную рыбу к пиву получить?».

Мечты о золотой рыбке не раз посещали умы даже опытных разработчиков. В погоне за оптимальной системой обработки запросов многие отдают недели и месяцы своей жизни, а некоторые готовы отдать и душу, чтобы всё работало без сбоев.
Но нужны ли такие жертвы? Нет... Ведь у вас есть мегабыстрая Apache Kafka, супергибкий Python и возможности NoSQL баз данных. Все эти решения прекрасны по отдельности, но как из них собрать один конвейер для обработки данных, не растеряв их преимущества? Рассмотрим под катом.

Привет, Хабр! Мы команда мониторинга и анализа данных биотехнологической компании BIOCAD. Хотим рассказать вам о том, как мы собираем данные для аналитики из практически всех сервисов компании и при этом вполне успешно справляемся без полноценного дата-инженера.

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

Всем привет! Основным инструментом оркестрации задач для обработки данных в Леруа Мерлен является Apache Airflow, подробнее о нашем опыте работы с ним можно прочитать тут. А также мы находимся в постоянном поиске инструментов и фреймворков для упрощения работы наших дата сайентистов и дата инженеров. Один из таких инструментов – фреймворк Ray, который позволяет создавать ML пайплайны из DAGов Airflow. В статье от Astronomer подробно рассматривается, как начать его использовать и с его помощью быстро развернуть и обучить модель.

Развертывание Apache Spark в Kubernetes, вместо использования управляемых сервисов таких как AWS EMR, Azure Databricks или HDInsight, может быть обусловлено экономической эффективностью и переносимостью. Подробнее о миграции с AWS EMR в K8s вы можете прочитать в этой статье. 

Однако при уходе с управляемых сервисов возникает ряд проблем. И, вероятно, самая большая из них — потеря мониторинга и алертинга. Например, в AWS EMR есть действительно мощные встроенные инструменты мониторинга в виде CloudWatch, Ganglia, CloudTrail и YARN history server. В этой статье рассмотрим реализацию мониторинга для Apache Spark в Kubernetes с помощью Prometheus и Grafana.

О том как мы внедряли Apache Airflow для использования различными командами в нашей компании, какие задачи мы хотели решить этим сервисом. Внутри описание архитектуры деплоя и наш Infrastructure as Code (IaC).

DevOps-инженеры компании inDriver Радик Сейфуллин и Александр Плотников распилили старое монолитное приложение и создают новое, а Евгений Бутырин, технический редактор Слёрма, пообщался с ребятами об этом: опыте с Kafka, проблемах, решениях и обучении. 

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

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

Сделать свою собственную SQL-базу данных или запускать SQL-запросы в NoSQL-базе данных — кажется, это очень непростая задача.  А если мы говорим о распределенной БД, то сложность возрастает многократно. Но, к счастью, Apache Calcite — фреймворк с открытым кодом — поможет сделать это довольно легко.

Роман Кондаков, Software Engineer в Querify Labs, на конференции HighLoad++ Весна 2021 рассказал об опыте интеграции Apache Calcite в распределенную in-memory-платформу Apache Ignite. Если ваша система распределена, и вы хотите завести в ней SQL, читайте про то, как устроен Apache Calcite и какие есть нюансы его использования для распределенных систем.  Видео его выступления можно посмотреть здесь.

Единая биометрическая система (ЕБС) с 2018 года используется для идентификации человека по его биометрическим характеристикам: голосу и лицу.

Чтобы получать услуги по биометрии, пользователю необходимо зарегистрироваться в системе в одном из 13,1 тысяч отделений банков. Там операционист сделает его фотографию, запишет голос и отправит эти данные в систему. А для того чтобы компании могли оказывать по биометрии различные услуги, им необходимо провести интеграцию с ЕБС.

Оператором системы является «Ростелеком», а разработкой занимаемся мы – дочерняя компания РТЛабс .

Меня зовут Сергей Браун, я заместитель директора департамента цифровой идентичности в РТЛабс. Вместе с Артуром Душелюбовым, начальником отдела развития и разработки департамента цифровой идентичности, мы расскажем, как мы создавали платформу для любой биометрии, с какими проблемами встретились и как их решали.

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

Константин Еремин, старший системный администратор дежурной службы «Облачной платформы Selectel», рассказал, как поменять архитектуру облака на OpenStack и не поломать пользовательский опыт. На примере выдуманного провайдера Vanilla cloud solutions он объяснил, как определить масштаб проблемы. Почему, перебрав различные варианты, разработчики пришли к Apache Airflow? Какую схему использовали для реализации своих задач и что им удалось сделать с облачным сервисом с помощью выбранного инструмента? Рассказываем под катом. 

Введение

В данной статье я бы хотел рассмотреть проблему обновления PHP в виртуальной машине BitrixVM, и действия, которые возможно применить если выполнение переезда на машину с обновленным ПО невозможно. Надеюсь, что статья будет полезна для вас.

Предыстория

Несколько месяцев назад перед нами встала задача обновления PHP до версии 7.4 на одном из наших проектов. Проект был расположен внутри виртуальной машины с развернутой на ней BitrixVM версии 7.2.2. Заглянув в меню Битрикс при обращениях к скрипту /root/menu.sh было обнаружено, что обновление PHP не возможно без обновления Битрикс окружения. При этом само обновление окружения выполняется из бета репозиториев, так как текущая стабильная версия не поддерживала работу с PHP версии 7.4 согласно курсу:

https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=32&LESSON_ID=12862

Прошерстив форумы Битрикс, мы не нашли конкретного ответа, когда будет выполнено обновление BitrixVM до стабильной версии с поддержкой с PHP 7.4. В связи с чем, нами было принято решение обновить версию окружения до актуальной беты на одном из виртуальных серверов разработки, предварительно сделав snapshot.

Проблема BitrixVM в том, что это готовое решение, использующее Ansible скрипты для выполнения операций. При этом в случае нарушения работы скрипта операция будет прервана, а идентифицировать ошибку крайне сложно, как и понять на какой именно стадии она возникла.

BitrixVM хранит лог выполняемых задач по пути /opt/webdir/temp/, в ходе выполнения обновления окружения в логе возникали различные ошибки, вызывавшие нарушение процесса обновления. Поиск и решение подобных ошибок занимало достаточный период времени. Как пример, возникали ошибки подключения репозитория:

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

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

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

Я - студент университета, знаком с машинным обучением в рамках пройденного курса, есть интерес к современным кластерным технологиям, конкретно - к Apache Ignite. Под катом — история о том, как я запускал пример OneVsRestClassificationExample из дистрибутива.

Один из современных способов хранения большущего объема данных для платформ обработки и анализа данных - это распределение каждого датасета между несколькими узлами в кластере. Если мы используем облако, то весь датасет разделяется на множество объектов. Это может привести к появлению “слишком большого количества небольших файлов” что является хорошо известной проблемой в области Big Data. Формирование небольших файлов происходит по нескольким причинам, например, при сохранении входящих потоковых данных, сообщение за сообщением, при партиционировании по ключу с перекосом данных и т.д. Драйвер должен следить за изменениями метаданных всех файлов, чтобы планировать распределенную обработку данных при сохранении или чтении данных датасета используя Namenode, MapReduce или задачи Spark. Когда файлов слишком много, для хранения их метаданных требуется дополнительная память, а при их перечислении этих данных требуется гораздо больше времени на сетевое взаимодействие.

Во время работы в Datalake вы могли заметить, что при выполнении задачи Spark затрачивается слишком много времени на чтение датасета из s3/HDFS, где нужно подождать, даже чтобы увидеть запущенные экзекьюторы. Или вы могли заметить, что вашему Hive запросу может понадобиться несколько минут, чтобы инициировать задачи. Скорее всего, причина в том, что изначально драйвер большую часть времени тратит на просмотр всех метаданных файлов/объектов датасета в s3, особенно когда небольших файлов слишком много. Это связано с тем, что именно драйвер выполняет перечисление файлов в датасете, оценивает размер/партиции, а затем распределяет работу между экзекьюторами. Таким образом, слишком большое количество небольших файлов может привести к снижению производительности, а в худшем случае драйвер может поймать исключение из-за нехватки памяти.