что такое стрим в проекте

Основные принципы подхода STREAM.PM

Продолжение статьи «Практика управления проектами STREAM.PM».
В предыдущем материале мы рассказали о том, что такое STREAM.PM, что дает данный подход и из чего он вырос.

Модель ST+RE+AM

Принцип 1. ST=SYSTEM+TEAM
Баланс потенциала проектных команд
с опорой на системы и инструменты управления

Управление проектом должно обеспечивать развитие и максимизацию использования потенциала людей и КОМАНД в проектах, одновременно предоставляя командам и организациям опору на системы и инструменты проектного управления.

Мы не противопоставляем подходы с опорой на людей (например, agile) и с опорой на системы (классическое управление проектами) – сбалансированный подход дает наибольшие результаты.
Мы расставляем приоритеты следующим образом: «Люди, команды, культура организации на первом месте. Системы и инструменты управления подбираются для усиления команд, а не люди и команды встраиваются в системы».

Подход STREAM.PM обеспечивает осознанное и планомерное развитие компетентности людей и команд, создание условий для их эффективной работы, включая создание поддерживающей инфраструктуры управления проектами.

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

Подход STREAM.PM использует возможности ЦИФРОВИЗАЦИИ и современных технологий для предоставления командам наиболее удобного и интеллектуального инструментария управления проектами.

Принцип 2.
RE= RESULT ORIENTED+ECONOMICAL
Обеспечение достижения одновременно двух условий успеха проектов и проектной деятельности – результативность и экономическая эффективность

Управление проектами должно быть ориентировано на значимые для организации РЕЗУЛЬТАТЫ проектной деятельности и в то же время обеспечивать БЕРЕЖЛИВЫЙ подход к управлению проектом и к реализации проекта.

Инструменты классического управления проектами больше ориентированы на классический треугольник УП и недостаточно обеспечивают управление достижением выгод.

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

Принцип 3. AM=ADAPTIVE METHODOLOGY
Методология проектного управления адаптируется (настраивается) с учетом особенностей проектов, особенностей отдельных фаз и задач проектов, особенностей организаций, реализующих проекты.

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

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

Подход STREAM.PM не определяет одной единой методологии управления проектом, а обеспечивает подбор и адаптацию методологии, инструментов и практик управления проектами с учетом различных факторов и особенностей реализации проектной деятельности. Подходы STREAM.PM обеспечивают интеграцию («сшивание») различных инструментов проектного управления.

В то же время в Группе компаний «Проектная ПРАКТИКА» разрабатываются типовые решения на базе гибридных методологий для разных по сложности проектов и разных отраслей.

Написать ответ Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник

Что такое стриминг и как на этом зарабатывают?

Журналист, автор блока «Технологии».

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

Специалисты часто называют стриминг медиа будущего. При этом популярные стриминговые платформы уже вошли в набор известных инструментов в digital, а рынки киберспорта и стриминга видеоигр постоянно попадают в поле внимания СМИ.

На чем зарабатывают стримеры

Стримеры – авторы и трансляторы стримов – могут зарабатывать на своем канале несколькими способами:

Какие существуют способы интеграции бренда в стрим

Интегрировать рекламу компании в стрим можно с помощью следующих инструментов:

Платформы для стриминга

Возможности для стриминга как дополнительный сервис предлагают крупнейшие медиаплощадки. Иные платформы и сервисы специализируются исключительно на потоковом вещании.

К популярным стриминговым платформам в мире и России можно отнести:

Twitch

Крупнейшая стриминговая площадка, согласно данным компании Streamlabs. Twitch.tv вырос из ресурса justin.tv, который не ограничивался специализацией на видеоиграх, а транслировал также стримы про животных, спорт и политику. Однако в 2011 году руководители justin.tv поняли, что за компьютерными играми большое будущее, и переключились только на игровую тематику.

Twitch доступен через браузер на любом устройстве, в том числе для iOS и Android. Платформа проводит трансляции геймплея и киберспортивных турниров и сотрудничает с крупнейшими конференциями и мировыми чемпионатами в игровой индустрии.

YouTube Live

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

Facebook Live

