Pärandandmete migreerimine on keeruline.

Paljudel organisatsioonidel on vanad ja keerukad kohapealsed äritegevuse CRM-süsteemid. Täna on pilves SaaS alternatiive, millel on palju eeliseid; maksma minnes ja maksma ainult selle eest, mida kasutate. Seetõttu otsustavad nad liikuda uutesse süsteemidesse.

Keegi ei taha jätta klientide kohta vanasse süsteemi väärtuslikke andmeid ja alustada tühja uue süsteemiga, seega peame need andmed üle viima. Kahjuks pole andmete migratsioon lihtne ülesanne, nagu ka umbes 50 protsenti kasutuselevõtu pingutustest kulub andmete migreerimisel. Vastavalt Gartner , Salesforce on pilv CRM-lahenduste liider. Seetõttu on andmete üleviimine Salesforce'i juurutamise peamine teema.

Kuidas tagada pärandandmete edukas üleminek uude süsteemi
säilitades kogu ajaloo. Piiksuma

Niisiis, kuidas saaksime tagada pärandandmete eduka ülemineku läikivasse uude süsteemi ja selle, et säilitame kogu selle ajaloo? Selles artiklis esitan 10 nõuannet andmete edukaks migreerimiseks. Esimesed viis näpunäidet kehtivad mis tahes andmete migreerimisel, olenemata kasutatavast tehnoloogiast.

mis põhjustas Kreeka majanduskriisi

Andmete ränne üldiselt

1. Tehke migratsioonist eraldi projekt

Tarkvara juurutamise kontroll-loendis pole andmete migreerimine üksus „eksport ja import”, mida haldab nutikas andmeedastuse tööriist, millel on eelnevalt määratletud sihtmärkide süsteemide kaardistamine.

Andmete ränne on keeruline tegevus, mis väärib eraldi projekti, plaani, lähenemist, eelarvet ja meeskonda. Projekti alguses tuleb luua üksuse tasemega ulatus ja plaan, mis ei taga üllatusi, näiteks 'Oh, me unustasime nende klientide külastuste aruandeid laadida, kes seda teeb?' kaks nädalat enne tähtaega.

Andmete migreerimise lähenemisviis määratleb, kas laadime andmed ühe korraga (tuntud ka kui suur pauk ) või kas laadime väikseid partiisid iga nädal.

See pole siiski lihtne otsus. Lähenemisviisis tuleb kokku leppida ja sellest tuleb teavitada kõiki äri- ja tehnilisi sidusrühmi, et kõik teaksid, millal ja millised andmed uues süsteemis ilmuvad. See kehtib ka süsteemikatkestuste kohta.

2. Hinnake realistlikult

Ärge alahinnake andmete migratsiooni keerukust. Selle protsessiga kaasnevad paljud aeganõudvad ülesanded, mis võivad projekti alguses olla nähtamatud.

Näiteks konkreetsete andmekogumite laadimine koolituse eesmärgil koos hulga realistlike andmetega, kuid tundlike üksustega, mis on hägustatud, nii et koolitustegevused ei tekita klientidele e-posti teel teateid.

Hinnangu andmise põhitegur on allikasüsteemist sihtsüsteemi ülekantavate väljade arv.

Projekti erinevates etappides on iga välja jaoks vaja mõnda aega, sealhulgas välja mõistmine, allikavälja kaardistamine sihtväljale, teisenduste konfigureerimine või ehitamine, testide läbiviimine, välja andmete kvaliteedi mõõtmine jne.

Nutikate tööriistade, näiteks Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas jms kasutamine võib seda aega vähendada, eriti ehitamise etapis.

Eelkõige ei saa tööriistad lähteandmete mõistmist - mis tahes rändeprojekti kõige olulisemat ülesannet - automatiseerida, vaid see nõuab analüütikutelt aega, et ükshaaval väljade loend läbi vaadata.

Lihtsaim hinnang üldise pingutuse kohta on üks inimpäev iga pärandsüsteemist üle kantud valdkonna kohta.

