鲁棒性和容错能力。由于批处理层被设计为追加式，即包含了自开始以来的整体数据集，因此该系统具有一定的容错能力。如果任何数据被损坏，该架构则可以删除从损坏点以来的所有数据，并替换为正确的数据。同时，批处理视图也可以被换成完全被重新计算出的视图。而且速度层可以被丢弃。此外，在生成一组新的批处理视图的同时，该架构可以重置整个系统，使之重新运行。
可扩展性。Lambda体系架构的设计层是作为分布式系统被构建的。因此，通过简单地添加更多的主机，最终用户可以轻松地对系统进行水平扩展。
通用性。由于Lambda体系架构是一般范式，因此用户并不会被锁定在计算批处理视图的某个特定方式中。而且批处理视图和速度层的计算，可以被设计为满足某个数据系统的特定需求。
延展性。随着新的数据类型被导入，数据系统也会产生新的视图。数据系统不会被锁定在某类、或一定数量的批处理视图中。新的视图会在完成编码之后，被添加到系统中，其对应的资源也会得到轻松地延展。
按需查询。如有必要，批处理层可以在缺少批处理视图时，支持临时查询。如果用户可以接受临时查询的高延迟，那么批处理层的用途就不仅限于生成的批处理视图了。
最少的维护。Lambda架构的典型模式是：批处理层使用Apache Hadoop，而服务层使用ElephantDB。显然，两者都很容易被维护。
可调试性。Lambda体系架构通过每一层的输入和输出，极大地简化了计算和查询的调试。
低延迟的读取和更新。在Lambda体系架构中，速度层为大数据系统提供了对于最新数据集的实时查询。
由于所有数据都是被追加进来，并且批处理层中的任何数据都不会被丢弃，因此系统的扩展成本必然会随着时间的推移而增长。
如前文所述，批处理层可使用Hadoop或Snowflake，而速度层则可以使用Storm或Spark。显然，这两层虽然运行同一组数据，但是它们是在完全不同的系统上构建的。因此，用户需要维护两套相互独立的系统代码。这样不但复杂，而且极具一定的挑战性。
(1) client访问NameNode，查询元数据信息，获得这个文件的数据块位置列表，返回输入流对象。
(2) 就近挑选一台datanode服务器，请求建立输入流 。
(3) DataNode向输入流中中写数据，以packet为单位来校验。
(4) 关闭输入流
（1）客户端通过Distributed FileSystem模块向NameNode请求上传文件，NameNode检查目标文件是否已存在，父目录是否存在。
（2）NameNode返回是否可以上传，若通过检查，直接先将操作写入 EditLog，并返回输出流对象。（注：WAL，write ahead log，先写Log，再写内存，因为EditLog记录的是最新的HDFS客户端执行所有的写操作。如果后续真实写操作失败了，由于在真实写操作之前，操作就被写入EditLog中了，故EditLog中仍会有记录，我们不用担心后续client读不到相应的数据块，因为在第6步中DataNode收到块后会有一返回确认信息，若没写成功，发送端没收到确认信息，会一直重试，直到成功）
（3）客户端请求第一个 Block上传到哪几个DataNode服务器上，client端按每个Block128MB的块切分文件。
（4）client将NameNode返回的分配的可写的DataNode列表和Data数据一同发送给最近的第一个DataNode节点，此后client端和NameNode分配的多个DataNode构成pipeline管道(NameNode返回3个DataNode节点，分别为dn1、dn2、dn3)，client端向输出流对象中写数据。
（5）客户端通过FSDataOutputStream模块请求dn1上传数据，dn1收到请求会继续调用dn2，然后dn2调用dn3，将这个通信管道建立完成。
（6）dn1、dn2、dn3逐级应答客户端。
（7）客户端开始往dn1上传第一个Block（先从磁盘读取数据放到一个本地内存缓存），以Packet为单位，dn1收到一个Packet就会传给dn2，dn2传给dn3；dn1每传一个packet会放入一个应答队列等待应答。
（8）写完数据，关闭输输出流，发送完成信号给NameNode。
（注：发送完成信号的时机取决于集群是强一致性还是最终一致性，强一致性则需要所有
DataNode写完后才向NameNode汇报。最终一致性则其中任意一个DataNode写完后就能单独向
NameNode汇报，HDFS一般情况下都是强调强一致性）
参考文档：HDFS读写流程（史上最精炼详细）_little prince，blue coder-CSDN博客_hdfs的读写流程
