0816

docs/数据湖.md

@@ -53,7 +53,8 @@
 
 #### 第二阶段
 `lambda架构`。随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark Streaming、Flink等。然而，随着越来越多的应用上线，大家发现，其实批处理和流计算配合使用，才能满足大部分应用需求；而对于用户而言，其实他们并不关心底层的计算模型是什么，用户希望无论是批处理还是流计算，都能基于统一的数据模型来返回处理结果，于是Lambda架构被提出，如下图所示。
-- [lambda](/img/1597549355.png)
+
+![lambda](/img/1597549355.png)
 
 Lambda架构的核心理念是``流批一体``，如上图所示，整个数据流向自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。无论哪种计算模式，最终的处理结果都通过服务层对应用提供，确保访问的一致性。
 
@@ -87,7 +88,8 @@ Kappa架构。Lambda架构解决了应用读取数据的一致性问题，但是
 8. 任务编排
 9. 元数据管理
 ```
-- [数据湖架构](/img/1597550727.png)
+![数据湖架构](/img/1597550727.png)
+
 
 上图的“集中式存储”更多的是业务概念上的集中，本质上是希望一个企业/组织内部的数据能在一个明确统一的地方进行沉淀。事实上，数据湖的存储应该是一类可按需扩展的分布式文件系统，大多数数据湖实践中也是推荐采用S3/OSS/OBS/HDFS等分布式系统作为数据湖的统一存储。