Back to Roots
Пришло время вернуть канал к истокам.
Засучиваю рукава, и в следующий месяц будет ядерная прожарка дата-инжиниринговых и архитектурных тем и технологий. Включая отложенный архитекторский стрим и большой мясной вебинар по Лейкхаусу и Айсбергу.
STAY TUNED
Также просьба написать интересующие вас вопросы в комментариях.
Пришло время вернуть канал к истокам.
Засучиваю рукава, и в следующий месяц будет ядерная прожарка дата-инжиниринговых и архитектурных тем и технологий. Включая отложенный архитекторский стрим и большой мясной вебинар по Лейкхаусу и Айсбергу.
STAY TUNED
Также просьба написать интересующие вас вопросы в комментариях.
Читаю Clickhouse 25.6 Release Notes
Single snapshot for SELECT
Contributed by Amos Bird
ClickHouse ensures that SELECT queries run on a consistent snapshot of the data. This means that for the entire duration of the query, it will see the same data, even if new rows are inserted or existing rows are updated or deleted in parallel.
То есть теперь Кликхаус - начиная с версии 25.6 - читает одни и те же данные в разных подзапросах одного запроса.
А раньше как было. Вот у вас есть таблица Т, в которую постоянно кто-то пишет даные. И вы отправляете запрос, который содержит 2 CTE с обращением к Т. И никаких гарантий, что разные части одного запроса к одной и той же таблице прочитают одни и те же строки.
В копилку милых чудачеств Кликхауса. Это чудачество починили, к счастью.
Release Notes тут:
https://clickhouse.com/blog/clickhouse-release-25-06
Single snapshot for SELECT
Contributed by Amos Bird
ClickHouse ensures that SELECT queries run on a consistent snapshot of the data. This means that for the entire duration of the query, it will see the same data, even if new rows are inserted or existing rows are updated or deleted in parallel.
То есть теперь Кликхаус - начиная с версии 25.6 - читает одни и те же данные в разных подзапросах одного запроса.
А раньше как было. Вот у вас есть таблица Т, в которую постоянно кто-то пишет даные. И вы отправляете запрос, который содержит 2 CTE с обращением к Т. И никаких гарантий, что разные части одного запроса к одной и той же таблице прочитают одни и те же строки.
В копилку милых чудачеств Кликхауса. Это чудачество починили, к счастью.
Release Notes тут:
https://clickhouse.com/blog/clickhouse-release-25-06
Telegram
Архитектор Данных
Блиц-обзор возможностей и "милых прикольчиков" кластерного Clickhouse.
Прочитано студентам ФКН ВШЭ практически экспромтом. Не судите строго.
#Clickhouse #webinar
Прочитано студентам ФКН ВШЭ практически экспромтом. Не судите строго.
#Clickhouse #webinar
Оказалось, что у Яндекса и экстремистов из Меты был способ нелегально сливать себе данные о вас. Если сильно упростить схему, то механизм такой.
Приложение Яндекса для андроид (Браузер, Карты, Такси или ФБ, ИнГрам) открывает порт на localhost и анонсит туда данные. Потенциально любые: ID трубки, гео и т.д. Потом с любого сайта, на котором он установлен, приходит скрипт Яндекс Метрики (или ФБ пиксель), забирает с порта эту информацию и добавляет к своей обычной. В итоге компания имеет возможности соотнести действия браузера и вашу физическую трубку.
На выходе
⁃ по идее куки метрики должны довольно быстро протухать и меняться (что-то вроде 30 дней), но на деле у Я есть способы привязать разные куки к одной ОС за долгое время
⁃ сброс кук не работает
⁃ по идее на разных сайтах висят разные куки, но на деле ваши посещения на разных сайтах легко привязываются друг к другу
⁃ инкогнито режим не спасет
⁃ разрешения андроид не спасут
⁃ активность в разных браузерах привязывается друг к другу
И еще что неприятно, что сведения, которые заанонсило приложение, теоретически, может прочитать не один только Яндекс, а любой, кто понял, как это работает.
А вы говорите, зачем им хранить всю вашу историю за все года.
Душная версия на Хабре
P.S. Яндекс начал использовать технологию в 2017-м, экстремисты в 2024-м.
P.P.S. На iOS по какой-то причине этот хак не используется. Хотя специалисты говорят, что технически возможен. Возможно, разработчики просто боятся банхамера от Эпла, а от Гугла - нет 😄
Приложение Яндекса для андроид (Браузер, Карты, Такси или ФБ, ИнГрам) открывает порт на localhost и анонсит туда данные. Потенциально любые: ID трубки, гео и т.д. Потом с любого сайта, на котором он установлен, приходит скрипт Яндекс Метрики (или ФБ пиксель), забирает с порта эту информацию и добавляет к своей обычной. В итоге компания имеет возможности соотнести действия браузера и вашу физическую трубку.
На выходе
⁃ по идее куки метрики должны довольно быстро протухать и меняться (что-то вроде 30 дней), но на деле у Я есть способы привязать разные куки к одной ОС за долгое время
⁃ сброс кук не работает
⁃ по идее на разных сайтах висят разные куки, но на деле ваши посещения на разных сайтах легко привязываются друг к другу
⁃ инкогнито режим не спасет
⁃ разрешения андроид не спасут
⁃ активность в разных браузерах привязывается друг к другу
И еще что неприятно, что сведения, которые заанонсило приложение, теоретически, может прочитать не один только Яндекс, а любой, кто понял, как это работает.
А вы говорите, зачем им хранить всю вашу историю за все года.
Душная версия на Хабре
P.S. Яндекс начал использовать технологию в 2017-м, экстремисты в 2024-м.
P.P.S. На iOS по какой-то причине этот хак не используется. Хотя специалисты говорят, что технически возможен. Возможно, разработчики просто боятся банхамера от Эпла, а от Гугла - нет 😄
Telegram
Архитектор Данных
Huge Data
На этой неделе общался с боссами дата офиса ВК. Господа управляют всеми данными 3 соцсетей группы ВК, а также ВК Видео, РуСтора, и многих десятков других бизнес-юнитов группы. Масштабы впечатляют. Счет идет на сотни петабайт полезных данных, а…
На этой неделе общался с боссами дата офиса ВК. Господа управляют всеми данными 3 соцсетей группы ВК, а также ВК Видео, РуСтора, и многих десятков других бизнес-юнитов группы. Масштабы впечатляют. Счет идет на сотни петабайт полезных данных, а…
😱11🤬8✍5👍1😭1
Forwarded from Данные на стероидах
Мы обещали провести прямой эфир про Data Lakehouse с экспертами? Мы его проводим.
23 июля в 17:00 присоединяйтесь к трансляции прямо в Telegram. Ждем ваши вопросы уже сейчас 🤔
О чем будем разговаривать
🔷 Типичный БигДата ландшафт крупной российской компании. Какие типовые челенжи есть.
🔷 Зачем придуман Data Lakehouse. Какие типовые проблемы он решает.
🔷 Зачем +1 технология? Почему нельзя дальше ехать на Hadoop + Greenplum + ClickHouse.
🔷 Data Lakehouse: эволюция или революция.
🔷 Data Lakehouse: модный хайп или можно уже приносить в прод.
🔷 Какие типовые трудности бывают с решением.
Спикеры
🔷 Алексей Белозерский, руководитель команды Big Data Services VK Cloud, компания VK Tech
🔷 Вадим Белов, руководитель системной разработки DMP, компания Х5 Group.
Присоединяйтесь к эфиру
23 июля в 17:00 присоединяйтесь к трансляции прямо в Telegram. Ждем ваши вопросы уже сейчас 🤔
О чем будем разговаривать
🔷 Типичный БигДата ландшафт крупной российской компании. Какие типовые челенжи есть.
🔷 Зачем придуман Data Lakehouse. Какие типовые проблемы он решает.
🔷 Зачем +1 технология? Почему нельзя дальше ехать на Hadoop + Greenplum + ClickHouse.
🔷 Data Lakehouse: эволюция или революция.
🔷 Data Lakehouse: модный хайп или можно уже приносить в прод.
🔷 Какие типовые трудности бывают с решением.
Спикеры
🔷 Алексей Белозерский, руководитель команды Big Data Services VK Cloud, компания VK Tech
🔷 Вадим Белов, руководитель системной разработки DMP, компания Х5 Group.
Присоединяйтесь к эфиру
❤4👍4✍3
Запись стрима "Разговоры на Архитекторском" с Вадимом Беловым, X5.
-----------------------------
Архитектор данных
-----------------------------
-----------------------------
Архитектор данных
-----------------------------
❤6👏2👍1
Инсайды из «Разговоров на архитекторском» с Вадимом Беловым, Head of DMP X5.
Про хранилища данных
1️⃣ Зрелое хранилище - это когда процессы-потребители данных ходят в ХД напрямую, минуя этап обратного ETL, загрузки данных батчами из подготовленных витрин куда-то в отдельную продовую систему.
2️⃣ Много разнородных потребителей - это реальность современного развитого ХД, с высокой ожидаемой ценностью для бизнеса. Проблема роста - в росте количества и разнообразия потребителей в большей степени, чем в объеме данных.
3️⃣ Стриминг и суб-минутные / секундные прогрузки данных: 10 лет назад мечта, сегодня - реальность и необходимость.
4️⃣ Транзакционность в аналитической системе - упрощает код, упрощает и ускоряет работу дата инженеров, понижает требуемую квалификацию дата инженера. Очень приятно работать со сложной системой так, будто это классическая СУБД с транзакциями.
Про лейкхаус
1️⃣ Ключевая технология, отличающая Lake и LakeHouse - формат данных и транзакционность.
2️⃣ Лейкхаус помогает убрать ненужные перегрузки данных из системы в систему. Причем надо понимать, что каждая продовая переливка из А в Б это а) стейджинговые и промежуточные слои, многократное дублирование данных, б) код, в) команда, которая поддерживает код и пайплайны, г) доп нагрузка на чтение в А и запись в Б. Если можно этого не делать, то получаем огромную экономию в лонг-ране.
3️⃣ «Старый» стек (Greenplum + Hadoop, + Clickhouse + …) - зоопарк. Лейкхаус - тоже зоопарк. Нельзя уйти от зоопарка технологий, но можно выбрать зоопарк себе по вкусу, в котором приятнее жить.
4️⃣ Развитие технологий спиральное. Сейчас виток разделения вычислений и хранения, рано или поздно сольемся обратно. Но текущий тренд - разделение.
5️⃣ Точно будем пилить свой мета-каталог. Опен-сорсные не устраивают по своей зрелости.
6️⃣ Тренд - умные метакаталоги. Нужен развитый RBAC на уровне каталога. Нужны умные метаданные, развитые кеши данных и мета-данных. Нужны элементы дата-гавернанс на уровне мета-каталога. Дата контракты на уровне метастора - в Gravitino уже есть.
Про экономику данных и миграцию
💯 Первые 100 ТБ мигрировали с Data Vault в Greenplum на Data Vault в Lakehouse за 1-2 месяца.
2️⃣ Лейкхаус дает больший оверхед на старте по железу, большие требования к сети. Но это окупается за счет того что одна команда работает со всеми юз-кейсами данных. Выгоднее купить больше железа, но обойтись одной командой разработки, одним релизным процессом, одной проверкой качества и т.д.
3️⃣ Также получаем более дешевое и быстрое развитие по росту объема и сложности данных. И технологическую модульность.
4️⃣ Эффективен путь RnD и пилотов. Пробуйте в облаках, где много готовых сервисов от многих вендоров. Пробуйте у себя на железе - для грамотного ДевОпса развернуть лейкхаус из доступных компонентов - тривиальная задача
5️⃣ Тестируйтесь на своих данных и своих задачах перед внедрением. Любые попугаи публичных тестов нерелевантны.
-----------------------------
Запись "Разговоров"
-----------------------------
Архитектор данных
-----------------------------
Про хранилища данных
1️⃣ Зрелое хранилище - это когда процессы-потребители данных ходят в ХД напрямую, минуя этап обратного ETL, загрузки данных батчами из подготовленных витрин куда-то в отдельную продовую систему.
2️⃣ Много разнородных потребителей - это реальность современного развитого ХД, с высокой ожидаемой ценностью для бизнеса. Проблема роста - в росте количества и разнообразия потребителей в большей степени, чем в объеме данных.
3️⃣ Стриминг и суб-минутные / секундные прогрузки данных: 10 лет назад мечта, сегодня - реальность и необходимость.
4️⃣ Транзакционность в аналитической системе - упрощает код, упрощает и ускоряет работу дата инженеров, понижает требуемую квалификацию дата инженера. Очень приятно работать со сложной системой так, будто это классическая СУБД с транзакциями.
Про лейкхаус
1️⃣ Ключевая технология, отличающая Lake и LakeHouse - формат данных и транзакционность.
2️⃣ Лейкхаус помогает убрать ненужные перегрузки данных из системы в систему. Причем надо понимать, что каждая продовая переливка из А в Б это а) стейджинговые и промежуточные слои, многократное дублирование данных, б) код, в) команда, которая поддерживает код и пайплайны, г) доп нагрузка на чтение в А и запись в Б. Если можно этого не делать, то получаем огромную экономию в лонг-ране.
3️⃣ «Старый» стек (Greenplum + Hadoop, + Clickhouse + …) - зоопарк. Лейкхаус - тоже зоопарк. Нельзя уйти от зоопарка технологий, но можно выбрать зоопарк себе по вкусу, в котором приятнее жить.
4️⃣ Развитие технологий спиральное. Сейчас виток разделения вычислений и хранения, рано или поздно сольемся обратно. Но текущий тренд - разделение.
5️⃣ Точно будем пилить свой мета-каталог. Опен-сорсные не устраивают по своей зрелости.
6️⃣ Тренд - умные метакаталоги. Нужен развитый RBAC на уровне каталога. Нужны умные метаданные, развитые кеши данных и мета-данных. Нужны элементы дата-гавернанс на уровне мета-каталога. Дата контракты на уровне метастора - в Gravitino уже есть.
Про экономику данных и миграцию
2️⃣ Лейкхаус дает больший оверхед на старте по железу, большие требования к сети. Но это окупается за счет того что одна команда работает со всеми юз-кейсами данных. Выгоднее купить больше железа, но обойтись одной командой разработки, одним релизным процессом, одной проверкой качества и т.д.
3️⃣ Также получаем более дешевое и быстрое развитие по росту объема и сложности данных. И технологическую модульность.
4️⃣ Эффективен путь RnD и пилотов. Пробуйте в облаках, где много готовых сервисов от многих вендоров. Пробуйте у себя на железе - для грамотного ДевОпса развернуть лейкхаус из доступных компонентов - тривиальная задача
5️⃣ Тестируйтесь на своих данных и своих задачах перед внедрением. Любые попугаи публичных тестов нерелевантны.
-----------------------------
Запись "Разговоров"
-----------------------------
Архитектор данных
-----------------------------
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
Запись стрима "Разговоры на Архитекторском" с Вадимом Беловым, X5.
-----------------------------
Архитектор данных
-----------------------------
-----------------------------
Архитектор данных
-----------------------------
👍10
ИИ Разбор "Диалогов"
Разбор записи с помощью OpenSource AI модели. Это не могучий ChatGPT или Gemini, а модель, развернутая на ВМ с Видеокартой в облаке. Такого качества распознавания можно достигнуть без утечек материалов ваших видео-встреч в недружественные дата-центры.
Можно сравнить с ручным разбором.
Разбор записи с помощью OpenSource AI модели. Это не могучий ChatGPT или Gemini, а модель, развернутая на ВМ с Видеокартой в облаке. Такого качества распознавания можно достигнуть без утечек материалов ваших видео-встреч в недружественные дата-центры.
Можно сравнить с ручным разбором.
**Краткая версия транскрипта стрима: Алексей Белозерский и Вадим Белов о больших данных и Lakehouse**
**Основные темы:**
1. **Путь к Lakehouse**
- Вадим рассказывает, как его работа с Hadoop и Exadata привела к пониманию ограничений классических решений (Greenplum, Hadoop). Рост объемов данных и разнообразие нагрузок (аналитика, потоковые данные, ML) потребовали более гибкой архитектуры.
- **Проблемы классического подхода**: зоопарк технологий (Greenplum, Spark, ClickHouse), высокий TCO, сложности интеграции, дублирование данных.
2. **Lakehouse как эволюция**
- **Ключевая идея**: объединение преимуществ Data Lake (дешевое хранение) и Data Warehouse (консистентность, ACID-транзакции).
- **Форматы данных**: Delta и Iceberg обеспечивают ACID-свойства, версионность и эффективное управление данными.
- **Преимущества**:
- Упрощение архитектуры (меньше зоопарка).
- Поддержка разнородных нагрузок (аналитика, стриминг, ML) в одном стеке.
- Гибкость: можно менять компоненты (S3, Apache Ozone) без смены логики.
3. **Практические примеры**
- **Реал-тайм аналитика**: обработка потоковых данных через CDC (Debezium), интеграция с Iceberg для актуализации данных в секундном масштабе.
- **Снижение TCO**: унификация стека снижает затраты на хранение и обработку, устраняет дублирование.
4. **Вызовы и рекомендации**
- **Риски перехода**: необходимость тестирования на реальных данных, обучение команды, интеграция с процессами управления данными (governance, безопасность).
- **Советы для внедрения**:
- Начать с пилотных проектов в облаках (например, S3 + Kubernetes).
- Использовать open-source (Delta, Iceberg) с осторожностью: важно тестировать.
- Акцент на управление метаданными и правами доступа (каталоги, как Graviton).
5. **Футурологические взгляды**
- **Тренды**: переход к стриминговым архитектурам (Streamhouse), оптимизация метаданных (например, через кэширование в метакаталогах).
- **Ограничения**: пока нет «серебряной пули» — выбор зависит от конкретных задач компании.
**Заключение:**
Lakehouse — это не революция, а эволюция, позволяющая справляться с современными вызовами больших данных. Успех внедрения зависит от баланса между технологическим стеком, процессами управления данными и гибкостью команды.
Telegram
Архитектор Данных
Запись стрима "Разговоры на Архитекторском" с Вадимом Беловым, X5.
-----------------------------
Архитектор данных
-----------------------------
-----------------------------
Архитектор данных
-----------------------------
👍7
Ребенок ИИ уже достаточно вырос и окреп. Он уже получил начальный заряд знаний.
Дальше справится сам.
Репост:
Дальше справится сам.
Репост:
Forwarded from FastSaltTimes.com
This media is not supported in your browser
VIEW IN TELEGRAM
Демис Хассабис такой говорит:
«Я не беспокоюсь о том, что закончится качественная человеческая информация. У нас уже достаточно данных, чтобы создавать мощные системы и симуляции, которые генерируют полезные синтетические данные. Мы уже на этом этапе».
Высказывание Хассабиса, главы DeepMind, можно интерпретировать как намёк на снижение зависимости ИИ от живых людей. ИИ уже наелся человеческими данными — текстами, диалогами, изображениями, кодом и т.д. Теперь можно использовать симуляции и синтетические данные, чтобы продолжать обучение моделей. Не надо собирать новые данные у людей — ИИ уже может генерировать «достаточно реалистичные» данные сам для себя. Если модель уже поняла «как устроен мир» на основе огромных объемов текстов, она может сама создавать новые обучающие примеры, основанные на своих «пониманиях» — и дальше учиться на них. Можно сказать, что люди уже передали ИИ «базовую библиотеку жизни», а дальше он способен дописывать главы сам. Это как бы и вдохновляет, и пугает одновременно.
«Я не беспокоюсь о том, что закончится качественная человеческая информация. У нас уже достаточно данных, чтобы создавать мощные системы и симуляции, которые генерируют полезные синтетические данные. Мы уже на этом этапе».
Высказывание Хассабиса, главы DeepMind, можно интерпретировать как намёк на снижение зависимости ИИ от живых людей. ИИ уже наелся человеческими данными — текстами, диалогами, изображениями, кодом и т.д. Теперь можно использовать симуляции и синтетические данные, чтобы продолжать обучение моделей. Не надо собирать новые данные у людей — ИИ уже может генерировать «достаточно реалистичные» данные сам для себя. Если модель уже поняла «как устроен мир» на основе огромных объемов текстов, она может сама создавать новые обучающие примеры, основанные на своих «пониманиях» — и дальше учиться на них. Можно сказать, что люди уже передали ИИ «базовую библиотеку жизни», а дальше он способен дописывать главы сам. Это как бы и вдохновляет, и пугает одновременно.
😁9🤔6❤2🙈2🤡1
Привет, дорогой дайджест! Постараюсь ответить.
Первое, на самом деле, это обе системы не про скорость. Про скорость - Clickhouse, DuckDB, Tarantool. А эти про удобство. Там много где платится скоростью за удобство. За наличие [почти] честных транзакций, или за способность съедать огромные «крокодилы» SQL запросов, где 40 раз написано слово JOIN. Сравнивать по скорости две заранее архитектурно тормозные вещи - забавное упражнение.
Второе. Скорость сети в 100 ГБит/с (12500 мб/сек) сейчас не особо кого удивит. На ноду! Эта скорость вполне сравнима с дисками образца 4-5 летней давности. То есть современные Трины примерно по скорости как немного старые Гринпламы. Терпимо вполне.
Третье. А в какой нагрузке измеряем? Узкое место гринплама в большой организации - число потоков выполнения. А если нам надо concurrency=100? ГП известен своей непроходимостью при большом числе параллельных потоков выполнения. А что если нам надо нарастить внезапно число потоков? Тут нам на помощь и придет разделение compute-storage (на самом деле compute-metastore-storage) и возможность нарастить потоки чтения в конкретный датасет.
Одним словом, есть общее правило - удобство выше перформанса. Мы уже все давно сидим на виртуализации, облаках, с детачнутыми сторажами дисков и т.д. Так же и тут.
И Четвертое. Мы все инженеры, и если стоит задача в «правильном» сравнении, то его всегда можно придумать. Например, адски зажать Гринплам по ресурсам, а у него оверхедов много. Трино более неприхотливае, там одна джава машина вместо 4-8 сегментов-постгресов. Запусти на 6 облачных ядрах это все - вот тебе и будет нужная картинка.
Как мы говорили на самом стриме - только тесты на твоих датасетах под твоей нагрузкой дадут тебе адекватную картину. Любые тесты из интеренетов - булшит.
Первое, на самом деле, это обе системы не про скорость. Про скорость - Clickhouse, DuckDB, Tarantool. А эти про удобство. Там много где платится скоростью за удобство. За наличие [почти] честных транзакций, или за способность съедать огромные «крокодилы» SQL запросов, где 40 раз написано слово JOIN. Сравнивать по скорости две заранее архитектурно тормозные вещи - забавное упражнение.
Второе. Скорость сети в 100 ГБит/с (12500 мб/сек) сейчас не особо кого удивит. На ноду! Эта скорость вполне сравнима с дисками образца 4-5 летней давности. То есть современные Трины примерно по скорости как немного старые Гринпламы. Терпимо вполне.
Третье. А в какой нагрузке измеряем? Узкое место гринплама в большой организации - число потоков выполнения. А если нам надо concurrency=100? ГП известен своей непроходимостью при большом числе параллельных потоков выполнения. А что если нам надо нарастить внезапно число потоков? Тут нам на помощь и придет разделение compute-storage (на самом деле compute-metastore-storage) и возможность нарастить потоки чтения в конкретный датасет.
Одним словом, есть общее правило - удобство выше перформанса. Мы уже все давно сидим на виртуализации, облаках, с детачнутыми сторажами дисков и т.д. Так же и тут.
И Четвертое. Мы все инженеры, и если стоит задача в «правильном» сравнении, то его всегда можно придумать. Например, адски зажать Гринплам по ресурсам, а у него оверхедов много. Трино более неприхотливае, там одна джава машина вместо 4-8 сегментов-постгресов. Запусти на 6 облачных ядрах это все - вот тебе и будет нужная картинка.
Как мы говорили на самом стриме - только тесты на твоих датасетах под твоей нагрузкой дадут тебе адекватную картину. Любые тесты из интеренетов - булшит.
✍8❤6🔥4👍3💯3
Почтенная дама RDBMS:
Вот смотри, LLM, и мне и тебе посылают запросы. Для того, чтобы запросы работали, как надо, требуется некоторым образом обученный инженер со специфическими навыками.
Фактически и SQL-аналитик, и промпт-инженер излагают ЧТО они хотят получитьна некотором птичьем языке, а не тот процесс КАК мы это должны собрать.
Я, почтенная СУБД, делаю это все с 90-х, а ты появилась только сейчас.
Но Искуственный Интеллект - это почему-то ТЫ.
Ответ (ваши варианты):
.........................................
Вот смотри, LLM, и мне и тебе посылают запросы. Для того, чтобы запросы работали, как надо, требуется некоторым образом обученный инженер со специфическими навыками.
Фактически и SQL-аналитик, и промпт-инженер излагают ЧТО они хотят получить
Я, почтенная СУБД, делаю это все с 90-х, а ты появилась только сейчас.
Но Искуственный Интеллект - это почему-то ТЫ.
Ответ (ваши варианты):
.........................................
😁11❤3👏3⚡1
Рабочая проверка №2 - для кандидатов
В ходе беседы находишь пункт, который
а) кандидат явно не знает
б) важен для тебя / твоей позиции
Прозрачно говоришь, что вот этого - не хватает.
Встречаешься через неделю и смотришь, если есть прогресс конкретно в этом пункте. Все остальные опыт и заслуги не важны, только этот. Затраты по времени - 15 минут, но все понятно.
В ходе беседы находишь пункт, который
а) кандидат явно не знает
б) важен для тебя / твоей позиции
Прозрачно говоришь, что вот этого - не хватает.
Встречаешься через неделю и смотришь, если есть прогресс конкретно в этом пункте. Все остальные опыт и заслуги не важны, только этот. Затраты по времени - 15 минут, но все понятно.
👍10😁2⚡1❤1
У нас было (Жиза)
💾 17 ETL джобов из ниоткуда в никуда, которые загружали под крышку MPP базу на 50 ТБайт
💾 Красивый технологичный AI Layer который делал непонятно что
💾 Дата Каталог который никто не обновлял 4 года. И никто не смотрел в него
💾 Алерты на качество данных, замьюченные у всех
💾 Ручной загружатор CSV
💾 5 аналитиков, которые рисовали сводные в экселе и вставляли их картинками в Павер Поинт. На разных слайдах были разные цифры по месячной выручке.
Please open Telegram to view this post
VIEW IN TELEGRAM
5😁15
Вопросы со стрима часть 2
Спасибо, Сергей Сафронов, за вопрос!
1️⃣ Если не говорить про управляемые облака, то, кажется, что ограничением по по объему данных для унифицированного LakeHouse на S3 opensource движках (Minio, Ceph) будет примерно 1ПБ. А если нужно больше, то, или смотреть в сторону облаков, или делать несколько кластеров S3 с усложнением и архитектуры хранения-обработки?
Для дата команды S3 - базовая инфраструктура. Сколько там кластеров, какие они и как распределены по ЦОДам - вопрос к инфраструктуре. Сейчас довольно много способов получить S3 либо в SaaS, либо развернуть у себя в контуре - как самостоятельно, так и просто купив S3 как продукт или ПАК.
2️⃣ Кажется, что Вадим несколько лукавил про простоту и быстроту миграции на LakeHouse данных. Все-таки, факторы бэклога инженеров, их компетенции в новых технологиях, сетевая доступность и разная конфигурация (разное шардирование) кластеров источника и приемника, разный формат хранения, возможно, разная архитектура слоев данных и многое другое. Поэтому, слабо верится, с учетом этого, что миграция может пройти за месяц (если я правильно понял срок)
Тут речь шла про прикладную миграцию данных. Data Vault в Гринпламе на Data Vault в Lakehouse. Для такого не нужно много времени и переделки архитектуры.
3️⃣ Есть ли какие-то best practice по оптимальной архитектуре слоев данных в LakeHouse с учетом разных движков доступа (Trino +) и разных сценариев использования? С точки зрения технических ограничений и особенностей (для примера, в ClickHouse нет смысла делать Data Vault и вообще 3NF)
В крупных организациях почти везде DV так или иначе. Плохеет ли от ДатаВолта распределенной системе - конечно плохеет. Но мы снова платим оверхедом за удобство и скорость разработки. К тому же проблему «неудобной» для МРР архитектуры данных можно решить добавив ресурсов в некоторых разумных проблемах.
Нет смысла подгонять архитектуру данных под инструмент. Пусть работает, как нам удобно, тупая железяка! 😎
-----------------------------
Разбор стрима
Вопросы со стрима - Часть 1
-----------------------------
💾 💾 💾 💾 💾
Спасибо, Сергей Сафронов, за вопрос!
Для дата команды S3 - базовая инфраструктура. Сколько там кластеров, какие они и как распределены по ЦОДам - вопрос к инфраструктуре. Сейчас довольно много способов получить S3 либо в SaaS, либо развернуть у себя в контуре - как самостоятельно, так и просто купив S3 как продукт или ПАК.
Тут речь шла про прикладную миграцию данных. Data Vault в Гринпламе на Data Vault в Lakehouse. Для такого не нужно много времени и переделки архитектуры.
В крупных организациях почти везде DV так или иначе. Плохеет ли от ДатаВолта распределенной системе - конечно плохеет. Но мы снова платим оверхедом за удобство и скорость разработки. К тому же проблему «неудобной» для МРР архитектуры данных можно решить добавив ресурсов в некоторых разумных проблемах.
Нет смысла подгонять архитектуру данных под инструмент. Пусть работает, как нам удобно, тупая железяка! 😎
-----------------------------
Разбор стрима
Вопросы со стрима - Часть 1
-----------------------------
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
Инсайды из «Разговоров на архитекторском» с Вадимом Беловым, Head of DMP X5.
Про хранилища данных
1️⃣ Зрелое хранилище - это когда процессы-потребители данных ходят в ХД напрямую, минуя этап обратного ETL, загрузки данных батчами из подготовленных витрин…
Про хранилища данных
1️⃣ Зрелое хранилище - это когда процессы-потребители данных ходят в ХД напрямую, минуя этап обратного ETL, загрузки данных батчами из подготовленных витрин…
👍7
Эпоха сражающихся хранилищ
Из недавней беседы с весьма уважаемым ИТ-лордом. Типичная динамика КХД в организации.
Сначала в конце 2000-ных хранилища строились в основном для финансовой отчетности. Главная цель - отчеты для собственников и топов на тему PnL и основных управленческих метрик. Как правило за это ХД либо отвечает, либо непосредственно производит на свет финансовый отдел. Назовем эту структуру ФинХД.
ФинХД быстро окукливается в себе и копает ров по периметру. Когда у кого-то еще появляется потребность в данных, он как правило отправляется далеко и надолго - у ФинХД свои ресурсы, роадмапы, беклоги, спринты.
Идет время, и от безысходности в других отделах появляются свои ЭрзацХД, хоть как-то отвечающие их интересам. Стек данных фрагментируется, появляются все связанные с этим болячки.
Болячки проступают до руководства - немудрено! Где у вас единая версия правды? Сколько клиентов за последний месяц? Почему настолько разные цифры от разных людей в ответ на самые простые вопросы? И принимается решение делать ЕдиноеХД. С вероятностью 98% на роль ЕдиногоХД назначается команда ФинХД, как самого аппаратно весомого. Привычки замкнуться в своих роадмапах и посылать всех в путешествие от переформатирование ФинХД в ЕдиноеХД не меняются.
Наступает еще больший разброд и разлад с переходом во все виды аппаратных конфликтов. Эпоха сражающихся хранилищ.
В 2025 году компания ждет сияющего CDO Цинь Шихуанди, который прекратит эпоху раздробленности и устроит «все под Небесами».
Не всегда гуманными методами.
Из недавней беседы с весьма уважаемым ИТ-лордом. Типичная динамика КХД в организации.
Сначала в конце 2000-ных хранилища строились в основном для финансовой отчетности. Главная цель - отчеты для собственников и топов на тему PnL и основных управленческих метрик. Как правило за это ХД либо отвечает, либо непосредственно производит на свет финансовый отдел. Назовем эту структуру ФинХД.
ФинХД быстро окукливается в себе и копает ров по периметру. Когда у кого-то еще появляется потребность в данных, он как правило отправляется далеко и надолго - у ФинХД свои ресурсы, роадмапы, беклоги, спринты.
Идет время, и от безысходности в других отделах появляются свои ЭрзацХД, хоть как-то отвечающие их интересам. Стек данных фрагментируется, появляются все связанные с этим болячки.
Болячки проступают до руководства - немудрено! Где у вас единая версия правды? Сколько клиентов за последний месяц? Почему настолько разные цифры от разных людей в ответ на самые простые вопросы? И принимается решение делать ЕдиноеХД. С вероятностью 98% на роль ЕдиногоХД назначается команда ФинХД, как самого аппаратно весомого. Привычки замкнуться в своих роадмапах и посылать всех в путешествие от переформатирование ФинХД в ЕдиноеХД не меняются.
Наступает еще больший разброд и разлад с переходом во все виды аппаратных конфликтов. Эпоха сражающихся хранилищ.
В 2025 году компания ждет сияющего CDO Цинь Шихуанди, который прекратит эпоху раздробленности и устроит «все под Небесами».
Не всегда гуманными методами.
1
Архитектор Данных
Почтенная дама RDBMS: Вот смотри, LLM, и мне и тебе посылают запросы. Для того, чтобы запросы работали, как надо, требуется некоторым образом обученный инженер со специфическими навыками. Фактически и SQL-аналитик, и промпт-инженер излагают ЧТО они хотят…
"Порог входа, бабушка. Все дело - в пороге входа"
❤5😁4👍1👏1
Forwarded from Наука и университеты
#Прямая_речь
Декан экономического факультета МГУ Александр Аузан об искусственном интеллекте в образовании:
<…..>
Источник
Декан экономического факультета МГУ Александр Аузан об искусственном интеллекте в образовании:
«ИИ распространяется как торфяной пожар - скрыто, но неизбежно. Рискну предположить, что нынешняя система школьного и высшего образования из-за этого изменится даже быстрее, чем рынок труда. В ближайшие 3-5 лет она просто сгорит с привычными нам контрольными, тестами и экзаменами.
Что такое экзамен сегодня? Это микрокамера в пуговице, микронаушник в ухе и нейросеть в смартфоне. Вместо ученика экзамен сдает ИИ, а с другой стороны его ответы вместо преподавателя проверяет тоже ИИ. Результат известен заранее.
Конечно, в особых случаях можно экзаменовать так, чтобы никто не смог воспользоваться техникой, но в масштабах всей системы это невозможно и, в общем-то, бессмысленно. Люди все равно будут чем дальше, тем чаще перекладывать решение широкого круга задач на ботов. Это не остановить, как нельзя было остановить переход от ручного труда к машинному»
<…..>
«Вызов системе образования заключается в том, что для эффективного применения ИИ человеку требуется высококачественное, фундаментальное и желательно междисциплинарное образование. В противном случае не человек будет контролировать машину, а машина будет зомбировать человека, незаметно подсовывая ему свои ошибки».
Источник
👍14💯3
Эпохи
Биткойн в 2012 году: Прикольно, но в реальности не взлетит
Биткойн в 2017 году: Похоже, будет работать, но пока неясно как именно.
Биткойн в 2022 году: Неплохо работает, но кто ж такое разрешит!
Биткойн / Крипто в 2025 году: Давайте решать проблему с госдолгом США путем выпуска стейблкойнов!
——————————————
ИИ в 2022 году: Прикольно, но в реальности не взлетит
ИИ в 2024 году: Будет работать, но пока неясно как
ИИ в 2025-2026: Неплохо, но кто ж такое разрешит!
ИИ в 2027-2028: Давайте решать [Большую проблему] путем [как-то]
—————————————
Какая проблема и какой путь решения?
Биткойн в 2012 году: Прикольно, но в реальности не взлетит
Биткойн в 2017 году: Похоже, будет работать, но пока неясно как именно.
Биткойн в 2022 году: Неплохо работает, но кто ж такое разрешит!
Биткойн / Крипто в 2025 году: Давайте решать проблему с госдолгом США путем выпуска стейблкойнов!
——————————————
ИИ в 2022 году: Прикольно, но в реальности не взлетит
ИИ в 2024 году: Будет работать, но пока неясно как
ИИ в 2025-2026: Неплохо, но кто ж такое разрешит!
ИИ в 2027-2028: Давайте решать [Большую проблему] путем [как-то]
—————————————
Какая проблема и какой путь решения?
1👍6❤4😁2
Forwarded from System Design & Highload (Alexey Rybak)
Погружение в Лейкхаус! Офигенная новость, ребят – качаем, наконец, DWH! В следующую среду 13-го августа в 18:30 msk в Zoom состоится встреча с Алексеем Белозерским, руководителем группы BigData Services VK Cloud.
Тема встречи “Погружение в Лейкхаус: почему все о нём говорят”.
Обсудим:
- Ретроспектива развития хранилищ данных. Принципы и компоненты. Озера vs DWH. ETL vs event streaming. Витрины. Базовые классы компонент: базы и подтипы, распределенные хранилища, стриминг и процессинг, in-memory grids. HDFS/Hadoop, Spark, колоночные базы (Clickhouse, Vertica etc), Greenplum/Greengage, Exasol, Snowflake и тд и трансформация в современный стэк, Trino/Iceberg/S3 или in-memory processing, аналитические embedded-базы типа DuckDB
- Тренды, разделение compute/storage, in-memory вычисления. Почему сейчас старые методы не едут. Какие требования от современного бизнеса и почему старые ХД не удовлетворяют им: рост объемов, рост аналитической нагрузки, требования регуляторов в разных странах.
- Как это все расшивается на "новом" стеке из Лейкхауса - и почему об этом все говорят.
Встреча состоится в Zoom, в этот раз она свободна и для сообщества Devhands Club (слушатели наших курсов) и для всех остальных желающих принять участие в живой дискуссии, но обязательно нужно быть авторизованным в Zoom.
Topic: Devhands Open Sessions: Lakehouse deep-dive (A. Belozersky)
Time: Aug 8, 2025 06:30 PM Istanbul/MSK
Zoom: https://us06web.zoom.us/j/85409552470?pwd=mfmnt6aRvmllJB1iLx8Ws4sdiIqVD3.1
Добарить в календарь: https://addcal.io/e/k0dw9sgjk8ai
Приходите, приводите друзей!
Тема встречи “Погружение в Лейкхаус: почему все о нём говорят”.
Обсудим:
- Ретроспектива развития хранилищ данных. Принципы и компоненты. Озера vs DWH. ETL vs event streaming. Витрины. Базовые классы компонент: базы и подтипы, распределенные хранилища, стриминг и процессинг, in-memory grids. HDFS/Hadoop, Spark, колоночные базы (Clickhouse, Vertica etc), Greenplum/Greengage, Exasol, Snowflake и тд и трансформация в современный стэк, Trino/Iceberg/S3 или in-memory processing, аналитические embedded-базы типа DuckDB
- Тренды, разделение compute/storage, in-memory вычисления. Почему сейчас старые методы не едут. Какие требования от современного бизнеса и почему старые ХД не удовлетворяют им: рост объемов, рост аналитической нагрузки, требования регуляторов в разных странах.
- Как это все расшивается на "новом" стеке из Лейкхауса - и почему об этом все говорят.
Встреча состоится в Zoom, в этот раз она свободна и для сообщества Devhands Club (слушатели наших курсов) и для всех остальных желающих принять участие в живой дискуссии, но обязательно нужно быть авторизованным в Zoom.
Topic: Devhands Open Sessions: Lakehouse deep-dive (A. Belozersky)
Time: Aug 8, 2025 06:30 PM Istanbul/MSK
Zoom: https://us06web.zoom.us/j/85409552470?pwd=mfmnt6aRvmllJB1iLx8Ws4sdiIqVD3.1
Добарить в календарь: https://addcal.io/e/k0dw9sgjk8ai
Приходите, приводите друзей!
2🔥9👍4😎3