Yandex Cloud: Data Platform

📈 Рынок больших данных в облаке: разбираем тренды За первое полугодие 2023 года потребление сервисов Yandex Cloud для различных дата-сценариев выросло в 2 раза. Их применяют для построения единого корпоративного хранилища данных, аналитики в реальном времени и других задач при работе с данными. О ключевых изменениях на глобальном рынке данных и о том, как они влияют на развитие Yandex Cloud, читайте в статье. #yacloud_articles

Можете задать вопросы тут, если не успели задать на вебинаре

Поставлять из Кафки в кх с лагом в секунду это стандартная практика, кх к такому хорошо приучен

Ну вот вопрос - будет ли?

Открытие Yandex Scale подошло к концу. Завтра с 11.00 вас ждет второй день конференции. Мы расскажем о главных новостях Yandex Cloud, в тематических треках обсудим подробнее сервисы платформы, а клиенты и партнеры поделятся самыми свежими кейсами. Чтобы не упустить главное, можно составить удобное расписание на сайте конференции. Сегодня мы говорили о том, какой путь за эти 5 лет прошла облачная платформа и чего нам удалось добиться уже сейчас. Это впечатляющие результаты: 🔊 пользователи хранят у нас десятки петабайт информации; 🔊 на платформе запущено более 250 тысяч виртуальных машин; 🔊 количество запросов к IAM превышает 400 тысяч в секунду – это одна из самых высоконагруженных систем. Ещё 5 лет назад эти цифры казались невероятными. Весь этот рост состоялся благодаря вам, нашим пользователям, потому что вы в нас верили. А мы верили в вас. До завтра! 🚀

А можете рассказать почему так лучше не делать? Чтобы понять с какими проблемами столкнёмся

Ну или, как вариант, класть в S3 (раз все равно спарк уже есть в пайплайне), там тем же спарком при необходимости делать микробатчами трансформацию в витрины КХ и уже через КХ давать к ним быстрый доступ

имеет смысл сначала лить в S3, например, если нужно развязать по времени ETL-обработку данных на входе и обновление витринного слоя в клике например, когда несколько разных витрин для разных бизнес-юнитов готовятся раздельными ETL-процессами и появляются в S3 в разное время, а потом синхронизированно обновляются на витринах клика и в дашбордах

Максим, приветствую и тут 🙂 получилось тикет в поддержку завести по проблеме?

Для авторизации через федерацию необходима возможность запустить браузер. На этой машине браузер запустить не получилось

Note that AllowPublicKeyRetrieval=True could allow a malicious proxy to perform a MITM attack to get the plaintext password, so it is False by default and must be explicitly enabled. https://mysqlconnector.net/connection-options/

@kolechenkov Роман, привет! У нас в чатах активно интересуются - нет ли планов по self-hosted DL?

Начали! Присоединяйтесь)

> - так понимаю, аналог google big query? какие ключевые отличия? у big query основной сценарий работы это собственное хранилище. мы же не хотим настаивать на какой-либо технологии хранения, а вместо этого сосредотачиваемся на работу с любыми источниками. в этом плане мы ближе к aws athena иногда источник может быть совсем произвольный, например, бинарные данные. в этом случае мы занимаемся интеграцией с cloud functions, где можно разместить адаптер, переводящий собственные форматы данных в формат, который мы понимаем и можем обрабатывать но общие точки с bigquery, действительно, есть - это решение без выделенных мощностей, которое полностью управляет инфраструктурой

Вроде там запоминается подпись хоста, к кторому коннектишься (как и на любом линуксе). У меня, например ssh ключей пара десятков используется для разных подключений - в ~/.ssh/config прописал какой ключ для какого хоста и с каким username использовать

Привет! Да, спасибо, я это видела. Я пробую LOCATION('pxf://<мое имя бакета/имя папки>?PROFILE=s3:parquet&SERVER="https://storage.yandexcloud.net"') и получаю Invalid server name '&quot;https://storage.yandexcloud.net&quot;'. Явно как-то иначе нужно задавать сервер. Как?

У меня ограничение по железу. РАМ более чем достаточно, а вот СПУ нет. При этом упираемся именно в РАМ при выполнении запросов

Спасибо! Попробуем

подойдет! пришлите, пожалуйста.