Erandiks on andmete replikatsioon sama lähte- ja sihtskeemi vahel ilma täiendava teisendamiseta - mida mõnikord nimetatakse ka 1: 1 migratsiooniks - kus saame hinnangu aluseks võtta kopeeritavate tabelite arvu.

Üksikasjalik hinnang on omaette kunst.

3. Kontrollige andmete kvaliteeti

Ärge ülehindage lähteandmete kvaliteeti, isegi kui pärandsüsteemidest pole andmetega seotud probleeme.

Uutel süsteemidel on uued reeglid, mida pärandandmetega võidakse rikkuda. Siin on lihtne näide. Kontakti e-post võib olla uues süsteemis kohustuslik, kuid 20-aastasel pärandsüsteemil võib olla erinev vaatenurk.

Ajaloolistes andmetes võivad olla peidetud miinid, mida pole pikka aega puudutatud, kuid mis võivad uude süsteemi üleminekul aktiveeruda. Näiteks tuleb vanad andmed, mis kasutavad Euroopa valuutasid, mida enam pole, eurodesse ümber arvutada, vastasel juhul tuleb uude süsteemi lisada valuutad.

programmeerimise õppimine c

Andmete kvaliteet mõjutab oluliselt pingutusi ja lihtne reegel on: mida kaugemale ajaloos jõuame, seda suurema segaduse avastame. Seega on ülioluline otsustada varakult, kuidas palju ajalugu, mille tahame uude süsteemi üle kanda.

4. Kaasake ärimehi

Äriinimesed on ainsad, kes saavad andmetest tõeliselt aru ja kes saavad seetõttu otsustada, milliseid andmeid võib minema visata ja milliseid andmeid säilitada.

Kaardistamise ajal on oluline kaasata keegi ärimeeskonnast ja edaspidiseks tagasiteeks on kasulik kaardistamisotsused ja nende põhjused fikseerida.

Kuna pilt on väärt rohkem kui tuhat sõna, laadige uude süsteemi proovipartii ja laske ärimeeskonnal sellega mängida.

Isegi kui andmete meeskonna kaardistamine on ärimeeskonna poolt läbi vaadatud ja heaks kiidetud, võivad üllatused ilmneda, kui andmed kuvatakse uue süsteemi kasutajaliideses.

'Oh, nüüd ma näen, peame seda natuke muutma,' muutub levinud fraasiks.

Pärast uue süsteemi kasutuselevõttu on probleemide kõige levinum põhjus, kui ei kaasata valdkonna eksperte, kes on tavaliselt väga hõivatud inimesed.

5. Eesmärk automatiseeritud migratsioonilahendusele

Andmete rännet vaadatakse sageli ühekordse tegevusena ja arendajad kipuvad jõudma lahendusteni, mis on täis käsitsi tehtud toiminguid, lootes neid teostada ainult üks kord. Kuid sellise lähenemise vältimiseks on palju põhjuseid.

• Kui ränne jaguneb mitmeks laineks, peame samu toiminguid kordama mitu korda.
• Tavaliselt on iga laine jaoks vähemalt kolm migratsioonijooksu: kuivkäik andmete migreerimise toimivuse ja funktsionaalsuse testimiseks, täielik andmete valideerimise koormus kogu andmekogumi testimiseks ja äritestide läbiviimiseks ning loomulikult ka tootmiskoormus. Käitamiste arv suureneb halva andmekvaliteedi korral. Andmekvaliteedi parandamine on korduv protsess, seega vajame soovitud edukuse saavutamiseks mitu kordust.

Seega, isegi kui ränne on oma olemuselt ühekordne tegevus, võib käsitsi toimimine teie toiminguid oluliselt aeglustada.

Salesforce'i andmete migreerimine

Järgmisena käsitleme viit nõuannet Salesforce'i edukaks üleviimiseks. Pidage meeles, et need näpunäited sobivad tõenäoliselt ka teiste pilvelahenduste jaoks.

6. Valmistuge pikkade koormuste jaoks

