Электронные игры (аркадными, видео и компьютерными они станут значительно позже) появились не в уютных гостиных и даже не в шумных игровых клубах. Первые игры родились совсем в других местах — в исследовательских лабораториях, университетах и на военных базах чьей-то там минобороны, где военные искали новые способы использования технологий, чтобы внести побольше рацпредложений на одну солдатиковую единицу. На авиастанции корпуса морской пехоты Канеохе, солдатикам предлагали электромеханические игры еще в 1949. Чтобы хоть ненадолго отвлечь молодцев от изнуряющей подготовки и строгой дисциплины, в гулко звучащих казармах новобранцы часами сосредоточенно вертели ручки и нажимали кнопки, стараясь на время забыть тяготы и лишения, пока начальство судорожно решало проблему нехватки брома в части.

Тем временем, в тишине университетских корпусов, среди гудящих cтоек и залежей перфокарт, заспанные и перегруженные учебой студенты, будущие светила программирования и предлагатели новых стандартов превращали огромные дорогущие мейнфреймы в примитивные игровые приставки. Вместо добивания перфокартами сложных математических расчётов или моделей для научных работ, эти люди писали код для первых игр. Не могу их в этом винить, потому что сам в конце 90х прокрадывался в зал, где стоял отцовский комп и тайком запускал SimCity или Цезаря, или пытался накропать морской бой на BASIC руководствуясь исходниками, напечатанными в каком-то журнале и молясь, чтобы скрип жесткого диска и попискивание бипера не были услышаны родителями.

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

Содержание

Вступление (и некоторые общие сведения)

Немного теории

Используемые функции PostgreSQL

Описание используемого примера данных

Предварительные шаги

Запросы

Краткий итог

«Задачи»

Слова про испытание могут показаться бредом, ведь современная работа — это просто работа. Это не «Матрица», не «Властелин колец» и не «Кунг-фу панда». Тут достаточно хорошо делать и хорошо будет, тут не надо голодать в пустыне и таскаться с кольцом по окрестностям, так ведь?

Ошибки в построении DWH возникают не только в результате того, что первоначально не были учтены возможные изменения в бизнес-процессах, потребностях и целях компании, но и из-за некорректного выбора стека технологий и СУБД. 

Порядок хранения данных выбирается в соответствии с разными сценариями работы - запросами, разным объемом данных, количеством транзакций, необходимостью обновлений данных.

В статье читайте о СУБД Greenplum и о том, в каких случаях строить хранилища на ее основе.

Зачем тратить время на выбор методологии построения DWH? Крайне важно правильно выбрать методологию моделирования данных для хранилища еще на этапе проектирования, это поможет обеспечить необходимый уровень гибкости и масштабируемости, а также позволит синхронизоваться с поставленными бизнес-задачами.

Сравниваем Снежинку, Data Vault и Anchor Modeling и предлагаем алгоритм выбора методологии построения DWH.

Эпоха современных хранилищ данных началась с появления реляционных баз данных (далее БД). С появлением бизнес‑аналитики следствием развития БД стала концепция Data Warehouse (корпоративное хранилище данных, DWH).

Дальнейший рост объемов данных, введение термина «большие данные» и разнообразие требований к обработке привели к эволюции архитектур данных.

Рассмотрим этапы эволюции архитектуры данных: чем отличаются концепции, какие у них преимущества и недостатки, для каких задач в работе с данными подходят.

Буквально недавно я начал создавать свой аналог сервиса Discord, используя веб-сокеты и передавая сообщения через очередь. В один из моментов мне понадобилось проверить, корректно ли проходят сообщения в этой очереди. Тогда я осознал, как неудобно каждый раз заходить в docker контейнер и вручную вводить команду для просмотра всех сообщений в топиках. После дня анализа и советов от моего коллеги, опытного DevOps-инженера Паши, я пришел к выводу, что kafka-ui от команды provectus — это наилучший и наиболее удобный инструмент для визуализации данных в Kafka.

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

С одной стороны, это может быть и хорошо. Такие шаги стимулируют индустрию. Но всё же лучше понимать, что ты делаешь, иначе проекту можно сделать только хуже. В этой статье я обращаюсь к разработчикам, аналитикам и тестировщикам, которые еще не сталкивались с Kafka по работе. Помогу понять, почему все же в микросервисной среде многие не ходят просто по REST, а используют этот инструмент - что конкретно делает Kafka и когда есть смысл её применять.

