🗿 подкасты про карьеру
специально для постоянной читательницы этого блога — Натальи — ни к чему не обязывающая подборка подкастов на тему карьеры, её смены и всякого такого >_>
подкасты хороши тем, что можно слушать на фоне, удобно чтобы ненапряжно набраться чужого опыта. пока остальные процессы ещё только готовятся или обдумываются
⌘⌘⌘
первым делом, конечно, стоит упомянуть про подкаст «собес» — в последнем сезоне они делают эпизоды в формате мок-собесов. это когда реальный рекрутер под реальную вакансию собесит кандидата прямо в эфире, а потом дают обратную связь и говорят что можно подкрутить.
на своём опыте ощутил, что полезно послушать со стороны как звучит все эти привычные фразы и что излишняя скромность на интервью только мешает и будет интерпретирована не пользу кандидата. это сложно принять в теоретическом вакууме, надо просто послушать N раз других людей.
→ https://libolibo.ru/sobes
⌘⌘⌘
я бы сказал, что подлодка — мастхев в подкаст-приёмнике айтишника. как шутят сами ведущие, когда законичились темы про айти, начались про всё остальное, поэтому в длинном списке эпизодов можно найти темы под любые запросы.
в недавнем выпуске собрался весь состав ведущих и обсудили смену работы, переход из кодеров в менеджеры и обратно (!), переходы внутренние и внешние. кажется на всех они собрали все возможные кейсы и всё подробно обсудили. м-м-мякотка!
→ https://t.iss.one/podlodkanews/1440
⌘⌘⌘
и отдельно на тему аналитики два проекта от ребят из тбанка.
первый про аналитику — тоже можно повыбирать эпизоды с привлекательной темой. мне понравился выпуск про офлайн-ритейл с представителем Магнита. ребята в унисон разгоняли про темы как вообще анализировать штуки из реального мира, когда надо прямо ножками дойти, что-то поменять, а потом ещё как-то измерить результат. масштаб внушает трепет, а подходы — уважение.
→ https://t.iss.one/eto_schitaetsya/477
и вот только что узнал про ещё один их подкаст, добавил себе в послушать. подводка звучит интересно. тематика, видимо, связана с продуктами их банка, но иногда зовут и людей извне.
→ https://t.iss.one/karty_dengi_product/112
⌘⌘⌘
ещё один пример с другой стороны, когда продукт надо не только анализировать, но и управлять им. кто такие продакты, зачем они нужны, где их место в общей организации и как наладить диалог с разработкой.
→ https://music.yandex.ru/album/22481935/track/129159864
⌘⌘⌘
§ что ещё можно послушать-посмотреть условному бизнес-аналитику в условном финтехе?
что вообще понимают в разных компаниях под «бизнес-аналитиком»? в моей голове есть системные аналитики, которые ближе к данным и процессам, а есть продакты, которые ближе к бизнесу. а «бизнес-аналитиком» получается, это что-то между этими двумя.
специально для постоянной читательницы этого блога — Натальи — ни к чему не обязывающая подборка подкастов на тему карьеры, её смены и всякого такого >_>
подкасты хороши тем, что можно слушать на фоне, удобно чтобы ненапряжно набраться чужого опыта. пока остальные процессы ещё только готовятся или обдумываются
⌘⌘⌘
первым делом, конечно, стоит упомянуть про подкаст «собес» — в последнем сезоне они делают эпизоды в формате мок-собесов. это когда реальный рекрутер под реальную вакансию собесит кандидата прямо в эфире, а потом дают обратную связь и говорят что можно подкрутить.
на своём опыте ощутил, что полезно послушать со стороны как звучит все эти привычные фразы и что излишняя скромность на интервью только мешает и будет интерпретирована не пользу кандидата. это сложно принять в теоретическом вакууме, надо просто послушать N раз других людей.
→ https://libolibo.ru/sobes
⌘⌘⌘
я бы сказал, что подлодка — мастхев в подкаст-приёмнике айтишника. как шутят сами ведущие, когда законичились темы про айти, начались про всё остальное, поэтому в длинном списке эпизодов можно найти темы под любые запросы.
в недавнем выпуске собрался весь состав ведущих и обсудили смену работы, переход из кодеров в менеджеры и обратно (!), переходы внутренние и внешние. кажется на всех они собрали все возможные кейсы и всё подробно обсудили. м-м-мякотка!
→ https://t.iss.one/podlodkanews/1440
⌘⌘⌘
и отдельно на тему аналитики два проекта от ребят из тбанка.
первый про аналитику — тоже можно повыбирать эпизоды с привлекательной темой. мне понравился выпуск про офлайн-ритейл с представителем Магнита. ребята в унисон разгоняли про темы как вообще анализировать штуки из реального мира, когда надо прямо ножками дойти, что-то поменять, а потом ещё как-то измерить результат. масштаб внушает трепет, а подходы — уважение.
→ https://t.iss.one/eto_schitaetsya/477
и вот только что узнал про ещё один их подкаст, добавил себе в послушать. подводка звучит интересно. тематика, видимо, связана с продуктами их банка, но иногда зовут и людей извне.
→ https://t.iss.one/karty_dengi_product/112
⌘⌘⌘
ещё один пример с другой стороны, когда продукт надо не только анализировать, но и управлять им. кто такие продакты, зачем они нужны, где их место в общей организации и как наладить диалог с разработкой.
→ https://music.yandex.ru/album/22481935/track/129159864
⌘⌘⌘
§ что ещё можно послушать-посмотреть условному бизнес-аналитику в условном финтехе?
что вообще понимают в разных компаниях под «бизнес-аналитиком»? в моей голове есть системные аналитики, которые ближе к данным и процессам, а есть продакты, которые ближе к бизнесу. а «бизнес-аналитиком» получается, это что-то между этими двумя.
1👍5❤4🔥3
2025_02_06_Новые_возможности_YDB_СУБД_Яндекса_для_аналитических.pdf
8.7 MB
📦 YDB + OLAP = ?
ydb — это отлп-база данных от Яндекса. основная характеристика — нативная распределённость с поддержкой транзакции. из свойства распределённости следует высокая доступность и гибкая масштабируемость. помимо олтп-базы там есть ещё такая сущность как топики, с кафка-совместимым апи.
и вот недавно ребята объявили, что ещё они идут в сторону олап-нагрузки. собирая эдакую всё-в-одном базу: с одной стороны у вас сервисы, с другой аналитика, а между ними нативный сдс-процесс, прямо не выходя из контура бд.
https://yandex.cloud/ru/blog/posts/2024/12/ydb-dwh
⌘⌘⌘
интересно посмотреть со стороны аналитики и нашего двх-мира.
→ очереди настраиваются через SQL-команды (кажется, в кликхаусе можно так же настроить читателя для кафки). в целом удобно, но хз как будет поддерживать в масштабе сотен таких топиков-читателей.
→ изначально идут по пути раздельного хранения и обработки — соответственно, можно независимо масштабировать под текущую потребность.
→ добавили колоночное хранение c массивно-параллельными вычислениями через векторные движки
→ стоимостной оптимизатор (cost-based) для плана запроса с подбором оптимального порядка и алгоритма джойнов
→ поддержка скл-хинтов для ручных подсказок оптимизатору
→ спиллы на диск для больших вычислений
→ нативная поддержка охлаждения данных в s3 (автоматическое гибридное хранение для колоночных таблиц)
→ сбор статистики для таблиц
→ predicate pushdown для оптимизации чтения
→ федеративные sql-запросы из разных источников
→ пулы ресурсов — разделение под разные нагрузки
→ асинхронная репликация между удб-инстансами
по мотивам обзорного доклада про новости удб с конфы yandex scale
https://vkvideo.ru/video-200452713_456239488
и недавнего вебинара, посвященного релизу ydb dwh (ссылки не осталось есть ссылка, есть презентация)
1/2
ydb — это отлп-база данных от Яндекса. основная характеристика — нативная распределённость с поддержкой транзакции. из свойства распределённости следует высокая доступность и гибкая масштабируемость. помимо олтп-базы там есть ещё такая сущность как топики, с кафка-совместимым апи.
и вот недавно ребята объявили, что ещё они идут в сторону олап-нагрузки. собирая эдакую всё-в-одном базу: с одной стороны у вас сервисы, с другой аналитика, а между ними нативный сдс-процесс, прямо не выходя из контура бд.
https://yandex.cloud/ru/blog/posts/2024/12/ydb-dwh
⌘⌘⌘
интересно посмотреть со стороны аналитики и нашего двх-мира.
→ очереди настраиваются через SQL-команды (кажется, в кликхаусе можно так же настроить читателя для кафки). в целом удобно, но хз как будет поддерживать в масштабе сотен таких топиков-читателей.
→ изначально идут по пути раздельного хранения и обработки — соответственно, можно независимо масштабировать под текущую потребность.
→ добавили колоночное хранение c массивно-параллельными вычислениями через векторные движки
→ стоимостной оптимизатор (cost-based) для плана запроса с подбором оптимального порядка и алгоритма джойнов
→ поддержка скл-хинтов для ручных подсказок оптимизатору
→ спиллы на диск для больших вычислений
→ нативная поддержка охлаждения данных в s3 (автоматическое гибридное хранение для колоночных таблиц)
→ сбор статистики для таблиц
→ predicate pushdown для оптимизации чтения
→ федеративные sql-запросы из разных источников
→ пулы ресурсов — разделение под разные нагрузки
→ асинхронная репликация между удб-инстансами
по мотивам обзорного доклада про новости удб с конфы yandex scale
https://vkvideo.ru/video-200452713_456239488
и недавнего вебинара, посвященного релизу ydb dwh (
1/2
🔥2👍1
2/2
в общем, много чего для нужд аналитики в удб уже есть, но чего там нет — надо додумывать самому)
из озвученного — нет поддержки триггеров и хранимых процедур. плюс конечно как у любого нового инструмента нет такого богатого набора аддонов и инструментов как у того же постгреса, то же относиться и к коммьюнити.
плюс в документации есть отдельная сноска чего пока нет в колоночных таблицах
> В настоящий момент реализована не вся функциональность колоночных таблиц
https://ясубд.рф/docs/ru/concepts/datamodel/table.html#column-oriented-tables
(надеюсь, документация просто чуток отстаёт от новых фич)
⌘⌘⌘
в теории звучит хорошо — один инструмент лучше, чем пять разных (при прочих равных)
если задачи пост-обработки данных тесно связаны с бизнесом, есть плюсы от использования единой системы. на ум приходят задачи типа реверс-етл или тот же фича-стор для мл. было бы удобно посчитать что-то по-колоночно, а потом отдать это для доступа где нужен высокий рпс.
либо по-быстрому настроить быстрые базовые витрины: наклепать каких-то простых трансформаций операционных данных в несколько колоночных таблиц и вывести на деши. но такое решение рискует быстро превратиться в какой-то теневой двх — надо иметь в уме следующий шаг и вовремя перевести на продовые рельсы с подобающими моделями.
⌘
с другой стороны — амбициозная задача максимально широко покрыть кейсы других узкоспециализированных баз данных заведомо имеет явный трейдоф. общий инструмент не будет так хорош для каких-то задач, как явно заточенный под конкретно эти задачи.
то есть зоопарк инструментов остаётся, но задачи и кейсы могут чуток перераспределиться — polyglot persistance пока не отменяем
https://martinfowler.com/bliki/PolyglotPersistence.html
либо можно принять явное архитектурное решение, чтобы перейти с условного гринплама на удб, чтобы снизить косты на поддержку, вместе с этим получая какие-то ограничения по функциональности.
в любом случае кажется, что ниша дата-лейка как будто бы в безопасности — хранить и обрабатывать петабайт в том же yt должно быть дешевле, чем в удб. в силу архитектуры и заявленных характеристик систем.
в общем, много чего для нужд аналитики в удб уже есть, но чего там нет — надо додумывать самому)
из озвученного — нет поддержки триггеров и хранимых процедур. плюс конечно как у любого нового инструмента нет такого богатого набора аддонов и инструментов как у того же постгреса, то же относиться и к коммьюнити.
плюс в документации есть отдельная сноска чего пока нет в колоночных таблицах
> В настоящий момент реализована не вся функциональность колоночных таблиц
https://ясубд.рф/docs/ru/concepts/datamodel/table.html#column-oriented-tables
(надеюсь, документация просто чуток отстаёт от новых фич)
⌘⌘⌘
в теории звучит хорошо — один инструмент лучше, чем пять разных (при прочих равных)
если задачи пост-обработки данных тесно связаны с бизнесом, есть плюсы от использования единой системы. на ум приходят задачи типа реверс-етл или тот же фича-стор для мл. было бы удобно посчитать что-то по-колоночно, а потом отдать это для доступа где нужен высокий рпс.
либо по-быстрому настроить быстрые базовые витрины: наклепать каких-то простых трансформаций операционных данных в несколько колоночных таблиц и вывести на деши. но такое решение рискует быстро превратиться в какой-то теневой двх — надо иметь в уме следующий шаг и вовремя перевести на продовые рельсы с подобающими моделями.
⌘
с другой стороны — амбициозная задача максимально широко покрыть кейсы других узкоспециализированных баз данных заведомо имеет явный трейдоф. общий инструмент не будет так хорош для каких-то задач, как явно заточенный под конкретно эти задачи.
то есть зоопарк инструментов остаётся, но задачи и кейсы могут чуток перераспределиться — polyglot persistance пока не отменяем
https://martinfowler.com/bliki/PolyglotPersistence.html
либо можно принять явное архитектурное решение, чтобы перейти с условного гринплама на удб, чтобы снизить косты на поддержку, вместе с этим получая какие-то ограничения по функциональности.
в любом случае кажется, что ниша дата-лейка как будто бы в безопасности — хранить и обрабатывать петабайт в том же yt должно быть дешевле, чем в удб. в силу архитектуры и заявленных характеристик систем.
1👍2🔥1
🦆 прилетят орлы и поднимут прод
когда в работе встречаю какую-то проблему, то первым делом хочется написать в командный чатик, типа «ребята, там на дисках место заканчивается»
со стороны это читается как «там на дисках место заканчивается … кто-нибудь сделайте что-нибудь!»
получается, что я привлекаю внимание всех коллег к проблеме и тогда один из коллег (кстати, кто?) должен оторваться от своего текущего контекста и пойти расследовать эту проблему, потратить своё время и внимание, и найти причину и потенциальное решение
но если я уже видел проблему, почему бы самому не посмотреть глубже, потратить какое-то время на расследование и прикинуть варианты решений. и в результате прийти в чатик уже не с проблемой, а с каким-то решением!
- понятно, что расследование может занять больше нескольких минут
- понятно, что решение может быть тоже не простое или даже несовсем правильное
в этих случая включаются уже устоявшиеся процессы в команде; но базовый принцип остаётся — не рассчитывать, что в последний момент прилетят орлы и решат все проблемы
иными словами, приходи с решением, а не проблемой!
когда в работе встречаю какую-то проблему, то первым делом хочется написать в командный чатик, типа «ребята, там на дисках место заканчивается»
со стороны это читается как «там на дисках место заканчивается … кто-нибудь сделайте что-нибудь!»
получается, что я привлекаю внимание всех коллег к проблеме и тогда один из коллег (кстати, кто?) должен оторваться от своего текущего контекста и пойти расследовать эту проблему, потратить своё время и внимание, и найти причину и потенциальное решение
но если я уже видел проблему, почему бы самому не посмотреть глубже, потратить какое-то время на расследование и прикинуть варианты решений. и в результате прийти в чатик уже не с проблемой, а с каким-то решением!
- понятно, что расследование может занять больше нескольких минут
- понятно, что решение может быть тоже не простое или даже несовсем правильное
в этих случая включаются уже устоявшиеся процессы в команде; но базовый принцип остаётся — не рассчитывать, что в последний момент прилетят орлы и решат все проблемы
иными словами, приходи с решением, а не проблемой!
🔥11👍6❤2
🤑 yet another zarplaty
классный пример коллаборации:
Саша Варламов собрал парсер и визуализацию
https://t.iss.one/data_bar/60
а Никита это дело автоматизировал
https://t.iss.one/joni_in_web/21
в результате получаем работающий проект и возможность посмотреть живую аналитику зарплат — на скрин вынес кусочек деша с фильтром по аналитике.
что мне нравится в подобных проектах:
1. проактивность — сам придумал, сам спроектировал, сам затащил, сам отчитался в блог
2. коллаборация — организоваться вдвоём гораздо сложнее, чем сделать одному, но эффект может быть круче
3. полезность, направленная наружу: когда решал свою задачу, а польза — всем
в общем, смотрите деш и ставьте лайки Саше с Никитой)
классный пример коллаборации:
Саша Варламов собрал парсер и визуализацию
https://t.iss.one/data_bar/60
а Никита это дело автоматизировал
https://t.iss.one/joni_in_web/21
в результате получаем работающий проект и возможность посмотреть живую аналитику зарплат — на скрин вынес кусочек деша с фильтром по аналитике.
что мне нравится в подобных проектах:
1. проактивность — сам придумал, сам спроектировал, сам затащил, сам отчитался в блог
2. коллаборация — организоваться вдвоём гораздо сложнее, чем сделать одному, но эффект может быть круче
3. полезность, направленная наружу: когда решал свою задачу, а польза — всем
в общем, смотрите деш и ставьте лайки Саше с Никитой)
👍22❤12🔥5
🐤 джуны, LLM и Shopify
в интернетах есть тезис, что с внедрением LLM джуны будут не нужны: мол, llm-агент сам как крайне усердный и очень производительный джун
→ и тогда со временем всю базовую джуновскую работу будут делать llm-агенты
⌘⌘⌘
противоположный тезис высказывает Farhan Thawar, Head of Engineering в Shopify (всё время читаю как Spotify, приходится себя одёргивать и перепроверять)
Shopify среди меня известен своим мега-крутым фаундером — Tobias Lütke; слушал его в Lenny's Podcast — создаёт впечатление очень здравого и продвинутого человека
кроме того, про него неоднократно упоминал Lex Fridman, что даёт ещё сколько-то очков этому джентельмену и культуре в его компании
⌘⌘⌘
ещё добавляет веса этой дискуссии фигура ведущего. Gergely Orosz — автор рассылки The Pragmatic Engineer (а теперь ещё и одноимённого подкаста)
Gergely каждый раз глубоко копает тему, проводит предварительный ресёрч и «наводит справки». многие вопросы он задаёт «а вот твои коллеги, говорят… ».
ну и в целом гигантский опыт Gergely в бигтехе позволяет ему фильтровать всякий булшит, если вдруг тот появится.
⌘⌘⌘
про адоптинг аи-тулзов
господин Farhan замечает, что Шопифай был первым пользователем Copilot за пределами GitHub — для этого просто надо было написать письмо напрямую СЕО и просто попросить.
⌘
при этом инженеры — не основная профессия, которая пользуется аи-тулзами: помимо них там продакты, аналитики, сейлзы и, конечно, саппорт.
почти для каждого инструмента внутри Шопифай есть MCP сервер и инструкция как его подключить к своему Курсору.
⌘
про найм стажёров
- в прошлый семестр (?) Шопифай нанял 25 стажёров
- Farhan уговорил своего СЕО в следующий семестр нанятьноль 1000 (!) стажёров
при этом на собесах разрешается использовать любые помогаторы. а скорее даже поощряется! подразумевается, что кандидат идёт в комплекте с ai-агентом и умеет пользоваться этими новыми технологиями — без них он просто отстанет от будущих коллег
логика для такого найма простая — Farhan видит, что новое поколение думает по-другому. они уже буквально ai-native, они учатся и заканчивают вузы, когда chatgpt уже стал нормой, поэтому могут предложить нестандартные решения для задач.
и само наличие таких людей в командах помогает «старичкам» узнавать новое и где-то по-другому смотреть на свой опыт.
в общем, Шопифай делает ставку на ai-стажёров
подкаст есть на ютубе
https://youtu.be/u-3IILWQPRM
@data_days
в интернетах есть тезис, что с внедрением LLM джуны будут не нужны: мол, llm-агент сам как крайне усердный и очень производительный джун
→ и тогда со временем всю базовую джуновскую работу будут делать llm-агенты
⌘⌘⌘
противоположный тезис высказывает Farhan Thawar, Head of Engineering в Shopify (всё время читаю как Spotify, приходится себя одёргивать и перепроверять)
Shopify среди меня известен своим мега-крутым фаундером — Tobias Lütke; слушал его в Lenny's Podcast — создаёт впечатление очень здравого и продвинутого человека
кроме того, про него неоднократно упоминал Lex Fridman, что даёт ещё сколько-то очков этому джентельмену и культуре в его компании
⌘⌘⌘
ещё добавляет веса этой дискуссии фигура ведущего. Gergely Orosz — автор рассылки The Pragmatic Engineer (а теперь ещё и одноимённого подкаста)
Gergely каждый раз глубоко копает тему, проводит предварительный ресёрч и «наводит справки». многие вопросы он задаёт «а вот твои коллеги, говорят… ».
ну и в целом гигантский опыт Gergely в бигтехе позволяет ему фильтровать всякий булшит, если вдруг тот появится.
⌘⌘⌘
про адоптинг аи-тулзов
господин Farhan замечает, что Шопифай был первым пользователем Copilot за пределами GitHub — для этого просто надо было написать письмо напрямую СЕО и просто попросить.
сразу после того, как Томас Домк стал генеральным директором GitHub, он отправил ему электронное письмо с просьбой предоставить доступ к Copilot для инженеров Shopify.
хотя на тот момент инструмент не был доступен для коммерческого использования, Shopify всё равно получила к нему доступ. Компания пользовалась Copilot около двух лет без оплаты и в обмен предоставляла разработчикам GitHub обширные отзывы о работе инструмента.
⌘
при этом инженеры — не основная профессия, которая пользуется аи-тулзами: помимо них там продакты, аналитики, сейлзы и, конечно, саппорт.
почти для каждого инструмента внутри Шопифай есть MCP сервер и инструкция как его подключить к своему Курсору.
⌘
про найм стажёров
- в прошлый семестр (?) Шопифай нанял 25 стажёров
- Farhan уговорил своего СЕО в следующий семестр нанять
при этом на собесах разрешается использовать любые помогаторы. а скорее даже поощряется! подразумевается, что кандидат идёт в комплекте с ai-агентом и умеет пользоваться этими новыми технологиями — без них он просто отстанет от будущих коллег
логика для такого найма простая — Farhan видит, что новое поколение думает по-другому. они уже буквально ai-native, они учатся и заканчивают вузы, когда chatgpt уже стал нормой, поэтому могут предложить нестандартные решения для задач.
и само наличие таких людей в командах помогает «старичкам» узнавать новое и где-то по-другому смотреть на свой опыт.
в общем, Шопифай делает ставку на ai-стажёров
подкаст есть на ютубе
https://youtu.be/u-3IILWQPRM
@data_days
2❤8👍5🔥3👀1
NewHR в очередной — уже шестой! — раз проводит опрос про работу аналитиков
я бы тоже прошёл, но я, к сожалению, я не аналитик
если тоже любите читать результаты таких исследований, можно инвестировать 20 минут в опрос
новый опрос за 2025 год тут
я бы тоже прошёл, но я, к сожалению, я не аналитик
если тоже любите читать результаты таких исследований, можно инвестировать 20 минут в опрос
новый опрос за 2025 год тут
❤1👍1🔥1
🎧 Data Platform T-Bank
послушал подкаст с СТО платформы данных Т-Банка
https://t.iss.one/book_cube/3766
для понимания масштаба
→ 15К MAU пользователей платформы (при условных 18К всех сотрудниках инхаус — это довольно большое проникновение)
→ всю платформу поддерживает ~230 человек
→ сторадж — около 15–20 петабайт;
→ компьют — порядка 100К ядер
→ внутри ~20 тысяч объектов
основная аналитическая СУБД — Greenplum: около 10 кластеров от 30 до 72 нод в каждом
проблемы с текущей архитектурой
⌘ Greenplum имеет ограничение на количество параллельных запросов, которые он может обработать эффективно; считается, что это около ста запросов.
⌘ система требует постоянного мониторинга и ручного управления распределением нагрузки между кластерами. это включает решение «задачки рюкзака», когда необходимо определить, сколько нагрузки можно распределить на каждый кластер с учётом их мощности и возраста оборудования
⌘ архитектура с Greenplum оказалась сложной и нестабильной; даже небольшие сбои могут привести к необходимости переключения пользователей на резервные кластеры, что не всегда проходит гладко и может вызывать негативный опыт
⌘ несмотря на то, что данные распределяются по сегментам, возникают проблемы с их равномерным распределением и обработкой, особенно при больших объёмах и высокой нагрузке
планы дальше
со временем стало понятно, что текущая архитектура не выдерживает всё возрастающий масштаб платформы
теперь задача — рядом с уже летящим самолётом построить ещё один, новый; и как-то аккуратно пересадить «пассажиров» с одного борта на другой
в качестве новой целевой архитектуры выбрали стандартный набор:
iceberg + s3 + spark + trino
по отзывам пользователей где-то новая архитектура отрабатывает дольше, чем старая; но по наблюдениям, она в целом надёжнее и готова к дальнейшему масштабированию в принципе
@data_days
послушал подкаст с СТО платформы данных Т-Банка
https://t.iss.one/book_cube/3766
для понимания масштаба
→ 15К MAU пользователей платформы (при условных 18К всех сотрудниках инхаус — это довольно большое проникновение)
→ всю платформу поддерживает ~230 человек
→ сторадж — около 15–20 петабайт;
→ компьют — порядка 100К ядер
→ внутри ~20 тысяч объектов
основная аналитическая СУБД — Greenplum: около 10 кластеров от 30 до 72 нод в каждом
проблемы с текущей архитектурой
⌘ Greenplum имеет ограничение на количество параллельных запросов, которые он может обработать эффективно; считается, что это около ста запросов.
⌘ система требует постоянного мониторинга и ручного управления распределением нагрузки между кластерами. это включает решение «задачки рюкзака», когда необходимо определить, сколько нагрузки можно распределить на каждый кластер с учётом их мощности и возраста оборудования
⌘ архитектура с Greenplum оказалась сложной и нестабильной; даже небольшие сбои могут привести к необходимости переключения пользователей на резервные кластеры, что не всегда проходит гладко и может вызывать негативный опыт
⌘ несмотря на то, что данные распределяются по сегментам, возникают проблемы с их равномерным распределением и обработкой, особенно при больших объёмах и высокой нагрузке
планы дальше
со временем стало понятно, что текущая архитектура не выдерживает всё возрастающий масштаб платформы
теперь задача — рядом с уже летящим самолётом построить ещё один, новый; и как-то аккуратно пересадить «пассажиров» с одного борта на другой
в качестве новой целевой архитектуры выбрали стандартный набор:
iceberg + s3 + spark + trino
по отзывам пользователей где-то новая архитектура отрабатывает дольше, чем старая; но по наблюдениям, она в целом надёжнее и готова к дальнейшему масштабированию в принципе
@data_days
1❤7👍4🔥2
🤓 Martin Fowler в гостях Pragmatic Engineer
https://youtu.be/CQmI4XKTa0U
Мартину уже за 60 лет, из которых он 40 с лишним считает себя инженером; когда опыт исчисляется десятками, то накапливается тот уровень насмотренности, когда можно сравнивать эпохи и видеть глобальные тенденции
⌘⌘⌘
по своему масштабу Мартин сравнивает нынешний скачок с переходом программистов с ассемблера на языки более высокого уровня
сам Мартин не имеет ничего против вайбкодинга как такового (тут он понимает «вайбкодинга» именно как безоглядное принятие любого результата ллм-ки без глубокого осознания написанного), однако чётко ограничивает зону его возможностей: небольшие проекты, прототипы на выброс и т.д.
главный недостаток слепого вайбкодинга — отсутствие цикла обратной связи. не пропуская через себя этот код, нет процесса обучения. новые знания не налипают и не копятся
получается вайбкодер через год останется ровно с таким же уровнем и потом его сменит просто другой вайбкодер (помоложе); или просто следующее поколение агентов, которым не нужна будет «простилка» между клавиатурой и креслом
⌘⌘⌘
при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду.
здесь быстрый цикл обратной связи помог им сразу на практике осознать простанство потенциальных вариантов и найти подходящие векторы для развития, отбросив остальные
⌘⌘⌘
ещё одна проблема ллм-ок — полная неспособность решить задачу «переименования класса»; по своему дизайну она скорее перепишет половину кодовой базы, чем поправит в трёх местах нужное название
при этом современные иде уже давно научились это делать, правда со своей подкапотной магией (которой, видимо, и не хватает ллм-кам)
⌘⌘⌘
общий подход к результатам работы моделей — ничему не верить, всё проверять; вдумчиво читать, внимательно вникать, нещадно тестировать, чтобы добавить чуток детерменированности их безудержной креативности.
и тогда действительно можно получать какой-то профит от совместной работы
https://youtu.be/CQmI4XKTa0U
Мартину уже за 60 лет, из которых он 40 с лишним считает себя инженером; когда опыт исчисляется десятками, то накапливается тот уровень насмотренности, когда можно сравнивать эпохи и видеть глобальные тенденции
⌘⌘⌘
по своему масштабу Мартин сравнивает нынешний скачок с переходом программистов с ассемблера на языки более высокого уровня
сам Мартин не имеет ничего против вайбкодинга как такового (тут он понимает «вайбкодинга» именно как безоглядное принятие любого результата ллм-ки без глубокого осознания написанного), однако чётко ограничивает зону его возможностей: небольшие проекты, прототипы на выброс и т.д.
главный недостаток слепого вайбкодинга — отсутствие цикла обратной связи. не пропуская через себя этот код, нет процесса обучения. новые знания не налипают и не копятся
получается вайбкодер через год останется ровно с таким же уровнем и потом его сменит просто другой вайбкодер (помоложе); или просто следующее поколение агентов, которым не нужна будет «простилка» между клавиатурой и креслом
⌘⌘⌘
при этом в прототипировании аи-помощник показывает небывалые приросты в продуктивности. приводят пример инженера из Антропика, который за 2 дня собрал 20 прототипов, итеративно проверяя и валидируя их об команду.
здесь быстрый цикл обратной связи помог им сразу на практике осознать простанство потенциальных вариантов и найти подходящие векторы для развития, отбросив остальные
⌘⌘⌘
ещё одна проблема ллм-ок — полная неспособность решить задачу «переименования класса»; по своему дизайну она скорее перепишет половину кодовой базы, чем поправит в трёх местах нужное название
при этом современные иде уже давно научились это делать, правда со своей подкапотной магией (которой, видимо, и не хватает ллм-кам)
⌘⌘⌘
общий подход к результатам работы моделей — ничему не верить, всё проверять; вдумчиво читать, внимательно вникать, нещадно тестировать, чтобы добавить чуток детерменированности их безудержной креативности.
и тогда действительно можно получать какой-то профит от совместной работы
❤6👍6🔥3