Телеграм — настоящая соцсеть

в чём главная проблема канала в телеге? дорогу туда найдёт лишь тот, кто там уже был, хе-хе

просто в отличие от фейсбуков и тиктоков, в телеге не было механизма дискавери новых каналов; чтобы новый читатель узнал про канал, он доложен был его сам найти, либо ему кто-то его прислал — пошерил в другом или прислал лично

соответственно, чтобы канал рос, нужно чтобы его репостили

вокруг выросла целая индустрия «давайте включим ваш канал в подборку» или более креативные и интересные стратегии типа «перестрелки»

авторы каналов в надежде выдавить ещё пару капель конверсии ставят в конце каждого поста ссылку на канал (@data_days !), ведь иначе при репосте невнимательный читатель может не отличить репост от оригинального контента (и не подпишется на исходный канал!)

и вот теперь тёмное время окончено и да начнётся перекрёстное опыление релевантных каналов — для каждого канала Телеграм сделал сториз подборку похожих

я посмотрел для @data_days и надо сказать, что с компанией мне крайне повезло — все замечательные как на подбор. Сначала подумал, с нашей темой всё было довольно просто: достаточно пройтись регуляркой по названию и выделить всё со словом data 🤣 но судя по каналам других тематик, там под капотом всё-таки что-то сложнее

осталось только достать эту функцию поближе к пользователям, а не прятать за три клика (почему про это не пишут из всех каналов как было с релизом сторис??)

призываю затестить на всех своих каналах и поискать похожие

ну вы поняли, @data_days

оставлю тут гифку из официального блога телеграма как найти эти Similar Channels

(в комментах подсказывают, что на Андроид и в веб версии пока не раскатили)

Kafka is dead, long live Kafka

https://www.warpstream.com/blog/kafka-is-dead-long-live-kafka

два выходца из Datadog накидывают на Кафку. Ну, точнее не на саму Кафку, а на окружение, в котором крутятся современные инсталляции.

дисклеймер: сам я Кафку не варил, шарды не перебалансировал и патриции не восстанавливал; но кажется я понимаю спектр проблем, на которые указывают авторы, и мне в целом нравится что они ставят под вопрос дефолтное решение. И было интересно для общего кругозора прочитать что там их не устраивает и как же сделать лучше (по законам жанра в конце статьи [коммерческое] предложение).

авторы пишут, что сама по себе Кафка всем хороша и с момента релиза зарекомендовала себя как дефолтный способ реалтаймового перекладывания байтов. А заметка про техническую базу распределённого бревна лога стала культовой

Базовых проблем две:
- большие потоки данных между внутренними узлами
- много ручного труда для поддержки и развития

Изначально Кафка крутилась в датацентрах Линкедина, где внутренний трафик не тарифицировался. Текущие реализации работают в основном в облаках, где это стоит денег. Помимо прямого трафика, есть ещё внутренняя репликация в целях отказоустойчивости.

понравился кусочек про Accidental SRE; мол, вот в чём приходится разбираться, если решил завести себе Кафку:

1. Kafka (brokers, coordinators, watermarks, etc)
2. ZooKeeper (or KRaft)
3. Leader elections
4. Partitions (how many partitions do I need? Unclear, but better get it right because you can never change it!)
5. Consumer groups
6. Rebalancing
7. Broker tuning
8. Client tuning
9. etc

🏦 Klarna — куда я попал

если коротко, то Klarna — это сервис отложенных платежей, т.н. BNPL — buy now, pay later (or never lol). Самоидентифицируют себя как банк, что ведёт за собой дополнительное регулирование. Начинали из Швеции, постепенно вышли в некоторые страны Европы и потом ещё в Штаты.


📍команда

из Штатов, кстати, наши тимлид и архитектор. Поэтому дейлики у нас в середине дня (но при этом Уэса всегда можно приветствовать «доброе утро!» :-)

остальная команда тоже довольно мультинациональная и распределённая: Германия, Румыния, Италия и, собственно, Швеция.

компания себя позиционирует как международная, поэтому вся документация и коммуникация внутри — на английском, включая все массовые встречи.


📍спектр задач

тут самое интересное — я как-то не догадался об этом спросить на этапе собесов (сейчас понимаю, что у меня в голове были другие дефолтные предположения)

