Или: как корпоративный софт вынудил меня написать своё приложение

Представьте картину. Понедельник, 10:00. В календаре — ежеквартальный all-hands на час. CEO заходит в Teams с видом человека, которому есть что сказать. Первые пять минут — действительно интересно. Потом начинается.

«Наша миссия — создавать ценность для клиентов, двигаясь вперёд как единая команда к амбициозным целям следующего квартала, опираясь на наши ключевые компетенции и синергию между подразделениями...»

Вы смотрите в экран. Потом в окно. Потом снова в экран. Мозг предательски начинает думать о том, что бы поесть на обед и не пора бы поставить кофе.

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

Ранее я уже делился опытом, как мой приятель искал работу в Германии в 2025 году (см. статью [Личный опыт] Поиск работы в Германии в середине 2025). И вот теперь уже нашей компании самой пришлось искать Middle Data Engineer в команду на замену увольняющемуся сотруднику, что позволило мне взглянуть на процесс с другой стороны баррикад, так как я выполнял в этом найме роль основного технического эксперта. Как это выглядит со стороны работодателя, а также своими наблюдениями я хочу поделиться в данной статье.

Спойлер - от результата (кого в итоге мы наняли) я выпал в осадок %)

Всем привет!

Сейчас много пишут о проблемах с поиском работы в ИТ‑отрасли и массовых увольнениях/«оптимизациях» персонала, в том числе якобы из‑за внедрения ИИ. Однако если открыть LinkedIn, складывается несколько иное впечатление — вакансий, конечно, не «пруд пруди», но и на «зимнюю спячку» это совсем не похоже. По крайней мере, на первый взгляд.

Совсем недавно мой друг искал работу в Германии. Сам он говорит, что «чукча — не писатель», поэтому с его позволения я решил поделиться с сообществом его наблюдениями и выводами по результатам данного «погружения в рынок». Тем более, что был непосредственным свидетелем данного поиска, и мы часто обсуждали его за чашкой кофе или бокалом пива:‑) На объективную оценку ситуации не претендую (или «не претендуем»?), но, наверняка есть немало коллег, которым эта информация может показаться полезной/интересной. Данная статья является компиляцией того, чем делился со мной он и моими собственными вставками и наблюдениями.

Написать меня эту статью-мнение сподвигла все неутехающая волна хайпа вокруг ИИ (он же AI, он же Исскуственный Интеллект) и огромное число статей, видео и прочего контента на эту тему, который все равно прорывается в мое "инфо-пространство", хотя я прилагаю немало усилий, чтобы беречь его от проявлений любой крайности. Последними каплями стал разговор с хорошим другом-высококлассным ИТ'ником, который делился со мною апокалиптическими сценариями и мыслями о том, "какую рабочую профессию хорошо бы нам, программистам, освоить уже сейчас, чтобы через несколько лет суметь заработать на себе на хлеб?" (предложил ему освоить пчеловодство или переехать в Германию, где до сих пор компании отправлют бумажных писем больше, чем электронных :-)) , и пост в одном популярном канале по Дата-инженерии, где автор канала тащиться от вайб-кодинга и удивляется, что "есть еще люди, которые не верят, что ИИ через два года будет ..." - и далее по списку. Ну а про то, что количество "ура-статей" тут, на хабре, зашкаливает (хотя попадаются и скептические) вообще молчу...

Это мой вольный перевод статьи "Data Engineering is Not Software Engineering", с рядом моих правок, дополнений, а так же сокращений (так как автор склонен повторять одно и то же, но иными словами или излишне "разжевывать" очевидные вещи). Мне кажется, автор действительно поднял очень важную тему, которую я "чувствовал" по своей практике, но не мог сформулировать так точно, как это сделал он.

Мало кто задумывается, что дата-инженерия и разработка ПО имеют значительные различия. Поэтому распространено мнение, что некое отставание дата-инженерии в части внедрения современных методов разработки, таких как Agile, Test Driving Development и т.д. обусловлено лишь отставанием в освоении этих передовых практик.

На самом деле этот взгляд ошибочен. Хотя дата-инженерия и разработка ПО действительно имеют много общего, между ними существуют значительные различия. Игнорирование этих различий и управление командой дата-инженеров по тем же принципам, что и командой разработчиков ПО, является ошибкой. Особенно этим грешат относительно молодые менеджеры, или те, кто никогда не работал с "датой". Собственно, этим зачастую и вызваны ошибки в пименении "в лоб" соврмененых методой разработки. Дата-инженерия — как томат: технически это фрукт, но это не значит, что его стоит добавлять в фруктовый салат.

