Практический опыт миграции платформы данных на российское ПО

[@vladig6649]

Не понятен смысл миграции данных из разных предметных баз данных, которые могут вообще не пересекаться по показателям, в одно хранилище. Если модель данных предметной области и ее прикладных задач достаточно полная и имеет нормализованную реляционную структуру, то в принципе, в зависимости от конкретной аналитической задачи, потребуется только построить мостик перегона необходимых данных в таблицы соответствующей базы данных (хранилища) аналитической системы (БДАС, ХАС). То есть, БДАС (ХАС) должна иметь определенную структуру в которую будут загружаться данные из конкретной прикладной БД, а аналитическая система делает к ней подключение (connection) для выполнения требуемых аналитических процедур и визуализации их результатов.

[@biqube-itpro]

Смысл - собрать данные для решения задачи управления бизнесом с той детализацией, которая позволяет рассмотреть все контролируемые показатели "от источника", победить разрозненность, обеспечить гарантированное извлечение данных, сделать гибкие механизмы преобразования и расчёта показателей. В деталях: типичная ситуация любого крупного предприятия - десятки юридических лиц, учёт в 1С разных редакций и версий, в dynamics ax, производственные показатели в SAP, складские в WMS, управленческий учёт в Excel, данные о прдажах через дистрибьюторов или сети или маркетплейсы - или через API, или файовые выгрузки совершенно разной структуры. А ещё окажется что готовых данных на источнике просто нет - остатки на каждую дату в учёте отсутствуют (есть только дельты), или показатель каждый раз внутри учёта рассчтывает какой-то модуль, или имеем дело с потоковыми данными и нужно отбирать только отклонения от нормы. НИГДЕ с 2007 года, ни в одной отрасли, если бизнес имеет размер выручки от 1 млрд руб, мы не видели "достаточно полную модель данных предметной области". Это просто неэффективно, так как системы-источники внедрены были в разное время под автоматизацию отдельных функций. И создаваемое (построянно развиающееся) DWH с гибкой моделью данных (мы делаем по методологии Data Vault), и является источником для BI. Естественно, с созданием отдельных витрин под блоки аналитических задач. И даже "только построить мостик перегона необходимых данных" - хорошая задача для фреймворка, с учетом необходимости "перегонять" данные, минимально нагружая систему-источник, с обеспечением историзации и контроля качества.

[@vladig6649]

@@biqube-itpro На предприятии, как правило, работает несколько автоматизированных систем (подсистем) выполняющих свои конкретные задачи и у каждой из них физически СВОЯ специализированная для этих задач база данных. Если у какой-то системы (подсистемы) возникает потребность в использовании данных из другой системы (например, бухгалтерии нужны данные по кадрам), то она через API системы КАДРЫ запрашивает необходимые ей данные хранящиеся в БД кадров. Поэтому потребности иметь какую-то одну общую модель данных с одной физической базой данных просто не существует. Должно быть налажено информационное взаимодействие между работающими системами через их API к базам данных. Если у системы нет такого API к своим данным, то такая система замкнута в себе (закрытая) и значит плохо спроектирована. Необходимые конкретные для аналитики данные из разных систем собираются через их API в базу данных аналитический системы и там обрабатываются. Вот под этот сбор данных из разных систем и требуется писать свой код в условиях конкретного предприятия. От этого никуда не деться, так у всех все по разному.