Facebook Live запустился в 2016 году. С помощью сервиса можно напрямую связываться с подписчиками. Согласно статистике, пользователи Facebook комментируют прямые трансляции в несколько раз чаще, чем обычные видео. Смотреть потоки в Facebook Live можно непосредственно в момент их записи или постфактум.

Mixer

Mixer – стриминговая платформа, принадлежащая Microsoft, так же, как и Twitch, сфокусированная на видео-гейминге. Сервис интегрирован в Xbox One и Windows 10 и позволяет играть и общаться нескольким игрокам одновременно и устраивать интерактив со зрителями, которые могут воздействовать на геймплей и отдавать стримерам голоса.

Periscope

Periscope – служба потокового вещания, принадлежащая Twitter. Приложения Periscope доступны для Android и iOS. Пользователи Periscope могут транслировать видео в прямом эфире, общаться со зрителями, смотреть пропущенные трансляции в записи, делиться видео онлайн в соцсетях и проводить закрытые трансляции для отдельных пользователей.

GoodGame.ru

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

CyberGame.tv

CyberGame.tv – еще одна российская площадка, специализирующаяся на потоковом вещании для геймеров. Среди преимуществ CyberGame.tv – стабильная работа служб, постоянно обновляющийся функционал, удобная навигация и достаточное разнообразие трансляций с турниров и фестивалей.

VK Live

«Одноклассники»

Трансляция стримов доступна также для пользователей «Одноклассников» и OK Live. В 2017 году социальная сеть первой в России представила функцию стримов из браузера. Во время эфира стримеры могут общаться со зрителями в чате, получать «классы» и комментарии. Прямые трансляции попадают в ленты друзей и подписчиков и появляются на карте стримов, а самые популярные видео выходят в топ стримов OK Live.

Как настроить стрим

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

Xsplit Broadcaster достаточно проста в установке, но эта программа требует переустановки для каждой платформы. Open Broadcaster Software устанавливать сложнее, но зато, настроив программу один раз, к ее настройке возвращаться уже не нужно. Кроме того, OBS предлагает большой набор изменяемых параметров и не так сильно нагружает компьютер.

Зачем нужны чаты для стрима

Крайне важный элемент стрима – чат. Если стример проводит ретрансляцию для нескольких платформ, то он вряд ли сможет полноценно стримить без чата. Зрители с ресурсов с небольшой аудиторией в полупустых чатах чувствуют себя одиноко и не задерживаются на канале. Стримеры советуют уделять особое внимание таким зрителям и читать их сообщения в первую очередь. Причем выведение этих сообщений в общий поток на экране трансляции создает хорошие условия для пребывания пользователя на канале.

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

Источник

Что такое стрим? Определение, особенности, цели. Секреты удачного стрима

Стрим пришел к нам из YouTube и приложений наподобие «Перископа». Сейчас его вести можно и в «Инстаграме», и «ВКонтакте», и в «Одноклассниках». А что такое стрим вообще? Этот материал поможет вам разобраться.

Что такое стрим?

Каким бывает стрим?

Такой своеобразный прямой эфир бывает разного характера:

Особенности стримов

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

Цели стримов

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

Секреты удачного стрима

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

Бывалые стримеры делятся такими секретами своего успеха:

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

Источник

Практика управления проектами STREAM.PM

Более 25 лет специалисты группы компаний Проектная ПРАКТИКА помогают внедрять подходы проектного управления в различных организациях. За это время реализовано более 800 проектов. Результатом огромного практического опыта стал практический подход к управлению проектами в организации STREAM.PM.

Практика управления проектами STREAM.PM

STREAM.PM – что это?

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

Авторский подход ГК Проектная ПРАКТИКА по созданию и внедрению корпоративной методологии и системы управления проектной деятельностью организации, адаптированной под особенности проектов организации, а также под систему и культуру менеджмента организации.

STREAM.PM – практический подход, основан на опыте более 800 проектов ГК ПП
STREAM.PM – адаптация проектного управления под особенности проектов и организаций (технология создания гибридных методологий УП под разные типы проектов)
STREAM.PM – расширяем границы проектного управления (цикл управления: от идеи до выгод, интеграция полезных практик из смежных областей: управление изменениями, бережливое производство, управление знаниями и др.)
STREAM.PM – интеграция лучших практик от различных подходов (Системное + гибкое управление проектами System&Agile PM)

