1. Фон проекта и необходимость интеграции данных
В современном бизнес-менеджменте системы управления проектами становятся ключевыми платформами для операций компании, выходя за рамки простых инструментов для управления задачами.
Особенно в крупных организациях на основе текущего статуса проекта, графика, ресурсов и данных о взаимоотношениях принимаются различные решения.
Одним из самых важных факторов в этом процессе является надежность и целостность данных.
Главной задачей на начальном этапе проекта было объединение данных проекта, которые были разбросаны по нескольким устаревшим системам, в одну централизованную рабочую систему.
Проблема заключалась не просто в переносе данных. Каждая устаревшая система имела разные цели и архитектуры, а также использовала различные СУБД и модели данных.
Кроме того, в каждой системе ежедневно происходят непрерывные генерация и изменение данных.
Особенно, из-за характеристик данных управления проектом, данные Activity и Relationship были очень сложно связаны между собой.
Например, существовала проблема следующего характера.
- Несоответствие структуры данных по системам
- Модель отношений активности отличается
- Различия в системе ключей
- Проблема обработки удаленных данных
- Отсутствие отслеживания изменений
- Необходимо обеспечить целостность данных
В общем, в проектах интеграции данных часто используется метод CDC (Change Data Capture).
То есть, это способ отслеживания только измененных данных и передачи их в целевую систему.
Однако в этом проекте подход на основе CDC оказался неуместным. Причина в том, что исходная система сама не обеспечивала полное управление историей изменений.
Также в некоторых исключительных случаях также существовала вероятность возникновения удаленных данных или пропуска изменений.
Особенно в бизнесе на месте требовалась 100% целостность данных.
В итоге проект выбрал стратегию на основе Full-Load, которая заключается в том, чтобы «каждый день заново собирать все данные».
То есть, каждый день данные из всей системы Legacy собираются через ETL и сравниваются с данными существующей рабочей системы, чтобы отразить новые и измененные данные. Это был довольно смелый подход.
На самом деле объем данных, который нужно обрабатывать каждый день, был следующим.
- Десятки тысяч данных об активности
- Уровень данных о взаимоотношениях в 10 миллионов записей
- Обработка полного загрузки на десятки миллионов записей
В конце концов, суть этого проекта заключалась не в простой миграции данных, а в том, как надежно и эффективно обрабатывать «данные большого объема Full-Load».
2. Стратегия интеграции данных на основе Full-Load
Одна из самых важных философий проектирования в этом проекте заключалась в безоговорочной гарантии целостности данных.
Хотя обычный метод CDC имеет преимущества с точки зрения эффективности, существует вероятность нарушения целостности данных в случае пропуска изменений или возникновения исключительных ситуаций.
Особенно данные управления проектом имели сложную структурную взаимосвязь, поэтому даже небольшие пропуски в данных могли разрушить всю связанную структуру.
Поэтому в проекте была выбрана стратегия полного сбора данных (Full-Load) с ежедневным обновлением всей информации.
То есть, это был способ получения данных всей Source Table исходной системы каждый день через ETL. Конечно, этот подход создает значительную нагрузку в плане объема данных.
Потому что нужно было обрабатывать сотни тысяч данных Activity и более десяти миллионов данных Relationship каждый день.
Но преимущества, которые можно получить, были очевидны.
Первое - это обеспечение целостности данных.
Поскольку конечное состояние исходной системы отражается без изменений, удалось принципиально устранить возможность пропуска изменений.
Вторая задача заключалась в обработке удаленных данных.
В структурах на основе CDC часто трудно отслеживать удаленные данные, однако в структуре Full-Load было легко идентифицировать данные, которые в настоящее время отсутствуют.
Третьим аспектом была операционная стабильность.
Это связано с тем, что не нужно было зависеть от качества управления изменениями самого Legacy системы.
Однако такая структура привела к проблемам обработки больших объемов данных, которые нельзя решить только с помощью простого обработки БД.
Особенно большой проблемой было следующее:
- Операция сравнения больших объемов данных
- Увеличение стоимости обработки Upsert
- Обработка стандартизации на основе Join
- Ограничение времени на расстановку
- Увеличение нагрузки на базу данных
В реальном проекте необходимо было завершить всю пакетную обработку примерно за 3 часа в утреннее время.
Поэтому необходимо было оптимизировать архитектуру самой системы для обработки больших объемов данных, выходя за рамки простой оптимизации запросов.
В конечном итоге проект выбрал стратегию распределенной обработки данных поэтапно, разработав структуру на основе многоступенчатой трубопроводной системы.
3. Этап 1 ~ 2: Архитектура сбора и очистки
Первый шаг заключался в сборе данных (Ingestion).
В проекте требовалось собирать данные из нескольких устаревших систем, которые работали на разных серверах и в различных средах СУБД.
Например, некоторые системы работали на базе Oracle, некоторые на MSSQL, а некоторые на MySQL. Сначала мы также рассматривали возможность разработки индивидуальных адаптеров для каждой системы.
Однако каждый раз, когда добавлялась устаревшая система, требовалась разработка нового адаптера, что могло повлечь за собой значительные затраты на обслуживание.
В конечном итоге было решено использовать Informatica, ETL-решение, специализированное для интеграции разнородных данных.
Поскольку Informatica предлагает функции подключения к различным СУБД и сбора данных по умолчанию, удалось значительно эффективнее организовать структуру подключения системы.
Кроме того, минимизация нагрузки на устаревшие операционные системы также была очень важным требованием. Поскольку все устаревшие системы были действующими производственными системами, ситуация, при которой производительность могла бы снизиться из-за ETL-процессов, была недопустима.
Чтобы решить эту проблему, проект разработал структуру на основе Replica.
То есть, данные Legacy операционной базы данных были скопированы в внутреннюю Replica DB рабочей системы, а затем фактическая очистка выполнялась на Replica DB.
В этом процессе использовалась стратегия полной загрузки на основе Truncate & Insert.
Благодаря этому, нам удалось минимизировать нагрузку на рабочую базу данных и стабильно получать последние данные.
Вторым этапом была Refinement (этап уточнения).
Данные по системам Legacy имели совершенно разные структуры.
Например, структура таблицы Activity и структура Relationship различались между системами. В таком состоянии было невозможно провести интеграционное сравнение и обработку Upsert, поэтому стандартизация была абсолютно необходима.
В проекте была разработана структура для очистки данных Activity и Relationship в общую стандартную модель.
Проблемой был объем данных. Ежедневно нужно было обрабатывать десятки миллионов записей, при этом в процессе стандартизации должны были выполняться массовые операции, такие как Join, обработка строк, вычисление отношений и др. Простая оптимизация запросов не позволяла уложиться в требуемые сроки обработки.
В конечном итоге была внедрена параллельная обработка.
Учитывая, что нет взаимосвязи между данными в устаревших системах, мы выполнили очистку данных параллельно по системам. В результате время обработки удалось сократить на половину.
4. Этап 3 ~ 4 : Интеграция и окончательная загрузка
Третий этап - это этап интеграции.
На этом этапе была выполнена работа по объединению очищенных данных о деятельности и отношениях по каждому из устаревших систем в единую интегрированную модель.
На этом этапе существовала сложность, превышающая простое слияние.
Самой большой проблемой была возможность дублирования ключей, так как разные унаследованные системы могли использовать одинаковые значения ключей.
Для решения этой проблемы мы совместно разработали систему идентификации на основе Origin System.
То есть, это не просто использование простого PK, а разработано так, чтобы также управлять вопросом «из какой Legacy системы были созданы данные».
Это позволило устранить возможность конфликта данных и обеспечить прослеживаемость.
Также все данные были дополнены тегом Origin System.
Благодаря этой структуре впоследствии было легко отслеживать, из какой исходной системы были созданы определенные данные в процессе эксплуатации.
Четвертый этап был этапом Преобразования и Загрузки.
Ключом на этом этапе было эффективное сравнение существующих данных базы данных с новыми данными полной загрузки.
Проблема заключалась в объеме данных. Сравнение миллионов записей каждый день с использованием обычных методов сравнения может занять слишком много времени.
Для решения этой проблемы в проекте использовалась стратегия сравнения на основе хеширования.
Каждая строка использовалась для создания хеш-значения, и это значение сравнивалось с хешем существующих данных с тем же PK.
То есть мы не сравнивали все реальные данные, а лишь быстро определяли изменения, сравнивая только хеш-значения.
Эта структура позволила быстро идентифицировать следующие данные.
- Новый объект вставки
- Обновить объект
- Данные без изменений
Также фактическая обработка Upsert была спроектирована с асинхронной структурой. Подтвержденные данные для вставки и обновления были переданы в временные таблицы каждого сервиса через Kafka.
Затем каждая служба самостоятельно выполняет Upsert, чтобы обновить финальную рабочую базу данных.
Такая асинхронная структура на основе Kafka снизила связность между системами и обеспечила эффект изоляции отказов.
5. Оптимизация производительности и операционная стабильность
Одной из главных целей данного проекта было не просто успешно обрабатывать данные, но и создать "структуру, которую можно стабильно обрабатывать ежедневно".
Особенно важно было обеспечить высокую производительность обработки и стабильность работы для структуры массовой полной загрузки.
В проекте были применены следующие стратегии оптимизации.
- Параллельная структура обработки
- Хэш-основывающее сравнение
- Постепенная распределенная обработка
- Балансировка нагрузки на основе Replica
- Асинхронная обработка на основе Kafka
- Изоляция сбоев на основе Stage
Особенно структура пайплайна на основе Stage оказалась очень эффективной с точки зрения операционной стабильности.
На каждом этапе ведется журнал, и в случае возникновения ошибки обработка приостанавливается с этого момента.
Таким образом, удалось избежать ситуации, когда неверные данные передаются в конечную рабочую базу данных.
Кроме того, мы настроили автоматическую отправку уведомлений по электронной почте администратору в случае возникновения неполадок, что позволяет быстро реагировать.
Благодаря этой структуре нам удалось обеспечить как стабильность работы, так и надежность данных.
В реальных проектах была обеспечена производительность, способная ежедневно надежно обрабатывать данные в количестве от нескольких миллионов до десятков миллионов. Особенно это было значимо, что удалось достичь уровня обработки, который можно было бы эксплуатировать даже на основе архитектуры Full-Load.
Кроме того, благодаря архитектуре на основе Kafka удалось предотвратить распространение сбоев в отдельных службах на весь поток данных.
В результате проект смог обеспечить уровень надежности и масштабируемости, превосходящий простой ETL-системы, до уровня «платформы для интеграции больших данных».
6. Завершение
Этот проект был не просто проектом по переносе данных.
Это был проект по построению архитектуры интеграции данных для объединения больших объемов данных управления проектами, разбросанных по различным устаревшим системам, в одной централизованной платформе, чтобы поддерживать надежное бизнес-решение на его основе.
Особенностью, которая особенно выделяется, является то, что была реализована структура на основе полного загрузки на уровне, пригодном для реальной эксплуатации.
Хотя обычно массовые структуры полной загрузки часто считают неэффективными, в проекте приоритетом была целостность данных, и архитектура была оптимизирована соответственно.
В результате были достигнуты следующие результаты.
- Обеспечение целостности данных
- Надежное отражение данных удаления
- Повышение операционной стабильности
- Обеспечение производительности обработки больших данных
- Построение структуры изоляции сбоев
- Обеспечение расширяемых данных.
Самым важным моментом было то, что мы попытались гарантировать не только простую реализацию технологий, но и саму «деловую надежность» через структуру данных.
В процессе реализации проекта я еще раз осознал, что интеграция данных является не просто перемещением информации, а крайне важной областью, создающей основу для принятия решений в компании.
Кроме того, в ходе этого опыта я глубже осознал, что в среде обработки больших данных необходимо разрабатывать не только простую оптимизацию запросов, но и всю архитектуру и поток данных в целом.
Я думаю, что этот опыт станет очень важной отправной точкой, даже если в будущем мы будем проводить аналогичные проекты по интеграции крупных данных.
informalife