Архитектор Данных

Чему я научился в трейдинге Я довольно много трейдил. По молодости криптой, в более зрелом состоянии - на российском рынке. И конечно же, много терял на этом. И сейчас понимаю, что это довольно полезный опыт. Главное - он дает ментальную рамку, как действовать, когда случилось что-то плохое. Непредвиденно плохое. Вот твоя большая поза залетела в убытки. Ты на такое не рассчитывал, ты, естественно, хотел, чтобы был большой плюс, иначе зачем ты бы в эту позу залез. Все просчитал, выверил. Но не так сталось как казалось. В этот момент ты не: 🚫 Не уговариваешь позу измениться с минуса на плюс 🚫 Не думаешь, вот надо было по-другому поступать, вставать не в лонг, а наоборот в шорт. 🚫 Не винишь черных лебедей, не ищешь виноватых, Трампа и Путина. Это не их палец нажимал на кнопки в терминале. 🚫 Не винишь и себя (блин, какой же я идиот!) 🚫 Не вспоминаешь, как раньше-то было хорошо и сколько ты заработал в аналогичных ситуациях. Вместо этого ты: ➕ Определяешь максимальный объем убытка и боли, который готов пережить. Это надо сделать ДО вхождения в позицию, но если раньше нет, то хотя бы сейчас. «Стоп-лосс» ➕ Максимально насколько возможно режешь убытки. «Зарезать лося» на трейдерском. ➕ Составляешь план минимизации долгосрочных последствий. Как и на чем будем отыгрываться. И будем ли, или вообще бросаем этот рынок и идем заниматься чем-то другим в другом месте. ➕ Делаешь выводы, какие именно неверные действия и какая неверная логика привела к тому, что ты наполучал горячих. - - Делаешь выводы с тем чтобы такое в твоей голове никогда не повторялось. Казалось бы, что такого, вполне естественные алгоритмы, все мы стремимся действовать именно так. Не бином Ньютона и не открытая вдруг Америка. Фишка в том, что для тебя как трейдера это становится рутиной. Что-то вроде второй кожи, дисциплиной, проверенной многократными тренировками. Потом это начинает работать во всех жизненных ситуациях. В кризисе на работе. В том что нанялся не туда работать. В различных отношениях с людьми, когда доверился не тому человеку. Спокойно без эмоций режем лося, ставим себе зарубку на будущее и идем дальше. Как жаль, что не все в мире можно так просто зарезать как лося в терминале. Найти другую приличную работу занимает время, закрыть невыгодный контракт не всегда возможно. А некоторый фарш назад вовсе не провернуть: потерянное здоровье, залетание в остроги, публичные пятна на биографии. Но даже там можно и полезно спокойно действовать на минимизацию последствий и убытков. Отдельный навык - не словить звездочку в случае внезапного успеха. Отличить, когда это твоя заслуга в прибыли, а когда ты просто случайно угадал с таймингами покупки битка. Или когда просто случился общий прилив, который поднял все лодки (а твою поменьше остальных, кстати!). "Альфа и бета" на языке трейдеров. П.С. Недавно подсчитал результат за 12 месяцев и он оказался +37%. Похвастаюсь немного. 🧐 Повторить не смогу.

Обратный ETL через Superset и премудрости корп архитектуры Словарь архитектора по-простому. Прямой ETL это когда аналитики забирают информацию с прода. Обратный ETL - когда прод забирает полезное из дата стека. Мы так отдаем хитро рассчитанные метрики активации в разных фичах. Будем отдавать признаки скорого оттока с подписки. Открыл для себя что один из самый простых способов поставить данные из КХД на прод - через Superset API. Там есть несколько методов программно по HTTP выдрать датасет из-под чарта. Опа! https://superset.company.name/api/v1/chart/{chart_id}/data/ - и готово! И это здорово, так как не порождает никаких доп процессов и систем. Суперсет-то все равно работает. Данные - обычный датасетик-витрина, легко создается и обмазывается теми же DBT тестами. Всяко лучше, чем городить силами дата офиса отдельные сервисы на FastAPI. Ноль лишних сущностей для команды данных. И самый смех в том, что в условиях кровавого энтерпрайза эта конструкция легко протаскивантся через самые жесткие комитеты. Включая кибербезников. Сами посудите 1️⃣ Данные идут из готовой системы, которая уже утверждена по высокому классу безопасности. А как по-другому, в BI в любом случае содержатся и перс данные и корп тайна. 2️⃣ Ролевая модель доступа - есть. Достаточно замороченная (для целей BI - слишком замороченная). Авторизация - есть, причем уже сынтегрированная с принятыми в вашей конторке SSO и LDAP-ами. Даже RLS можно сделать! Даже секьюрити аудит через логи суперсета можно устроить. 3️⃣ HTTP протокол, значит он легко убирается за доп слои безопасности, за любые балансировщики и фаерволлы, хоть NGFW с анализами паттернов доступа. Накинуть серты Минцифры - запросто! Его же легко замониторить, он понятен разработчикам на абсолютно любом стеке. 4️⃣ Готовый MCP сервер заказывали? А он там есть. В итоге на первый взгляд - элемент дендрофекальной архитектры. А на деле - надежный энтерпрайзный паттерн интеграции. 🧐🧐🧐