Что дает данный подход?

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

Предпосылки к созданию подхода STREAM.PM

Практический опыт ГК Проектная ПРАКТИКА показывает, что внедрение систем управления проектной деятельностью в организации (СУПД) не всегда обеспечивает ожидаемое повышение эффективности реализации проектов. Необходимость следования требованиям и регламентам системы повышает нагрузку на участников проектов, а полезность не всегда очевидна. В результате работа в единой системе может вызывать негативные эмоции, что осложняет внедрение и «приживаемость» системы.

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

Обобщая опыт внедрения систем управления проектами, мы выделили несколько важнейших факторов успеха СУПД в организации, позволяющих повысить полезность применения системы, избежать излишней формализации и нагрузки на персонал, повысить «приживаемость» СУПД.

Наш подход к созданию СУПД мы назвали STREAM.PM.

Основные принципы подхода STREAM.PM. Продолжение материалы

Подход STREAM.PM не определяет одной единой методологии управления проектом, а обеспечивает подбор и адаптацию методологии, инструментов и практик управления проектами с учетом различных факторов и особенностей реализации проектной деятельности. Подходы STREAM.PM обеспечивают интеграцию («сшивание») различных инструментов проектного управления.

В то же время в Группе компаний «Проектная ПРАКТИКА» разрабатываются типовых решения на базе гибридных методологий для разных по сложности проектов и разных отраслей.

Написать ответ Отменить ответ

Для отправки комментария вам необходимо авторизоваться.

Источник

О стримах и таблицах в Kafka и Stream Processing, часть 1

* Michael G. Noll — активный контрибьютор в Open Source проекты, в том числе в Apache Kafka и Apache Storm.

Статья будет полезна в первую очередь тем, кто только знакомится с Apache Kafka и/или потоковой обработкой [Stream Processing].

В этой статье, возможно, в первой из мини-серии, я хочу объяснить концепции Стримов [Streams] и Таблиц [Tables] в потоковой обработке и, в частности, в Apache Kafka. Надеюсь, у вас появится лучшее теоретическое представление и идеи, которые помогут вам решать ваши текущие и будущие задачи лучше и/или быстрее.

* Мотивация
* Стримы и Таблицы простым языком
* Иллюстрированные примеры
* Стримы и Таблицы в Kafka простым языком
* Пристальный взгляд на Kafka Streams, KSQL и аналоги в Scala
* Таблицы стоят на плечах гигантов (на стримах)
* Turning the Database Inside-Out
* Заключение

Мотивация, или почему это должно заботить?

В своей повседневной работе я общаюсь со многими пользователями Apache Kafka и теми, кто занимается потоковой обработкой с помощью Kafka через Kafka Streams и KSQL (потоковый SQL для Kafka). У некоторых пользователей уже есть опыт потоковой обработки или использования Kafka, у некоторых есть опыт использования РСУБД, таких как Oracle или MySQL, у некоторых нет ни того, ни другого опыта.

Часто задаваемый вопрос: «В чём разница между Стримами и Таблицами?» В этой статье я хочу дать оба ответа: как короткий (TL;DR), так и длинный, чтобы вы могли получить более глубокое понимание. Некоторые из приведённых ниже объяснений будут немного упрощены, потому что это упрощает понимание и запоминание (например, как более простая модель притяжения Ньютона вполне достаточна для большинства повседневных ситуаций, что избавляет нас от необходимости переходить сразу к релятивистской модели Эйнштейна, к счастью, потоковая обработка не настолько сложна).

Другой распространённый вопрос: «Хорошо, но почему это должно меня волновать? Как это поможет мне в моей повседневной работе?» Короче говоря, по многим причинам! Как только вы начнёте использовать потоковую обработку, вы вскоре осознаете, что на практике в большинстве случаев требуются и стримы, и таблицы. Таблицы, как я объясню позже, представляют состояние. Всякий раз, когда вы выполняете любую обработку с состоянием [stateful processing], как объединения [joins] (например, обогащение данных [data enrichment] в реальном времени путём объединения потока фактов с «размерными» таблицами [dimension tables] ) или агрегации [aggregations] (например, вычисление в реальном времени среднего значения для ключевых бизнес-показателей за 5 минут), тогда таблицы вводят потоковую картину [streaming picture]. В противном случае, это означает, что вы вынуждены будете делать это сами [a lot of DIY pain].