после нескольких онбордингов, под конец второй недели я обнаружил себя в команде разработки одного из микросервисов — ребята пилят серивис на TypeScript для управления аффилированными ссылками и их дальнейшее отслеживание.

ну штош, не зря читал про Data Mesh — буду пробовать себя как выделенный инженер данных в отдельно взятом дата-продукте

я не так часто собеседуюсь и ещё реже меняю работы, поэтому ещё не накачал умение задавать правильные вопросы на этапе знакомства и выбора команды; иначе бы я вряд ли решился пойти в команду разработки микросервиса единственным дата-инженером :-D


📍 техностек

в основном всё работает на AWS — данные с источников заливаются в S3, откуда их можно селектить через Athena. Или заливать дальше в Redshift.

С последним знакомые проблемы — на вход большая очередь, в которой таски могут простоять день или больше; плюс встречаются жалобы «всё тормозит, невозможно работать!!11» — кластер-то коммунальный.

узнал новую для себя фишку: Redshift умеет селектить «внешние» схемы напрямую из S3. Тогда можно обойти узкое место в виде переливки данных, но и скорость чтения будет ниже.

DataHub в качестве дата-каталога.

на оркестрации централизованный Airflow. Даги генерятся из ямликов через воркеры на Jenkins. Из коробки умеет делать SQL в тех же Athena и Redshift, плюс джобы на AWS Glue.

видел записи докладов других команд, где народ настраивает себе стриминг через Flink и Firehose. Видимо локально в командах тут может встречаться всякое.


📍 дата-архитектура

за первые 8 недель успел только погрузить в дела команды и немного мониторю чаты поддержки избранных команд, поэтому сложно экстраполировать на всю компанию

я кажется упоминал тут «теневой двх» — это когда рядом с «официальным» красивым двх с дк-чеками, документацией, конвенцией и т.д. аналитики собирают «на коленке» свои пайплайны. Каждый делает как умеет, поэтому рядом могут лежать почти одинаковые таблицы из одних источников, но при этом данные в них будут разные.

у нас в команде есть только «теневой» двх :-D чисто собрали витринки на своих таблицах. У каждого аналитика — свои. При этом свежесть данных по некоторым источникам — до пяти дней. Что-то неладное в датском королевстве. Будем разбираться.

пока что не видел признаков какой-то централизованной конвенции по неймингу или рекомендации по раскладыванию данных по слоям. Может ещё не докопал, или существуют только локальные внутри команд.

с одной стороны без единой архитектуры почти всё пишешь с нуля, а с другой — много свободы и, соответственно, большой потенциал для роста и реализации.

Data Modeling is Dead! Long Live Data Modeling!

https://youtu.be/OCClTPOEe5s

увидел у Семёна ссылку на рассылку про моделирование данных от Joe Reis, автора Fundamentals of Data Engineering — книги, которая вроде как пробилась в топы Амазона сразу по нескольким категориям.

помимо книги и рассылки, нашёл небольшой доклад от Джо на тему того же моделирования.

В целом, от доклада сложилось впечатление «дед ворчит на облако», но кажется смысл сводиться, что мы стали забывать что такое модели данных и в принципе забивать на этот этап. Остаётся только поверить его обширному кругу общения — у него своё консалтинговое агентство, он много катается по миру с докладами, поэтому повидал и услышал всякое там; и даже сам Andrew Ng пригласил делать его делать курс вместе.

Автор приводит две книги по моделированию данных, с которыми стоит познакомиться. Мне тема близка и актуальна по работе, поэтому вторую книгу я уже заказал — посмотрим что там к чему (правда, тот же Кабанчик у меня лежал года полтора прежде чем я его прочитал с книжным клубом >_> )

В конце автор призывает вернуться к моделированию данных: ведь когда, если не сейчас — все эти ваши ллм-ки поломаются без красивых данных на входе.

🎧 Father of «DataWarehouse»

продолжая копать под этого Joe Ries, нашёл у него подкаст. Полистая прошлые эпизоды, нашёл там никого иного как Билла наше-всё Инмона. Оказывается Билл его менторит (вот это размах!).

эпизод слушается как смесь баек из склепа и триллера: всё на одном дыхании — хотя уже заранее знаешь кто убийца, но до самого конца было непонятно как оно всё придёт к этому.