Toimivus on üks, kui mitte kõige suurem kompromiss, kui minna kohapealt pilvlahendusele - Salesforce pole välistatud.

Kohapealsed süsteemid võimaldavad tavaliselt otse andmebaasi laadida andmebaasi ja hea riistvaraga jõuame hõlpsalt miljonite kirjeteni tunnis.

Kuid mitte pilves. Pilves on meid mitmed tegurid tugevalt piiranud.

• Võrgu latentsus - andmeid edastatakse Interneti kaudu.
• Salesforce'i rakenduskiht - andmed viiakse läbi paksu API mitmekihiline kiht kuni nad maanduvad oma Oracle'i andmebaasides.
• Kohandatud kood Salesforce'is - kohandatud valideerimised, päästikud, töövood, dubleerimise tuvastamise reeglid ja nii edasi - paljud neist keelavad paralleel- või hulgikoormused.

Seetõttu võib koormuse jõudlus olla tuhandeid kontosid tunnis.

Seda võib olla vähem või rohkem, sõltuvalt asjadest, näiteks väljade arvust, valideerimisest ja käivitajatest. Kuid see on mitu klassi aeglasem kui andmebaasi otsene koormus.

Samuti tuleb arvestada jõudluse halvenemisega, mis sõltub Salesforce'i andmete mahust.

Selle põhjuseks on aluseks oleva RDBMS-i (Oracle) indeksid, mida kasutatakse võõrvõtmete, unikaalsete väljade ja dubleerimisreeglite hindamiseks. Põhivalem on umbes 10-protsendiline aeglustumine iga klassi 10 jaoks, mille põhjuseks on O (logN) aja keerukuse osa sorteerimise ja B-puu operatsioonides.

mitu githubi lehte teil võib olla

Pealegi on Salesforce'il palju ressursikasutuse piiranguid.

Üks neist on Hulgi API limiit on määratud kuni 5000 partiid 24-tunnises veerevas aknas, kusjuures igas partiis on maksimaalselt 10 000 kirjet.

Teoreetiline maksimum on 50 miljonit 24 tunni jooksul laaditud plaati.

Päris projektis on maksimum palju väiksema partii piiratud suuruse tõttu näiteks kohandatud päästikute kasutamisel.

Sellel on tugev mõju andmete migratsiooni lähenemisviisile.

Isegi keskmise suurusega andmekogumite (100 000 kuni 1 miljon kontot) puhul pole suure paugu lähenemisviis kõne all, seega peame jagama andmed väiksemateks migratsioonilaineteks.

See mõjutab muidugi kogu juurutusprotsessi ja suurendab migreerimise keerukust, sest lisame andmete juurdekasvu süsteemi, mis on juba asustatud varasemate migreerimiste ja kasutajate sisestatud andmetega.

Peame neid olemasolevaid andmeid arvestama ka migratsiooni teisendustes ja valideerimisel.

Lisaks võivad pikad koormused tähendada, et me ei saa süsteemi katkemise ajal migreeruda.

Kui kõik kasutajad asuvad ühes riigis, saame öösel kasutada kaheksatunnist seisakut.

Kuid kogu maailmas tegutseva ettevõtte, näiteks Coca-Cola, jaoks pole see võimalik. Kui süsteemis on USA, Jaapan ja Euroopa, hõlmame kõiki ajavööndeid, seega on laupäev ainus katkestusvõimalus, mis kasutajaid ei mõjuta.

Ja see ei pruugi olla piisav, nii et peame laadima võrgus olles , kui kasutajad töötavad süsteemiga.

7. Austa rakenduste arendamisel rändevajadusi

Rakenduse komponendid, nagu valideerimised ja käivitajad, peaksid saama hallata andmete migreerimistegevusi. Kui süsteem peab olema võrgus, ei saa valideerimise tugevat blokeerimist migreerimiskoormuse ajal valida. Selle asemel peame andmete migratsiooni kasutaja tehtud muudatuste valideerimisel rakendama erinevat loogikat.