В Superset сделали MCP сервер из коробки. Кто пробовал? https://superset.apache.org/developer-docs/extensions/mcp/ Максимально популярная BI-ка в российском и не-российском дата бомже-стеке.

RustFS анонсировал S3 Tables функционал. Что такое S3 Tables? Это по сути Iceberg REST Catalog, встроенный прямо в коробку S3

А ведь теперь Ютуб может сам генерить вот этот жанр видео сколь угодно массово. Менторский контент, неторопливый монтаж, картинки и видео со стоков. То что раньше требовало сотни часов нарратива и монтажа от миллионов криэторов, теперь сделает толковая ИИ ферма. Значит и рекламой делиться с ними незачем.

Не, серьезно! 55% участников опроса считают что команда данных может жить с нулем знаний, как оживить вставшее колом КХД?

По заявкам. Разные движки воспринимают ролевую модель айсберг-лейкхауса по-разному. И с этим надо смириться и воспринимать как вариант нормы. Поэтому учимся защищать данные даже в тех ситуациях, когда конкретный движок решит забить на правила. Один из способов- начать работать с S3 ключами. А как? А вот так. 1️⃣ команде пользователю данных выдаем ключ не на весь бакет, а более гранулярно. Пользуемся тем, что если default location у нас s3://ice-bucket/data, то объекты по умолчанию будут разложены по префиксам s3://ice-bucket/data/schema/table. Вот и выписываем их гранулярно на схемы и таблицы. Эти же ключи раскладываем по ноутбукам, спаркам, трино каталогам, аэрфлоу и тд. 2️⃣ В айсберг таблице есть параметр location. Это корень обхода дерева метадаты айсберг и то куда айсберг складывает свой стафф. По умолчанию он берется из настроек коннектора и каталога. Так вот, ничего не мешает этот локейшен точечно переопределить. Например на s3://ice-bucket/secret/ или s3://secret-bucket или (внезапно!) hdfs://path И все будет работать до тех пор пока чтец обладает правами на предоставленных ему s3 ключах. Причем во многих s3 реализациях нельзя на один ключ грантовать права в разных бакетах. Разнося таблицы по бакетам мы получаем гарантию, что команды из чистой зоны физически не смогут добраться до секретной зоны со своими ключами. Вот так мы добавляем доп слой гарантированной безопасности, который будет работать на низком уровне даже если сервисы джейлбрейкнут Ranger или REST Catalog. (А они ведь могут!) Не забудьте только навайбкодить сервис, который будет выпускать, отзывать, аудировать и раскладывать в конфиги и волты ваши s3 ключи! 😎

Мощность подключённых к сети дата-центров в России достигла 5 ГВт, большая часть сосредоточена в Москве и Санкт-Петербурге — Замминистра энергетики Пётр Конюшенко Читать далее 👉 https://smartlab.news/i/203772 мы в max

Горжусь теми 151 подписчиками, кто выбрали Лейкхаус. Только не забудьте познакомиться с моделью безопасности. И особенностями комплаенса с ней тех сервисов, которые планируете использовать. Это я еще про крутилку S3 ключей для различных команд не вспомнил. И то что локейшены в одном каталоге можно (и наверняка понадобится) размазать по разным бакетам для ролевки. Потом на эти все художества смотрит ваш корпоративный кибербез в растерянном недоумении.