первую программу Билл написал в 1965, за свою карьеру успел пописать на ассемблере, паскале и коболе. Застал программирование на перфокартах; когда несёшь стопку таких карт к «компьютеру», то главное их не рассыпать — иначе придётся вручную восстанавливать и проверять их порядок >_<

сейчас мы (по крайней мере мы в нашем уютном инфопузыре) рассматриваем хранилище данных как нечто само собой разумеющиеся. Однако, в 80-х всё было далеко не так радужно. В начале было слово OLTP и только транзакционные базы данных.

Когда Билл читал свои первые лекции про «новый инструмент для аналитики — DWH», первые 3-4 года его слушателями были исключительно маркетологи, и никого из технических профессий.

После докладов на конференциях ему даже приходили гневные письма, чтобы он заканчивал со всей этой ересью про OLAP и «хватит тянуть отрасль назад»

тогда топовой компанией была IBM (которая продавала свои мейнфреймы по 2-3 миллиона при себестоимости в $165), и они там были настолько против этого вашего OLAP, что просили не упоминать в одном предложении OLAP и IBM.

типичная проблема больших корпораций тогда — понять сколько именно они зарабатывают. Когда у тебя 10 000 программистов и практически бесконечные бюджеты, то даже такие ресурсы не способны приблизить к ответу; потому что данные размазаны по всем отделам равномерно и нет одного места, где можно было бы всё свести в единый отчёт.

и вот когда первая компания сделала у себя DWH, это дало такой прирост эффективности их аналитиков, что по отрасли пошли слухи о «новом секретном инструменте — DWH»; и сразу все захотели к себе такое же и на лекциях Билла стали появляться технари.


#подкаст в Apple Podcasts и Overcast

первая неделя с CoPilot

тут в нашей Кларне держат фокус на AI. Может где-то и перегибают в горячке, но тем не менее всем разработчикам оплатили лицензию на CoPilot и неустанно напоминают её активировать и установить плагин свой IDE.

последнюю неделю дорвался наконец до питонячего кода и таки активировал-установил копайлот в свою Идею. Делюсь ощущениями по итогам первой недели с аи-помошником. Наверняка тут есть прожженные промпт-инженеры и гпт-мастера — не судите строго (а лучше приходите в комменты!)


+++

мне понравилось как копайлот справляется с питоном и конфигами терраформа: предлагает дополнения исходя из контекста файла и непосредственного окружения.

в одном месте писал функцию для дебага и нужно было создать словарик с мок-данными на вход; и вот тут копайлот мне предложил готовый вариант ровно с теми полями, которые ожидает функция ниже. Топчик!

можно дополнять строки или генерировать целые функции. На функциях при этом получается такой микро-паттерн: пишешь в комменте что должна делать функций, копайлот тебе её генерит, а изначальный коммент-промт идеально подходит на роль докстринга к этой новой функции

в VSCode функциональность ещё шире: можно просить пояснить за целый файл или кусок кода; плюс есть отдельный или инлайн- чат, где можно отдельно поговорить с ботом по душам. Тут спасибо Майкрософту.

− − −

не получилось помощи с ридми — видимо, не хватает контекста для релевантных подсказок. Пока писал короткий ридми с основными моментами нового проекта кажется ни один промт не подошёл — всё как-то мимо. Но я писал больше по-программистски: короткие сухие предложения с примерами кода и ссылками на папки-файлы.


⌘⌘⌘

ещё тут у нас проводят еженедельные встречи любителей помучать чатжпт. на одном ребята показывали как с нуля можно написать простой скрипт с помощью копайлота.

в итоге у них получилось чисто через промты и автодополнения написать скрипт на полторы страницы, который парсил рядом лежащий .csv и выводил агрегат по заданному вопросу

вывод:
- можно писать код на незнакомом языке (мама, я — фулстек!)

- в среднем код с копайлотом получается лучше документированным: комменты с промтами можно оставлять как просто комменты и в целом просить его написать первую версию докстринга

- копайлот можно использовать как резиновую уточку, которой будешь объяснять свои проблемы: может повезёт и найдёшь пробел в рассуждениях в процессе. В любом случае иногда полезно явно формулировать свои мысли где-то помимо своей головы


⌘⌘⌘

