Перенесите устаревшие данные, не испортив их

Миграция устаревших данных затруднена.

Многие организации имеют старые и сложные локальные бизнес-системы CRM. Сегодня существует множество альтернатив облачным SaaS, которые имеют множество преимуществ; платить по мере использования и платить только за то, что вы используете. Поэтому они решают перейти на новые системы.

Никто не хочет оставлять ценные данные о клиентах в старой системе и начинать с пустой новой системы, поэтому нам необходимо перенести эти данные. К сожалению, миграция данных — непростая задача, так как около 50 % усилий по развертыванию приходится на действия по миграции данных. По данным Gartner, Salesforce является лидером облачных CRM-решений. Таким образом, миграция данных является основной темой для развертывания Salesforce.

Итак, как мы можем обеспечить успешный перенос устаревших данных в новую блестящую систему и сохранить всю ее историю? В этой статье я даю 10 советов по успешной миграции данных. Первые пять советов применимы к любой миграции данных, независимо от используемой технологии.

Миграция данных в целом

1. Сделайте миграцию отдельным проектом

В контрольном списке развертывания программного обеспечения миграция данных не является элементом «экспорта и импорта», который обрабатывается умным инструментом миграции данных «одной кнопкой», который имеет предопределенное сопоставление для целевых систем.

Миграция данных — сложная деятельность, заслуживающая отдельного проекта, плана, подхода, бюджета и команды. Масштаб и план на уровне объекта должны быть созданы в начале проекта, чтобы не было сюрпризов, таких как «О, мы забыли загрузить отчеты о посещениях этих клиентов, кто это сделает?» за две недели до срока.

Подход к переносу данных определяет, будем ли мы загружать данные за один раз (также известный как « большой взрыв ») или будем загружать небольшие пакеты каждую неделю.

Однако это не простое решение. Подход должен быть согласован и доведен до сведения всех деловых и технических заинтересованных сторон, чтобы все знали, когда и какие данные появятся в новой системе. Это относится и к системным сбоям.

2. Оценивайте реалистично

Не стоит недооценивать сложность переноса данных. Этот процесс сопровождается множеством трудоемких задач, которые могут быть незаметны в начале проекта.

Например, загрузка определенных наборов данных для целей обучения с набором реалистичных данных, но с запутанными конфиденциальными элементами, чтобы действия по обучению не генерировали уведомления по электронной почте для клиентов.

Основным фактором для оценки является количество полей, которые необходимо передать из исходной системы в целевую систему.

Некоторое количество времени требуется на разных этапах проекта для каждого поля, включая понимание поля, сопоставление исходного поля с целевым полем, настройку или построение преобразований, выполнение тестов, измерение качества данных для поля и т. д.

Использование умных инструментов, таких как Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas и им подобных, может сократить это время, особенно на этапе сборки.

В частности, понимание исходных данных — самая важная задача в любом проекте миграции — не может быть автоматизировано с помощью инструментов, но требует от аналитиков времени на просмотр списка полей одно за другим.

Простейшая оценка общих усилий — один человеко-день на каждое поле, перенесенное из устаревшей системы.

Исключением является репликация данных между одними и теми же исходной и целевой схемами без дальнейшего преобразования (иногда называемая миграцией 1:1), когда мы можем основывать оценку на количестве копируемых таблиц.

Детальная смета – это отдельное искусство.

3. Проверьте качество данных

Не переоценивайте качество исходных данных, даже если в устаревших системах не сообщается о проблемах с качеством данных.

Новые системы имеют новые правила, которые могут быть нарушены с помощью устаревших данных. Вот простой пример. Контактный адрес электронной почты может быть обязательным в новой системе, но у устаревшей системы 20-летней давности может быть другая точка зрения.

В исторических данных могут быть спрятаны мины, которые давно не трогались, но могли сработать при переходе на новую систему. Например, старые данные с использованием европейских валют, которых больше не существует, необходимо конвертировать в евро, в противном случае необходимо добавить валюты в новую систему.

