Operational Considerations for Matching
You must consider these key points for matching in Reltio platform.
In legacy systems, matching is treated as a batch process that is designed to run once a day usually at 2am while employees are asleep, teeing up a fresh batch of matches to consume the next morning. And it usually runs after a landing process, a staging process, and before a subsequent merge process. Together these legacy processes usually take hours upon hours and hopefully finish before employees arrive the next morning.
Reltio changes all this. With Reltio, cleansing, matching and merging of a profile occur in real-time whenever a profile is created or updated. Here are recommendations for business processes related to Reltio Matching.
Recommendations for Data Load Use Cases
Initial Data Load
During an initial data load of a tenant which could involve millions of records or hundreds of millions of records, the recommended approach is to load your data without matching or merging enabled. The best way to accomplish this is to remove the match rules from your L3, load the data, reinstate your match rules, and then re-index your tenant including a rebuild of the match tables. For more information, see Creating a Reindex Data Job and Creating a Rebuild Match Tables Job.
Incremental Data Loads
Best practice is to review the size of the additional records you are loading into your tenant. Generally, if you are doubling the number of records in your tenant, you should consider the same process as for an Initial Data Load, which essentially means removing your match rules temporarily, loading the data, then putting the rules back and running the job to reindex and rebuild the match table, as described above
Updates and new records streaming into the platform throughout the day
This includes records being posted in real-time from other applications as well as from business users via the UI. For this modality, nothing special or different is recommended. Records should be allowed to cleanse, match and merge as they flow into the tenant.
What to do when you modify your match rules
Once data is in your tenant and has been indexed and matched according to the steps described above and perhaps has been operating for quite some time, you may decide to modify your match rules. Naturally you’ll want to test your new rules in your dev and test tenants. When ready, you will migrate those to your prod tenant. Any time you modify rules in any tenant where records are already resident, you will need to reindex and rebuild the match table, as described above to ensure the records are retokenzied and rematched according to your new rules.