Часто слышу вопрос: «А зачем нам отдельная выделенная команда данных? Вон у нас все разработчики умеют в SQL, все менеджеры на ты с Экселем. Сами разве не справимся?»
Конечно справитесь! Но есть нюанс.
Возьмем аналогию.
Каждый может взять гитару и на ней набренчать. Каждый может взять баскетбольный мяч и начать закидывать его в кольцо. И более того, порядок действий, движения, у вас и профессионального музыканта/баскетболиста будут одинаковыми.
Но не одинаковым будет результат. Причем не чуть-чуть неодинаковым, а сильно неодинаковым. Именно из-за этой разницы в результате и существуют профессионалы.
Точно также как есть люди, занимающиеся профессиональным звуко-извлечением, существуют люди, профессионально занимающиеся извлечением полезностей из данных.
Заметьте, это никак не отменяет, что есть процент людей, которые очень уверенно играют на гитаре или очень неплохо играют в баскетбол. Помимо своей основной профессии. Но таких мало.
Конечно справитесь! Но есть нюанс.
Возьмем аналогию.
Каждый может взять гитару и на ней набренчать. Каждый может взять баскетбольный мяч и начать закидывать его в кольцо. И более того, порядок действий, движения, у вас и профессионального музыканта/баскетболиста будут одинаковыми.
Но не одинаковым будет результат. Причем не чуть-чуть неодинаковым, а сильно неодинаковым. Именно из-за этой разницы в результате и существуют профессионалы.
Точно также как есть люди, занимающиеся профессиональным звуко-извлечением, существуют люди, профессионально занимающиеся извлечением полезностей из данных.
Заметьте, это никак не отменяет, что есть процент людей, которые очень уверенно играют на гитаре или очень неплохо играют в баскетбол. Помимо своей основной профессии. Но таких мало.
❤6💯6👍3🔥2
Говорят, выглядит страшно.
Хотя что там страшного, умеючи.
Половина в облаке поднимается. Сиди себе и кнопочки тыкай
Хотя что там страшного, умеючи.
Половина в облаке поднимается. Сиди себе и кнопочки тыкай
👍7❤3😁2
Forwarded from Русский ИТ бизнес (Максим Кульгин)
Техлид с опытом в дата-инжиниринге, выложил на Reddit в сабреддите r/dataengineering свой взгляд на open source инструменты для 2025 года. См. картинку, ну очень сложно - кликабельная, кстати.
Он три года работал в изолированных средах, где облака были под запретом, и сосредотачивался больше на платформенной части, чем на работе с данными. За это время к задачам дата-инженеров добавились DevOps, MLOps, LLM, RAG и дата-лейкхаусы, помимо классических дата-стеков и хранилищ.
Его подборка - набор инструментов вроде Apache Airflow, Spark, Kafka, dbt, PostgreSQL, ClickHouse и других, которые он использует для разных кейсов. Например, для оркестрации - Airflow, для аналитики - Superset, для машинного обучения - MLflow и JupyterHub.
В комментариях народ активно обсуждает. Есть идеи добавить Redash для визуализации или Ballista с DataFusion для замены Spark.
Мне одному кажется, что это слишком заморочисто :) ? Прикиньте, сколько надо учиться, чтобы освоить такую специальность?!
Русский ИТ бизнес
Он три года работал в изолированных средах, где облака были под запретом, и сосредотачивался больше на платформенной части, чем на работе с данными. За это время к задачам дата-инженеров добавились DevOps, MLOps, LLM, RAG и дата-лейкхаусы, помимо классических дата-стеков и хранилищ.
Его подборка - набор инструментов вроде Apache Airflow, Spark, Kafka, dbt, PostgreSQL, ClickHouse и других, которые он использует для разных кейсов. Например, для оркестрации - Airflow, для аналитики - Superset, для машинного обучения - MLflow и JupyterHub.
В комментариях народ активно обсуждает. Есть идеи добавить Redash для визуализации или Ballista с DataFusion для замены Spark.
Мне одному кажется, что это слишком заморочисто :) ? Прикиньте, сколько надо учиться, чтобы освоить такую специальность?!
Русский ИТ бизнес
❤5💯3 3🤓1
В композии М.Круга "Кольщик" дан отличный пример хорошего промпт-инжиниринга.
🤣10👍3😁3
Про курсы
Продолжая аналогию.
На курсах гитары (от Скилбокса и Практикума) вас научат четырем аккордам, мотивируя тем что Metallica собирает стадионы и зарабатывает сотни миллионов
Продолжая аналогию.
На курсах гитары (от Скилбокса и Практикума) вас научат четырем аккордам, мотивируя тем что Metallica собирает стадионы и зарабатывает сотни миллионов
Telegram
Архитектор Данных
Часто слышу вопрос: «А зачем нам отдельная выделенная команда данных? Вон у нас все разработчики умеют в SQL, все менеджеры на ты с Экселем. Сами разве не справимся?»
Конечно справитесь! Но есть нюанс.
Возьмем аналогию.
Каждый может взять гитару и на ней…
Конечно справитесь! Но есть нюанс.
Возьмем аналогию.
Каждый может взять гитару и на ней…
😁8💯3🤝3
Рабочая проверка
Отправляешь человеку встречу со странным заголовком, крайне слабо относящуюся к его работе, без описания.
Если не переспросил, не отменил, а просто пришел, то данный персонаж - бездельник и балласт.
Отправляешь человеку встречу со странным заголовком, крайне слабо относящуюся к его работе, без описания.
Если не переспросил, не отменил, а просто пришел, то данный персонаж - бездельник и балласт.
😁8🔥6👏4❤1👍1
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 7❤4🔥2👏1
ИИ Разбор "Диалогов"
Разбор записи с помощью 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 4✍2🤓1
Ребенок ИИ уже достаточно вырос и окреп. Он уже получил начальный заряд знаний.
Дальше справится сам.
Репост:
Дальше справится сам.
Репост:
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 12👍3🔥1👏1