论文阅读——In-Storage Computing for Hadoop MapReduce Framework: Challenges and Possibilities

继续Smart SSD主题相关
本文主要将Smart SSD应用到MapReduce系统中。MapReduce是由谷歌公司提出的一种面向大规模数据处理的并行计算模型和方法。Map处理原始数据，杂乱无章；Reduce中数据是根据键值对key后面的value来组织的。可以看做把一堆杂乱无章的数据按照某种特征归纳处理，提取出key和value。从而方便进一步处理。
大规模数据就决定了难以全部存档在内存，通常借助外存；又会使得访问外存中数据时的IO成为bottleneck。
因此本文为了减少大规模数据并行计算过程中的数据通信开销，尝试着把数据传送到处理器or代码端靠拢或迁移。
本文是将MapReduce系统的MAP操作offloading到SSD。
得益于SSD的顺序访问速度比堆积访问快+高速的内部总线，从而减少计算机存储体系的搬移。
最终带来了2.3x的计算效率提升，功耗降低了11.5x。

Section I Introduction

SSD比HDD快100倍功耗却只有HDD的1/10，近年来人们也逐渐关注不再将SSD当做单纯的存储设备而是当做计算单元，衍生出ISC的概念。


Hadoop MapReduce是一个集群的高性能并行计算平台/框架，把对数据集的大规模操作分发给网络上的每个节点实现可靠性，把处理向数据端迁移。在MapReduce中操作被分为Map和Reduce.
Mapper:以键值对作为输入并产生一系列新的键值对，框架会将产生的key进行聚类
Reducer:以键对应的值作为输入，经合并相同key的值（化简）如此递归直至最后只剩下一个元素

但将一个MapReduce系统移植到Smart SSD实现存在以下挑战：
数据表示不统一、系统接口（一个用Java写的一个用C++写的）、
为什么只offloadMap部分？因为Reduce需要接受其他Map shuffle后的结果作为输入，但在ISC中不同device之间不好进行通信的，而且还需要host重新给每一个ISC器件分配中间值，会增加冗余的计算量以及数据移动。





 ## Section II Background

## Part A ISC
ISC较早时期便被提出并且应用在了HDD上，但由于HDD算力有限限制了ISC的进一步扩展。随着SSD的发展，配备了多核处理器以及足够的片上DRAM人们开始重新考虑ISC的SSD实现。
SSD的优势在:提供高速的内部带宽，通常是I/O接口的3倍以上；另一方面I/O的延时更短。以上两点表明对于I/O密集型的应用很适合用SSD实现计算。
但考虑到SSD上面配备的处理器往往算力不佳，即是处于成本也是处于功耗的考虑，因此对于计算密集型的应用可能不那么适合用SSD实现。
ISC的硬件架构
主要由外存（NAND Flash)+SSD controller+内存（片上DRAM）组成。
而SSD Controller主要包括：
（1）embeded processor（一般是32bit的Arm核）
(2)host controller
(3)flash controller
(4)DRAM controller
各自具体的功能也在前一篇介绍过，在此不赘述

ISC的软件架构
ISC的软件架构
软件包含两大块内容：
（1）ISC firmware嵌在SSD和host程序中的ISC固件，通过API完成host和SSD之间的通信
ISC host interface完成host对ISC操作的控制
ISC device interface用于协调ISC runtime system和application
因此软件部分就需要实现
ISC host program：
也包含两部分
session management-OPEN/CLOSE来开启一个对话调用 device program啥的，以及完成SSDlet的GET SET PUT等操作
operation
ISC device program-SSDlet通过编译器由C++代码生成给device看的binary code;还需要完成常用的IO读写操作

Part B Apache Hadoop