Качество данных существенно влияет на усилия, и действует простое правило: чем дальше мы углубимся в историю, тем больший беспорядок мы обнаружим. Таким образом, очень важно заранее решить, какую часть истории мы хотим перенести в новую систему.

4. Привлекайте деловых людей

Деловые люди — единственные, кто действительно понимает данные и поэтому может решить, какие данные можно выбросить, а какие оставить.

Важно, чтобы кто-то из бизнес-группы участвовал во время картографирования, а для дальнейшего отслеживания полезно записывать решения по картированию и их причины.

Поскольку картинка стоит больше, чем тысяча слов, загрузите тестовую партию в новую систему и дайте бизнес-команде поиграть с ней.

Даже если сопоставление миграции данных проверено и одобрено бизнес-группой, могут возникнуть сюрпризы, как только данные появятся в пользовательском интерфейсе новой системы.

«О, теперь я вижу, мы должны это немного изменить», — становится расхожей фразой.

Неспособность привлечь экспертов в предметной области, которые обычно очень заняты, является наиболее распространенной причиной проблем после запуска новой системы.

5. Стремитесь к решению для автоматизированной миграции

Миграция данных часто рассматривается как одноразовое действие, и разработчики, как правило, получают решения, полные ручных действий, в надежде выполнить их только один раз. Но есть много причин избегать такого подхода.

• Если миграция разбита на несколько волн, нам придется повторять одни и те же действия несколько раз.
• Как правило, для каждой волны выполняется не менее трех прогонов миграции: пробный прогон для проверки производительности и функциональности переноса данных, полная загрузка проверки данных для проверки всего набора данных и выполнения бизнес-тестов и, конечно же, рабочая загрузка. Количество прогонов увеличивается при плохом качестве данных. Улучшение качества данных — это итеративный процесс, поэтому нам нужно несколько итераций, чтобы достичь желаемого коэффициента успеха.

Таким образом, даже если миграция является разовой операцией по своей природе, ручные действия могут значительно замедлить ваши операции.

Миграция данных Salesforce

Далее мы рассмотрим пять советов по успешной миграции Salesforce. Имейте в виду, что эти советы, вероятно, применимы и к другим облачным решениям.

6. Подготовьтесь к длительным нагрузкам

Производительность является одним из, если не самым большим, компромиссом при переходе от локального к облачному решению, не исключая Salesforce.

Локальные системы обычно допускают прямую загрузку данных в базовую базу данных, а при наличии хорошего оборудования мы можем легко обрабатывать миллионы записей в час.

Но не в облаке. В облаке мы сильно ограничены несколькими факторами.

• Сетевая задержка — данные передаются через Интернет.
• Уровень приложений Salesforce. Данные перемещаются через толстый слой мультиарендности API, пока не попадут в свои базы данных Oracle.
• Пользовательский код в Salesforce — настраиваемые проверки, триггеры, рабочие процессы, правила обнаружения дублирования и т. д. — многие из которых отключают параллельную или массовую загрузку.

В результате производительность нагрузки может составлять тысячи аккаунтов в час.

Это может быть меньше или больше, в зависимости от таких вещей, как количество полей, проверок и триггеров. Но это на несколько разрядов медленнее, чем прямая загрузка базы данных.

Также необходимо учитывать ухудшение производительности, которое зависит от объема данных в Salesforce.

Это вызвано индексами в базовой СУБД (Oracle), используемыми для проверки внешних ключей, уникальных полей и оценки правил дублирования. Базовая формула — примерно 50-процентное замедление для каждого класса из 10, вызванное O(logN) частью временной сложности в операциях сортировки и B-дерева.

Более того, Salesforce имеет множество ограничений на использование ресурсов.

Одним из них является ограничение Bulk API, установленное на 5000 пакетов в 24-часовых скользящих окнах с максимальным количеством записей 10000 в каждом пакете.

