Привет, Хабр! Меня зовут Наджим Мохаммад, я руководитель продукта МТС. Вместе с моим коллегой, руководителем направления разработки платформы МТС Big Data Максимом Бартеневым сегодня мы  поговорим об эволюции платформ данных и нюансах работы платформы МТС для работы с данными. Также обсудим историю развития самой DataOps Platform.

Стадии развития платформ для работы с данными

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

Каменный век. Это примерно 1998 год, пик развития локальных баз данных. То была эпоха баз данных (БД) Oracle и других БД. Все они хранились изолированно, и к ним время от времени обращались. Они помогали в поиске информации, но особо эффективной такая работа не была. В первую очередь БД использовались для хранения информации о различных транзакциях, событиях и прочих подобных вещах.

Аналитика как инструмент работы с данными применялась редко. К этому бизнес пришёл уже позже. Выше показана структура типичной платформы для работы с данными конца XX — начала XXI вв. В шутку этот этап действительно можно назвать «каменным веком». Тем, кто работал с такими платформами, стало понятно, что необходимы более функциональные инструменты, которые предоставляли бы возможность анализировать данные.

Средние века. Становление Data Warehouse, появление таких технологий, как корпоративное хранилище данных (КХД) и единое хранилище данных (ЕХД). К слову, во многих компаниях они существуют до сих пор.

В этот период данные становятся нужны всем, но возникают сложности с пониманием того, какие именно данные и кому требуются.  Это же время — пик востребованности ETL-разработчиков, но им приходится непросто, поскольку мало кто из сотрудников/руководства способен дать чёткое техническое задание. Примерная ситуация с этими специалистами показана на картинке выше. К слову, через время ETL-разработчики станут одними из самых востребованных специалистов на рынке, превратившись чуть позже в дата-инженеров.

На этом этапе стали активно использоваться распределённые аналитические базы данных или MPP-системы — в основном закрытые вендорские решения, например Teradata, Exadata, Sap Hana и т. п. Это были отличные предложения для построения корпоративных хранилищ данных. Работали они хорошо, были производительными и функциональными, бизнес ими активно пользовался. Но, к сожалению, их цена была высокой, а использовать можно было только вариант от одного вендора, поскольку поставлялись и «железо», и софт вместе. Собственно, это был «коробочный продукт», который сложно было поменять впоследствии на что-то другое. Чаще всего такие продукты были несовместимы друг с другом.

Ещё чуть позже появился вендорский ETL, своего рода «гильдии» ETL-разработчиков, включая SAS, Informatica и другие. Но кардинально ничего не поменялось.

Вишенка на торте — вендорский BI, включая Tableau и Power BI. Это отличные решения, которые просто работали, выполняя необходимые бизнесу задачи.

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

Эпоха Возрождения. Это примерно 2015–2020 гг., и данных реально много, приходится искать выход из положения. Им становится Data Lake. Технологий для построения Data Lake было чрезвычайно много, фрагментация рынка была заметной. Многие компании выходили на рынок работы с данными, предлагали свои решения. Во многом это была экосистема Apache-сервисов вокруг Hadoop.

Мы в  МТС тоже стали строить собственный Data Lake на Hadoop, который, кстати, до сих пор отлично работает. Тогда мы верили, что есть возможность неограниченной масштабируемости. Что можно собрать все данные, какие только возможно, а затем решить, что с ними делать. В целом, так работа и велась.

Считать так помогало изобилие программных open-source-решений, которые можно было ставить на недорогое и, главное, разнообразное «железо» от разных вендоров. На тот момент это был гигантский шаг вперёд по сравнению с эпохой вендорских залоченных решений.

Но здесь возникла проблема: Hadoop во многих случаях работал нестабильно и не так быстро, как хотелось. Для МТС возникла ещё одна проблема: мы только-только построили первый кластер, у нас был запас в 8 Пб, и он неожиданно быстро закончился. Оказалось, что стратегия вроде «загружаем всё, что можно, а потом разбираемся» не работает, поскольку доступное место действительно очень быстро заканчивается.

Затем проявилась ещё одна проблема. Так, у Hadoop достаточно высокий порог входа, технических специалистов пришлось обучать, на что ушло достаточно много времени. Получается, что мы брали обычных аналитиков и превращали их в data-аналитиков.

Как бы там ни было, мы справились, построили собственный Data Lake. Но осталась проблема с данными, которые были загружены ранее.

2020–2022. История Нового времени, Data Governance. В этот период мы начали решать проблему с данными. Стали присматриваться к DAMA-DMBOK, но здесь пришлось много в чём разбираться. Дело в том, что это просто огромный свод правил, разделённый на разные секции, где всё направлено на то, чтобы улучшить работу со своими данными.

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

2022. Новое время. Эпоха Data Mash, когда в компаниях появляются экосистемы. Они, эти экосистемы, взаимодействуют с конечным потребителем на разных временных интервалах его жизненного цикла. Так, утром человек просыпается — это одна точка. Днём, на работе — вторая. Вечером, во время покупки товаров в магазине — третья.

Мы в МТС начали создавать такую экосистему работы с данными, где всё организовано рационально и удобно. При этом порог входа минимальный, экосистема организована по схеме Cloud as a service, что позволяет сильно экономить на работе с данными. А сами они становятся дешевле, так что хранить можно более глубокую историю, чем раньше, затрачивая меньше средств, чем ранее.

А что мы построили сейчас?

Выше — иллюстрация строения экосистемы МТС в отношении работы с данными. Какие у неё достоинства?

Один из наиболее важных моментов заключается в том, что мы убрали все вендорские решения, за малыми исключениями. Убрали Tableau, Teradata и всё, о чём говорилось выше. Вместо этого используются открытые решения с широким спектром возможностей. И даже там, где решения от вендоров ещё используются, сейчас совершается переход на новые решения. Например, в день с Tableau на Superset в среднем переходит около 4 тыс. бордов. Процесс миграции близок к завершению, т. е. вскоре в экосистеме компании вообще не будут использоваться вендорские решения.

Кроме того, очень заметно выросли эффективность работы и производительность сервиса. Так, количество запросов в день к разным базам превышает 5 000, при старых показателях в 2 000–2 500. Пользователи уже сами создают для себя те борды, которые им нужны для работы, анализа данных и получения ценных инсайтов. Всё это стало очень простым для использования — ключевой момент для компании. Ну а вся работа с данными стандартизирована, что не допускает хаоса.