Последнее время доверие к облакам как-то резко упало, и пока кончалась годовая подписка на Google One на 2Т было время подумать, что делать дальше. В итоге родилась старая концепция - 'храним данные дома'. И вот что их этого получилось.

Всем привет! С вами снова Дмитрий, не программист. В прошлый раз я установил на Wiren Board 7 визуальную среду Node-RED, не умерев в консоли. И даже проверил четыре популярных сценария: ноду Debug, мастер-выключателя, включения вытяжки при превышении концентрации CO₂, приборной панели (dashboard). Позднее я рассмотрел еще три сценария: темной комнаты, дневного/ночного освещения, термостата для теплого пола и батарей.

Но умный дом можно собрать не только на визуальной среде Node-RED. Российские разработчики давно предлагают программный пакет Sprut.hub для домашней автоматизации. Сценарии можно задавать как через фирменную визуальную среду, так и скриптами js. В Sprut.hub поддерживается большое число различных устройств, а некоторые пользователи считают его даже удобнее и проще Node-RED. Значит, настало время его попробовать! Более подробную информацию о Sprut.hub можно почерпнуть здесь.

Побыть Львом Толстым, выпить сидра прямо из бочки и провести лошадиную психотерапию.

Предисловие.

Давно хотел cделать кинотеатр в доме, так как являюсь большим поклонником кинематографа во всех его проявлениях. Наконец появилось время реализовать задуманное и я приступил к реализации.

Началось детальное изучение с нуля, так как мое представление об этом было весьма скудным. Какой экран выбрать? Как организовать звук? Что делать с шумоизоляцией?, Какой размер экрана нужен? Какой проектор купить и еще миллион других вопросов. Данный "сетап" конечно же не претендует на профессиональные решения за миллионы рублей, поэтому выступает в роли пособия для построения бюджетного кинотеатра у себя дома.

В статье будет рассмотрен процесс экспорта данных в Hadoop из различных РСУБД посредством фреймворка Spark. Для взаимодействия с фреймворком Spark будет использован язык программирования Python с применением api pySpark.

• Небольшие команды в начале пути.
• Создание решений с быстрым возвратом инвестиций.

• Реализовывал три похожих не очень больших проекта по созданию DWH: 5-15 терабайт, 100+ сущностей, в команде 2-4 специалиста, в качестве источника — одна основная база продукта (сервиса) и несколько дополнительных.
• Участвовал в супер большом проекте DWH: 1+ Петабайт (прирост 1 терабайт в день), 2000+ сущностей, в команде 100+ специалистов. В этой компании жадно изучал Data Vault 2, исходники DWH движка, бизнес-процессы, которые масштабируются на сотни специалистов, правила описания DWH в вики и методы постановки задач.
• В продакшн работал только с batch процессами, со stream знаком только по обучающим курсам и книгам.

Ценность для бизнеса

На одной конференции мне задали вопрос (спасибо Александру!): как сделать стрим в PostgreSQL? Представьте, что имеется bytea и вы к нему хотите что-то дописать. Люди столкнулись с тем, что на это в PostgreSQL  тратится гигантское время  и растет WAL-трафик. 

Расскажу, что с этим возможно сделать — это будет еще один пример оптимизации TOAST (о чем я недавно писал), на на этот раз — для быстрой записи потока бинарных данных. На самом деле мой коллега, Никита Глухов, за несколько часов сделал расширение, которое «вылечило» проблему, и мы даже успели рассказать про это на сессии блиц-докладов на PGConf.Online 2021.

Привет! Меня зовут Павел Агалецкий, я старший инженер в команде архитектуры. Одна из областей ответственности нашей команды — синхронное (RPC) и асинхронное взаимодействие между сервисами. 

В этой статье я расскажу о том, как можно связать сервисы друг с другом и как это делаем мы в платформе Авито. 

Существует великое множество статей об оптимизации PostgreSQL — эта «кроличья нора» весьма глубока. Когда несколько лет назад я начал разрабатывать бэкэнд аналитического сервиса, у меня уже был опыт работы с другими СУБД, такими как MySQL и SQL Server. Тем не менее, раньше мне не приходилось так фокусироваться на производительности. В прошлых проектах, над которыми я работал, либо не было жестких требований к времени обработки (DS/ML), либо не требовалось обрабатывать много строк одновременно (обыкновенные веб-приложения). Однако в этот раз мои запросы:

• состояли из 3-10 JOIN-ов по коррелирующим запросам;

• уielded от 10 до 1,000,000 строк;

• должны были выполняться в течение времени, определенного UX-ом;

• не могли быть hinted — пока Cloud SQL, управляемый PostgreSQL в Google Cloud, не стал поддерживать pg_hint_plan в конце 2021 года;

• запрещали прямой доступ к серверному процессу, чтобы, например, хакнуть некоторые perf — потому что PostgreSQL был managed.