Даже пресловутый пример WordCount, вероятно ваш первый «Hello World» из этой области, попадает в категорию «с состоянием»: это пример обработки с состоянием, где мы агрегируем поток строк в непрерывно обновляемую таблицу/мапу для подсчёта слов. Таким образом, независимо от того, реализуете вы простой стриминг WordCount или что-то более сложное, как выявление мошенничества [fraud detection], вы хотите простое в использовании решение для потоковой обработки с основными структурами данных и всем необходим внутри (подсказка: стримы и таблицы). Вы, конечно же, не захотите строить сложную и ненужную архитектуру, где требуется соединять технологию (только лишь) потоковой обработки с удалённым хранилищем, таким как Cassandra или MySQL, и возможно, с добавлением Hadoop/HDFS для обеспечения отказоустойчивости обработки [fault-tolerance processing] (три вещи — слишком много).

Стримы и Таблицы простым языком

Вот лучшая аналогия, которую я смог придумать:

Иллюстрированные примеры

В первом примере показан стрим с геоположениями пользователей, которые агрегируются в таблицу, фиксирующую текущее (последнее) положение каждого пользователя. Как я объясню позже, это также оказывается для таблиц семантикой по умолчанию, когда вы читаете топик [Topic] Kafka непосредственно в таблицу.

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

Стримы и Таблицы в Kafka простым языком

Прежде чем мы погрузимся в детали, давайте начнём с простого.

Стрим — топик со схемой [schema]. Ключи и значения больше не массивы байтов, а имеют определённый типы.

Пример: топик читается как стрим геоположений пользователей.

Пример: стрим с обновлениями геоданных агрегируется в таблицу, которая отслеживает последнее положение пользователя. На этапе агрегации обновляются [UPSERT] значения в таблице по ключу из входного стрима. Мы видели это в первом проиллюстрированном примере выше.

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

Топики, стримы и таблицы обладают следующими свойствами в Kafka:

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

Пристальный взгляд на Kafka Streams, KSQL и аналоги в Scala

Если вы не знаете Scala: Не смущайтесь! Вам не нужно понимать Scala-аналоги во всех деталях. Достаточно обратить внимание на то, какие операции (например, map() ) соединяются вместе, чем они являются (например, reduceLeft() представляет собой агрегацию), и как «цепочка» стримов соотносится с «цепочкой» таблиц.

Топики

В Kafka Streams и KSQL нет понятия «топик». Они только знают о стримах и таблицах. Поэтому я покажу здесь только аналог топика в Scala.

Стримы

Теперь мы читаем топик в стрим, добавляя информацию о схеме (схему на чтение [schema-on-read]). Другими словами, мы превращаем сырой, нетипизированный топик в «типизированный топик» или стрим.

Схема на чтение vs Схема на запись [schema-on-write]: Kafka и её топики не зависят от формата сериализации ваших данных. Поэтому вы должны указать схему, когда захотите прочитать данные в стрим или таблицу. Это называется схемой на чтение. У схемы на чтение есть как плюсы, так и минусы. К счастью, вы можете выбрать промежуточное звено между схемой на чтение и схемой на запись, определив контракт для ваших данных — подобно тому, как вы, вероятно, определяете контракты API в ваших приложениях и сервисах. Это может быть достигнуто путём выбора структурированного, но расширяемого формата данных, такого как Apache Avro с разворачиванием реестра для ваших Avro-схем, например Confluent Schema Registry. И да, и Kafka Streams, и KSQL поддерживают Avro, если вам интересно.

Таблицы

Теперь мы читает этот же топик в таблицу. Во-первых, нам нужно добавить информацию о схеме (схему на чтение). Во-вторых, вы должны преобразовать стрим в таблицу. Семантика таблицы в Kafka гласит, что итоговая таблица должна отображать каждый ключ сообщений из топика в последнее значение для этого ключа.

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