• Kuupäevavälju ei tohiks võrrelda süsteemi tegeliku kuupäevaga, kuna see keelaks ajalooliste andmete laadimise. Näiteks peab valideerimine võimaldama migreeritud andmete jaoks sisestada konto varasema alguskuupäeva.
• Kohustuslikud väljad, mis ei pruugi olla täidetud ajalooliste andmetega, tuleb rakendada mittekohustuslikena, kuid kasutajale tundliku valideerimisega, lubades seega migratsioonilt pärinevate andmete tühjad väärtused, kuid lükates tagasi tavakasutajatelt GUI kaudu saadud tühjad väärtused .
• Käivitajaid, eriti neid, mis integreerimisele uusi kirjeid saadavad, peab olema võimalik andmete migreerimise kasutaja jaoks sisse / välja lülitada, et vältida integreerimise üleujutamist üle kantud andmetega.

Teine nipp on väli Legacy ID või Migration ID kasutamine igas migreeritud objektis. Sellel on kaks põhjust. Esimene on ilmne: ID taganemine vanast süsteemist tagasilöömiseks; pärast seda, kui andmed on uues süsteemis, võivad inimesed ikkagi soovida oma kontodelt otsida vanu ID-sid, mis on leitud kohtadest e-kirjade, dokumentide ja vigade jälgimise süsteemidena. Halb harjumus? Võib olla. Kuid kasutajad tänavad teid, kui säilitate nende vanad ID-d. Teine põhjus on tehniline ja tuleneb asjaolust, et Salesforce ei aktsepteeri uute kirjete jaoks selgesõnaliselt esitatud ID-sid (erinevalt Microsoft Dynamics), vaid genereerib need laadimise ajal. Probleem tekib siis, kui me tahame alaobjekte laadida, kuna peame neile määrama vanemobjektide ID-d. Kuna me teame neid ID-sid alles pärast laadimist, on see kasutu harjutus.

Kasutame näiteks kontosid ja nende kontakte:

1. Kontode jaoks andmete genereerimine.
2. Laadige kontod Salesforce'i ja saate genereeritud ID-sid.
3. Lisage kontaktandmetesse uued konto ID-d.
4. Looge kontaktide jaoks andmed.
5. Kontaktide laadimine Salesforce'i.

Saame seda teha lihtsamalt, laadides kontod nende pärand-ID-dega, mis on salvestatud spetsiaalsele väliväljale. Seda välja saab kasutada vanema viitena, nii et kontaktide laadimisel kasutame lihtsalt vanema konto kursorina konto pärand-ID-d:

1. Looge kontode jaoks andmed, sealhulgas pärand-ID.
2. Looge kontaktide jaoks andmed, sealhulgas konto pärandi ID.
3. Laadige kontod Salesforce'i.
4. Laadige kontaktid Salesforce'i, kasutades vanemviidetena konto pärand-ID-d.

Tore on siin see, et oleme eraldanud põlvkonna ja laadimisfaasi, mis võimaldab paremat paralleelsust, vähendada seisaku aega jne.

8. Olge teadlik Salesforce'i spetsiifilistest omadustest

Nagu igas süsteemis, on ka Salesforce'is palju keerulisi osi, millest me peaksime teadma, et vältida andmete migreerimisel ebameeldivaid üllatusi. Siin on käputäis näiteid:

mis on välisvaluutarisk?

