你的话来自《学习hbase》一书。引用不准确，但这是个好消息：）
看看作者是怎么形容高瘦的
在一个高而薄的table设计中，table向下生长的速度比向右手边生长的速度快。[…]
rowkey（userid+timestamp）|博客entriescf:entries

好吧，首先要绕过的是行锁定。
假设你有一个大行，你需要更新它。这意味着必须锁定此行。因为它被锁定了，所以没有其他作者可以在那一刻更新它。他们必须等到锁松开。
对于“高”和“薄”，数据包含在短行中的一个字段中，这样更新数据不会给其他希望更新其内容（位于单独一行）的编写者带来问题。
高瘦也有助于建立动态关系，扩展用户群，更快的索引，更好的响应时间。
人类可读性不强，但对于机器来说，更容易处理、连接、修改和改变结构。
如果您有一个对象关系Map接口（比如javahibernate、php eloquent等等），那么将其转换为一个或多个关系并更新、修改、轮询整个对象就变得非常容易了。
“高”和“薄”还允许在其他地方轻松实现相同的数据对象，而不需要视图来清理/删除垃圾数据。
例如：
我有一个产品a，产品b，产品c的价格数据库的价格有日期，他们是有效的季节（圣诞节等…）。我示例中的所有产品都受同一季节的约束
宽：

date_from | date_to    | ProductA_price | ProductB_price | ProductC_price
  22-10-2000| 22-11-2000 | 100            | 110            | 90
  23-11-2000| 26-12-2000 | 200            | 210            | 190
  27-12-2000| 22-01-2001 | 100            | 110            | 90

现在，如果您想添加一个额外的产品，您必须执行以下操作：
修改表。这可能是非常昂贵的一个大表上做，造成停机
更新价格会导致很多行锁定
修改查询。到处都在使用查询。他们都必须考虑额外的列，特别是如果 select * 已使用。
修改实现代码。有一个额外的列，松散的循环可能会中断。需要修改数组迭代器以考虑额外的产品。
如果软件基础有点老化，那么在更改后很长一段时间内东西都会损坏。
更新对表名的硬编码引用
高：

table: Products
id | product_name
1  | ProductA
2  | ProductB
3  | ProductC

table: Periods
id| name    | date_from | date_to
1 | autumn  | 22-10-2000| 22-11-2000
2 | xmas    | 23-11-2000| 26-12-2000
3 | newyear | 27-12-2000| 22-01-2001

table: Prices
product_id | period_id | price
1          | 1         | 100
2          | 1         | 110
3          | 1         | 90
1          | 2         | 200
2          | 2         | 210
3          | 2         | 190
1          | 1         | 100
2          | 1         | 110
3          | 1         | 90

现在，如果您想添加一个额外的产品，您必须执行以下操作：
将产品添加到表产品
在perioddate>now（）的价格表中添加条目
因为它都是关系型的，所以代码已经将它视为关系型的，并将它作为关系型的来读取，只需将它添加到现有的代码流中即可。

窄数据或堆叠数据显示为一列包含所有值，另一列列出值的上下文。这通常更容易实现，添加新字段不需要对表的结构进行任何更改，但是人们可能更难理解。”
来自“宽窄数据”，维基百科https://en.wikipedia.org/wiki/wide_and_narrow_data [访问时间：2016年12月29日]
我假设这意味着如果你想得到一个纯粹的值列表，而不关心它们的上下文，你只需要读取一列。如果您想在短范围的数据结构中实现这一点，就必须找到行并到达所需的列，并且对每一行都是这样，而不是一次读取。
当做，

 写入时间戳1     | hbaseentry公司
 写入时间戳2     | Hadoop入口
 写入时间戳3     | Hadoop入口
  ...            |  ...
请注意，行键顺序不对，这与解释混淆的示例不同。这个例子解释了writera
遍历多行。
然而hbase不是这样工作的，它实际上是在写入密钥之前对密钥进行排序（从技术上讲，突变不会被排序到wal中，但是如果一切正常，wal就不会被使用，如果被使用，突变会被重放到保存区域数据的memstore中）。
由于hbase拆分是在行上进行的，因此可以在一个区域服务器上找到与特定用户相关的数据。
这一部分似乎在逻辑上与短宽有关。。。
所以总而言之，我认为这本书的这一部分可能需要复习一下。请参阅mapr的这篇优秀的博客文章，快速了解hbase的概况。