小文件存储与大文件存储的差异化定位

除了结构化的业务数据，互联网行业还有大量用于展示的数据（淘宝商品图片、Facebook用户头像、微博内容），这类小文件有三个典型特征：单个文件小（一般1MB以下）、数量巨大（Facebook 2013年每天上传照片就达3.5亿张）、访问量巨大（Facebook每天访问量超10亿）。因为几乎每个业务都会产生大量小文件，如果每个业务各自设计海量存储和海量访问方案，效率必然低下、重复造轮子，因此自然要把小文件存储做成统一的、和具体业务无关的平台。和[[SQL存储的三阶段演进：从直接使用到中间件再到统一存储平台]]、[[NoSQL存储平台：节点数上千后才真正划算的三大功能]]不同的是，小文件存储不需要等到公司或业务规模很大才值得做，基本上业务在起步阶段就可以考虑统一存储——得益于开源生态的成熟，在HBase、Hadoop、Hypertable、FastDFS这类开源方案基础上封装一个小文件存储平台并不算太难，典型实现有淘宝TFS、京东JFS、Facebook Haystack。大文件则主要分两类：一类是业务本身的大数据（YouTube的视频、电影网站的电影），一类是海量日志数据（访问日志、操作日志、用户轨迹日志）；和小文件正相反，大文件数量不算多，但单个文件体积巨大（几百MB到几GB常见，几十GB甚至几TB也有可能），存储方式和小文件系统有本质差别，不能直接拿小文件存储系统来存大文件。大文件存储和处理领域的技术格局主要由Google和Yahoo奠定：Google的三篇大数据论文（Bigtable/MapReduce/GFS）开启了大数据时代，Yahoo开源的Hadoop系列（HDFS、HBase等）几乎垄断了开源界的大数据处理生态，后续虽然又涌现出更多优秀开源方案，但整体思路已经定型。正因为要照Google论文原样自研一整套大数据处理方案的难度和成本太高、而开源方案又已经足够成熟，大数据存储和处理这块反而是相对”最简单”的技术选型——因为可选项本来就不多，基本只能在Hadoop、HBase、Storm、Hive这几个主流开源方案里选，实力雄厚的大公司会在这些开源方案基础上结合自身业务封装成大数据平台（如淘宝云梯、腾讯TDW）。

结构图：

flowchart TB
  A["小文件存储"]
  A --> A1["特征：单文件小(<1MB)+数量巨大+访问量巨大"]
  A1 --> A2["门槛低：业务起步阶段即可做<br/>基于开源方案(HBase/Hadoop/FastDFS)封装即可<br/>(淘宝TFS/京东JFS/Facebook Haystack)"]
  B["大文件存储"]
  B --> B1["来源：业务大数据(视频/电影)+海量日志"]
  B1 --> B2["特征：数量不多但单文件极大(几百MB~几TB)<br/>不能直接复用小文件存储系统"]
  B2 --> B3["技术格局已定型：Google三篇论文奠基<br/>+Yahoo Hadoop生态垄断开源界<br/>选型反而'最简单'(只能在Hadoop/HBase/Storm/Hive中选)"]
  B3 --> B4["大公司在此基础上封装大数据平台<br/>(淘宝云梯/腾讯TDW)"]

内容

参考来源