Записки Дата инженера
18 subscribers
10 photos
1 file
12 links
Здравствуйте! Я Дата инженер. Буду писать сюда тому что научился или термины, понятия которые я не знал
Download Telegram
Сегодня погрузился как спарк управляет памятью executor’ов.

Напоминаю, что spark написан на Scala, поэтому все операции выполняются внутри JVM. Существует глобально две области памяти

- On-Heap Memory (spark.executor.memory)
- Off-Heap Memory + Overhead (spark.memory.offHeapsize + spark.executor.memoryOverhead) память вне кучи (Off-Heap Memory) – сегмент за пределами JVM, который иногда используется виртуальной машиной Java. Память вне кучи также может использоваться для хранения сериализованных датафреймов и RDD.

Основные вычисления и хранения данных происходит в On-Heap Memory. В свою очередь On-Heap Memory разделяется на следующие части:

1. Execution memory (=spark.execution.memory * spark.memory.fraction - spark.memory.storageFraction) - здесь происходит JOIN, Shuffle, Sorting, GroupBy
2. Storage memory (spark.memory.storageFraction=0.5) - хранятся закешированые данные и Broadcast переменные
3. User memory (=spark.executor.memory - spark.memoryFraction) - переменные определенные со стороны пользователя
4. Reserved memory (300Mb) - 300Mb зарезервированных данных

Пример:

`Spark.executor.memory=10Gb
spark.memory.fraction=0.8
spark.memory.storageFraction=0.5`

Execution memory => spark.executor.memory * spark.memory.fraction - <Storage Memory> => 10Gb * 0.8 - 4Gb = 4Gb
Storage memory => spark.executor.memory * spark.memory.fraction * spark.memory.storageFraction => 10Gb * 0.8 * 0.5 = 4Gb
User memory => spark.executor.memory - spark.memoryFraction => 10Gb - 300Mb - 10Gb*0.8 = 1.7Gb
Reserved memory => 300Mb

* Для примера 1Gb взял как 1000Мб, знаю что это 1024Мб
🔥1
Также этот рисунок дает графическое описание, чтобы легче было воспринять
🔥1
Решил интересную задачу от Яндекса. Хотел бы поделиться.

Дана таблица с логами пользователя в формате:

create table logs ( user_id text, time int );

INSERT INTO logs (user_id, time) values
('u1',0),
('u1',20),
('u2',30),
('u2',40),
('u1',40),
('u1',60),
('u2',65),
('u1',80),
('u1',130),
('u1',150),
('u1',200);

где user_id — id пользователя, time — время.

Активной сессией будем считать отрезок времени, в котором промежуток между действиями пользователя меньше или равен 30.

Нужно написать запрос, который найдет количество всех активных сессий пользователей, результат отсортировав по ключу user_id.

Вот самое решение:
WITH t AS
(SELECT user_id,
TIME,
lag(TIME) over(PARTITION BY user_id ORDER BY TIME) AS prev_time
FROM logs)
SELECT user_id, COUNT(*)
FROM t
WHERE prev_time IS NULL
OR TIME - prev_time > 30
GROUP BY user_id
ORDER BY user_id
🎄 Advent of SQL

Начал решать задачи из Advent of SQL — это такой SQL-челлендж с интересными заданиями на каждый день. Решения выкладываю в репозиторий на GitHub:
🔗 Смотреть на GitHub

Если тоже участвуете или просто интересно посмотреть, заходите. Буду рад обратной связи или обсуждению! 😊
1
Уже больше пол года прохожу курс дата-инженера на Яндекс.Практикум.

Работая фулл-тайм и совмещать полноценный курс не из легких оказывается. Но я доволен собой, так как отправил на проверку один из больших проектов. Жду ОС, но пока уже начал изучать Vertica.
1
За последний год количество вакансий для дата-инженеров в Узбекистане значительно увеличилось. Два года назад я мог насчитать их на пальцах одной руки, а сейчас компании активно ищут специалистов в этой области. Вот лишь некоторые из них:

• Корзинка
• Click
• Sarkor
Avo.uz
• Payme
• SQB
• Infin Bank
• Ipotek Bank
• Ucell
• Beeline
• Hamkorbank
• Epam
• Uzum

