В первой статье «Облачный умный дом: что нужно знать, чтобы избежать проблем» я рассмотрел преимущества и недостатки облачных решений, а также проблемы, с которыми за последние месяцы пришлось столкнуться пользователям разных облаков. Но довольно теории, переходим к практике.

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

Затем я откажусь от облака Aqara и перейду на локальное решение Wiren Board 7 с модулем расширенияSprut.stick ZigBee WBE2R-R-ZIGBEE-SH, оболочкой Sprut.hub и Алисой. Сравню результат и процесс с родным облаком.

В одной из предыдущих статей я описал Push-based Outbox Pattern (шаблон исходящих сообщений на основе push с логической репликацией Postgres). Идея заключается в том, чтобы сохранить исходящее сообщение (например, событие) в той же транзакции базы данных вместе с изменением состояния. Благодаря этому мы гарантируем, что сообщение не будет потеряно, а наш бизнес-процесс будет продолжаться и станет согласованным.

Postgres может помочь и проинформировать нас, когда добавляется новое сообщение. Мы можем использовать встроенный механизм журнала упреждающей записи (WAL, Write-Ahead Log) вместе с логической репликацией.

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

Привет! На связи как всегда Артемий Козырь, Analytics Engineer в Wheely.

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

В этой публикации попробую резюмировать свои знания:

— Каталог поддерживаемых источников и приемников данных

— Метод чтения данных из источников (Extract)

— Способы репликации в целевое Хранилище (Load)

— Работа с изменениями структуры данных (Schema Evolution)

— Трансформации перед загрузкой данных (EtLT)

— Тип развертывания решения (Deployment)

Буду объянять и показывать примеры на сервисах, которые использовал сам: Hevo Data, Fivetran, Airbyte. Однако критерии униварсальны и применимы для любых других систем подбного класса.

Последнее время доверие к облакам как-то резко упало, и пока кончалась годовая подписка на 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 сегодня стало гораздо проще.

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

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