Why it matters
Column family count is one of the earliest HBase design decisions and one of the most consequential. Too many families means excessive compaction load — every family has its own compaction and they all compete for cluster I/O. Too few families means access patterns interfere with each other and you cannot tune storage per data class.
Getting this wrong requires a schema migration to fix, which is not a small undertaking. Better to understand the trade-offs before creating the table.
The architecture
Physically, each column family has its own directory under the region's HDFS directory. HFiles for that family live only in that directory. The memstore is per-family per-region. Compactions run per family, and their schedules are independent.
Reads that touch multiple families read from each family's store scanner and merge results. This is efficient but not free — every additional family in a query adds overhead.
How it works end to end
Common wisdom is that one column family per table is optimal unless you have a specific reason to split. Two or three families is acceptable. Beyond that, compaction load compounds and cluster CPU starts being dominated by rewriting HFiles rather than serving queries.
Legitimate reasons for multiple families include: different TTL requirements (hot recent data with 30-day TTL, cold history with 5-year TTL); different access frequencies (hot columns queried often, cold columns rarely, where separating them lets bloom filters and block cache work better); very different data sizes (small columns and large blob columns where mixing hurts scan efficiency).
Bad reasons include: schema organization (use qualifiers, not families); logical grouping (again, qualifiers); anticipated future access patterns (over-engineering).