ARA-C01 Question 123
Single answerData vaultA retail company is implementing a Raw Data Vault in Snowflake to consolidate customer data from CRM, e-commerce, and in-store systems. Source systems frequently resend the same records, and some attributes such as customer status and loyalty tier can change multiple times per day. The architecture team wants to preserve full history, support parallel loading, and avoid unnecessary satellite growth caused by duplicate payloads. Which design choice best meets these requirements?
- A
Store all customer attributes directly in the CUSTOMER hub and update the hub row whenever any descriptive attribute changes.
- B
Load the CUSTOMER hub with the business key, load links for relationships, and load satellites with hashdiff-based change detection so only changed descriptive records are inserted with their load timestamps.
- C
Merge all source records into a single wide CUSTOMER table using the business key and overwrite prior values to keep only the latest version for each customer.
- D
Create one satellite per source record and insert every inbound row without comparing payloads, because Data Vault requires all source duplicates to be stored as separate historical versions.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to use the canonical Raw Data Vault pattern: hubs for business keys, links for associations, and satellites for descriptive attributes and history. In this scenario, customer attributes such as status and loyalty tier are volatile and should be historized in satellites rather than stored in hubs. Because upstream systems resend unchanged records, hashdiff-based change detection is a common best practice to prevent unnecessary satellite bloat by inserting a new satellite row only when the descriptive payload changes. This approach aligns with Data Vault 2.0 implementation patterns and works well in Snowflake because ELT loading can be parallelized across hubs, links, and satellites. It also supports auditability through metadata such as load timestamp and record source. Snowflake documentation on ELT and scalable loading supports this pattern operationally, while Data Vault best practices emphasize the separation of business keys, relationships, and historized descriptive context.
- A. Incorrect.
Incorrect. In Data Vault, hubs store stable business keys and related metadata, not changing descriptive attributes. Updating hub rows when customer status or loyalty tier changes would violate core Data Vault modeling principles and reduce the ability to preserve attribute history cleanly. Descriptive changes belong in satellites, which are designed for historization.
- B. Correct.
Correct. This is the standard Raw Data Vault pattern. Hubs capture unique business keys, links capture relationships, and satellites hold descriptive context with load dates and record source. Using a hashdiff of the descriptive payload helps detect whether an incoming row is materially different from the latest stored version, which avoids inserting redundant satellite rows when source systems resend identical data. This preserves full history for actual changes while supporting scalable, parallel ELT processing in Snowflake.
- C. Incorrect.
Incorrect. A single wide table with overwrites is closer to a current-state dimensional or normalized target, not a Raw Data Vault. Overwriting prior values loses historical lineage, makes auditability harder, and does not align with the requirement to preserve full history. It also reduces flexibility when integrating multiple heterogeneous sources.
- D. Incorrect.
Incorrect. Satellites do store historical descriptive data, but inserting every resent duplicate row without change detection causes unnecessary growth and processing overhead. A common misconception is that Raw Data Vault requires storing every identical duplicate as a new historical event. In practice, many implementations use hashdiff-based comparisons to distinguish true attribute changes from repeated identical payloads, while still retaining source lineage and load metadata.