Сейчас развертывание дата платформ и решений для аналитки в облаке - явление повсеместное. Кажется, что так было (и будет?) всегда. При этом существует постоянное (но не всегда очевидное) противостояние между подходами 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.