Если вы потратили хоть немного времени на работу в сфере программного обеспечения или разработки DevOps, скорее всего, фраза «миграция данных» не вызывает в воображении сцен счастья, спокойствия и ностальгии. (Если это так, возможно, вы волшебник / чернокнижник / ведьма или у вас очень избирательная память.) Переносите ли вы данные с устаревшего локального сервера на новейшее и лучшее облачное решение или ваш компания только что объединилась с другой, и вы извлекли досадно короткую соломинку интеграции различных бизнес-систем вместе, процесс передачи данных из точки A в точку B может быть утомительным и пугающим.
Обычно мы называем этот громоздкий процесс ETL («Извлечение, преобразование, загрузка»). Если вы новичок в ETL, вот краткое объяснение того, как это работает:
Шаг 1 - Извлечь:
Извлечение - это процесс извлечения данных из разных мест, обычно называемых источниками. Поскольку в пространстве ETL очень мало простых вещей, эти источники могут различаться по типу, размеру и сложности. Вы имеете дело с плоскими файлами, такими как CSV, JSON или XML, или перемещаетесь по базам данных SQL или NoSQL? Вы обрабатываете килобайты или гигабайты данных? И как размер этих данных влияет на количество времени, необходимое для их извлечения? Все это важные соображения, когда дело доходит до планирования и выполнения фазы извлечения ETL.
Шаг 2 - Преобразование:
Преобразование - следующий шаг. После извлечения данных они обычно обрабатываются или «преобразуются» перед загрузкой в целевое место назначения. Естественно, типы, требования и масштабы преобразований многочисленны и могут варьироваться от проверки данных до очистки, дедупликации и т. Д.
Шаг 3 - Загрузите:
Теперь, когда данные были каким-то образом преобразованы, пора загрузить их в конечный пункт назначения. Загрузка может быть последним шагом в процессе, но (вы заметили здесь тему?) он не лишен своих собственных сложностей. Как и на этапе извлечения, вы должны учитывать, куда загружаются данные - например, в плоский файл (CSV, JSON или XML) или базу данных (SQL или NoSQL).
Соображения:
Все это приводит нас к вопросу: что мы должны учитывать при выборе решения ETL? Фактически, есть несколько вещей, о которых вам следует подумать при оценке различных инструментов и библиотек, некоторые из которых включают:
- Стоимость. Сколько будет стоить решение ETL вашей команде в долларах в месяц, квартал и год? Стоимость многих инструментов может варьироваться от сотен до тысяч долларов в месяц, в зависимости от объема обрабатываемых данных. Кроме того, вы всегда должны знать о потенциальных скрытых платежах, таких как годовые контракты на поддержку.
- Адаптация. Сколько будет стоить решение ETL вашей команде с точки зрения времени и человеческих ресурсов? Как быстро ваша команда сможет освоить любой конкретный продукт ETL и приступить к работе? К сожалению, многие решения и инструменты - это чудовища с крутыми кривыми обучения.
- Гибкость. Можно ли быстро и легко настроить решение в соответствии с вашими требованиями? Достаточно ли он устойчив для буферизации и обработки больших объемов данных? Можно ли легко запланировать повторяющиеся задачи? Может ли задача запускаться после выполнения других задач?
- Документация и поддержка. Возможно, наиболее важным вопросом должно быть то, насколько хорошо это решение реагирует, когда мы сталкиваемся с проблемой? Если это платная услуга, как работает поддержка? Достаточна ли документация? Вы можете поговорить с человеком об этой документации? Если это решение с открытым исходным кодом, насколько хорошо написана документация GitHub? Хорошо ли прокомментирован и понятен код?
Решения с открытым исходным кодом:
Если вы не работаете в компании из списка Fortune 500 с соответствующим бюджетом, каковы ваши варианты? У сообщества разработчиков ПО с открытым исходным кодом, безусловно, есть варианты, но, к сожалению, многие из них не имеют надежной или понятной документации, активно не поддерживаются или не обладают гибкостью для учета различных типов и требований извлечения, преобразования и загрузки. Этот пробел вынудил нас создать собственный набор инструментов, известный как Kangaru-ETL и RxJS-ETL.
RxJS-ETL - это модульная платформа, построенная с использованием наблюдаемых RxJS, которые позволяют разработчикам создавать потоковые конвейеры ETL. Платформа предлагает дополнительные возможности, такие как буферизация, массовая вставка, уведомления о завершении задачи, планирование заданий и установление зависимостей задач.
Kangaru-ETL - это удобное кроссплатформенное приложение Electron, разработанное для использования библиотеки RxJS-ETL. Те, кто хочет или нуждаются в более наглядном и управляемом опыте использования RxJS-ETL, могут запустить Kangaru-ETL для импорта и экспорта файлов, подключения к базам данных, написания сценариев преобразования и настройки очереди запланированных заданий ETL.
Оба этих инструмента - плод любви, и мы, конечно, надеемся, что они могут быть полезны сообществу разработчиков ПО с открытым исходным кодом.
Ресурсы:
Https://medium.freecodecamp.org/sqlalchemy-makes-etl-magically-easy-ab2bd0df928