Итак, теоретический максимум — 50 миллионов записей, загруженных за 24 часа.

В реальном проекте максимум намного ниже из-за ограниченного размера пакета при использовании, например, пользовательских триггеров.

Это оказывает сильное влияние на подход к переносу данных.

Даже для наборов данных среднего размера (от 100 000 до 1 миллиона учетных записей) о подходе «большого взрыва» не может быть и речи, поэтому мы должны разделить данные на более мелкие волны миграции.

Это, конечно, влияет на весь процесс развертывания и увеличивает сложность миграции, поскольку мы будем добавлять инкременты данных в систему, уже заполненную предыдущими миграциями и данными, введенными пользователями.

Мы также должны учитывать эти существующие данные при преобразованиях и проверках миграции.

Кроме того, длительные загрузки могут означать, что мы не можем выполнять миграцию во время сбоя системы.

Если все пользователи находятся в одной стране, мы можем использовать восьмичасовое отключение в ночное время.

Но для такой компании, как Coca-Cola, работающей по всему миру, это невозможно. Как только в системе появятся США, Япония и Европа, мы охватим все часовые пояса, поэтому суббота — единственный вариант отключения, который не влияет на пользователей.

И этого может быть недостаточно, поэтому мы должны загружаться в режиме онлайн , когда пользователи работают с системой.

7. Уважайте потребности миграции при разработке приложений

Компоненты приложения, такие как проверки и триггеры, должны иметь возможность обрабатывать действия по переносу данных. Жесткое отключение проверки во время загрузки миграции не вариант, если система должна быть в сети. Вместо этого мы должны реализовать другую логику проверки изменений, выполненных пользователем переноса данных.

• Поля даты не следует сравнивать с фактической системной датой, потому что это отключит загрузку исторических данных. Например, проверка должна позволять вводить прошлую дату начала действия учетной записи для переносимых данных.
• Обязательные поля, которые не могут быть заполнены историческими данными, должны быть реализованы как необязательные, но с проверкой, зависящей от пользователя, таким образом позволяя пустые значения для данных, поступающих от миграции, но отклоняя пустые значения, поступающие от обычных пользователей через графический интерфейс. .
• Триггеры, особенно отправляющие новые записи в интеграцию, должны иметь возможность включаться и выключаться для пользователя переноса данных, чтобы предотвратить переполнение интеграции перенесенными данными.

Еще одна хитрость заключается в использовании поля Legacy ID или Migration ID в каждом переносимом объекте. Этому есть две причины. Первый очевиден: сохранить идентификатор из старой системы для возврата; после того, как данные находятся в новой системе, люди могут по-прежнему искать свои учетные записи, используя старые идентификаторы, найденные в таких местах, как электронные письма, документы и системы отслеживания ошибок. Плохая привычка? Может быть. Но пользователи будут вам благодарны, если вы сохраните их старые идентификаторы. Вторая причина носит технический характер и связана с тем, что Salesforce не принимает явно заданные идентификаторы для новых записей (в отличие от Microsoft Dynamics), а генерирует их во время загрузки. Проблема возникает, когда мы хотим загрузить дочерние объекты, потому что мы должны присвоить им идентификаторы родительских объектов. Поскольку мы узнаем эти идентификаторы только после загрузки, это бесполезное занятие.

Давайте использовать учетные записи и их контакты, например:

1. Генерация данных для учетных записей.
2. Загрузите учетные записи в Salesforce и получите сгенерированные идентификаторы.
3. Включите новые идентификаторы учетной записи в контактные данные.
4. Создание данных для контактов.
5. Загрузите контакты в Salesforce.

Мы можем сделать это проще, загрузив учетные записи с их устаревшими идентификаторами, хранящимися в специальном внешнем поле. Это поле можно использовать в качестве родительской ссылки, поэтому при загрузке контактов мы просто используем устаревший идентификатор учетной записи в качестве указателя на родительскую учетную запись:

