HBase is a good fit for record-oriented data access.
HBase (BigTable) describe an data-layout called "locality groups". A locality group is a grouping of columns across rows which are frequently accessed together. This is meant to avoid a penalty of having to filter data (server-side) to answer a query which the client definitively knows it does not want.
In HBase, each column family is a locality group. Within a column family, all the columns (qualifiers) in a row are stored adjacent in a single file. Thus, there is absolutely no concern when fetching data for a row in HBase when only fetching columns in a single family -- this is the optimal case.
There is a (very) minor concern when you request all the columns for a row which has multiple column families combined. In this case, the data for each family is stored in separate files. Because each file is sorted by row-order, it is a trivial merge of sorted data which is very efficient. So, as long as you are not implementing a schema which has each column in its own family (which would be considered a bad schema decision), the perceived cost would be relatively low (if you had one column per family, this would result in opening a file for each column queried which would increase HBase memory, HDFS utilization, etc). Most use-cases use a few column families (e.g. 1-5), many only using a single family.
