Запись стрима "Разговоры на Архитекторском" с Вадимом Беловым, 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
Forwarded from Greenplum secrets🎩
На заметку
А вы знали, что не каждая транзакция откатывается при ошибке ?
Если pl/pgsql функция абортнулась из-за нехватки места
schema's disk space quota exceeded with name : public
то таблицы, которые были ей созданы не откатываются, а остаются как будто транзакция корректно завершилась.
А вы знали, что не каждая транзакция откатывается при ошибке ?
Если pl/pgsql функция абортнулась из-за нехватки места
schema's disk space quota exceeded with name : public
то таблицы, которые были ей созданы не откатываются, а остаются как будто транзакция корректно завершилась.
😱9😢3🤓2👀2
Друзья, не забудьте сегодня зайти на наш с Алексеем стрим!
Алексей - эксперт в области хайлоада, архитектуры сервисов, кубернетису и другим сложным и полезным вещам!
Будем говорить про аналитический хайлоад и конечно же, Лейкхаусы.
Вопросы напишите в комменты - обязательно постараюсь ответить (со скидкой на то что я в гостях).
Спасибо!
Алексей - эксперт в области хайлоада, архитектуры сервисов, кубернетису и другим сложным и полезным вещам!
Будем говорить про аналитический хайлоад и конечно же, Лейкхаусы.
Вопросы напишите в комменты - обязательно постараюсь ответить (со скидкой на то что я в гостях).
Спасибо!
Telegram
Архитектор Данных
Погружение в Лейкхаус! Офигенная новость, ребят – качаем, наконец, DWH! В следующую среду 13-го августа в 18:30 msk в Zoom состоится встреча с Алексеем Белозерским, руководителем группы BigData Services VK Cloud.
Тема встречи “Погружение в Лейкхаус: почему…
Тема встречи “Погружение в Лейкхаус: почему…
❤4