diff --git a/ch10.md b/ch10.md
index 3df8071..18ce719 100644
--- a/ch10.md
+++ b/ch10.md
@@ -538,7 +538,7 @@ Hadoop 生态系统既包括随机访问型的 OLTP 数据库，如HBase（参
 
 与之相对，MapReduce 在遇到某个 map 或 reduce 子任务运行出错时，可以单独、自动地进行重试，而不会引起整个 MapReduce 任务的重试。此外，MapReduce 倾向于将数据（甚至是 map 到 reduce 中间环节的数据）进行落盘，一方面是为了容错，另一方面是因为 MapReduce 在设计时假设面对的数据量足够大，内存通常装不下。
 
-因此，MapReduce 通常更适合**大任务**：即那些需要处理大量数据、运行较长时间的任务。而巨量的数据、过长的耗时，都会使得处理过程中遇到故障司空见惯。在这种情况下，由于一个 **子任务（task）** 的故障而重试整个**任务（job）**就非常得不偿失。当然，即使只在子任务粒度进行重试，也会让那些并不出错的任务运行的更慢（数据要持久化）。但对于频繁出错的任务场景来说，这个取舍是合理的。
+因此，MapReduce 通常更适合**大任务**：即那些需要处理大量数据、运行较长时间的任务。而巨量的数据、过长的耗时，都会使得处理过程中遇到故障司空见惯。在这种情况下，由于一个**子任务（task）** 的故障而重试整个**任务（job）** 就非常得不偿失。当然，即使只在子任务粒度进行重试，也会让那些并不出错的任务运行的更慢（数据要持久化）。但对于频繁出错的任务场景来说，这个取舍是合理的。
 
 但这种假设在多大程度上是正确的呢？在大多数集群中，机器确实会故障，但非常低频——甚至可以低到大多任务在运行时不会遇到任何机器故障。在这种情况下，为了容错引入的巨量额外损耗值得吗？