• Mõned aktiivsete kasutajate muudatused genereerivad kasutajate meilidele automaatselt e-posti märguandeid. Seega, kui me tahame kasutajaandmetega mängida, peame kasutajad kõigepealt deaktiveerima ja pärast muudatuste tegemist aktiveerima. Testikeskkondades rabeleme kasutaja e-kirju, et märguandeid ei käivitataks üldse. Kuna aktiivsed kasutajad tarbivad kulukaid litsentse, ei saa me kõiki kasutajaid kõigis testikeskkondades aktiivseks muuta. Peame haldama näiteks aktiivsete kasutajate alamhulki, et aktiveerida just need, kes on koolituskeskkonnas.
• Mitteaktiivsed kasutajad saab mõne standardobjekti jaoks, näiteks konto või juhtum, määrata alles pärast süsteemi loa andmist „Värskenda passiivsete omanikega kirjeid”, kuid neid saab määrata näiteks kontaktidele ja kõigile kohandatud objektidele.
• Kui kontakt on deaktiveeritud, lülitatakse kõik loobumisväljad vaikselt sisse.
• Konto tiimiliikme või konto jagamise objekti duplikaadi laadimisel kirjutatakse olemasolev kirje vaikselt üle. Opportunity partneri duplikaadi laadimisel lisatakse kirje lihtsalt, mille tulemuseks on duplikaat.
• Süsteemivälju, näiteks Created Date, Created By ID, Last Modified Date, Last Modified By ID, saab selgesõnaliselt kirjutada alles pärast uue süsteemiloa andmist „Määra auditi väljad kirje loomisel”.
• Välja väärtusloo muutusi ei saa üldse üle viia.
• Teadmusartiklite omanikke ei saa laadimise ajal täpsustada, kuid neid saab hiljem värskendada.
• Keeruline osa on sisu (dokumentide, manuste) salvestamine Salesforce'i. Seda saab teha mitmel viisil (manuste, failide, voo manuste, dokumentide kasutamine) ja igal viisil on omad plussid ja miinused, sealhulgas erinevad failisuuruse piirangud.
• Valikloendi väljad sunnivad kasutajaid valima ühe lubatud väärtustest, näiteks konto tüübi. Kuid andmete laadimisel kasutades Salesforce'i API (või mis tahes sellele ehitatud tööriist, näiteks Apexi andmete laadija või Informatica Salesforce'i pistik ), mis tahes väärtus möödub.

Nimekiri jätkub, kuid põhirida on järgmine: Enne eelduste tegemist tutvuge süsteemiga ja õppige, mida see suudab ja mida mitte. Ärge eeldage standardset käitumist, eriti põhiobjektide puhul. Uurige ja testige alati.

9. Ärge kasutage Salesforce'i andmete migreerimise platvormina

On väga ahvatlev kasutada Salesforce'i andmemigratsiooni lahenduse loomise platvormina, eriti Salesforce'i arendajatele. Andmemigratsiooni lahenduse jaoks on see sama tehnoloogia nagu Salesforce'i rakenduse kohandamiseks, sama GUI, sama Apexi programmeerimiskeel , sama infrastruktuur. Salesforce'il on objektid, mis võivad toimida tabelitena, ja omamoodi SQL-keel, Salesforce'i objektipäringute keel (SOQL) . Kuid palun ärge seda kasutage; see oleks põhimõtteline arhitektuuriline viga.

Salesforce on suurepärane SaaS-i rakendus, millel on palju toredaid funktsioone, näiteks täiustatud koostöö ja rikkalik kohandamine, kuid andmete massitöötlus ei kuulu nende hulka. Kolm kõige olulisemat põhjust on:

• Performance - Andmete töötlemine Salesforce'is on mitu klassi aeglasem kui RDBMS-is.
• Analüütiliste tunnuste puudumine - Salesforce SOQL ei toeta keerukaid päringuid ja analüütilisi funktsioone, mida peab toetama Apexi keel, ja see halvendaks jõudlust veelgi.
• Arhitektuur * - Andmemigratsiooni platvormi paigutamine konkreetsesse Salesforce'i keskkonda pole eriti mugav. Tavaliselt on meil eriotstarbel mitu keskkonda, mis on sageli loodud ad hoc, et saaksime koodide sünkroonimisele palju aega panna. Lisaks tugineksite ka selle konkreetse Salesforce'i keskkonna ühenduvusele ja kättesaadavusele.

Selle asemel koostage andmete migreerimise lahendus eraldi eksemplaris (see võib olla pilv või kohapeal), kasutades RDBMS- või ETL-platvormi. Ühendage see lähtesüsteemidega ja suunake soovitud Salesforce'i keskkondadesse, teisaldage vajalikud andmed oma lavastusalasse ja töötlege seal. See võimaldab teil:

• Kasutage SQL-keele või ETL-i funktsioonide täielikku võimsust ja võimalusi.
• Hoidke kõik koodid ja andmed ühes kohas, et saaksite kõiki süsteeme analüüsida.
  • Näiteks saate kombineerida kõige ajakohasema testimiskeskkonna Salesforce uusima konfiguratsiooni reaalsete andmetega tootmisüksuse Salesforce keskkonnast.
• Te ei sõltu nii lähte- kui sihtsüsteemide tehnoloogiast ja saate oma lahendust järgmiseks projektiks uuesti kasutada.

10. Järelevalve Salesforce'i metaandmetel

Projekti alguses haarame tavaliselt Salesforce'i väljade loendi ja alustame kaardistamise harjutust. Projekti käigus juhtub sageli, et rakenduste arendustiim lisab Salesforce'i uued väljad või muudetakse mõnda välja atribuuti. Võime paluda, et rakendusemeeskond teavitaks andmeedastusmeeskonda igast andmemudeli muutusest, kuid see ei tööta alati. Turvalisuse tagamiseks peavad kõik andmemudeli muudatused olema järelevalve all.

Levinud viis seda teha on migreerumisega seotud metaandmete korrapärane allalaadimine Salesforce'ist mõnda metaandmete hoidlasse. Kui see on olemas, ei saa me tuvastada ainult muudatusi andmemudelis, vaid saame võrrelda ka kahe Salesforce'i keskkonna andmemudeleid.

Millised metaandmed allalaadimiseks:

• Objektide loend koos siltide, tehniliste nimede ja atribuutidega, näiteks creatable või updatable.
• Väljade loetelu koos nende atribuutidega (parem, kui soovite neid kõiki hankida).
• Valimisloendi väljade valimisloendi väärtuste loend. Vajame neid sisendandmete õigete väärtuste kaardistamiseks või valideerimiseks.
• Valideerimiste loend, et veenduda, et uued valideerimised ei tekitaks migreeritud andmetele probleeme.

Kuidas metaandmeid Salesforce'ist alla laadida? Noh, standardset metaandmete meetodit pole, kuid on mitu võimalust:

• Looge ettevõtte WSDL - Navigeerige Salesforce'i veebirakenduses jaotisse Setup / API menüü ja laadige alla tugevalt sisestatud Enterprise WSDL, mis kirjeldab kõiki Salesforce'i objekte ja välju (kuid mitte valimisloendi väärtusi ega valideerimisi).
• Helistage Salesforce'i describeSObjects veebiteenus, otse või Java või C # ümbrist kasutades (konsulteerige Salesforce'i API ). Nii saate vajaliku ja see on soovitatav viis metaandmete eksportimiseks.
• Kasutage mõnda Internetis saadaval olevat arvukat alternatiivset tööriista.

Valmistuge järgmiseks andmete üleviimiseks

Pilvelahendused, näiteks Salesforce, on koheselt valmis. Kui olete sisseehitatud funktsioonidega rahul, logige lihtsalt sisse ja kasutage seda. Kuid ka Salesforce, nagu iga teine ​​CRM-i pilvlahendus, toob andmete migreerimise teemadega kokku erilisi probleeme, et olla teadlik eelkõige jõudluse ja ressursside piirangutega.

Pärandandmete teisaldamine uude süsteemi on alati teekond, mõnikord teekond ajaloosse, mis on peidetud eelmiste aastate andmetesse. Selles artiklis, mis põhineb tosinal rändeprojektil, olen esitanud kümme nõuannet, kuidas pärandandmeid migreerida ja edukalt kõige lõkse vältida.

Peamine on mõista, mida andmed näitavad. Nii et enne andmete migreerimise alustamist veenduge, et: Salesforce'i arendusmeeskond on hästi ette valmistatud võimalike probleemide jaoks, mis teie andmetel võivad olla.

Seotud: Relatsioonandmebaasidest kinni jäänud HDFS-i õpetus andmeanalüütikutele