Получение целого миллиона строк в одном API endpoint сигнализирует о проблеме в алгоритме или архитектуре. Конечно, все можно переписать и перепроектировать, но за это нужно платить.

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

Эта статья является переводом материала «Untangling Microservices, or Balancing Complexity in Distributed Systems».

Расцвет микросервисов закончился. Uber преобразовывает тысячи микросервисов в более управляемое решение [1]; Келси Хайтауэр предсказывает, что будущее за монолитами [2]; и даже Сэм Ньюман заявляет, что микросервисы никогда не должны быть выбором по умолчанию, а скорее крайним средством [3].

Что происходит? Почему так много проектов стало невозможно поддерживать, несмотря на обещание микросервисов простоты и гибкости? Или все-таки монолиты лучше?

В этом посте я хочу ответить на эти вопросы. Вы узнаете об общих проблемах проектирования, которые превращают микросервисы в распределенные большие комки грязи (distributed big balls of mud), и, конечно же, о том, как их избежать.

Прошло уже почти 3 года с тех пор, как я впервые воспользовался чистой архитектурой на практике. С тех пор я побывал на многочисленных конференциях, где выступал с докладами на эту тему (вот, например, доклад Clean Architecture in Python с конференции PyGotham 2018). Кроме того, я написал статью о чистой архитектуре на Python, которая попала в рассылку RealPython.com … но сейчас заканчивается 2021 год, и мы ушли далеко вперед. Давайте рассмотрим, как развился Python, изучим разные крутые библиотеки, благодаря которым реализовывать чистую архитектуру на Python сегодня стало гораздо проще.

Сначала вспомним о том, зачем она нужна.

Считается, что запуск микросервисов изначально затратнее по времени, чем монолит, и наш опыт это подтверждает. Однако, если следовать проверенным процессам, эти затраты можно минимизировать. Делюсь лучшими практиками и составляю чек-лист запуска.

• «Инверсия зависимостей» и ее связи с портами и адаптерами (гексагональная/чистая архитектура).
• Различия между паттернами «Сущность», «Объект-значение» и «Агрегат» в рамках DDD.
• Паттерны «Репозиторий» и UoW, обеспечивающие постоянство хранения данных.
• Паттерны «Событие», «Команда» и «Шина сообщений».
• Разделение ответственности на команды и запросы (CQRS).
• Событийно-управляемая архитектура и реактивные расширения.

Django — самый популярный Python web-framework. За больше чем 10 лет оброс огромным слоем возможностей. Среди них можно выделить — Django Admin — это готовый CRUDL интерфейс с поиском, фильтрами и хитрыми настройками.

Каждый раз стартуя проект на Django, удивляюсь насколько круто иметь админку — web интерфейс просмотра данных. Да еще и бесплатно.

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

В этой статье я постараюсь привести 11 практик, которые позволят избегать тормозов админки максимально долго.

Postgres.ai делает возможным работу с полноразмерными базами данных в CI, значительно улучшая качество разработки и тестирования.

Разрабатываемый компанией открытый инструмент, Database Lab Engine, позволяет создавать полноразмерные клоны баз данных любого размера за секунды. Используя такие клоны, вы можете тестировать изменения, оптимизировать SQL-запросы и быстро развёртывать независимые тестовые стенды.
Вебсайт компании – https://Postgres.ai/ – содержит также SaaS-версию Database Lab.

Предисловие Около года назад я задался целью получить оффер от FAANG. Как следствие, постоянной частью моей жизни стали тематические форумы, площадки и вся сопутствующая атрибутика. Спустя какое-то время я попробовал себя на собеседованиях в околоFAANGoвые компании: Lyft, Spotify, Booking и т. д, где-то успешно, где-то не очень. В это же время мне порекомендовали попробовать пройти собеседование в Тинькофф банк, который внедрил схожий процесс. После стандартного общения с HR менеджером была получена ссылка на описание процесса собеседования. “Хм, почти что FAANG + тех. интервью по Primary Skill”, - подумал я и сказал, что готов приступать. В тот же час было назначено 2 интервью: техническое и coding, а вот 3 этап, system design, нужно было заслужить успешным прохождением первых двух. Почему именно эти 2 части являлись основополагающими, осталось неясным.

Акт первый, технический

В назначенный час я встретился со своим интервьюером. Собеседование выглядело “добротным” и стандартным в заданной проф. области, оттого местами скучным. Было много задач на ревью кода и обсуждения специфики языка, в частности...

Недавно я в очередной раз услышал:

“CSV — это популярный формат хранения данных, имеющий встроенную поддержку в Apache Spark…”

Ну, на счет “популярный” — согласен, “имеющий встроенную поддержку” — согласен, но на счет “хранения данных” — категорически не согласен. Подобные фразы могут не только сбить с толку окружающих, но и привести к значительным непродуктивным затратам времени (и памяти данных). Давайте разберемся.