Безопасность в Iceberg-Lakehouse Берем Iceberg REST Catalog в виде Apache Polaris. Коннектим его к Трино как каталог. При этом передаем общие принципала и креды. Все подключается и успешно создаем, удаляем, работаем со схемами и таблицами. Теперь хотим подцепиться к тому же каталогу через PyIceberg. С теми же кредами. И Ловим 401 на попытке прочитать таблицу? Почему? Потому что PyIceberg честный и спрашивает креды на значимые действия с таблицей. Подчинаяется ролевой модели поляриса в этом плане. А трино просто взял metadata.json из каталога и пошел сам по S3 расшифровывать айсберговскую дату и метадату, никакого разрешения от каталога ему для этого не нужно. Ну и свою ролевую модель поверх наложил. Одна и та же таблица, одна схема подключения, но два представления о прекрасном от двух движков данных. Напоследок - доступные роли в Полярисе, грантов которых PyIceberg от нас ждет. Грантуется это исключительно через CURL. # Доступные права в поларис [ CATALOG_MANAGE_ACCESS, CATALOG_MANAGE_CONTENT, CATALOG_MANAGE_METADATA, NAMESPACE_CREATE, TABLE_CREATE, VIEW_CREATE, NAMESPACE_DROP, TABLE_DROP, VIEW_DROP, NAMESPACE_LIST, TABLE_LIST, VIEW_LIST, NAMESPACE_READ_PROPERTIES, TABLE_READ_PROPERTIES, VIEW_READ_PROPERTIES, NAMESPACE_WRITE_PROPERTIES, TABLE_WRITE_PROPERTIES, VIEW_WRITE_PROPERTIES, TABLE_READ_DATA, TABLE_WRITE_DATA, NAMESPACE_FULL_METADATA, TABLE_FULL_METADATA, VIEW_FULL_METADATA ] В другом каталоге Iceberg REST роли могут быть другие. В JDBC/Hive каталогах - вообще своя атмосфера.

Моя топовая история починки чего-либо тянулась нон-стоп 32 часа. Это был Greenplum заказчика, который несколькими последовательными командами gprecoverseg вывели в «нештатный» режим. Ночная смена под жестким sla плюс неудачное стечение обстоятельств. Через примерно час я сказал что кластеру хана и данным хана, и пошел восстанавливать из бекапа. Пока команда инцидента из 6 или 8 человек проходила стадии Отрицание-Гнев-Торг-Принятие, терабайты уже поднимались в резерв кластер. Потом звали вендора, искали причину, писали бумажки, клялись-божились что больше никогда-никогда. Нагоняли с заказчиком дельту из источников, крепились под нагрузку х4 от обычной. Перенастраивали DNS и все виды коннектов-фаерволлов на резервный кластер. Были веселые выходные. Бизнес-заказчик в понедельник увидел отчеты как ни в чем ни бывало. Записали как учения по отказоустойчивости 🤪

Насколько же правы оказались те, кто голосовали за Термояд. В нем, родимом проблема, а не в моделях и даже не в видеокартах. Точнее в розетке. Причем, это раньше было экономически непонятно, зачем нам 50-100 ГВт дополнительной энергии в одной точке. Это точка окупаемости термоядерной установки - есть ли вот столько платежеспособного спроса. Если есть, то строим, а если нет, то 4-6 блоков ВВЭР-1400 это предел, с чем можно связываться. Примерно объем, который съест крупная агломерация. А теперь вот он, есть у нас потребитель, который съест 100 ГВт, заплатит за них и еще попросит. Stay Tuned, Архитектор вернется снова с новыми опросами.

Прогноз потребления ЦОДов по миру. Российская энергосистема это порядка 1.2 ТераВатт-часов в год. График подрезал из большой статьи коллег про ситуацию с энергетикой ЦОД. Небольшие тезисы оттуда 1️⃣В Техасе, где очень много дешевого газа и цены на электричество исторически очень низкие введен мораторий на подключение новых ЦОД от губернатора. Так как энергосистема (Местный Россети и Энергосбыты) не справляются с нагрузкой. 2️⃣Очередь заявок на подключение в одной Техасе на 450 ГВт. Это две энергосистемы России. 3️⃣Есть большой дефицит промышленных турбин. То что преобразует тепло в электричество. Очередь уже на много лет. ЦОДы съедают людей. В Англии промышленной революции повышение производительности ткацкого станка в 40 тыс раз за пару поколений привело к тому, что фермеров сгоняли с сземли ради овец и шерсти. Тканая шерсть - это товар, его можно погрузить на корабль и продать за золото в любой точке мира. А крестьяне - ну что, перебьются как-то. Томар Мор написал что "Овцы съели людей" А у нас ЦОДы съедают людей. Выработанное электричество выгоднее пустить на нейронки, которые можно продать по всему миру. А то что электрухи не хватит в городах - ничего, перебьются как-то.

Больше всего удивляют люди, которые в жизни общаются языком корпоративных писем. «В рамках», «привлечь», «проработать задачу», «выстроить процессы». Камераден, нас никто не видит, объясни нормально, что ты хочешь. И вообще мы в баре, работа кончилась час назад. Язык партсобраний поражает слабых разумом.

Все дата инженерные проблемы обычно решаются дополнительным тестированием данных Кроме одной - избыточного тестирования данных