Мигрирането на стари данни е трудно.

Много организации имат стари и сложни локални бизнес CRM системи. Днес има много алтернативи на SaaS в облака, които идват с много предимства; плащайте докато отивате и да плащате само за това, което използвате. Затова те решават да преминат към новите системи.

Никой не иска да оставя ценни данни за клиентите в старата система и да започне с празната нова система, затова трябва да мигрираме тези данни. За съжаление миграцията на данни не е лесна задача, тъй като около 50% от усилията за разгръщане се консумира от дейности за мигриране на данни. Според Гартнер , Salesforce е лидер на CRM решенията в облак. Следователно миграцията на данни е основна тема за внедряването на Salesforce.

Как да осигурим успешен преход на стари данни в нова система
като същевременно запазва цялата история. Tweet

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

Миграция на данни като цяло

1. Направете миграцията отделен проект

В контролния списък за внедряване на софтуер миграцията на данни не е елемент за „експортиране и импортиране“, обработван от умен инструмент за мигриране на данни с „натискане на един бутон“, който има предварително дефинирано картографиране за целевите системи.

Миграцията на данни е сложна дейност, заслужаваща отделен проект, план, подход, бюджет и екип. Обхватът и планът на ниво обект трябва да бъдат създадени в началото на проекта, като се гарантира, че няма изненади, като например „О, забравихме да заредим отчетите за посещенията на тези клиенти, кой ще направи това?“ две седмици преди крайния срок.

Подходът за мигриране на данни определя дали ще заредим данните наведнъж (известен също като голям взрив ), или дали ще зареждаме малки партиди всяка седмица.

Това обаче не е лесно решение. Подходът трябва да бъде съгласуван и съобщен на всички заинтересовани страни от бизнеса и техническите среди, така че всички да са наясно кога и какви данни ще се появят в новата система. Това се отнася и за прекъсвания на системата.

2. Оценете реално

Не подценявайте сложността на миграцията на данни. Много отнемащи време задачи придружават този процес, който може да бъде невидим в началото на проекта.

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

Основният фактор за оценка е броят на полетата, които трябва да бъдат прехвърлени от изходна система към целева система.

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

Най-добри практики за визуализация на данни 2015 г

Използването на интелигентни инструменти като Jitterbit, Informatica Wizard Cloud Data, Starfish ETL, Midas и други подобни може да намали това време, особено във фазата на изграждане.

По-специално, разбирането на изходните данни - най-важната задача във всеки миграционен проект - не може да се автоматизира с инструменти, но изисква анализаторите да отделят време, като преглеждат списъка с полета едно по едно.

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

Изключение прави репликацията на данни между една и съща схема на източник и цел без по-нататъшна трансформация - понякога известна като миграция 1: 1 - където можем да основаваме оценката на броя таблици за копиране.

Подробна оценка е собствено изкуство.

3. Проверете качеството на данните

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

Новите системи имат нови правила, които могат да бъдат нарушени със старите данни. Ето един прост пример. Имейл адресът за връзка може да бъде задължителен в новата система, но 20-годишната наследствена система може да има различна гледна точка.

Може да има мини, скрити в исторически данни, които не са били докосвани дълго време, но биха могли да се активират при прехвърляне към новата система. Например старите данни, използващи европейски валути, които вече не съществуват, трябва да бъдат конвертирани в евро, в противен случай валутите трябва да бъдат добавени към новата система.

Качеството на данните значително влияе на усилията и простото правило е: Колкото по-напредваме в историята, толкова по-голяма бъркотия ще открием. Поради това е жизненоважно да се реши по-рано как много история, която искаме да прехвърлим в новата система.

4. Ангажирайте бизнесмени

Бизнесмените са единствените, които наистина разбират данните и следователно могат да решат какви данни могат да бъдат изхвърлени и какви данни да се пазят.

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

Тъй като снимката струва повече от хиляда думи, заредете тестова партида в новата система и оставете бизнес екипа да играе с нея.

Дори ако картографирането на миграцията на данни бъде прегледано и одобрено от бизнес екипа, изненади могат да се появят, след като данните се покажат в потребителския интерфейс на новата система.

„О, сега разбирам, трябва да го променим малко“, става често срещана фраза.

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

5. Стремете се към решение за автоматизирана миграция

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

• Ако миграцията е разделена на множество вълни, трябва да повторим едни и същи действия няколко пъти.
• Обикновено има най-малко три миграции за всяка вълна: сухо изпълнение за тестване на производителността и функционалността на миграцията на данни, пълен товар за проверка на данните за тестване на целия набор от данни и за извършване на бизнес тестове и, разбира се, производствено натоварване. Броят на изпълненията се увеличава с лошо качество на данните. Подобряването на качеството на данните е итеративен процес, така че се нуждаем от няколко повторения, за да постигнем желаното съотношение на успеха.

По този начин, дори ако миграцията е еднократна дейност по природа, ръчните действия могат значително да забавят операциите ви.

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

