Последние 10 лет о данных говорят, что это новое электричество, новая нефть, из которых можно извлекать выгоду для компании. Но не все умеют это делать. Если данные просто лежат в старой Oracle Exadata или внутри 1С, толку от них немного. Если же вы научитесь создавать новые аналитические связи для дальнейшего анализа бизнес-процессов или предсказывать тренды на основе исторических данных — это уже другая история.
Привет, Хабр! Меня зовут Максим Еремин, руководитель направления развития продуктов beeline cloud, и сегодня я затрону тему работы с данными: почему ими нужно уметь управлять и с какими трудностями вы можете столкнуться.
А 19 марта в 11:00 мск я проведу вебинар о том, как эффективно хранить и обрабатывать большие объемы данных, когда в компании множество разрозненных корпоративных систем. Возникли вопросы? Накидывайте в комментариях — обсудим.
Что дает анализ данных?
Анализ данных помогает разобраться с некоторыми процессами в компании: что-то улучшить, скорректировать, оптимизировать показатели и выдать топам отчет в виде готовой аналитики. К этому сегодня стремятся практически все отрасли на нашем рынке. Но далеко не всем хватает зрелости, бизнес только встает на путь цифровой трансформации.
Поскольку данные могут быть разными, важно понимать, какую семантику они несут и в каком формате хранятся. Проще работать с текстом и временными рядами — в принципе это можно назвать подвидом текста, но не всегда.
Здесь могут быть подходы, связанные с анализом временных рядов, текста, его классификация, выделение сущностей, анализ краткого содержания, перевод текста и другое. Чуть сложнее, когда мы начинаем хранить и обрабатывать аналоговую информацию — изображение и звук. Такие данные хранить гораздо сложнее, поскольку не всегда для них подходит быстрый табличный формат. Соответственно, обрабатывать их тоже сложнее, поскольку для анализа используются другие алгоритмы, более требовательные по ресурсам: например, Object Detection для изображений или детектирование импульсных сигналов для звука.
Почему данными нужно управлять и почему это трудно?
Для задач прогнозирования и более глубокого анализа, помимо стандартной финансовой отчетности, важно понимать, какие данные, где лежат, как обрабатываются, что в себе хранят. Типичный случай для средней и крупной компании — обилие внутренних корпоративных систем: начиная от бухгалтерии и CRM, заканчивая внутренними или внешними сайтами и порталами, где тоже генерируются данные как от коллег внутри компании, так и от клиентов.
На первый взгляд кажется, что эти данные представляют ценность только по отдельности, но, когда встает необходимость отследить количество выставленных счетов клиентам для каждого менеджера по продажам и определить процент выполнения воронки, внезапно появляется необходимость в связке данных из разных систем. А где их в итоге соединять и хранить?
Можно использовать промежуточное хранилище, но если данных много, а результирующих таблиц не меньше, чем исходных данных, — стоит задуматься о более эффективном подходе. Для этого используют такие концепции, как «озеро данных», «корпоративное хранилище данных», «витрины данных» — это напрямую связано с хранением информации. Обычно их отличают по двум параметрам: структурированность и скорость доступа. Кстати, последнее еще можно охарактеризовать длительностью хранения.
Структурированные данные | Неструктурированные данные |
Часто изменяются, актуализируются, доступ предоставляется как можно быстрее. | Хранятся дольше, запрашиваются редко, доступ к таким данным обычно медленный. |
Такие данные называют горячими, лежат в «горячих» хранилищах — витринах данных. | Такие данные называют холодными, держат в «холодных» хранилищах — озерах данных. |
Где-то посередине лежат «теплые» данные — некоторое промежуточное состояние актуальных данных, которые еще будут подвергаться анализу и дополнительной трансформации.
ETL, ELT или OLAP?
А теперь о трансформации. За нее отвечает подход ETL/ELT — концепция, объединяющая в себе: 1) выгрузку данных из источника, 2) трансформацию и 3) загрузку данных в целевую систему.
Что ставить вторым, а что третьим — загрузку или трансформацию, — зависит от задачи.
Задача 1. Если мы загружаем данные из источника в холодное озеро данных, можно использовать ETL: здесь данные сначала достаем, затем преобразуем, чтобы сохранить их вдолгую, и загружаем в озеро данных. Такой подход работает чуть медленнее, чем ELT.
Задача 2. Если наша цель — выгрузить огромный массив данных и преобразовать в правильный и необходимый структурированный вид, лучше использовать подход ELT, поскольку данные сначала загружаются в целевую систему и параллельно трансформируются в нужный формат.
Не стоит забывать о подходе промежуточного хранилища данных. Под этим мы понимаем базу данных, которая играет роль долговременного и аналитического корпоративного хранилища.
При слишком большом объеме хранимых и обрабатываемых данных стоит использовать OLAP-подход и OLAP-базу данных. Важно понимать, что такие системы требовательны к вычислительным ресурсам и скорости записи/чтения дисков. Если же объем данных не сильно высокий, то роль КХД берет на себя обычная OLTP СУБД, по типу PostgreSQL, которая справляется с объемом до 1 ТБ.
Судя по текущим положениям, управлять разрозненными данными — не всегда простая задача, хотя работать с каждой системой по отдельности не сложно, особенно при наличии собственной команды и технической поддержки вендора.
Что такое платформа данных и как она помогает?
Сегодня на рынке представлены различные услуги, сервисы и ПО, обеспечивающие работу с данными. Они разделяются по концептуальному назначению.
Сбор данных — отвечает за накопление и первичную агрегацию данных на уровне входных потоков. Здесь выделяются два подхода — проактивный и реактивный:
Проактивный подразумевает, что система сбора данных сама «лезет» в источник и достает данные.
Реактивный подразумевает, что источник данных — это пользователь или группа пользователей: они «кидают» информацию в некую шину данных, которая потом обрабатывает и агрегирует их, а затем сохраняет в озеро данных.
Озеро данных — как уже говорили, место, где хранятся исходные «сырые» данные. В качестве озера может использоваться и холодное объектное хранилище с поддержкой протокола S3, поскольку скорость записи и чтения здесь не сильно важна. Главное — дешево хранить большой объем необработанных данных, которые занимают больше места, чем обработанные и агрегированные.
Просто хранить данные без дальнейшей возможности обращения к ним можно даже в параллельном режиме. Но тут теряется смысл, ведь рано или поздно к таким данным нужно будет обращаться и не просто выгружать в файлик с табличкой, а подключаться программным интерфейсом. Поэтому к такому хранилищу подключают множество надстроек, которые позволяют быстро доставать и обрабатывать данные. Примером может стать Hadoop с файловой системой hdfs и подключенным к ней Spark для параллельной обработки данных.
Корпоративное хранилище данных — место, куда сливаются и где хранятся структурированные (возможно, слабоструктурированные для дальнейших аналитических преобразований) и обработанные данные, разделенные по разным предметным областям. В этом случае данные не считаются сырыми, но из них можно сделать много новых отчетов и аналитических связей. Такие хранилища можно использовать еще и как движок для построения аналитических связей и вычислений.
Витрина данных — конечное «горячее» структурированное хранилище, где хранятся агрегированные данные, готовые для отчетности и оперативной выгрузки по предметно-ориентированным сферам компании. Витрины данных служат некой подложкой для конечных систем, которые направлены на конечный анализ данных, подготовку отчетности и BI.
Business Intelligence — давно известная тема, поскольку является неотъемлемой частью внутренней отчетности любой зрелой компании, где есть итеративный подход к анализу данных. Если данных немного — этим подходом можно пользоваться как «Экселем» (или самим «Экселем»). Но когда данных становится больше (например, несколько таблиц, каждая по несколько ГБ), уже становится трудновато агрегировать данные для отчетности через «Эксель». Тут в дело вступают системы анализа данных или специализированное ПО для отчетности.
Также, если необходимо, можно сливать данные из корпоративного хранилища в кэш данных, чтобы обеспечить доступ для внешних систем и приложений, которые будут использовать данные для каких-то других задач. Подойдет и Redis, но можно посмотреть в сторону энтерпрайзных Data Grid, которые объединяют в себе как очереди сообщений, так и шины данных, включая функционал привычных СУБД.
Какие решения существуют на рынке?
Apache Hadoop — в данном случае будем рассматривать стек, связанный с Hadoop: это и Apache Spark, который отвечает за обработку данных, и Apache Airflow, который отвечает за оркестрацию пайплайнов, и сам HDFS, который используется для хранения данных и является основой для построения озера данных.
Databricks — next gen понимание хранилища данных, которое можно охарактеризовать смешением озера данных и корпоративного хранилища — lakehouse. Такой подход совмещает хранение сырых данных, трансформацию, обработку и перевод в структурированный формат. Наверное, предоставлять данные в виде витрины будет не самым быстрым решением, с точки зрения клиентского BI, но агрегировать и управлять ими точно получится. Доступно практически во всех крупных зарубежных облаках.
Snowflake — эластичное хранилище, приближенное к корпоративному хранилищу данных. Состоит из трех компонентов: уровня хранения данных, обработки данных и облачного сервиса. Сама платформа ориентирована на использование в облаках, а уровень хранения данных реализуется с помощью S3-хранилища.
Teradata — параллельная реляционная СУБД. Поддерживает более петабайта данных, автоматически балансирует хранение данных и является массово-параллельной СУБД с MPP-архитектурой.
Cloudera — предоставляет вендорский Hadoop.
Arenadata — отечественный вендор, предоставляет решения платформы данных для полного жизненного цикла хранения и обработки данных. Arenadata DB — отечественный коммерческий дистрибутив MPP-СУБД Greenplum, который используется для построения корпоративных и аналитических хранилищ данных. Вокруг этого решения выстраиваются ADH (Hadoop) в качестве озера данных, ADQM (Clickhouse) в качестве витрин данных и ADS (Kafka и Nifi) для построения и контроля потоков данных, шин данных и ETL-процессов.
Как эффективно хранить и обрабатывать большой объем разрозненных данных?
Об этом я расскажу на вебинаре 19 марта в 11:00 мск. Разберемся с трудностями при работе с данными, поговорим о платформе данных, рассчитаем TCO на примере эксплуатируемых решений. Регистрируйтесь здесь — и до встречи!