на другой такой аи-встрече аналитик показывал как с помощью чат-гпт и копайлота написал пайтон скрипт, который парсит расшифровки после встреч, выводит ключевые идеи и экшен-поинты, плюс формирует элементы для графа связей в общую базу знаний

при этом аналитик говорит что «не знает питон»


⌘⌘⌘

товарищ рядом со мной тоже с помощью гпт написал («скомпилировал»?) в ноутбуке код, который берёт гугл-таблицу, что-то там трансформирует, генерирует пдф и отправляет результат в нужный слак-канал.

при это товарищ тоже аналитик и не шарит за всякие там апи, функции и вызовы — но при этом благодаря гпт скриптик у него работает и приносит свою пользу.


⌘⌘⌘

в Яндекс Доставке тоже аналитик рассказывал как писал с помощью жпт скрипт для бутстрапа сплит-тестов и потом ещё итеративно оптимизировал его производительность, чтобы полностью утилизировать все ядра данной виртуалки.


⌘⌘⌘

в целом, выглядит как ещё один инструмент в наборе: python, sql, chatgpt …

а чо у вас по копайлотам по работе? применяете? полезно?

🤓 испытательный срок — тю!

прошло полгода в Кларне, объявили что я молодец и мой временный контракт превращается в тыкву настоящий бессрочный взрослый трудовой договор. Внутренний самозванец громко и глубоко выдохнул.

понял, насколько спокойно было в России — кажется, чтобы тебя уволили надо очень сильно постараться. Особенно в нашей уютной айтишечке.

хочется немного порадоваться, потому что было всякое за эти шесть месяцев: расскажу ниже. я так и не научился вести прямой репортаж, поэтому ниже краткий пересказ.

⌘ на второй неделе моего пребывания местный профсоюз предупредил компанию о забастовке — они хотели подписать коллективный трудовой договор. Последний раз про забастовки я слышал из телевизора ещё при Ельцине. А тут это как бы обычный инструмент профсоюзов.

⌘ через месяц НЕ полетел в Лондон на офсайт сходку нашего департамента — не успели сделать вовремя визы, хотя билеты и отель был уже заказан. Почувствовал (виртуально) размах активностей компании. Ну и виза осталась >_>

⌘ перед новым годом наш департамент расформировали (не говорите супруге!) — помню как прямо на встрече после объявления кинулся смотреть внутренние вакансии. Нашему отделу повезло, мы целиком перешли в другой департамент. Хорошо когда отдел напрямую генерирует прибыль (я говорил, что попал в команду аффилированного трафика?) Другие коллеги отправились во внутренний competence pool в поисках подходящих вакансий в других департаментах компании.

⌘ где-то в этот же момент в Спотифае буквально через дорогу сократили 1500 человек. Поэтому было довольно тревожно. С одной стороны, в Кларне «прямых» сокращений не было (в этот раз), но с другой — меня-то и сокращать не надо было, можно было бы просто не продлить рабочий контракт.

⌘ чтобы записать сына в детский сад, спарсил емейлы ректоров с сайта коммуны, чтобы сделать холодную рассылку с вопросом можно ли получить у них место и сколько людей в очереди к ним прямо сейчас. яжпрограммист! Чтобы отранжировать сады, добавил расчёт расстояния по гео-координатам до нашего дома. 13 писем отправлено, 4 ответа получено, одно место предложено.

⌘ сходил на митап Coachbasе в местном офисе Google. Послушал про базы два-в-одном — как они с одной стороны держат транзакционную нагрузку, а с другой не боятся сотен аналитиков с их select *

⌘ слетали семьей в Милан за €100 на человека (спасибо Ryanair). И город посмотрел, и поработал там из местного офиса. Развиртуализировался с коллегой. Плюсы большой компании и распределённой команды. На очереди Берлин и Бухарест.

⌘ помимо отменённых самолётов в Россию ещё закрыли сухопутную границу между Питером и Хельсинки, так что и без того весёлый трёх-сегментный маршрут домой превратился в четырёх-сегментный: Стокгольм → Хельсинки → Таллин → Питер → Москва. Удивлял коллег на стендапах вступлением «из какой страны выхожу на связь в этот раз».

