«Традиционно, самым узким местом в архитектуре любой информационной системы является система управления базами данных (СУБД). Можно сколько угодно оптимизировать прикладное программное обеспечение (ПО), но все равно упремся в ограничения в части производительности запросов». В своем материале я рассказываю о том, как построить архитектуру системы без слабых мест, и кого для этого стоит принести в жертву.  Если верить исследованиям международной исследовательской и консалтинговой компании IDC, то к 2025 году общий объем цифровых данных, генерируемых во всем мире, вырастет более чем вчетверо — до 175 Зеттабайт. Напомню, что в конце 2020-го года мир перешагнул отметку в 40 Зеттабайт. Естественно, достичь новых рекордов можно только при условии, что все поголовно будут правильно строить свою архитектуру системы. Но как это лучше делать, и какие есть подводные камни — разбираемся вместе в этой статье.  Вообще, чтобы разобрать вопрос в комплексе, следует начать с теории, ведь это основа основ. И в первую очередь, надо понять, что такое архитектура системы.   Архитектура системы — это принципиальная организация системы, воплощенная в её элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие её проектирование и эволюцию.  Архитектура включает в себя: Если с первыми двумя пунктами все более-менее понятно, то третий, однозначно, требует пояснений. В ходе проектирования, разработки, развития и модернизации информационной системы (ИС), ее архитектура требует постоянного обсуждения со всеми участниками проекта, включая бизнес.  Перейдем к следующему этапу — классификация: Информационная архитектура — набор методик и инструментов, описывающий информационную модель конкретной предметной области (домена).
Включает в себя: Архитектура прикладных решений – совокупность прикладных программных продуктов и интерфейсов между ними. Техническая архитектура — совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений: Бизнес-архитектура — модель бизнес-процессов и сквозных информационных потоков.