След това ще разгледаме пет съвета за успешна миграция на Salesforce. Имайте предвид, че тези съвети вероятно са приложими и за други облачни решения.

как да проектираме уебсайт за електронна търговия

6. Подгответе се за дълги товари

Ефективността е един от, ако не и най-големият, компромис при преминаване от локално към облачно решение - Salesforce не е изключено.

Локалните системи обикновено позволяват директно зареждане на данни в основна база данни и с добър хардуер можем лесно да достигнем милиони записи на час.

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

• Латентност на мрежата - Данните се прехвърлят през интернет.
• Приложен слой на Salesforce - данните се преместват през дебелина Многослойност на API докато кацнат в своите бази данни на Oracle.
• Персонализиран код в Salesforce - Персонализирани проверки, задействания, работни потоци, правила за откриване на дублиране и т.н. - много от които деактивират паралелни или групови товари.

В резултат на това производителността на зареждане може да бъде хиляди акаунти на час.

Тя може да бъде по-малка или може да бъде повече, в зависимост от нещата, като например броя на полетата, проверки и задействания. Но това е с няколко степени по-бавно от директното зареждане на базата данни.

Влошаване на производителността, което зависи от обема на данните в Salesforce, също трябва да се има предвид.

Причинява се от индекси в основната RDBMS (Oracle), използвани за проверка на външни ключове, уникални полета и оценка на правилата за дублиране. Основната формула е приблизително 50 процента забавяне за всеки клас от 10, причинено от O (logN) частта от сложността във времето при операции на сортиране и B-дърво.

Освен това Salesforce има много ограничения за използване на ресурсите.

Един от тях е Настроено ограничение за групови API до 5000 партиди в 24-часови подвижни прозорци, с максимум 10 000 записа във всяка партида.

И така, теоретичният максимум е 50 милиона записа, заредени за 24 часа.

В реален проект максимумът е много по-нисък поради ограничен размер на партидата, когато се използват например персонализирани задействания.

Това има силно въздействие върху подхода за мигриране на данни.

Дори за средно големи масиви от данни (от 100 000 до 1 милион акаунта) подходът за Големия взрив не може да става и затова трябва да разделяме данните на по-малки миграционни вълни.

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

Ние също трябва да вземем предвид тези съществуващи данни при миграционните трансформации и проверки.

Освен това, дългите товари могат да означават, че не можем да извършваме миграции по време на прекъсване на системата.

Ако всички потребители се намират в една държава, можем да използваме осемчасово прекъсване през нощта.

Но за компания като Coca-Cola, работеща по целия свят, това не е възможно. След като имаме САЩ, Япония и Европа в системата, ние обхващаме всички часови зони, така че събота е единствената опция за спиране, която не засяга потребителите.

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

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

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

• Полетата за дата не трябва да се сравняват с действителната системна дата, защото това би забранило зареждането на исторически данни. Например валидирането трябва да позволява въвеждане на минала начална дата на акаунта за мигрирали данни.
• Задължителните полета, които не могат да бъдат попълнени с исторически данни, трябва да бъдат внедрени като незадължителни, но с валидиране, чувствително към потребителя, като по този начин позволяват празни стойности за данни, идващи от миграцията, но отхвърлящи празни стойности, идващи от редовни потребители чрез GUI .
• Задействанията, особено тези, изпращащи нови записи към интеграцията, трябва да могат да бъдат включени / изключени за потребителя на миграция на данни, за да се предотврати заливането на интеграцията с мигрирани данни.

Друг трик е използването на полето 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 разполага с много сложни части, за които трябва да сме наясно, за да избегнем неприятни изненади по време на миграция на данни. Ето няколко примера:

• Някои промени в активните потребители автоматично генерират известия по имейл на имейли на потребители. По този начин, ако искаме да играем с потребителски данни, трябва първо да деактивираме потребителите и да активираме след приключване на промените. В тестови среди ние бъркаме потребителски имейли, така че известията изобщо да не се задействат. Тъй като активните потребители консумират скъпи лицензи, не можем да имаме всички потребители активни във всички тестови среди. Трябва да управляваме подмножества от активни потребители, например, за да активираме само тези в среда за обучение.
• Неактивните потребители за някои стандартни обекти като Акаунт или Дело могат да бъдат назначени само след предоставяне на системното разрешение „Актуализиране на записите с неактивни собственици“, но те могат да бъдат назначени, например, към Контакти и всички персонализирани обекти.
• Когато контактът е деактивиран, всички полета за отказ се включват безшумно.
• При зареждане на дублиран член на екип на акаунт или обект за споделяне на акаунт, съществуващият запис се презаписва тихо. При зареждане на дубликат на Opportunity Partner, записът просто се добавя, което води до дубликат.
• Системните полета, като Created Date, Created By ID, Last Modified Date, Last Modified By ID, могат да бъдат изрично написани само след предоставяне на ново системно разрешение „Задаване на одитни полета при създаване на запис“.
• Промените в стойността на историята на полето изобщо не могат да бъдат мигрирани.
• Собствениците на статии от знания не могат да бъдат посочени по време на зареждането, но могат да бъдат актуализирани по-късно.
• Трудната част е съхраняването на съдържание (документи, прикачени файлове) в Salesforce. Има няколко начина да го направите (като използвате прикачени файлове, файлове, прикачени файлове към емисии, документи) и всеки начин има своите плюсове и минуси, включително различни ограничения за размера на файла.
• Полетата Picklist принуждават потребителите да избират една от разрешените стойности, например тип акаунт. Но при зареждане на данни с помощта на API на Salesforce (или който и да е инструмент, изграден върху него, като Apex Data Loader или Конектор на Informatica Salesforce ), всякакви стойност ще премине.

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