⌘ залетел перед работой на дата-завтрак от Snowflake с участием dbt labs. Я думал, что и те, и другие дальше штатов не заглядывают, а оказывается у них тут есть офис и люди. Правда, судя по вакансиям, только сейлзы =) Послушал как Эриксон строит универсальный датамеш (уже как год). Мне конечно до таких масштабов далеко, поэтому просто довольствуюсь кружкой и блокнотом со снежинкой ❄️

📓 Infrastructure as a Code

будучи начинающим дата-инженером в Эпохе довелось первый раз сетапить дата-инфру с нуля для нового проекта

я тогда уже чуток представлял из каких «кубиков» должна получиться система: где-то должны быть пайплайны, где-то храниться данные и в итоге желательно из всего этого сделать дашборды.

с хранением всё понятно — был GCP и значит всё льём в BigQuery, там будут жить наши таблицы, аккуратно разложенные по слоям.

осталось поднять Airflow, который, собственно, и будет всё раскладывать по слоям, а ещё Metabase, где будут жить все дашборды.

я долго смотрел на этот космолёт приборную панель управления облачными ресурсами: столько там всяких разделов что сложно понять с чего начинать. В итоге как-то нашёл docker registry с понял куда пихать ссылки на docker hub из соответствующих туториалов.

где-то там же осознал, что Airflow и Metabase надо где-то хранить свои данные типа юзеров и истории, а значит помимо общего хранилища им ещё понадобится и своя отдельная постгря

в итоге я что-то там накликал и оно даже заработало (через стопицот итераций, естественно!) — открывался интерфейс Метабейза, там можно было зарегаться и накликать себе деш с данными из BQ

я был дико горд собой. не иначе как «Ты девопс, Гарри!». Всё-таки первый проект в облаке, это вам не в тапки это самое

показываю Андрею — нашему основателю и по совместительству техдиру. Он посмотрел так скептически. Допустим, говорит, красивый урл для админки вместо циферок айпи мы настроим, ок. Но вот зачем тебе три медиум инстанса ЕС2 для одного метабейза с полутора пользователями? но ладно, можно скейлнуть вниз — не проблема. В целом годиться для начала! Показывай теперь, говорит, свои Helm чарты, посмотрим что там как.

Так я узнал про подход infrastructure as a code.

всё, что я тогда тыкал мышкой через облачную админку, правильные ребята делают через код — в специальных конфигах (чартах) расписывают желаемый результат и потом одной командой раскатывают это на сколько угодно машин.

ведь натыканное через админку неудобно поддерживать — можно быстро получить результат, но сложно его повторить или перенести на другой проект; так же сложно проверить новую правки или откатить последнее обновление — как теперь вспомнить что там было натыкано.

с кодом же всё чётко: каждое обновление — пулл реквест. Явно видно предлагаемые изменения. Легко встраивается в CI/CD пайплайны. Раскатывается на одну или тысячи машин — неважно.

🐭 постоянство в достижениях

взять, например, шефа в ресторане. недостаточно один раз приготовить божественный рататуй, а всё остальное время подавать посредственную яичницу.

должно пройти какое-то время, чтобы «слава закрепилась»; нужно, чтобы люди приходили, восхищались твоим рататуем, приходили снова и снова, а потом всем рассказывали, что лучший рататуй — только у вас.

если приготовить вкусно только один раз, то такого эффекта не получится. Первый раз кому-то попадётся божественный рататуй, а на следующий — будут только яичницы. Земля не остановится, конечно, но и звезду мишлена за яичницы не дадут.

вспомнил об этом, когда задумался о перфоманс наших ревью. Раньше мне казалось, что если я один раз затащил, то меня можно смело повышать до синьора! но теперь понимаю, что синьор — тот, кто планомерно перфомит на должном уровне.

При этом для него просто поднимается дефолтная планка качества работы — он не выжимает из себя 146% эффективности, он просто «бежит в комфортном для себя темпе» и дыхание не сбивается.

Для него приготовить божественный рататуй — это ежедневная рутина, а не достижение.

открываю для себя семейство продуктов Kinesis от AWS. Всё вместе оно решает дата-стриминговые задачи, но чисто по названиям не понять чем Streams отличаются от Analytics и зачем там ещё Firehose.

посмотрев три обзора на ютубе, ответственно заявляю вот что я узнал:

🟣 Kinesis Streams — типа топиков Кафки. Можно несколько консьюмеров на топик, есть ретеншен полиси для записей внутри — т.е. чтение на консьюмере управляется офсетом.