Продолжение моей предыдущей статьи [Ответ] Про цифровые сервисы в Германии. В этой части мы затронем такие темы, как Почта, Постановка авто на учет онлайн, Приложение для мониторинга цен на топливо, Приложение для медицины, Онлайн‑ритейл, Check24 и подобные агрегаторы, поговорим про защиту данных и прочие мелкие сервисы, а в конце немного порефликсируем.

Дисклеймер: Я пишу только на основании своего (скромного) опыта. Если у вас есть что дополнить, прокомментировать или возразить — велкам в комментарии для обмена опытом

Сейчас развертывание дата платформ и решений для аналитки в облаке - явление повсеместное. Кажется, что так было (и будет?) всегда. При этом существует постоянное (но не всегда очевидное) противостояние между подходами Cloud Native и Cloud Agnostic. Cloud Native поддерживает использование специфических сервисов конкретного облачного провайдера, в то время как Cloud Agnostic нацелен на создание приложений, которые могут работать на различных облачных платформах без изменений.

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

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

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

В предыдущей своей статье Почему стоит начать писать собственные Spark Native Functions? (Часть 1), которая является переводом и которая вдохновила меня на собственные изыскания, был разобран пример, как написать свою Spark Native Function по генерации UID. Это, конечно, здорово, но вот только данная функция не принимает аргументы на вход, в то время как в реальной практике нам требуются обычно функции, которым надо передать на вход 1, 2 или 3 аргумента. Такие случаи не рассматриваются в упомянутой выше переводной статье - ну что ж, попробуем восполнить этот пробел!

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

Это мой вольный перевод статьи "Why You Should Start Writing Spark Custom Native Functions", которая вдохновила меня на некоторые собстенные изыскания по данной теме. Их результат я планирую опубликовать позже, а пока выношу на ваш суд этот перевод.

Статья на примере реализации функции по генератации UUID рассматривает, как писать Spark native функции, которые были бы "прозрачны" для Catalyst (в отличии от UDF, которые являются "черными ящиками" для него). Сравнение производительности ожидаемо показывает, что Catalyst Expressions значительно превосходят UDF при увеличении размера данных.

Кому интересно узнать, как писать Spark native функции - прошу под кат.

Несколько дней назад на Хабре была опубликована статья Правда ли, что в Европе везде отсталые сервисы, медленные платежи и плохие онлайн-услуги? Которая достаточно быстро набрала много просмотров и вызвала бурные обсуждения в комментариях. Я так же с интересом ее прочел и еле удержался, чтобы не вступить в дискуссию, но потом все же решил написать отдельную статью "по горячим следам", так как написать хотелось много чего.

Не то, чтобы я согласен или не согласен с автором, а скорее хотелось бы показать, что ситуация сильно отличается от страны к стране, и может даже от региона к региону внутри этой страны. Сам я в настоящий момент живу в Германии и успел уже пожить как в крупном городе-миллионнике (Кельн), так и в маленьком баварском городке на 40 киложителей, название которого никому ничего не скажет (мне оно вообще было неизвестно, до того как судьба занесла меня в него, поэтому для простоты буду ниже по тексту называть его "город Y")

Below, we will discuss user-defined aggregation functions (UDAF) using org.apache.spark.sql.expressions.Aggregator, which can be used for aggregating groups of elements in a DataSet into a single value in any user-defined way.

Let’s start by examining an example from the official documentation that implements a simple aggregation

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

В мире Apache Spark начинающим точно не пропадешь: статьи, уроки, курсы - на любой вкус. Что хабр, что медиум, а так же другие онлайн-платформы просто завалены статьями, где вам в 100500-ый раз говорят про SparkContext, Driver и Executor, приводят тривиальные примеры кода из официальной документации (ок-ок, поправлюсь - часто все же с небольшими изменениями), читают уже заезженных датасет с поездками такси в Нью-Йорке и делают какие-то тривиальные агрегации, рассуждают с умным видом про разницу coalesce и repartition и т.п. Не отстают и произовдители курсов класса "Войти в ИТ" - как известные онлайн-школы, так и "частники" на порталах типа Udemy, Pluralsight и т.п. Выбор курсов по Spark там очень велик.

Я уже ранее публиковал статью [Пятничное] Онбординг: вредные советы. Теперь, руководствуясь принципом "критикуешь - предлагай", решил написать о том, а как должен быть по моему скромному мнению устроен хороший онбординг. Тем более последняя смена работы мне принесла просто отличнийший личный пример продуманного и комфортного во многих аспектах онбординга.

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

Всем привет!

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

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

Добрый день, уважаемые читатели Хабра!

На тему онбординга написано немало - в основном про то, как здорово устроен процесс в компании N. Я же, хочу с вами поделиться своими наблюдениями на тему “как делать ни в коем случае нельзя”, ведь порою отрицательный опыт не менее важен, чем истории успеха. 