9. Не използвайте Salesforce като платформа за мигриране на данни

Много е изкушаващо да се използва Salesforce като платформа за изграждане на решение за мигриране на данни, особено за разработчиците на Salesforce. Това е същата технология за решение за мигриране на данни, както за персонализиране на приложението Salesforce, същият GUI, същият Език за програмиране Apex , същата инфраструктура. Salesforce има обекти, които могат да действат като таблици, и един вид SQL език, Език на заявките за обекти на Salesforce (SOQL) . Моля, не го използвайте; това би било основен архитектурен недостатък.

добив на маслена палма на хектар

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

• производителност - Обработката на данни в Salesforce е с няколко степени по-бавна, отколкото в RDBMS.
• Липса на аналитични характеристики - Salesforce SOQL не поддържа сложни заявки и аналитични функции, които трябва да се поддържат от езика Apex и биха влошили още повече производителността.
• Архитектура * - Поставянето на платформа за мигриране на данни в определена среда на Salesforce не е много удобно. Обикновено имаме множество среди за конкретни цели, често създадени ad hoc, за да можем да отделим много време за синхронизация на кода. Освен това бихте разчитали и на свързаност и наличност на тази специфична среда на Salesforce.

Вместо това, изградете решение за мигриране на данни в отделен екземпляр (може да е облак или локално), използвайки RDBMS или ETL платформа. Свържете го със системите източници и насочете към средата на Salesforce, която искате, преместете данните, които са ви необходими, във вашата подреждане и ги обработете там. Това ще ви позволи да:

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

10. Контрол на метаданните на Salesforce

В началото на проекта обикновено вземаме списък с полета на Salesforce и започваме упражнението за картографиране. По време на проекта често се случва нови полета да се добавят от екипа за разработка на приложения в Salesforce или да се променят някои свойства на полетата. Можем да помолим екипа на приложението да уведоми екипа за мигриране на данни за всяка промяна на модела на данни, но не винаги работи. За да бъдем в безопасност, трябва да контролираме всички промени в модела на данни.

Често срещаният начин да направите това е да изтегляте редовно метаданни, свързани с миграцията, от Salesforce в някакво хранилище на метаданни. След като получим това, можем не само да открием промени в модела на данни, но също така можем да сравним модели на данни на две среди на Salesforce.

Какви метаданни да изтеглите:

• Списък на обекти с техните етикети и технически имена и атрибути като creatable или updatable.
• Списък със полета с техните атрибути (по-добре да ги вземете всички).
• Списък на стойностите на списъка за избор на полета. Ще ни трябват за картографиране или валидиране на входни данни за правилни стойности.
• Списък на проверките, за да се уверите, че новите проверки не създават проблеми за мигрираните данни.

Как да изтеглите метаданни от Salesforce? Е, няма стандартен метод за метаданни, но има множество опции:

• Генерирайте Enterprise WSDL - В уеб приложението Salesforce отидете до Setup / API меню и изтеглете силно въведени Enterprise WSDL, които описват всички обекти и полета в Salesforce (но не стойности на списъка и валидации).
• Обадете се на Salesforce describeSObjects уеб услуга, директно или чрез Java или C # обвивка (консултирайте се с API на Salesforce ). По този начин получавате това, от което се нуждаете, и това е препоръчителният начин за експортиране на метаданните.
• Използвайте някой от многобройните алтернативни инструменти, налични в интернет.

Подгответе се за следващата миграция на данни

Облачните решения, като Salesforce, са готови моментално. Ако сте доволни от вградените функционалности, просто влезте и го използвайте. Въпреки това, Salesforce, както всяко друго CRM решение в облака, създава специфични проблеми в темите за мигриране на данни, за да бъдат наясно, по-специално по отношение на производителността и ограниченията на ресурсите.

Преместването на старите данни в новата система винаги е пътуване, понякога пътуване до историята, скрито в данни от минали години. В тази статия, базирана на дузина миграционни проекти, съм представил десет съвета как да мигрирате наследени данни и успешно да избегнете най-много клопки.

Ключът е да се разбере какво разкриват данните. Така че, преди да започнете миграцията на данни, уверете се, че вашата Екип за разработка на Salesforce е добре подготвен за потенциалните проблеми, които могат да съдържат вашите данни.

Свързани: Урок за HDFS за анализатори на данни, заседнал с релационни бази данни