🟣 Kinesis Firehose — по сути коннектор, можно туда паблишить евенты и оно из коробки может писать во все основные тулзы AWS. Нельзя много консьюмеров.

🟣 Kinesis Analytics — под капотом это Managed Flink (почему нельзя было так назвать сразу?). Умеет в разные стрим-трансформации: джойнить потоки, анализировать налету, работать с разными окнами.

к Streams и Firehose можно присобачить Лямбду на обработку входящих событий — на каждое событие или батч будет инициироваться инстанс функции и выполняться её код.

и следом ютуб-фид мне выдал релевантный доклад с AWS re:Invent «как не терять данные в стриминге»

Рассказывает AWS Hero из консалтинга, т.е. она насмотрелась за свою карьеру на разные aws-архитектуры.

доклад понравился тем, что он практико-ориентированный: на примере одного проекта разобрали основные ошибки и как тихо не терять данные. При этом советы были простые, но действенные — на уровне вызываемых функций и их параметров. И всё это относиться не только в AWS или Kinesis, ведь терять данные можно в любом инструменте.

⌘⌘⌘

кейс начинается с того, что при простом паблише и консьюме из Kinesis Streams они заметили недостачу данных. И дальше по цепочке разбирали кейсы, которые они обнаружили (вместе с поддержкой aws)

хорошим тоном считается отправлять события пачкой, а не по одному. Прикол в том, что вызов апи может вернуть статус 200, но при этом часть событий не примет. Помимо самого статуса, надо в респонсе смотреть поле с количеством ошибок по отдельным евентам.

отдельные ошибки могут возникать из тротлинга со стороны авс — там есть лимиты на мегабайты и штуки в секунду (при этом логи в cloudwatch будут уже аггрегированные по минутам и криминала не подсветят)

у Streams единица параллелизации — шард. Хотя AWS называет это serverless, но по сути провизией мощностей надо заниматься самоу. Скейлить вниз и вверх в зависимости от текущей нагрузки, чтобы не попасть не попасть на тротлинг, но и не переплатить за лишнее.

из streams события консьюмит лямбда. По умолчанию 1 шард = 1 конкурентный запуск лямбды. Если включить event source mapping, то можно увеличить фактор параллелизации до 10 одновременно запущенных лямбд на каждый шард.

подстава кроется в том, что у всего аккаунта есть лимит на количество запущенных лямбд — и если вдруг у вас станет слишком много шардов и запущенных лямбд, то где-то у соседнего отдела их лямбды (работающие на том же аккаунте) могут начать кидать ошибки.


выводы

🟣 обработать ошибки правильно — не доверять общему коду, а смотреть детализацию в респонсе

🟣 настроить ретраи — exponential backoff + jitter, чтобы распределять нагрузку в случае проблем

🟣 добавить кастомные метрики на тротлинг в cloudwatch, чтобы не пропустить логи с ошибками

🟣 настроить ESM для Лямдб, чтобы распрараллелить обработку событий


и всё то же самое в виде статьи с примерами кода

🛫 визуализация полётов на Кликхаусе 🛬

Алексей Миловидов собрал красивый демо-проект, чтобы показать как Кликхас могёт ворочать миллиарды записей (это в день).

Получилось похоже на flightradar, только без самолётиков — только трейсы. Можно выбирать что показать, крутить карту как обычно и даже писать кастомные запросы.

всё работает на чистом html поверх кликхауса в их облаке. В статье подробный рассказ что под капотом: js-функции, ddl таблиц и вьюх, sql-запросы с сайта.


Статья https://clickhouse.com/blog/interactive-visualization-analytics-adsb-flight-data-with-clickhouse

Сайт https://adsb.exposed/

Исходники https://github.com/ClickHouse/adsb.exposed

Источники данных:
1. https://www.adsb.lol/
2. https://www.adsbexchange.com/products/historical-data/

🏆 что мне нравится в проекте с авиа-трейсами adsb.exposed

в дополнение к вчерашним картинкам и голой ссылке хочу подробнее рассказать чем именно меня привлёк проект Миловидова


⌘ во-первых, как увлечённый дата-инженер я радуюсь каждому проекту, где-то как-то вовлечены данные и потом с ними происходит что-то интересное. Всегда хотел замутить что-то своё, но всё никак не нашёл подходящего повода и времени (а вот фаундер международной компании таки нашёл, хе-хе!)