И это далеко не полный список! Это действительно радует и свидетельствует о растущем интересе к аналитике данных в стране.
Из последних новостей, Я начал читать лекции по SQL в курсе Дата-аналитика.

Скажу сразу это не легкая задача оказывается, так как меня слушают люди, которые вообще далеко от SQL или вообще от Computer Science. Получаю очень много плохой обратной связи, где студенты недовольны подходом и что им ничего не понятно. Думаю это все пройдет после нескольких практик.

Кстати вот ссылка на курс.
👍2🙏1
Записки Дата инженера
Photo
Помните, я писал, что прохожу курс от Яндекса? Так вот, я дошел до модуля, ради которого и начал — "Потоковая обработка данных". В нем разбираются Kafka и Spark Streaming.

Чтобы лучше закрепить знания, буду делать конспекты и изучать материал более детально. Ну и здесь тоже буду выкладывать — думаю, это будет интересно и полезно для остальных.
👍2
Записки Дата инженера
Помните, я писал, что прохожу курс от Яндекса? Так вот, я дошел до модуля, ради которого и начал — "Потоковая обработка данных". В нем разбираются Kafka и Spark Streaming. Чтобы лучше закрепить знания, буду делать конспекты и изучать материал более детально.…
Да, я это сделал!
Закончил курс дата-инженера от Яндекс.Практикума 🙌

Проходил почти год. Было сложно, особенно под конец — просто добивал задачи ради финиша. Но курс реально классный: море практики, интересные проекты, полезные навыки.

Если кто-то собирается проходить — советую делать это без длинных пауз. На одном дыхании пройти намного легче.

Теперь можно выдохнуть и двигаться дальше 💪
Please open Telegram to view this post
VIEW IN TELEGRAM
5👍1👏1
Как построить data-driven культуру, а не просто BI, в который никто не заходит?

🟣В прошлом посте я писала:
данные ≠ актив, если вы с ними ничего не делаете.

Но чтобы начали делать, нужна не просто BI-система.
Нужна культура.
И как и всё важное в бизнесе, она начинается с головы.

Я вообще выросла в аналитической среде.
Когда я начинала карьеру в консалтинге, ни Big Data, ни ChatGPT ещё не было,
но мышление
«данные → вывод → решение»
у нас тренировали так, как будто от этого зависела судьба миллионов (и иногда — правда зависела).

🟣Этот майндсет остался со мной до сих пор.
И я вижу: чем дальше, тем чаще компании говорят, что они аналитичные,
но при этом продолжают принимать решения на летучках в духе «ну по ощущениям».

А BI-системы — просто красивые панели, на которые никто не заходит.

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

1️⃣ Всё начинается с фаундера и C-Level:
Если CEO говорит «я чувствую, что надо пушить эту фичу» и не дает задачу проверить гипотезу — всё, приехали.

Команда будет делать то же самое.

Data-driven культура начинается с того, что лидер принимает решения на данных.
✸ Он задаёт вопросы.
✸ Просит цифры.
✸ Не ведёт обсуждения в стиле «мне кажется».

2️⃣ Без инструментария — ничего не взлетит:
Не надо думать, что культура вырастет на энтузиазме.
Если у людей нет доступных и понятных дешбордов —
никакая data-driven культура не сложится.

Метрики должны быть:
✸ Привязаны к бизнес-целям
✸ Регулярно обновляемы
✸ С возможностью копать вглубь, а не просто «доход-расход»

Иначе всё закончится в Excel на 17 вкладок у одного аналитика.

3️⃣ Люди должны понимать, что их перформанс считают по данным:
Не метафорически, а буквально.

✸ Если в компании бонус зависит от бизнес-результатов —
значит, сотрудник должен видеть свои метрики.
✸ Если продуктовая команда оценивается по росту retention — она должна уметь его мерить, а не угадывать.

Когда оценка и рост человека связаны с метриками —
у него появляется привычка на них смотреть.

4️⃣ Нормализуйте «сначала смотрим → потом решаем»:
Я обожаю команды, в которых принято начинать обсуждение с цифр.
Прямо нормализовать это:

✸ Хотите запустить фичу? Где данные?
✸ Хочешь отключить воронку? Что на неё влияет?
✸ Думаешь, надо пушить что-то в маркетинге? Где проверка гипотез?

Это становится привычкой.
А привычка → поведение → культура.

5️⃣ Культуру нужно растить через обучение:
Если вы строите команду посильнее или у вас уже есть масштаб, то работа с данными = отдельная компетенция.

🟣 Что можно делать:
✸ Обучение по интерпретации ключевых метрик
✸ Мини-тренинги по юнитке, ретеншну, воронкам
✸ Кейсы «что сказали данные и к чему это привело»
✸ Отправлять на курсы или собирать внутренний чек-лист

Если компания маленькая — то хотя бы:
✸ Привычка делиться аналитикой
✸ 1 инсайт недели в чат
✸ Простые дешборды для всей команды

🟣 Пример
Плохой сценарий:
✸ «У нас упала конверсия с лендинга!!!»
✸«Паника!!!»

Хороший:
✸ «Конверсия упала, но трафик вырос в 2 раза, потому что залили TikTok с нерелевантной аудиторией. А CTR по email — остался стабильным».

Это и есть мышление на данных.
Контекст, динамика, гипотеза, вывод.

В итоге, data-driven культура — это про то, чтобы каждый в команде реально начал думать через данные, а не через «мне кажется» или «ну, так всегда делали».
Чтобы цифры стали не страшным отчётом, а привычкой — первым делом смотреть на них, задавать вопросы и искать ответы.

А как часто вы в команде обращаетесь к данным и стараетесь ли вы формировать привычку в команде? Пишите в комментариях 🚀.

#Data_driven
Please open Telegram to view this post
VIEW IN TELEGRAM
Работаю в телекоме уже почти два года. За это время успел повидать 4 разных отдела (по 5–10 человек), и каждый из них делает дашборды по-своему: кто-то в Excel, кто-то пишет самодельные тулзы, кто-то заказывает визуализации у подрядчиков. А сегодня увидел, как бэкенд-разработчик просто поднял Metabase в Docker и сделал дашборд прямо над таблицами бэкенда.

Команды между собой никак не связаны, нет общей унификации — все плодят свои версии данных.

Еще заметил, что многие используют метрику ARPU каждый день, но до конца не понимают, что она означает.

Кажется, это все из-за того, что за последние пару лет тут сменилось 2 или 3 состава C-level руководства. Продуктового подхода практически нет — все гонятся за тем, чтобы «побыстрее запустить хоть что-то». А потом уже начинается разбор полётов: что вообще сделали, зачем, и почему не работает.

Осознаю ещё одну грустную вещь: тут много людей, которые годами делают одно и то же вручную — кликают, собирают, строят отчёты. Некоторым нужно пару часов, чтобы вручную собрать один Excel-отчёт. И при этом им это нравится. Они даже не догадываются, что всё это можно автоматизировать и сократить время до одной минуты.

Иногда прямо физически жалко это осознавать.
Прошло уже много времени, и я всё больше понимаю: последнее время на работе у меня и у половины команды уходит масса времени на поддержку легаси. Это невероятно выматывает. Каждый раз, когда сталкиваешься с результатами работы 5–10-летней давности, видишь просто набор скриптов без документации, без описаний. Всё держалось в головах тех, кто это писал.

Разобраться в этом — отдельный квест. Каждый раз на это уходит куча времени.

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

Плюс компания большая, нужно бегать по отделам, создавать тикеты, ждать апрув от ИБ (ощущение, что человек просто сидит, чтобы нажимать кнопку "Approve"). Одним постом и не опишешь весь процесс.

Итог: запланированные работы перешли в режим аварийных. Планировалось 2 часа, ушло 5. А готовился к задаче полторы недели.
👍1
Снова осознаю, что работа в крупных компаниях часто заключается в том, что задача, которую можно выполнить за 1-2 часа, затягивается на 4-5 дней. В течение этого времени ты постоянно держишь ситуацию под контролем, так как ты — сервис-овнер, и никому, кроме тебя, это не интересно. Поэтому тебе приходится постоянно напоминать и пушить коллег.
👍2