Что интересно касательно отношения между стримами и таблицами, так это то, что команда выше создаёт таблицу, эквивалентную короткому варианту ниже (помните о ссылочной прозрачности [referential transparency]), где мы строим таблицу напрямую из стрима, что позволяет нам пропустить задание схемы / типа, потому что стрим уже типизирован. Мы можем увидеть, что таблица является выводом [derivation], агрегацией стрима:

В Kafka Streams вы обычно используете StreamsBuilder#table() для чтения топика Kafka в KTable простым однострочником:

Что это означит? Это означает, что таблица на самом деле является агрегированным стримом [aggregated stream], как мы уже говорили в самом начале. Мы видели это непосредственно в специальном случае выше, когда таблица создавалась напрямую из топика. Однако, на самом деле это общий случай.

Таблицы стоят на плечах гигантов (на стримах)

Таблицы часто также описываются как материализованное представление [materialized view] стрима. Представление стрима — это не что иное, как агрегация в этом контексте.

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

Агрегации в Kafka

Агрегации — это одна из разновидностей потоковой обработки. К другим типам, например, относятся фильтрация [filters] и объединения [joins].

Партицирование [partition] и ключи сообщений: Не менее важный аспект Kafka, который я игнорирую в этой статье, состоит в том, что топики, стримы и таблицы партицированы. Фактически, данные обрабатываются и агрегируются по ключу по партициям. По умолчанию, сообщения / записи распределяются по партициям на основании их ключей, поэтому на практике упрощение «агрегация по ключу» вместо технически более сложного и более правильного «агрегация по ключу по партиции» вполне допустимо. Но если вы используете кастомный алгоритм партицирования [custom partitioning assigners], тогда вы должны учитывать это в свой логике обработки.

Второе свойство агрегаций в Kafka заключается в том, что агрегации непрерывно обновляются как только новые данные поступают во входящие стримы. Вместе со свойством вычисления по ключу это требует наличия таблицы или, более точно, это требует изменяемую таблицу [mutable table] в качестве результата и, следовательно, типа возвращаемых агрегаций. Предыдущие значения (результаты агрегаций) для ключа постоянно перезаписываются новыми значениями. И в Kafka Streams и в KSQL агрегации всегда возвращают таблицу.

Вернёмся к нашему второму примеру, в котором мы хотим подсчитать по нашему потоку количество посещённых каждым пользователем мест:

Код на Kafka Streams, эквивалентный примеру на Scala выше:

Таблицы — агрегированные стримы (input stream → table)

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

Особенность этапа агрегирования определяет, является ли таблица напрямую получаемой из стрима через семантику UPSERT без состояния (таблица отображает ключи в их последнее значение в стриме, который является агрегацией при чтении топика Kafka напрямую в таблицу), через подсчёт количества увиденных значений для каждого ключа с сохранением состояния [stateful counting] (см. наш последний пример), или более сложные агрегации, такие как суммирование, усреднение и так далее. При использовании Kafka Streams и KSQL у вас есть много вариантов для агрегирования, включая оконные агрегации [windowed aggregations] с «переворачивающимися» окнами [tumbling windows], «прыгающими» окнами [hopping windows] и «сессионными» окнами [session windows].

В таблицах есть стримы изменений (table → output stream)

Вот первый пример, но уже с changelog stream:

Обратите внимание, что changelog stream таблицы является копией входного стрима этой таблицы. Это связано с природой соответствующей функции агрегации (UPSERT). И если вам интересно: «Подождите, разве это не 1 к 1 копирование, расходующее место на диске?» — Под капотом Kafka Streams и KSQL выполняется оптимизация, чтобы свести к минимуму ненужные копирования данных и локальный / сетевой IO. Я игнорирую эти оптимизации на диаграмме выше для лучшей иллюстрации того, что в принципе происходит.

И, наконец, второй пример использования, включающий changelog stream. Здесь стрим изменений таблицы отличается, потому что здесь другая функция агрегации, которая выполняет поключевой [per-key] подсчёт.