У Kafka есть множество способов применения, и у каждого способа есть свои особенности. В этой статье разберём, чем Kafka отличается от популярных систем обмена сообщениями; рассмотрим, как Kafka хранит данные и обеспечивает гарантию сохранности; поймём, как записываются и читаются данные.

Статья подготовлена на основе открытого занятия из видеокурса по Apache Kafka. Авторы — Анатолий Солдатов, Lead Engineer в Авито, и Александр Миронов, Infrastructure Engineer в Stripe. Базовые темы курса доступны на Youtube.

В этой статье продемонстрирую и объясню работу Kafka, используя как можно меньше определений и больше практики. Мы рассмотрим 3 сценария работы с Kafka. Для последнего сценария мы поднимем Kafka Cluster в Docker и с помощью UI увидим, как происходит общение между сервисами.

Привет! Меня зовут Глеб Гончаров, и я руковожу подгруппой ИТ-инфраструктуры в СберМаркете. В работе мы широко используем Kafka как шину данных для микросервисов и не раз убедились на практике, что к инструменту важно подобрать правильный подход. Об этом сегодня и поговорим в двух частях — сначала обсудим основы, а в конце статьи будет ссылка на практические задания.

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

В моей предыдущей статье про симулятор одного из самых популярных брокеров сообщений — RabbitMQ (https://habr.com/ru/articles/859 982/) много читателей оставляли в личку разные вопросы, но одним из самых популярных и часто задаваемых стал: «Очень классный и удобный симулятор! А есть ли такой же для Kafka?» И тут я понял: действительно, несправедливо рассказывать и, так сказать, нести в массы симулятор одного типа брокеров, но совершенно забыть про другой. Ну что ж, Кафка, значит, Кафка!

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

И сегодня это будет Kafka Visualization от компании SoftwareMill.

При всех достоинствах Kafka как распределенного хранилища потока сообщений, боль вызывало раздельное хранение метаданных (топологии разделов, конфигурации кластера и прочего) и необходимость запуска в кластере рядом с Kafka еще и Apache Zookeeper. Побочным эффектом такого соседства (кроме дополнительных забот об администрировании и мониторинге) является долгое время восстановления после сбоя при больших размерах кластера, значительном количестве разделов или сложной топологии групп. Но ситуация улучшается и отличная новость появилась полторы недели назад в KIP-833, что в ближайшей версии Kafka 3.3 новый протокол согласования метаданных (KRaft), работающий внутри Kafka без Zookeeper, будет признан Production-Ready и далее постепенно зависимость от Zookeeper будет помечена как deprecated и удалена. В этой статье мы поговорим об особенностях протокола KRaft и разберемся как настроить новый кластер Kafka без необходимости установки Zookeeper.

Queue (очередь) — структура данных на диске или в оперативной памяти, которая хранит ссылки на сообщения и отдает их копии consumers (потребителям). Queue представляет собой Erlang-процесс с состоянием (где могут кэшироваться и сами сообщения). 1 тысяча очередей может занимать порядка 80Mb.

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

Добрый день, Хабр! Хочу поделиться учебником-справочником знаний, которые мне удалось собрать по RabbitMQ и сжать в короткие рекомендации и выводы.

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

Алексей Барабанов, IT-директор «Хлебница» и спикер курса «RabbitMQ для админов и разработчиков», подготовил конспект, который поможет понять терминологию и базовые сущности RabbitMQ.

Привет! На связи Миша Меркушин. Я тимлид команды Ruby Platform, ответственной за разработку внутренних библиотек и улучшение архитектуры микросервисов на Ruby в СберМаркете. Эта статья про архитектурный паттерн Outbox и инструмент, который мы создали и итерационно развивали внутри команды и лишь недавно «выпустили» его в мир. Он решает проблему обеспечения надежной и согласованной отправки сообщений из приложения, гарантируя, что сообщение будет отправлено после успешного завершения транзакции базы данных.

В этой статье я расскажу об инструкциях Docker, о том как написать Dockerfile и о существующих best practice для этого!

В этой статье я расскажу о том что такое docker compose, как его написать и разобраться во всех возможных конфигурациях этого файла!