Задание: Программист баз данных. Разработка ETL-платформы для автоматической консолидации данных из 1С, Zoho и Kingdee в единый DWH (Дистанционная работа)
1. Цель проекта В группе компаний используются несколько независимых информационных систем. Необходимо построить полностью автоматизированную систему, которая будет регулярно получать данные из всех учетных систем, приводить их к единому формату и сохранять в централизованном хранилище данных. 2. Исходные системы 2.1. 1С (Комплексная Автоматизация) Используется российским юридическим лицом, в краткосрочной перспективе появится аналогичная база 1С в Казахстане. Содержит: продажи; закупки; складской учет; контрагентов; товары; бухгалтерские документы; счета; платежи. Способ получения данных необходимо определить совместно с исполнителем. Возможные варианты: REST API; HTTP-сервисы 1С; OData; SQL; COM; выгрузки; иной технически обоснованный способ. 2.2. Zoho Books Используется компанией в ОАЭ, в краткосрочной перспективе появится аналогичная база Zoho Books в Саудовской Аравии. Содержит: продажи; закупки; складской учет; контрагентов; товары; бухгалтерские документы; счета; платежи. Доступен официальный API. 2.3. Kingdee Cloud Stellar Используется китайской компанией. Содержит: продажи; закупки; контрагентов; товары; бухгалтерские документы; счета; платежи. Способ подключения определяется после изучения имеющейся версии Kingdee, доступен API. 3. Общие требования Необходимо реализовать систему, которая: • автоматически получает данные; • автоматически обновляет изменения; • не требует ручного запуска; • не требует ручной обработки файлов; • предусматривает резервное копирование данных; • имеет журнал ошибок; • может быть перезапущена после сбоя без потери данных. 4. Архитектурные требования Исполнитель самостоятельно предлагает архитектуру решения. Допускается использование любых технологий, включая: • n8n; • Airbyte; • Apache NiFi; • Python; • собственные ETL; • Docker; • PostgreSQL; • другие современные инструменты. Главное требование — надежность, масштабируемость и возможность дальнейшей обработки собранных данных, в первую очередь для составления консолидированной финансовой отчетности по группе компаний. 5. Хранилище данных Необходимо организовать единое хранилище данных. Предпочтительно PostgreSQL. Исполнитель может предложить альтернативу при наличии аргументации. Хранилище должно обеспечивать: • хранение истории; • возможность повторной обработки данных; • возможность последующего подключения BI и AI. 6. Структура хранения Необходимо обеспечить максимально полное сохранение данных из источников. Желательно разделение данных на уровни (сырые/нормализованные). 7. Обновление данных Необходимо обеспечить: • первоначальную полную загрузку; • последующие инкрементальные обновления; • защиту от появления дубликатов; • повторную загрузку после ошибок. 8. Логирование Система должна вести журнал: • времени запуска; • времени окончания; • количества обработанных объектов; • ошибок; • предупреждений. 9. Мониторинг При возникновении ошибки система должна уведомлять администратора. 10. Масштабируемость Архитектура должна предусматривать возможность последующего подключения: • новых компаний; • новых ERP; • CRM; • банков; • BI; • AI. 11. Ожидаемый результат После завершения проекта должна существовать система, которая автоматически выполняет полный цикл, состоящий из получения данных, их преобразования, загрузки, логирования и уведомления при ошибках без участия пользователя. 12. Критерии приемки Проект считается выполненным, если одновременно соблюдаются следующие условия. • После запуска система автоматически получает данные из всех подключенных источников. • После изменения данных в ERP изменения появляются в едином хранилище без ручного вмешательства. • Повторный запуск не приводит к появлению дубликатов. • При временной недоступности одной из ERP после восстановления соединения данные догружаются корректно. • При ошибке пользователь получает уведомление. • Имеется журнал всех запусков. • Исполнитель демонстрирует полный цикл работы системы. • Исполнитель передает: исходный код; конфигурацию; инструкции по развертыванию; инструкции по резервному копированию; инструкции по восстановлению после сбоя. 13. Требования к документации По завершении проекта должна быть передана документация, включающая: • описание архитектуры; • описание потоков данных; • описание всех интеграций; • описание используемых API; • схему базы данных; • инструкцию по запуску; • инструкцию по обновлению; • инструкцию по переносу на новый сервер. 14. Требования к качеству архитектуры Исполнитель должен не просто реализовать интеграцию, но и обосновать выбранную архитектуру. В частности, необходимо описать: • причины выбора конкретного ETL-инструмента; • причины выбора способа подключения к каждой ERP; • принципы организации хранилища данных; • стратегию инкрементальной загрузки; • стратегию обработки изменений и удалений; • стратегию резервного копирования; • стратегию восстановления после сбоя; • оценку производительности и возможности масштабирования. Все архитектурные решения должны быть согласованы до начала разработки.
