Dear team,
Currently we are onboarding data with email and mobile as fields in schema, but in phase 1, we are planning to make only email as identifier and mobile as attribute. And then upload data from our data warehouse.
Phase 2 (6 months later), we are planning to change mobile field as identifier as well (now email is primary identifier and mobile as secondary identifier), and re-upload data for that schema.
Can you let me know
1) If above approach is feasible?
2) During phase 1, can query service use mobile number as field and query profile? I am told we need to use identifiers only (and not attributes) to query profile.
Thanks,
Veera
Solved! Go to Solution.
Views
Replies
Total Likes
1) If above approach is feasible? --> Yes
2) During phase 1, can query service use mobile number as field and query profile? I am told we need to use identifiers only (and not attributes) to query profile. --> Query service can use any field (provided that field was loaded in any dataset) to query data lake but I think you're asking about profile lookup for that only identity can be used
Views
Replies
Total Likes
1) If above approach is feasible? --> Yes
2) During phase 1, can query service use mobile number as field and query profile? I am told we need to use identifiers only (and not attributes) to query profile. --> Query service can use any field (provided that field was loaded in any dataset) to query data lake but I think you're asking about profile lookup for that only identity can be used
Views
Replies
Total Likes
Thanks for prompt reply @arijitg .
On Q2, can i do below in that case? Assuming email is identifier and mobile is attribute in a dataset.
Step 1: Use Query service to get email using mobile number
Step 2: Use profile look-up table using email
Can we apply index on tables for Step1
Cheers,
Veera
Views
Replies
Total Likes
1. Yes you can and you need to design the query carefully (to handle multiple matches or duplicate entries etc.)
2. Not sure what you mean by profile look-up table. If you mean unified profile store then that can't be queried like data lake.
Our underlying data is stored as parquet and mostly these parquets are partitioned on date, so using date and specific column names would return results faster compare to select * without filters
Regards,
Arijit Ghosh
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies
Views
Likes
Replies