Привет, я Ольга Свитнева, идеолог и менеджер продукта «Платформа данных» в VK Cloud. В современном мире ИТ тема Open Source поднимается довольно часто. Особенно когда речь идет о работе с данными. И тому есть ряд объективных причин.
В этой статье я предлагаю взглянуть на Open Source прагматично и разобрать неочевидные аспекты разработки и использования открытого ПО, в том числе лицензирование. Также мы поговорим об уникальном профиле риска OSS, о подходах к выбору решений и промышленных стандартах OSS для Data Pipeline.
Начнем с хорошего. Проблема, о которой речь пойдет далее, во многом продиктована быстрым ростом популярности OSS на российском рынке. Сегодняшний ИТ-рынок в целом и российский в частности сложно представить без открытого ПО. Помимо упомянутого выше импортозамещения, на это влияет несколько факторов:
Большинство из вас прекрасно знают, чем хороши Open-Source-проекты:
И вот здесь начинается самое интересное. Бытует мнение, что, применяя технологии с открытым кодом, компании экономят. Однако OSS не всегда экономит бюджет. Принесет ли проект на основе открытого кода экономическую выгоду, зависит от многих факторов, включая степень проработки архитектуры решения и наличие навыков, необходимых для его практической реализации и внедрения.
Можно поставить под сомнение и свободу выбора вариантов внедрения и поддержки. Для масштабных проектов, как правило, выбирают среди множества консалтинговых компаний и поставщиков, выпускающих продукты на основе OSS, либо это может быть вариант поддержки силами собственного ИТ-штата компании. Эта свобода находится между возможностями настраивать код по своему усмотрению и реальной способностью делать это, которая ограничена такими факторами, как инженерные знания и пропускная способность команд.
Еще один спорный аспект — разнообразие инструментов OSS, которое, безусловно, положительно влияет на развитие технологий. Разнообразие накладывает и дополнительные обязательства по правильному подбору стека и выстраиванию архитектуры в многокомпонентных платформенных решениях. Даже при большом ИТ-штате с развитой и разнообразной экспертностью это весьма длительная задача. На интеграцию продуктов между собой уходит дополнительное время, и зачастую это требует дополнительных расходов. Поддержка разных инструментов тоже закономерно требует больших усилий, поскольку каждый продукт нужно адаптировать под нужды компании.
Все это дает понимание сущности открытых продуктов и неизбежных рисков, с которыми вы столкнетесь на практике при их внедрении и использовании.
Для каждого решения OSS существует уникальный профиль риска, который формирует сочетание целого ряда факторов: зрелость проекта, пригодность лицензии, наличие коммерческих вариантов поддержки третьей стороной, применение практик разработки и ведения проектов, соблюдение стандартов и лучших практик в области безопасности и качества.
Основные риски, связанные с открытым кодом, включают в себя:
Вышеописанные риски приводят нас к проблеме безопасной разработки.
Открытый код известен, идентифицируем и исследуем. Казалось бы, весьма приятные условия для разработчика, но чем грозит открытая кодовая база? Open-Source-компоненты известны и идентифицируемы, а значит, атаку проще и быстрее подготовить именно через них. Чем популярнее пакет, тем тщательнее нужно исследовать его на предмет уязвимостей, поскольку он представляет наибольший интерес для атаки. С другой стороны, разработчик может включить в свой код ряд опен-сорс пакетов, которые, в свою очередь, ссылаются на дополнительные пакеты. Эта неявная зависимость также может впоследствии стать причиной уязвимости.
Чтобы контролировать ситуацию и создавать безопасный для пользователя продукт, необходимо регулярно отслеживать потенциальные эксплойты — программы, которые позволяют воспользоваться уязвимостью, — а также применять композиционный анализ (Software Composition Analysis, SCA).
На рынке существует отдельная ниша готовых решений класса SCA. Все они направлены на выстраивание процессов безопасной разработки: код должен пройти проверку на безопасность, прежде чем двигаться далее по релизному процессу. Средства автоматизированной проверки кода позволяют решить и проблему скорости безопасной разработки, поскольку позволяют синхронизировать процессы разработки и поиска уязвимостей без непредвиденных задержек.
Просто сказать «Код свободен для использования» уже недостаточно. Что значит «бесплатно»? Есть ли какие-либо ограничения? Что произойдет, если ваш код взломает систему? То есть мы должны быть осведомлены о связанных с этим рисках и юридических ограничениях.
Распространение OSS регулируется конкретной схемой лицензирования. По сути, лицензия определяет, какие права получают разработчики и компания, когда выбирают ту или иную открытую лицензию. Путаница, которая возникает из-за обилия лицензий и их совместимости друг с другом, — актуальная проблема Open Source, поэтому в этой главе попробуем пролить свет на этот вопрос.
Начнем с того, как найти информацию о лицензии. Поскольку речь идет об OSS, то исходный код проекта выложен на GitHub, и в директории с названием LICENSE можно найти содержание лицензии. Для удобства пользователей GitHub дополнительно предоставляет специальные разделы.
На страницах проектов, которые используют стандартные Open-Source-лицензии, есть секция с типом лицензии:
Если же перейти на страницу просмотра файла LICENSE из корневой директории проекта, то можно увидеть краткие сведения о лицензии с сайта Choose A License:
Этот раздел содержит три колонки:
Теперь, когда мы узнали тип лицензии, поговорим о том, где можно подробнее изучить ее содержание. Для этого я рекомендую несколько источников:
Я не буду дублировать информацию из этих ссылок, поскольку, на мой взгляд, она хорошо раскрыта в перечисленных источниках, но представлю некоторые выводы.
Очевидно, что лицензии на Open-Source-проекты определяют условия их использования. На что я хочу обратить особое внимание читателей: риски заключаются в том, что лицензии могут отсутствовать, быть неподходящими для проекта, могут требовать от разработчика раскрыть исходный код при распространении программы; при использовании нескольких продуктов с разными типами лицензий условия могут быть несовместимыми и не позволять выпустить единый продукт на основе их комбинации.
Многие лицензии практически дублируют друг друга с некоторыми небольшими оговорками, что создает сложности в их выборе и использовании. Существует отдельная организация Open Source Initiative, деятельность которой направлена на продвижение OSS и в том числе контроль видов лицензий. При этом юристы Open Source Initiative заявляют, что гарантируют защиту прав по каждой из указанных лицензий. Поэтому рекомендую при выборе OSS-инструмента уделить внимание подробному изучению лицензии, под которой он распространяется.
У каждой лицензии существует ряд производных. Чтобы легче было ориентироваться в аббревиатурах, перечислю несколько популярных типов:
Лицензия GNU GPL (General Public License). Предоставляет разработчикам широкий набор прав, поскольку позволяет легально копировать, распространять и модифицировать код и ПО на его основе, зарабатывать на распространении ПО и его поддержке. Прекрасна во всем, кроме одного: если вы решили использовать только часть кода, делая свой продукт, то ваш проект должен будет также распространяться под этой лицензией.
Лицензия Apache. Ее должны оценить сотрудники юридической службы, поскольку набор прав определен четко и затрагивает различные условия. Чем лицензия особенно хороша: права неотъемлемы, вечны и глобальны. Что это означает: с момента, как только права были вам предоставлены, вы можете пользоваться ими всегда и независимо от того, в какой стране они были выданы.
Из подводных камней: если собираетесь создавать продукт для платного распространения на основе задействованных инструментов на этой лицензии, то обратите внимание на раздел, регламентирующий название выпускаемого вами продукта или сервиса. Лицензия отдельно оговаривает, что для производных работ нельзя использовать те же названия, если они являются торговыми марками.
Лицензия MIT. Самая обобщенная и короткая из всех. По большому счету, она позволяет все: модифицируйте, копируйте, продавайте или распространяйте безвозмездно. Единственное ограничение состоит в том, что ваше ПО должно сопровождаться лицензионным соглашением.
Лицензия BSD (Berkeley Software Distribution). Точнее, это большое семейство лицензий, для примера выделим две, совместимые с GPL: New BSD/Modified BSD и Simplified BSD/FreeBSD.
Лицензия New BSD разрешает неограниченное распространение с любой целью, не дает никаких гарантий и не несет никакой ответственности. Подводный камень здесь в том, что без специального разрешения вы не можете указать себя в соавторах проекта, даже если вы его существенно модифицировали. Основное различие между New BSD и Simplified BSD в том, что последняя не включает в себя пункт, ограничивающий использование имен авторов. Сравнение различных BSD-лицензий хорошо описано здесь.
Итак, мы посмотрели на OSS с различных ракурсов, перейдем к насущной проблеме: на что обращать внимание при выборе OSS-инструмента.
Выбор софта на основе открытого кода не сильно отличается от выбора проприетарного коммерческого ПО. Ключевые критерии для оценки включают в себя функциональность, интеграцию и стоимость владения. При этом в случае OSS мы имеем большую прозрачность, поскольку все метаданные о решении документируются и их легко найти в свободном доступе. Поэтому не составит труда собрать необходимую информацию для выбора инструмента и оценки проекта. Среди критериев, которые нужно учитывать для принятия решения в пользу того или иного OSS, следует отметить следующие:
Помимо этих критериев, компаниям следует ориентироваться на эксперность и квалификацию специалистов своего штата, сложность и масштабы проекта и сценарии его реализации.
Чтобы успешно внедрить проект на основе OSS, необходимо донести его ценность до различных заинтересованных сторон, которые должны признать его важность для бизнес-стратегии. Масштабный проект будет интегрироваться в корпоративную архитектуру, что потребует участия служб инжиниринга, безопасности, рисков, инфраструктуры, разработки, операций. Поэтому OSS-проект — это своего рода инвестиция, которая при правильном управлении может принести выгоду бизнесу и увеличить общую стоимость владения.
Перейдем к практической стороне и начнем с подборки стека OSS для работы с данными. Не претендую на исчерпывающее перечисление всех существующих инструментов, но покажу некоторые промышленные стандарты, чтобы дать общую картину в виде конвейера данных.
Такой пайплайн показывает, что для работы с большими данными нужны разнообразные классы программ, технологий и методик. Причем главной задачей становится связка всех инструментов в единую цепочку, что требует платформенного решения. При этом у вас должна быть возможность выбрать Open-Source-инструменты, которые лучше всего подходят вам в той или иной точке пайплайна данных. К примеру, один проект требует реализации стриминга в реальном времени, а другой подразумевает пакетную загрузку; для одной команды удобна оркестрация задач с помощью Airflow, а другие предпочитают Dagster, и т. д.
И еще один важный момент заключается том, что возможности специалистов по работе с данными при таком подходе расширяются. Это происходит главным образом благодаря применению дополнительных инструментов. Например, инженеры-аналитики становятся более автономными, используя DBT.
При самостоятельном внедрении OSS нужно оценивать все риски, тщательно прорабатывать архитектуру, создавать культуру разработки, контролировать зависимости, регулярно отслеживать обновления безопасности, интегрировать все компоненты между собой в единое платформенное решение.
Альтернативным вариантом может выступать использование облачных платформенных продуктов, в составе которых находятся OSS-решения, доступные как управляемые сервисы. То есть облачный провайдер берет на себя обязательства по автоматизации развертки продуктов, их обновления, интеграции с другими облачными решениями и позволяет пользователю комбинировать отраслевые решения из набора необходимых ему сервисов. На примере близкой мне области — работа с данными — облачное платформенное решение может выглядеть следующим образом:
Платформа представлена в виде экосистемы интегрированных между собой масштабируемых облачных сервисов для захвата и обработки данных, их хранения, управления данными, анализа, визуализации и моделирования. Важно то, что все компоненты платформы технологически и логически связаны между собой.
Примером реализации потока данных на сервисах OSS-стека может быть следующая архитектура:
Мы видим два блока наиболее частых задач Big Data — это сбор и подготовка данных и машинное обучение. Основным результатом первого блока является доведение данных до уровня их пригодности для принятия управленческих решений. Можно сказать, что артефактом на выходе будет слой горячих витрин с актуальной и обработанной информацией.
Для этого мы проходим путь от источников, применяя инструменты загрузки и обработки данных, таких как Flink и Spark. Для оркестрации ETL-задачи можно использовать Airflow, а в качестве распределенной потоковой платформы — Kafka.
Затем идет слой разнообразных сервисов для хранения данных и организации их в витрины:
Второй блок позволяет углубиться в анализ и исследование ранее собранных данных, вплоть до предиктивной аналитики и машинного обучения. В качестве инструментов ML для проведения экспериментов можно воспользоваться JupyterHub, а воспроизводимость экспериментов, версионирование и сборку моделей может обеспечить компонент MLflow.
Инструменты, продемонстрированные в данном пайплайне, фактически являются промышленными стандартами и обладают развитым сообществом, что определяло их выбор. С другой стороны, для создания управляемого сервиса на основе OSS нужно соответствовать лицензионным политикам, и это очень важный аспект, на который ориентируется любой облачный провайдер. И безусловно, пайплайн должен покрывать разнообразные пользовательские сценарии, что подразумевает интеграцию ряда открытых продуктов между собой.
Это был общий обзор направления OSS и его проблематик. На мой взгляд, Open Source становится драйвером инноваций для современного стека данных, и в последующих статьях я сравню различные инструменты, являющиеся промышленными стандартами для данной области.
В этой статье я предлагаю взглянуть на Open Source прагматично и разобрать неочевидные аспекты разработки и использования открытого ПО, в том числе лицензирование. Также мы поговорим об уникальном профиле риска OSS, о подходах к выбору решений и промышленных стандартах OSS для Data Pipeline.
Нынешняя проблематика Open Source и перспективы развития
Начнем с хорошего. Проблема, о которой речь пойдет далее, во многом продиктована быстрым ростом популярности OSS на российском рынке. Сегодняшний ИТ-рынок в целом и российский в частности сложно представить без открытого ПО. Помимо упомянутого выше импортозамещения, на это влияет несколько факторов:
- Количество Open-Source-проектов растет с каждым годом, развитое сообщество сформировало промышленные стандарты решений в каждой области. Если еще 10–15 лет Open-Source-проектов было сравнительно немного, то сейчас фактически на любую задачу найдется достойное решение среди открытого ПО — и не одно, а сразу несколько, адаптированных под разные потребности. Можно сказать, что Open Source является доминирующей моделью ПО для открытых инноваций в новой цифровой экономике.
- Повышение интереса к стеку открытого программного обеспечения как к основе для собственных решений промышленного уровня. Здесь все линейно: адаптировать качественные Open-Source-разработки для промышленной эксплуатации проще, чем вести их с нуля.
- Развитие облачных платформ и рост потребления облачных сервисов. Облачные платформы предоставляют Open-Source-инструменты как готовые сервисы, тем самым делая их предпочтительными для многих проектов, для которых ИТ — не профильная деятельность.
Большинство из вас прекрасно знают, чем хороши Open-Source-проекты:
- прозрачность — доступна информация обо всех изменениях в коде, на каком этапе разработки находится проект;
- экспертность и открытое сотрудничество — для развитых инструментов характерно наличие сообщества, в котором множество заинтересованных программистов регулярно тестируют и обновляют код, чтобы сделать его лучше. Активное сообщество может помочь в поиске решений или предоставить видение, выходящее за рамки интересов определенной группы разработчиков;
- возможность бесплатного использования лицензий;
- гибкость, то есть свобода выбора внедрения и поддержки решений;
- разнообразие и вариативность инструментов.
И вот здесь начинается самое интересное. Бытует мнение, что, применяя технологии с открытым кодом, компании экономят. Однако OSS не всегда экономит бюджет. Принесет ли проект на основе открытого кода экономическую выгоду, зависит от многих факторов, включая степень проработки архитектуры решения и наличие навыков, необходимых для его практической реализации и внедрения.
Можно поставить под сомнение и свободу выбора вариантов внедрения и поддержки. Для масштабных проектов, как правило, выбирают среди множества консалтинговых компаний и поставщиков, выпускающих продукты на основе OSS, либо это может быть вариант поддержки силами собственного ИТ-штата компании. Эта свобода находится между возможностями настраивать код по своему усмотрению и реальной способностью делать это, которая ограничена такими факторами, как инженерные знания и пропускная способность команд.
Еще один спорный аспект — разнообразие инструментов OSS, которое, безусловно, положительно влияет на развитие технологий. Разнообразие накладывает и дополнительные обязательства по правильному подбору стека и выстраиванию архитектуры в многокомпонентных платформенных решениях. Даже при большом ИТ-штате с развитой и разнообразной экспертностью это весьма длительная задача. На интеграцию продуктов между собой уходит дополнительное время, и зачастую это требует дополнительных расходов. Поддержка разных инструментов тоже закономерно требует больших усилий, поскольку каждый продукт нужно адаптировать под нужды компании.
Все это дает понимание сущности открытых продуктов и неизбежных рисков, с которыми вы столкнетесь на практике при их внедрении и использовании.
Уникальный профиль риска OSS
Для каждого решения OSS существует уникальный профиль риска, который формирует сочетание целого ряда факторов: зрелость проекта, пригодность лицензии, наличие коммерческих вариантов поддержки третьей стороной, применение практик разработки и ведения проектов, соблюдение стандартов и лучших практик в области безопасности и качества.
Основные риски, связанные с открытым кодом, включают в себя:
-
технические — прежде всего это дефекты и уязвимости безопасности;
-
юридические — соблюдение лицензионных требований OSS, а также потенциальные нарушения интеллектуальной собственности;
-
безопасность — проистекает из природы Open Source. Компании могут столкнуться с некачественной поддержкой или ее отсутствием. Продукт может не обновляться так часто, как следовало бы.
Вышеописанные риски приводят нас к проблеме безопасной разработки.
(Не)безопасность разработки
Открытый код известен, идентифицируем и исследуем. Казалось бы, весьма приятные условия для разработчика, но чем грозит открытая кодовая база? Open-Source-компоненты известны и идентифицируемы, а значит, атаку проще и быстрее подготовить именно через них. Чем популярнее пакет, тем тщательнее нужно исследовать его на предмет уязвимостей, поскольку он представляет наибольший интерес для атаки. С другой стороны, разработчик может включить в свой код ряд опен-сорс пакетов, которые, в свою очередь, ссылаются на дополнительные пакеты. Эта неявная зависимость также может впоследствии стать причиной уязвимости.
Чтобы контролировать ситуацию и создавать безопасный для пользователя продукт, необходимо регулярно отслеживать потенциальные эксплойты — программы, которые позволяют воспользоваться уязвимостью, — а также применять композиционный анализ (Software Composition Analysis, SCA).
На рынке существует отдельная ниша готовых решений класса SCA. Все они направлены на выстраивание процессов безопасной разработки: код должен пройти проверку на безопасность, прежде чем двигаться далее по релизному процессу. Средства автоматизированной проверки кода позволяют решить и проблему скорости безопасной разработки, поскольку позволяют синхронизировать процессы разработки и поиска уязвимостей без непредвиденных задержек.
Особенности лицензирования
Просто сказать «Код свободен для использования» уже недостаточно. Что значит «бесплатно»? Есть ли какие-либо ограничения? Что произойдет, если ваш код взломает систему? То есть мы должны быть осведомлены о связанных с этим рисках и юридических ограничениях.
Распространение OSS регулируется конкретной схемой лицензирования. По сути, лицензия определяет, какие права получают разработчики и компания, когда выбирают ту или иную открытую лицензию. Путаница, которая возникает из-за обилия лицензий и их совместимости друг с другом, — актуальная проблема Open Source, поэтому в этой главе попробуем пролить свет на этот вопрос.
Начнем с того, как найти информацию о лицензии. Поскольку речь идет об OSS, то исходный код проекта выложен на GitHub, и в директории с названием LICENSE можно найти содержание лицензии. Для удобства пользователей GitHub дополнительно предоставляет специальные разделы.
На страницах проектов, которые используют стандартные Open-Source-лицензии, есть секция с типом лицензии:
Если же перейти на страницу просмотра файла LICENSE из корневой директории проекта, то можно увидеть краткие сведения о лицензии с сайта Choose A License:
Этот раздел содержит три колонки:
- Permission — информация о том, что лицензия вам разрешает делать с проектом;
- Limitation — ограничения, которые накладывает лицензия на тех, кто модифицирует или распространяет разработку;
- Conditions — что лицензия не гарантирует и чего не разрешает.
Теперь, когда мы узнали тип лицензии, поговорим о том, где можно подробнее изучить ее содержание. Для этого я рекомендую несколько источников:
- Описание содержания лицензий: https://choosealicense.com/licenses/. Обратите внимание на раздел https://choosealicense.com/appendix/, в нем представлена справочная таблица и промаркированы разрешения, ограничения и условия для наиболее популярных видов лицензий.
- Русскоязычный сайт http://licenseit.ru/, раздел «Некоммерческие лицензии». Это проект на добровольных началах, здесь, помимо исходного текста лицензии, можно найти дополнительные разъяснения понятий и юридических аспектов.
- Раздел с дополнительными комментариями по распространенным видам лицензий: https://www.gnu.org/licenses/license-list.en.html
- Небольшой гайд по самым популярным видам лицензий: https://www.smashingmagazine.com/2010/03/a-short-guide-to-open-source-and-similar-licenses/
Я не буду дублировать информацию из этих ссылок, поскольку, на мой взгляд, она хорошо раскрыта в перечисленных источниках, но представлю некоторые выводы.
Очевидно, что лицензии на Open-Source-проекты определяют условия их использования. На что я хочу обратить особое внимание читателей: риски заключаются в том, что лицензии могут отсутствовать, быть неподходящими для проекта, могут требовать от разработчика раскрыть исходный код при распространении программы; при использовании нескольких продуктов с разными типами лицензий условия могут быть несовместимыми и не позволять выпустить единый продукт на основе их комбинации.
Многие лицензии практически дублируют друг друга с некоторыми небольшими оговорками, что создает сложности в их выборе и использовании. Существует отдельная организация Open Source Initiative, деятельность которой направлена на продвижение OSS и в том числе контроль видов лицензий. При этом юристы Open Source Initiative заявляют, что гарантируют защиту прав по каждой из указанных лицензий. Поэтому рекомендую при выборе OSS-инструмента уделить внимание подробному изучению лицензии, под которой он распространяется.
У каждой лицензии существует ряд производных. Чтобы легче было ориентироваться в аббревиатурах, перечислю несколько популярных типов:
Лицензия GNU GPL (General Public License). Предоставляет разработчикам широкий набор прав, поскольку позволяет легально копировать, распространять и модифицировать код и ПО на его основе, зарабатывать на распространении ПО и его поддержке. Прекрасна во всем, кроме одного: если вы решили использовать только часть кода, делая свой продукт, то ваш проект должен будет также распространяться под этой лицензией.
Лицензия Apache. Ее должны оценить сотрудники юридической службы, поскольку набор прав определен четко и затрагивает различные условия. Чем лицензия особенно хороша: права неотъемлемы, вечны и глобальны. Что это означает: с момента, как только права были вам предоставлены, вы можете пользоваться ими всегда и независимо от того, в какой стране они были выданы.
Из подводных камней: если собираетесь создавать продукт для платного распространения на основе задействованных инструментов на этой лицензии, то обратите внимание на раздел, регламентирующий название выпускаемого вами продукта или сервиса. Лицензия отдельно оговаривает, что для производных работ нельзя использовать те же названия, если они являются торговыми марками.
Лицензия MIT. Самая обобщенная и короткая из всех. По большому счету, она позволяет все: модифицируйте, копируйте, продавайте или распространяйте безвозмездно. Единственное ограничение состоит в том, что ваше ПО должно сопровождаться лицензионным соглашением.
Лицензия BSD (Berkeley Software Distribution). Точнее, это большое семейство лицензий, для примера выделим две, совместимые с GPL: New BSD/Modified BSD и Simplified BSD/FreeBSD.
Лицензия New BSD разрешает неограниченное распространение с любой целью, не дает никаких гарантий и не несет никакой ответственности. Подводный камень здесь в том, что без специального разрешения вы не можете указать себя в соавторах проекта, даже если вы его существенно модифицировали. Основное различие между New BSD и Simplified BSD в том, что последняя не включает в себя пункт, ограничивающий использование имен авторов. Сравнение различных BSD-лицензий хорошо описано здесь.
Итак, мы посмотрели на OSS с различных ракурсов, перейдем к насущной проблеме: на что обращать внимание при выборе OSS-инструмента.
Как выбирать OSS-продукт
Выбор софта на основе открытого кода не сильно отличается от выбора проприетарного коммерческого ПО. Ключевые критерии для оценки включают в себя функциональность, интеграцию и стоимость владения. При этом в случае OSS мы имеем большую прозрачность, поскольку все метаданные о решении документируются и их легко найти в свободном доступе. Поэтому не составит труда собрать необходимую информацию для выбора инструмента и оценки проекта. Среди критериев, которые нужно учитывать для принятия решения в пользу того или иного OSS, следует отметить следующие:
- активность разработки, которая измеряется с помощью таких показателей, как количество коммитов за квартал, а также количеством коммиттеров (создателей кода);
- история выпуска ПО. Релизы должны быть регулярными и отражать общую зрелость проекта;
- поддержка сообщества и документация, уровень которых можно определить, исходя из активности сообщества и его величины. Прежде всего, это проявляется в количестве исправленных ошибок из трекера проблем проекта, а также в динамичности и полезности тем, которые обсуждаются в поддержке проекта;
- экосистема, которая должна включать в себя широкий спектр компаний и индивидуальных разработчиков, вносящих в нее код;
- модель лицензирования определяется степенью свободы применения и распределения кода, а также управляет любыми негативными последствиями злоупотребления лицензией;
- отчеты о безопасности, которые включают в себя процесс исправления ошибок и уязвимостей, связанных с кодом.
Помимо этих критериев, компаниям следует ориентироваться на эксперность и квалификацию специалистов своего штата, сложность и масштабы проекта и сценарии его реализации.
Чтобы успешно внедрить проект на основе OSS, необходимо донести его ценность до различных заинтересованных сторон, которые должны признать его важность для бизнес-стратегии. Масштабный проект будет интегрироваться в корпоративную архитектуру, что потребует участия служб инжиниринга, безопасности, рисков, инфраструктуры, разработки, операций. Поэтому OSS-проект — это своего рода инвестиция, которая при правильном управлении может принести выгоду бизнесу и увеличить общую стоимость владения.
Подборка стека OSS для работы с Big Data
Перейдем к практической стороне и начнем с подборки стека OSS для работы с данными. Не претендую на исчерпывающее перечисление всех существующих инструментов, но покажу некоторые промышленные стандарты, чтобы дать общую картину в виде конвейера данных.
Такой пайплайн показывает, что для работы с большими данными нужны разнообразные классы программ, технологий и методик. Причем главной задачей становится связка всех инструментов в единую цепочку, что требует платформенного решения. При этом у вас должна быть возможность выбрать Open-Source-инструменты, которые лучше всего подходят вам в той или иной точке пайплайна данных. К примеру, один проект требует реализации стриминга в реальном времени, а другой подразумевает пакетную загрузку; для одной команды удобна оркестрация задач с помощью Airflow, а другие предпочитают Dagster, и т. д.
И еще один важный момент заключается том, что возможности специалистов по работе с данными при таком подходе расширяются. Это происходит главным образом благодаря применению дополнительных инструментов. Например, инженеры-аналитики становятся более автономными, используя DBT.
Облако как альтернатива
При самостоятельном внедрении OSS нужно оценивать все риски, тщательно прорабатывать архитектуру, создавать культуру разработки, контролировать зависимости, регулярно отслеживать обновления безопасности, интегрировать все компоненты между собой в единое платформенное решение.
Альтернативным вариантом может выступать использование облачных платформенных продуктов, в составе которых находятся OSS-решения, доступные как управляемые сервисы. То есть облачный провайдер берет на себя обязательства по автоматизации развертки продуктов, их обновления, интеграции с другими облачными решениями и позволяет пользователю комбинировать отраслевые решения из набора необходимых ему сервисов. На примере близкой мне области — работа с данными — облачное платформенное решение может выглядеть следующим образом:
Платформа представлена в виде экосистемы интегрированных между собой масштабируемых облачных сервисов для захвата и обработки данных, их хранения, управления данными, анализа, визуализации и моделирования. Важно то, что все компоненты платформы технологически и логически связаны между собой.
Примером реализации потока данных на сервисах OSS-стека может быть следующая архитектура:
Мы видим два блока наиболее частых задач Big Data — это сбор и подготовка данных и машинное обучение. Основным результатом первого блока является доведение данных до уровня их пригодности для принятия управленческих решений. Можно сказать, что артефактом на выходе будет слой горячих витрин с актуальной и обработанной информацией.
Для этого мы проходим путь от источников, применяя инструменты загрузки и обработки данных, таких как Flink и Spark. Для оркестрации ETL-задачи можно использовать Airflow, а в качестве распределенной потоковой платформы — Kafka.
Затем идет слой разнообразных сервисов для хранения данных и организации их в витрины:
- для холодного хранения это может быть S3;
- для справочников и консистентных данных подойдет реляционная база данных вроде Postgres;
- в качестве аналитической базы, которая хорошо держит OLAP-нагрузку и горизонтально масштабируется, может выступать Greenplum;
- чтобы осуществлять выборку данных со сложными аналитическими вычислениями, целесообразно использовать колоночную базу, например ClickHouse;
- в качестве In-memory-базы для оперативной аналитики больших данных в режиме онлайн хорошо подойдет Tarantool.
Второй блок позволяет углубиться в анализ и исследование ранее собранных данных, вплоть до предиктивной аналитики и машинного обучения. В качестве инструментов ML для проведения экспериментов можно воспользоваться JupyterHub, а воспроизводимость экспериментов, версионирование и сборку моделей может обеспечить компонент MLflow.
Инструменты, продемонстрированные в данном пайплайне, фактически являются промышленными стандартами и обладают развитым сообществом, что определяло их выбор. С другой стороны, для создания управляемого сервиса на основе OSS нужно соответствовать лицензионным политикам, и это очень важный аспект, на который ориентируется любой облачный провайдер. И безусловно, пайплайн должен покрывать разнообразные пользовательские сценарии, что подразумевает интеграцию ряда открытых продуктов между собой.
Это был общий обзор направления OSS и его проблематик. На мой взгляд, Open Source становится драйвером инноваций для современного стека данных, и в последующих статьях я сравню различные инструменты, являющиеся промышленными стандартами для данной области.