Данная статья является гайдом по использованию кастомных агрегаторов в Spark SQL API. Она “выросла” из моих заметок, которые я делал себе с начала работы со Spark. Сейчас, по мере накопления опыта, мне все это кажется уж слишком наивным и простым, но в свое время мне это показалось чертовски удобным/изящным/заслуживающим внимания, поэтому и решил опубликовать, тем более на Хабре про это еще вроде не писали. Статья ориентирована в первую очередь на тех, кто только начинает работать со Spark, поэтому и помечена как “tutorial”. Если у вас есть какие-либо интересные кейсы по использованию кастомных агрегаторов - делитесь в комментариях!

Ниже мы будем говорить о user-defined aggregations functions (UDAF) org.apache.spark.sql.expressions.Aggregator, которые могут быть использованы для DataSet’ов с целью агрегации группы элементов в одно значение каким-угодно-пользователю образом.

Может быть вы заметили, а может нет, но в последнее время (год или даже более) сильно активизировалась реклама брокерских счетов для населения. Я не смотрю телевизор, не являюсь активным пользователем соц.сетей, на всех моих устройствах, на которых только возможно, стоит блокировка рекламы, но все равно, я это замечаю. Еще также активизировались различные "блогеры" и "Даши с фейсбука", которые вчера еще постили “котиков”, публиковали обзоры безделушек из Китая или видео распаковки айфонов, а теперь с умным видом пишут на своих страничках о прописных истинах “инвестирования”, “помогают” выбрать брокера который им проплатил рекламу и снимают видео о том, как открыть брокерский счет онлайн через госуслуги. Только я нахожу это смешным и печальным одновременно? 

Ведь самое прискорбное то, что сотни тысяч человек поддаются этой рекламе открывают брокерские счета (объективности ради, согласно информации ЦБ РФ, около 60%  физических  лиц – резидентов на брокерском обслуживании имеют пустые счета)...

Всем привет! В недавней статье мы рассказали, как мы шли к построению нашей Data Platform.

Сегодня хотелось бы глубже погрузиться в «желудок» нашей платформы и попутно рассказать вам о том, как мы решали одну из задач, которая возникла в связи с ростом разнообразия интегрируемых источников данных.

То есть, если возвращаться к финальной схеме из упомянутой выше статьи (специально дублирую ее ниже, чтобы уважаемым читателям было удобнее), то сегодня мы будем более углубленно говорить о реализации «правой части» схемы — той, что лежит после Apache NiFi.

"Хороший бухгалтер может раздуть баланс на 30%" (с)

Добрый день, уважаемые хаброжители, имеющие брокерские счета или просто интересующиеся финансами и/или инвестициями. Раз вы видите эту статью, значит вы наверняка подписаны на «Финансы в ИТ», а значит у некоторых у вас, вероятно, уже есть открытые у различных брокеров индивидуальные инвестиционные счета (ИИС). А значит скорее всего у вас возникал резонный вопрос – а какова доходность моих инвестиций? Вопрос, как оказалось, не такой уж и простой

Дисклеймер: в статье речь идет исключительно об инвестировании, а не активном трейдинге. Так же за скобками оставляем налоговые льготы по ИИС

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

Поэтому для обычного депозита не важно, когда и какую сумму вы на него положили и как пополняли - %-ставка фиксирована и выражена в привычных нам всем «процентах годовых»

Если же мы говорим про брокерский счет, то тут не все так просто.

Введение

«Нужно бежать со всех ног, чтобы только оставаться на месте,
а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!»
(с) Алиса в стране чудес

Некоторое время назад меня попросили прочитать лекцию аналитикам нашей компании на тему проектирования моделей данных, ведь сидя долгое время на проектах (порою по нескольку лет) мы упускаем из виду происходящее вокруг в мире ИТ-технологий. В нашей компании (уж так получилось) на многих проектах не используются NoSQL-базы данных (по крайней мере пока), поэтому в своей лекции я отдельно уделил им некоторое внимание на примере HBase и постарался ориентировать изложение материала на тех, кто с ними никогда не работал. В частности, я иллюстрировал некоторые особенности проектирования модели данных на примере, который несколько лет назад прочитал в статье «Introduction to HB ase Schema Design» by Amandeep Khurana. Разбирая примеры, я сравнивал между собой несколько вариантов решения одной и той же задачи, чтобы лучше донести до слушателей основные идеи.

Недавно, «от нечего делать», я задался вопросом (длинные майские выходные в режиме карантина к этому особенно располагают), насколько теоретические выкладки будут соответствовать практике? Собственно, так и родилась идея этой статьи. Разработчик, который не первый день работает с NoSQL, возможно и не почерпнет из нее что-то новое (и поэтому может сразу промотать полстатьи). Но для аналитиков, которые еще не работали плотно с NoSQL, полагаю, она будет полезна для получения базовых представлений об особенностях проектирования моделей данных для HBase.