fix bold format in markdown

ch10.md

@@ -538,7 +538,7 @@ Hadoop 生态系统既包括随机访问型的 OLTP 数据库，如HBase（参
 
 与之相对，MapReduce 在遇到某个 map 或 reduce 子任务运行出错时，可以单独、自动地进行重试，而不会引起整个 MapReduce 任务的重试。此外，MapReduce 倾向于将数据（甚至是 map 到 reduce 中间环节的数据）进行落盘，一方面是为了容错，另一方面是因为 MapReduce 在设计时假设面对的数据量足够大，内存通常装不下。
 
-因此，MapReduce 通常更适合**大任务**：即那些需要处理大量数据、运行较长时间的任务。而巨量的数据、过长的耗时，都会使得处理过程中遇到故障司空见惯。在这种情况下，由于一个**子任务（task）**的故障而重试整个**任务（job）**就非常得不偿失。当然，即使只在子任务粒度进行重试，也会让那些并不出错的任务运行的更慢（数据要持久化）。但对于频繁出错的任务场景来说，这个取舍是合理的。
+因此，MapReduce 通常更适合**大任务**：即那些需要处理大量数据、运行较长时间的任务。而巨量的数据、过长的耗时，都会使得处理过程中遇到故障司空见惯。在这种情况下，由于一个 **子任务（task）** 的故障而重试整个**任务（job）**就非常得不偿失。当然，即使只在子任务粒度进行重试，也会让那些并不出错的任务运行的更慢（数据要持久化）。但对于频繁出错的任务场景来说，这个取舍是合理的。
 
 但这种假设在多大程度上是正确的呢？在大多数集群中，机器确实会故障，但非常低频——甚至可以低到大多任务在运行时不会遇到任何机器故障。在这种情况下，为了容错引入的巨量额外损耗值得吗？
 
@@ -799,4 +799,4 @@ Spark 使用 JVM 字节码、Impala 使用 LLVM 来通过生成代码的方式
 
 批处理任务的基本特点是——读取输入，进行处理，产生输出的过程中，**不会修改原数据**。换句话说，输出是输入的衍生数据。其中一个重要特点是，输入数据是**有界的**（bounded）：**输入的大小是固定的、事先确定的**（比如输入是包含一组日志的数据或者一个快照点的数据）。唯其有界，处理任务才能知道什么时候输入读取结束了、什么时候计算完成了。
 
-但在下一章中，我们将会转到流处理（stream processing）上，其中，输入是**无界的**（unbounded）——你的任务面对的是不知道何时结束的**无限数据流**。在这种情况下，任何时刻都有可能有新的数据流入，任务会永不结束。我们之后可以看到，虽然批处理和流处理在某些方面有相似之处，但对于输入的无界假设，会在构建系统时对我们的设计产生诸多影响。
+但在下一章中，我们将会转到流处理（stream processing）上，其中，输入是**无界的**（unbounded）——你的任务面对的是不知道何时结束的**无限数据流**。在这种情况下，任何时刻都有可能有新的数据流入，任务会永不结束。我们之后可以看到，虽然批处理和流处理在某些方面有相似之处，但对于输入的无界假设，会在构建系统时对我们的设计产生诸多影响。