Очевидно, что для эффективного представления архитектурных решений, нужно найти способ, с помощью которого можно доступно, но в тоже время достаточно развернуто донести их суть (концепцию) до максимально широкого круга лиц. Чтобы мне не пришлось долго объяснять, вспомним Джона Захмана, он составил матричную модель, которая позволяет легко презентовать набор архитектурных артефактов путем ответа на простые вопросы: Сложив этот пазл Захмана, мы однозначно получим два итога: во-первых, откроем глаза всем заинтересованным, во-вторых, сохраним им структуру мозга — вероятно, она могла бы измениться, если бы весь процесс пришлось изучать самостоятельно.  Основа архитектуры систем — big data. Традиционно, принято считать, что большие данные имеют три признака – vvv: Ну а дальше появились 4 и 5 признаки (и до бесконечности) – veracity, visualization, value, viability… Видимо, это соревнование ученых мужей в том, сколько умных слов они знают на букву v.   В отличие от традиционной архитектуры информационных систем (ИС), архитектура современных распределенных систем класса Big Data больше похожа на «пирог» и имеет сложную многоуровневую архитектуру, которая называется LSA — Layered Scalable Architecture. И если, вы думаете, что про «пирог» я шутил, то, ошибаетесь — вот вам все его (LSA) слои: Чтобы было понятнее, объясню, как на практике выглядит архитектура LSA: Если что-то из вышенаписанного осталось неясным, есть два решения: первое — перечитать еще раз, второе – написать мне в сообщения, и мы разберем с вами «на пальцах».   Итак, мы и добрались до главного — исходные данные. Тут все достаточно прямолинейно: мы работаем с файлами на входе, соответственно нам нужна файловая система, но так как архитектура у нас распределенная, то и файловая система у нас должна быть распределенной. И вариантов тут не очень много: NFS, HDFS, CephFS, GlusterFS.  NFS – старый, добрый, проверенный и вполне годный. Но если вам нужна более «гибкая» система и возможность масштабирования, то для хранения сырых данных лучше подойдет HDFS. HDFS (Hadoop Distributed File System) — файловая система, предназначенная для хранения файлов, поблочно-распределённых между узлами вычислительного кластера. Благодаря репликации (механизм синхронизации содержимого нескольких копий объекта) обеспечивается устойчивость распределённой системы к отказам отдельных узлов. Файлы в HDFS могут быть записаны лишь однажды (модификация не поддерживается), а запись в файл в одно время может вести только один процесс. Организация файлов в пространстве имён — традиционная иерархическая: есть корневой каталог, поддерживается вложение каталогов, в одном каталоге могут располагаться и файлы, и другие каталоги. Но как же склеить коржи в нашем «слоеном пироге», и каков рецепт заварного крема? И хорошие новости – крем будет импортный (Apache Kafka), от известной фабрики LinkedIn, где этот брокер сообщений был создан еще в 2012 году.   Apache Kafka (3) — распределённый программный брокер сообщений. Спроектирован, как распределённая, горизонтально масштабируемая система, обеспечивающая наращивание пропускной способности как при росте числа и нагрузки со стороны источников, так и количества систем-подписчиков. Подписчики могут быть объединены в группы. Поддерживается возможность временного хранения данных для последующей пакетной обработки. Про Kafka можно рассказывать так много и интересно, что получится отдельная статья, которую я напишу ;) Вернемся к архитектуре. Традиционно, самым узким местом в архитектуре любой информационной системы является система управления базами данных (СУБД). Можно сколько угодно оптимизировать прикладное программное обеспечение (ПО), но все равно упремся в ограничения в части производительности запросов к СУБД. Что делать? — Использовать NoSQL вместо реляционных СУБД, но придется чем-то жертвовать (об этом позже).  На уровне ядра широко применяются NoSql СУБД: Изначально термин NoSQL буквально читался как: No («Не») и SQL (сокращение от англ. Structured Query Language — «структурированный язык запросов»). Хотя, вероятно, задумка была иной – «не реляционный», но NoSQL звучало лучше и в итоге прижилось. Позднее, NoSQL стали расшифровывать как «Not Only SQL» («не только SQL»).  NoSQL стал общим термином для различных баз данных и хранилищ, но он не обозначает какую-либо одну конкретную технологию или продукт. Традиционные (SQL) СУБД ориентируются на требования ACID к транзакционной системе: атомарность (atomicity), согласованность (consistency), изолированность (isolation), долговечность(durability), тогда как в NoSQL вместо ACID используется усеченный набор признаков BASE: Помните, чуть выше я говорил о «жертвах». Так вот, если вам требуется максимальная производительность, то следует отправить в мир иной консистентность! Как показывает практика,  без этого вполне можно жить, лишь бы система масштабировалась в горизонт линейно с ростом объемов данных. А как нам быть, если производительности СУБД все равно не хватает, а заказчик требует стремительного отклика на запросы в режиме реального времени?
Тут все просто: часто используемые запросы не надо приземлять сразу на СУБД, иначе она в эту землю и приляжет.
Выход — поднимаем эти данные в оперативную память. Тут проверенным решением является Redis (от англ. remote dictionary server) — резидентная in memory система управления базами данных класса NoSQL с открытым исходным кодом, работающая со структурами данных типа «ключ — значение». Ориентирована она на достижение максимальной производительности на атомарных операциях (приблизительно 100 тыс. SET- и GET-запросов в секунду на сервере начального уровня). Плюс, она хранит базу данных в оперативной памяти. И пару слов про витрины.
Витрины данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и настраивать. По сути, витрина — это просто слепок данных для аналитических целей. При этом, данные в витрине уже обогащены всем необходимым. То есть, нет необходимости джойнить данные из НСИ и терять на это уйму времени. Для современных витрин очень часто применяют такие решения как Elasticsearch и, относительно новую, колоночную СУБД Clickhouse от Yandex. Переливать данные можно опять же с помощью нашей любимой Kafka. В завершение статьи я бы хотел остановиться на очень важном аспекте — инфраструктуре в ЦОД (центре обработки данных), где развернута наша прекрасная информационная система. В погоне за функциональными возможностями и в потоке бесконечно меняющихся бизнес-требований, забывают о самом главном: надежной отказоустойчивой инфраструктуре в ЦОД, с запасом на 3-5 лет, с учетом кратного роста объема данных, количества пользователей и т.д…  Тут огромное количество аспектов, и все они одинаково важны для штатного режима эксплуатации ИС: Говоря о масштабировании базового и прикладного ПО, стоит отметить, что абсолютно все элементы должны быть развернуты в кластерной конфигурации. Никаких решений — «этот компонент можно развернуть как standalone» тут быть не должно!
Очереди в Kafka должны быть партиционированы, базы данных шардированы.  Резюмируя: при эксплуатации таких огромных информационных систем нет неважных деталей — каждая мелочь имеет вес и может «выстрелить в ногу» в самый неподходящий момент.  Также, читайте наши статьи в блоге, а на следующей неделе подробно разбираем систему хранения. CTO