⌘ во-вторых, видно инженерное мастерство как таковое: у проекта предельно простая инфраструктура. Нет тебе ни редисов с кешами, ни гео-балансеров, ни хитрого фронтенда с отдельным бэкендом — всё работает прямо в браузере.

если я правильно понял, мой веб-бразузер напрямую ходит в облачный КХ и тянет данные налету — даже сами запросы прозрачны (ещё и с динамическим прогрессбаром)

а чтобы браузеры не положили базу, данные предварительно разложены по оптимальной схеме в нужных форматах — подозреваю что там тоже не обошлось без тайного знания об особенностях обработки данных внутри бд.


→→→ итого получается, что у этого решения-как-продукта всё продумано:

× простым юзерам сходу показывает красивые картинки

× продвинутые же юзеры имеют прямой доступ к запросом и могут подхачить их под своё усмотрение

× ну и социальный фактор — своим кастомным результатом можно легко поделиться.


? к последнему я бы ещё докрутил удобную шерилку, чтобы нажал кнопку и красивая картиночка улетала в нужные соцсети. Я почему-то ожидал, что на выходе должен получить картинки как из статьи, но видимо там Алексей допиливал их напильником.


UPD: я уже переслал этот вопрос по всем своим дата-чатикам, но закину и тут. Как вам Extract на чистом баше, а? и потом такой же лаконичный Transform & Load уже на SQL с чтением джейсона

📚 Practical Data Modelling pre-book

не теряю надежды вкатиться в Data Modelling и продолжаю активно следить за господином Joe Reis.

ранее он объявил, что после соавторства книги Fundamentals of Data Engineering его следующей соло-книгой будет Practical Data Modelling (уже есть рисунок оглавления).

в своей рассылке на substack он закидывает темы в читателей и проводит дискуссионные клубы на тему. Там же вышел черновик первой главы будущей книги — правда, за пейволом. так что делюсь с вами контентом конспектом контента аж за 600 рублей

в качестве введения Джо предлагает договориться о терминах и приводит цитаты других, начиная с книги 1967 года

> A data model organizes and standardizes data in a precise structured representation to enable and guide human and machine behavior, inform decision-making, and facilitate actions.

> Модель данных организует и стандартизирует данные в точном структурированном представлении для возможности и направления поведения людей и машин, информирования принятия решений и облегчения их действий

обратите внимание, что автор явно включает машины в игру: под это понятие кажется подпадает всё МЛ направление со всеми этими фича-сторами и что там ещё у них есть

и далее любопытный заход через отрицание: чем же моделированные данных НЕ является:

⌘ идеальным. Модель не может содержать в себе всю реальность, поэтому она всегда будет что-то упускать.

⌘ исключительно физическим. часто про модель данных вспоминают непосредственно перед записью в базу и тогда задача превращается «как мне ЭТО засунуть в Сноуфлейк?!». Не стоит забывать, что есть перед этапом физического, есть ещё концептуальное и логическое моделирование.

⌘ какой-то отдельный подход. тезис «моделирование данных — это Кимбал» равен утверждению, что боевые искусства — это карате. На самом деле понятие шире и более этого: отсутствие модели — это тоже модель. У каждого подхода есть свои плюсы и минусы, по-разному проявляющие себя в конкретных условиях.

⌘ единовременный процесс. если модель — это срез реальности, то она начнёт устаревать с момента реализации. Сама компания и её термины так же постоянно эволюционируют и меняются. Модель должна поспевать за всем.

⌘ только для больших корпораций. не обязательно иметь стопицот сущностей, чтобы почувствовать пользу от хорошо спроектированной модели.

⌘ только для технарей. автор приглашает к столу не только архитекторов и инженеров, но и аналитиков, менеджеров и других потенциальных потребителей; ведь при проектировании не стоит забывать о том как работает бизнес сам по себе.

__________________
упомянутые ссылки:
* George Mealy, Another Look at Data, 1967
* William Kent, Data and Reality, 1978
* Steve Hoberman, Data Modeling Made Simple, 2005
* Larry Burns, Data Model Storytelling, 2021
* Eric Evans, Domain Driven Design, 2003