Apache Hadoop是一套用于在由通用硬件构建的大型集群上运行应用程序的框架，实现Map/Reduce编程范型，计算任务会被分割成小块（多次）运行在不同节点上。
这一并行计算的特点可以有效提升算力、存储以及带宽限制。
HDFS
HDFS分布式文件系统，数据被存储在计算节点上以提供更高的跨数据中心聚合带宽。HDFS是一个高度容错的系统，适合部署在链家的极其上，可以提供高吞吐量的数据方粉，非常适合大规模数据集上的应用。特点是流式读取文件。
namenode：1个，中心服务器负责管理文件系统的namespace以及host对文件的访问
datanode：1组，负责管理所在及诶点的存储问题
一个文件被分成多个数据块，这些数据块存储在一组datanode中，负责执行客户端的读写请求。namenode执行文件系统的打开关闭重命名等。
体现的思想：移动计算比移动数据更划算，将计算距离操作的数据越近越高效。

MapReduce Framework
首先键输入数据分成不同的chunk，送入不同的map
MapReduce主要包含3个步骤：
Map：并行计算根据输入得到一系列键值
Shuffle：聚类成k堆，将map的输出转移到reduce的输入
Reduce：根据map的输出作为输入根据一定的映射关系得到输出
#这一段没怎么看懂

Section III ISC Hadoop MapReduce

将MapReduce中Map部分offload给SSD
为此需要设计ISC engine解决接口和数据表示的问题。设计思路是先实现单个Hadoop节点然后扩展成Hadoop集群。
Part A
Single Node
Hadoop框架有3种实现方式
（1）standalone:namenode,datanode,jobtracker放在一个java中跑，不需要HDFS
(2)pseudo distributed
(3)fully distributed；不可实现
本文通过一种pseudo flly-distributed伪分布模式实现Hadoop框架，可以精确控制Mapper的数目
Multiple Nodes
建立了5个node组成的集群，一个作为namenode,四个作为datanode（从1增加到4）。由于性能是线性提升的因此没有测试更大的集群。
Part B workflow
（1）通过接口完成与SSD的通信，传入input data（a file name)
（2）原始的分块数据进行格式转换（LBA range informaion)
(3)SSD中的Mapper完成map task
（4）计算结果存储在本地，供host读取进行Reduce操作
Part C 设计要点与难点
数据表示
host和SSD之间数据不一致，本文软件部分设计了file-to-LBA converter,将原始64MB数据分成2-4组LBA lists，随后就可以送入SSD进行Mapper
接口不一致
一个用Java一个用C++，本文为了不额外占用SSD资源设计了一个interface layer接口层。主要完成
（1）数据转换
（2）写会Map后输出的结果
数据分片
在ISC中需要将输入数据从device送到host memory中，但目前SSD中还不支持这种通信。因此本文会搜索搜有文件的末尾，遇到空格 tab键等就把之前的词连城一个单词。
Part D ISC相关优化
实验中我们发现即使ISC Hadoop架构的Mapper时间已经缩短了近3倍，但还是没办法真正反映每个Map的执行时间。而且我们没有进行Hadoop常用的优化，二是进行了：
progress interval
Tasktracker out-of-band heartbeat
Heartbeat interval:主要来提升调度效率

Section IV 实验结果与分析

为了测试节点的性能，设置了两组参照，算力一高一低，每个都配备了400GB的SSD+SAS接口。
系统搭建好后评价指标有elapsed time\energy consumption\系统资源占用率。
实验发现不是所有的Hadoop操作都适合ISC架构的，就像之前说的对于IO密集的、随机访问多的、输出数据规模较小的才算是比较适合的。
Time
实验最终结果表明ISC Hadoop在常规Hadoop只进行了50%Maps时就完成了Map+Reduce。
Energy
资源上ISC比常规Hadoop的实现节能11.5x。
以上优势来源于减少了host与device之间的数据移动，更多利用SSD内部的高速带宽。
Usage
在资源利用率上测试了Host CPU、IORead、DRAM的使用率。很明显可以看出Read IO大大降低几乎不需要。

Summary

本文工作：Hadoop 的ISC实现
具体：将MapReduce的Map部分进行了Smart SSD的实现
挑战：
数据表示问题、接口问题、数据划分问题、未来如何进一步offload
主要留下印象的也可能是工作所在是software interface layer完成host与device之间的交流

这一篇实际没怎么看懂 云里雾里。。。