【IT名人堂】专访京东架构师：海量数据的IT架构演变

duronshi

hadoop本身就有har文件（多个小文件压缩，凑够block-size）

全文看好像核心就是讲jfs，在hdfs上封装一层（块映射，阿里的就有这种，通过文件名进行块定位）

系统架构，没有涉及CDN，负载，想知道他们的高迸发是怎么实现的

xkf01

问点尖锐性的问题啊：
总所周知，最近支付宝宕了一个下午多。。。。后来的解释说是蓝翔的挖掘机太厉害，把光纤挖断了。。然后移机器换机房什么的 速度太慢。

求从京东的角度 看 到底是发生了什么情况，比较有可能会造成这么大的影响以及这么长的恢复时间？  另外，支付宝的事件也给我们敲了一次警钟，  京东现有的措施和方案是否已经百分百可以避免 这种情况的发生（发生简短的意外无所谓，但是长时间影响应用就不可接受了） ？

xkf01

“京东有海量的小于1MB的在线数据，这些对HDFS的扩展性和性能会带来严重的影响”
不是很明白，求详细的指教。。到底什么情况不适合

dafei3020

学习  学习

uu6088

trafguy 发表于 2015-6-1 23:05
很强大。
HDFS不适于随机读写和大量小文件，这是毋庸置疑的。不过大量的小于1M的小文件，是不是可以看作小 ...

JFS更多的定位在文件系统，所以跟HDFS对标。你提到的NOSQL比如HBase和Cassandra，也是小文件存储的一个解决方案。不过HBase在查询的时候，client请求先打到RegionServer，RegionServer再通过网络去HDFS取，相比Client直连存储节点多了一层网络开销。另外HBase最近没跟了，之前存在split操作的时候，不能提供服务等，这些对于在线服务都不是很适合。京东很多业务比如图片发布出去了，要求可以从任何一个副本立即能读到，所以采取强一致性模型，而没有选择类似于Cassandra最终一致性模型。

uu6088

xkf01 发表于 2015-6-2 16:06
“京东有海量的小于1MB的在线数据，这些对HDFS的扩展性和性能会带来严重的影响”
不是很明白，求详细的指教 ...

比如京东的一些业务每天可以产生千万，1年就是30多亿，这还只是一个业务，如果存在HDFS，会把Namenode内存撑爆

tangyuxint

trafguy 发表于 2015-6-1 23:05
很强大。
HDFS不适于随机读写和大量小文件，这是毋庸置疑的。不过大量的小于1M的小文件，是不是可以看作小 ...

M/R的编程思路主要就是这个吧

uu6088

duronshi 发表于 2015-6-2 12:36
hadoop本身就有har文件（多个小文件压缩，凑够block-size）

全文看好像核心就是讲jfs，在hdfs上封装一层 ...

HDFS个人觉得最适合的是离线大数据，文件数目超级大的话，会撑爆namenode的内存。而且HDFS的一个小文件，对应于存储节点磁盘上的一个文件。如果使用2T的盘，文件的平均大小1k，磁盘使用50%就存放了2000000000个碎文件

duronshi

uu6088 发表于 2015-6-2 17:35
HDFS个人觉得最适合的是离线大数据，文件数目超级大的话，会撑爆namenode的内存。而且HDFS的一个小文件， ...

首先明白hdfs存储机制。

namenode:记录对应关系，可以理解成文件分配表MBR

datanode:专门用于存储数据

Client取文件时都会从namenode上获取这个文件的datanode节点信息、block块信息，然后通过rpc从datanode上将文件数据取回来。

如果1K小文件多的话，在namenode上面的对应关系就会很多，这样对namenode很不利，所以hdfs默认block-size=64M，针对京东1K的图片文件，hadoop有har压缩机制（也就是说类似于我们常用的winrar），生成一个har文件后，记录har与1K小图片文件对应关系，用的时候从har里取回来就可以了，只是这样会增加cpu的压力。

俺想问的是他们是如何解决高并发？

缓存、CDN、负载

metaking

商品订单、库房记录 这些不是存在关系数据库中吗？ 那请问，你们哪些存传统数据库？哪些存成文件？有没有标准，方便的话透露下。