Но эти внутренние changelog stream‘ы также имеют архитектурное и эксплуатационное влияние. Стримы изменений непрерывно бэкапятся и сохраняются как топики в Kafka, и тема самым являются частью магии, которая обеспечивает эластичность [elasticity] и отказоустойчивость в Kafka Streams и KSQL. Это связано с тем, что они позволяют перемещать задачи по обработке между машинам / виртуалками / контейнерами без потери данных и на протяжении всех операций, независимо от того, обработка с состоянием [stateful] или без [stateless]. Таблица является частью состояния [state] вашего приложения (Kafka Streams) или запроса (KSQL), поэтому для Kafka является обязательным возможность переноса не только кода обработки (что легко), но и состояния обработки, включая таблицы, между машинами быстрым и надёжным способом (что намного сложнее). Всякий раз, когда таблица должна быть перемещена с клиентской машины A на машину B, то на новом назначении B таблица реконструируется из её changelog stream в Kafka (на стороне сервера) точно такое же состояние, какое было на машине A. Мы можем увидеть это на последней диаграмме выше, где «таблица подсчётов» [«counting table»] может быть легко востановлена из её changelog stream без необходимости переработки входного стрима.

Двойственность Стрим-Таблица

Термин stream-table duality относится к вышеуказанной взаимосвязи между стримами и таблицами. Это означает, например, что вы можете превратить стрим в таблицу, эту таблицу в другой стрим, полученный стрим в ещё одну таблицу и так далее. Для получения дополнительной информации см. пост в блоге Confluent: Введение в Kafka Streams: Stream Processing Made Simple.

Turning the Database Inside-Out

В дополнение к тому, что мы рассмотрели в предыдущих разделах, вы, возможно, сталкивались со статьёй Turning the Database Inside-Out, и теперь вам может быть интересно взглянуть на это целиком? Поскольку я не хочу сейчас вдаваться в детали, позвольте мне кратко сопоставить мир Kafka и потоковой обработки с миром баз данных. Будьте бдительны: далее серьёзные упрощения [black-and-white simplifications].

В базах данных, таблица — конструкция первого порядка. Это то, с чем вы работаете. «Стримы» также существуют в базах данных, например, в виде binlog в MySQL или GoldenGate в Oracle, но они, как правило, скрыты от вас в том смысле, что вы не можете взаимодействовать с ними напрямую. База данных знает о настоящем, но она не знает о прошлом (если вам нужно прошлое, восстановите данные с ваших ленточных бэкапов [backup tapes], которые, ха-ха, как раз аппаратные стримы).

В Kafka и потоковой обработке, стрим — конструкция первого порядка. Таблицы — производные от стримов [derivations of streams], как мы видели раньше. Стрим знает о настоящем, так и о прошлом. Как пример, New York Times хранит все опубликованные статьи — 160 лет журналистики с 1850-х — в Kafka, источнике достоверных данных [source of truth].

Если коротко: база данных мыслит сперва таблицей, а потом — стримом. Kafka мыслит сперва стримом, а потом — таблицей. Тем не менее, Kafka-сообщество осознало, что в большинстве случаем практического использования стриминга требуются и стримы, и таблицы — даже в пресловутом, но простом WordCount, в котором агрегируется стрим текстовых строк в таблицу со счётчиками слов, как и в нашем втором примере использования выше. Следовательно, Kafka помогает нам соединить миры потоковой обработки и баз данных, предоставляя нативную поддержку стримов и таблиц через Kafka Streams и KSQL, чтобы избавить нас от множества проблем (и предупреждений пейджера). Мы могли бы назвать Kafka и тип стриминговой платформы, которой она является, поточно-реляционной [stream-relational], а не только стриминговой [stream-only].

База данных мыслит сперва таблицей, а потом — стримом. Kafka мыслит сперва стримом, а потом — таблицей.

Заключение

Надеюсь, вы найдёте эти объяснения полезными для того, чтобы лучше понять стримы и таблицы в Kafka и потоковой обработки в целом. Теперь, когда мы закончили с деталями, вы можете вернуться в начало статьи и перечитать ещё раз разделы «Стримы и Таблицы простым языком» и «Стримы и Таблицы в Kafka простым языком».

Если в этой статье вам было интересно попробовать поточно-реляционную обработку с помощью Kafka, Kafka Streams и KSQL, вы можете продолжить изучение:

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

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

Источник