1. Создание данных для учетных записей, включая Legacy ID.
2. Создание данных для контактов, включая устаревший идентификатор учетной записи.
3. Загрузите учетные записи в Salesforce.
4. Загрузите контакты в Salesforce, используя идентификатор прежней учетной записи в качестве родительской ссылки.

Здесь хорошо то, что мы разделили генерацию и фазу загрузки, что позволяет улучшить параллелизм, сократить время простоя и так далее.

8. Помните об особенностях Salesforce

Как и в любой системе, в Salesforce есть множество сложных моментов, о которых следует знать, чтобы избежать неприятных сюрпризов при переносе данных. Вот несколько примеров:

• Некоторые изменения активных пользователей автоматически генерируют уведомления по электронной почте на электронные адреса пользователей. Таким образом, если мы хотим поиграть с пользовательскими данными, нам нужно сначала деактивировать пользователей и активировать после завершения изменений. В тестовых средах мы шифруем электронные письма пользователей, чтобы уведомления вообще не запускались. Поскольку активные пользователи потребляют дорогостоящие лицензии, мы не можем обеспечить активность всех пользователей во всех тестовых средах. Мы должны управлять подмножествами активных пользователей, например, чтобы активировать только тех, кто находится в среде обучения.
• Неактивных пользователей для некоторых стандартных объектов, таких как Контрагент или Дело, можно назначать только после предоставления системного разрешения «Обновлять записи с неактивными владельцами», но их можно назначать, например, Контактам и всем пользовательским объектам.
• Когда контакт деактивирован, все поля отказа автоматически активируются.
• При загрузке дубликата объекта Account Team Member или Account Share существующая запись автоматически перезаписывается. Однако при загрузке дубликата возможного партнера запись просто добавляется, что приводит к дублированию.
• Системные поля, такие как « Created Date создания», «Идентификатор создания», « Last Modified Date », «Последнее изменение Created By ID Last Modified By ID », могут быть явно записаны только после предоставления нового системного разрешения «Установить поля аудита при создании записи».
• Изменения значений истории полей вообще не могут быть перенесены.
• Владельцев статей базы знаний нельзя указать во время загрузки, но их можно обновить позже.
• Сложность заключается в хранении контента (документов, вложений) в Salesforce. Есть несколько способов сделать это (используя вложения, файлы, вложения ленты, документы), и у каждого способа есть свои плюсы и минусы, включая различные ограничения на размер файла.
• Поля раскрывающегося списка заставляют пользователей выбирать одно из допустимых значений, например, тип учетной записи. Но при загрузке данных с помощью Salesforce API (или любого инструмента, созданного на его основе, например Apex Data Loader или Informatica Salesforce Connector) будет передано любое значение.

Список можно продолжать, но суть такова: ознакомьтесь с системой и узнайте, что она может и чего не может сделать, прежде чем делать предположения. Не предполагайте стандартное поведение, особенно для основных объектов. Всегда исследуйте и тестируйте.

9. Не используйте Salesforce в качестве платформы для переноса данных

Очень заманчиво использовать Salesforce в качестве платформы для создания решения для переноса данных, особенно для разработчиков Salesforce. Это та же технология для переноса данных, что и для настройки приложения Salesforce, тот же графический интерфейс, тот же язык программирования Apex, та же инфраструктура. В Salesforce есть объекты, которые могут действовать как таблицы, и своего рода язык SQL, язык запросов к объектам Salesforce (SOQL). Однако, пожалуйста, не используйте его; это было бы фундаментальным архитектурным недостатком.

Salesforce — отличное приложение SaaS с множеством приятных функций, таких как расширенная совместная работа и широкие возможности настройки, но массовая обработка данных не входит в их число. Три наиболее существенные причины:

