mirror of
https://github.com/DistSysCorp/ddia.git
synced 2024-12-25 12:20:22 +08:00
fix bold format
This commit is contained in:
parent
4f8108dd54
commit
3fcc9ffe53
2
ch10.md
2
ch10.md
@ -538,7 +538,7 @@ Hadoop 生态系统既包括随机访问型的 OLTP 数据库,如HBase(参
|
||||
|
||||
与之相对,MapReduce 在遇到某个 map 或 reduce 子任务运行出错时,可以单独、自动地进行重试,而不会引起整个 MapReduce 任务的重试。此外,MapReduce 倾向于将数据(甚至是 map 到 reduce 中间环节的数据)进行落盘,一方面是为了容错,另一方面是因为 MapReduce 在设计时假设面对的数据量足够大,内存通常装不下。
|
||||
|
||||
因此,MapReduce 通常更适合**大任务**:即那些需要处理大量数据、运行较长时间的任务。而巨量的数据、过长的耗时,都会使得处理过程中遇到故障司空见惯。在这种情况下,由于一个 **子任务(task)** 的故障而重试整个**任务(job)**就非常得不偿失。当然,即使只在子任务粒度进行重试,也会让那些并不出错的任务运行的更慢(数据要持久化)。但对于频繁出错的任务场景来说,这个取舍是合理的。
|
||||
因此,MapReduce 通常更适合**大任务**:即那些需要处理大量数据、运行较长时间的任务。而巨量的数据、过长的耗时,都会使得处理过程中遇到故障司空见惯。在这种情况下,由于一个**子任务(task)** 的故障而重试整个**任务(job)** 就非常得不偿失。当然,即使只在子任务粒度进行重试,也会让那些并不出错的任务运行的更慢(数据要持久化)。但对于频繁出错的任务场景来说,这个取舍是合理的。
|
||||
|
||||
但这种假设在多大程度上是正确的呢?在大多数集群中,机器确实会故障,但非常低频——甚至可以低到大多任务在运行时不会遇到任何机器故障。在这种情况下,为了容错引入的巨量额外损耗值得吗?
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user