Fact table Primary Key: Surrogate Key or multi-column Natural Key?
What's the context?  It sounds like you're talking about a data warehouse.  If so, I strongly recommend creating a synthetic key.  I can think of three good reasons, offhand:


It will be narrower than the business key.  While adding a column to a fact table should not be done lightly, because it will make your other indices narrower it may actually reduce the total size of your database.
Natural keys get dirty.  Sooner or later someone will reuse a product code for something unrelated, or you'll need to start tracking sub-customers.  If you have a mapping process between your natural keys and your synthetic keys, it's simple to account for these kinds of things.
You can use it to store synthetic values: -1 for "Not applicable", 0 for "Unknown", 1 for "Missing", 2 for "Illegible", etc.  Depending on your natural keys, you might be able to do the same there, but there would always be a risk of collision.


48+ billion records is a lot.  If you haven't already, you should consider aggregating data, perhaps after the current month.  Synthetic keys could make this simpler too: perhaps values 1,000,000,001..1,999,999,999 are reserved for 2017/08 details, and in October the August data gets collapsed into a single record with ID 1,000,000,000 (this probably wouldn't be a good idea, it's just an example of how you may need to disconnect business keys from warehouse keys).

One last note: don't forget that your choices for PK and for clustering key by no means need to be the same!  Each should be evaluated on its own merits.