• Производительность . Обработка данных в Salesforce на несколько уровней медленнее, чем в СУБД.
• Отсутствие аналитических функций — Salesforce SOQL не поддерживает сложные запросы и аналитические функции, которые должны поддерживаться языком Apex, что еще больше снижает производительность.
• Архитектура * — размещение платформы переноса данных в конкретной среде Salesforce не очень удобно. Обычно у нас есть несколько сред для определенных целей, часто создаваемых специально, чтобы мы могли уделять много времени синхронизации кода. Кроме того, вы также будете полагаться на подключение и доступность этой конкретной среды Salesforce.

Вместо этого создайте решение для переноса данных в отдельном экземпляре (это может быть облако или локальная среда) с использованием платформы RDBMS или ETL. Подключите его к исходным системам и настройте нужные среды Salesforce, переместите необходимые данные в свою промежуточную область и обработайте их там. Это позволит вам:

• Используйте всю мощь и возможности языка SQL или функций ETL.
• Храните весь код и данные в одном месте, чтобы можно было выполнять анализ во всех системах.
  • Например, вы можете комбинировать новейшую конфигурацию самой последней тестовой среды Salesforce с реальными данными из производственной среды Salesforce.
• Вы не так сильно зависите от технологии исходной и целевой систем и можете повторно использовать свое решение для следующего проекта.

10. Контроль метаданных Salesforce

В начале проекта мы обычно берем список полей Salesforce и начинаем сопоставление. Во время проекта часто бывает так, что команда разработчиков приложений добавляет новые поля в Salesforce или изменяет некоторые свойства полей. Мы можем попросить группу приложения уведомлять группу переноса данных о каждом изменении модели данных, но это не всегда работает. Чтобы быть в безопасности, мы должны контролировать все изменения модели данных.

Обычный способ сделать это — регулярно загружать метаданные, относящиеся к миграции, из Salesforce в какой-либо репозиторий метаданных. Получив это, мы сможем не только обнаруживать изменения в модели данных, но и сравнивать модели данных двух сред Salesforce.

Какие метаданные скачивать:

• Список объектов с их метками, техническими именами и атрибутами, такими как creatable или updatable .
• Список полей с их атрибутами (лучше получить их все).
• Список значений списка выбора для полей списка выбора. Они понадобятся нам для сопоставления или проверки правильности входных данных.
• Список проверок, чтобы убедиться, что новые проверки не создают проблем для перенесенных данных.

Как загрузить метаданные из Salesforce? Ну, стандартного метода метаданных нет, но есть несколько вариантов:

• Создать корпоративный WSDL — в веб-приложении Salesforce перейдите в меню « Setup / API » и загрузите строго типизированный корпоративный WSDL, который описывает все объекты и поля в Salesforce (но не значения раскрывающегося списка и проверки).
• describeSObjects веб-службу Salesforce descriptionSObjects напрямую или с помощью оболочки Java или C# (обратитесь к Salesforce API). Таким образом, вы получите то, что вам нужно, и это рекомендуемый способ экспорта метаданных.
• Используйте любой из многочисленных альтернативных инструментов, доступных в Интернете.

Подготовьтесь к следующему переносу данных

Облачные решения, такие как Salesforce, готовы мгновенно. Если вас устраивают встроенные функции, просто войдите в систему и используйте их. Однако Salesforce, как и любое другое облачное CRM-решение, создает определенные проблемы в темах миграции данных, о которых следует знать, в частности, в отношении ограничений производительности и ресурсов.

Перемещение устаревших данных в новую систему — это всегда путешествие, иногда путешествие в историю, скрытую в данных прошлых лет. В этой статье, основанной на дюжине проектов миграции, я представил десять советов о том, как перенести устаревшие данные и успешно избежать большинства ловушек.

Главное — понять, что показывают данные. Поэтому, прежде чем начать миграцию данных, убедитесь, что ваша команда разработчиков Salesforce хорошо подготовлена ​​к потенциальным проблемам, которые могут возникнуть с вашими данными.