【IT168 评论】在笔者持续调研国内Hadoop生态系统生存现状的同时，KDnuggets发布的2018年数据科学和机器学习工具调查报告再次将“Hadoop失宠”言论复活。报告一出，“Hadoop被抛弃”几个字瞬时成为各大标题党的最爱，充斥在不同的新闻平台。这些报告和数据是否足以动摇Hadoop在国内大数据领域的事实标准地位?本身并不擅长处理OLAP计算和ms级延迟要求的流计算，这是否会成为企业弃用Hadoop的重要原因?对于繁多的组件和搭配，企业倾向于哪种组合方式呢?

▲2018年数据科学和机器学习工具调查报告，Hadoop使用率下降35%

　　本期走访对象：苏宁易购。作为新一代B2C网上购物平台，经过了多年大小促的流量高峰考验，苏宁易购的大数据平台是如何搭建的?对于Hadoop生态的各类组件，苏宁易购如何取舍呢?

　　苏宁易购决定选用Hadoop：成熟、稳定、成本可接受!

　　大部分企业在进行技术选型时都会考虑成本与需求，迫切地希望知道同类型企业的选型方案，最终对可能的几大方案进行全方位调查，得出非常符合企业自身业务发展诉求的方案。苏宁易购首先考察了Hadoop生态与自身业务需求的契合度，Hadoop可靠、易扩展，集海量数据存储和计算于一体(正如Apache Hadoop项目官网所描述的)。从成本方面来看，Hadoop开源免费，不需要支付昂贵的商业软件成本，虽然需要额外的人力成本来维护和优化，但相对来说比较少，拥有强大的开源社区支持，目前github上已有7.3K的star。

　　当苏宁易购2013年开始搭建大数据平台时，Hadoop已经成为大数据领域的事实标准，早已在国内外大型互联网公司投产稳定运行多年，相对来说比较成熟，而且确实可以解决苏宁易购海量数据存储和分析需求，Hadoop便顺理成章成为苏宁易购大数据体系的基石。

　　在具体搭建过程中，苏宁易购使用HDFS作为海量数据存储系统;HBase作为表格存储系统，提供在线实时读写;YARN作为统一资源管理系统，为离线和流式计算提供资源调度服务;Hive/SparkSQL作为离线SQL分析主力，小部分无法用SQL描述的需求用MR/Spark补充;SparkStreaming作为准实时计算引擎提供服务;以Spark MLLib为基础扩展算法包，支撑整个机器学习平台。

　　Hadoop生态虽然足以应对海量数据存储和离线分析场景，但对于秒级延迟要求的OLAP计算和ms级延迟要求的流计算场景却无能为力，这也成为很多人看衰Hadoop生态的原因之一，当然目前也没有任何一个平台能完美应对以上所有场景。

　　组件级竞争激烈，Spark优势明显，容器兴起再掀风波!

　　所谓无风不起浪，Hadoop生态看似稳固，但其组件级别的竞争相当激烈，Spark和Flink成为强劲对手。苏宁易购认为，HDFS作为海量数据的存储系统，具有非常高的可靠性和易扩展性，一直以来表现稳定，在大文件存储和分析领域，市场上还没有能够替代的产品;HBase在KV存储领域占有绝对优势，特别是大规模数据集场景几乎是必选方案，在GB-TB的数据规模下，Redis和其他内存数据库被普遍使用;ZooKeeper作为分布式协调系统，被大规模广泛使用，依然拥有很强的生命力;YARN与Mesos在分布式资源调度领域竞争由来已久，在不同领域各有建树，YARN毕竟根源于Hadoop，已是Hadoop生态标配，随着容器的兴起和广泛使用，Swarm和Kubernetes也加入资源管理领域的竞争，使这个领域的竞争更加激烈。

　　Spark作为内存型计算框架，其先进的理念、优秀的性能表现对MapReduce冲击很大，MapReduce两阶段的计算特性虽然简化了程序开发的难度，但引入了过多磁盘、网络IO和任务启停开销，成为过去已是必然，特别是SparkSQL，基本让Hive的底层计算引擎MR无立足之地，苏宁易购也一直在推进SparkSQL替换HQL的工作，但Hive作为数据仓库的功能基本不会被替换。

　　Spark作为Hadoop生态系统中的重要组件，在大数据计算领域依然不可或缺，Spark SQL, Spark MLLib已被广泛应用。但是，苏宁易购认为，Spark目前只是作为计算引擎存在，数据存储还需要依靠HDFS，S3，Ceph等系统。未来的资源肯定要统一管理，只有资源集中管理、统一调配才能充分被利用，即使不On YARN模式运行，也会on Mesos或者on Kubernetes之类的系统去运行。至于资源统一管理带来的隔离性要求，这是YARN、Mesos们要考虑的问题。苏宁易购计划在下半年启动统一资源管理项目，将流计算、离线计算资源统一管理调度，预计能节省30%左右的机器成本。

　　此外，Flink作为近几年出现的计算框架，与Spark比较相似，都期望提供流处理、批处理统一API编程模式，但两者看问题的角度完全不同。Spark最先发力批处理，后做成微批处理实现流计算，而Flink从一开始就面向流计算，将数据看成Unbounded，将批处理当做流的一种特殊情况。基于此，目前Flink更多的被用在流计算领域，比如阿里深度定制的Blink已成为其内部主流的流处理框架。从设计角度来说，Flink也有很多亮点，比如支持Event-Time，支持Exactly-Once的处理语义，支持分布式异步checkpoint等。苏宁易购目前内部主推Flink，期望能替代有点老迈的Storm。

　　目前Flink刚刚发布1.5版本，修复了很多Bug，新增了很多特性，比如对SQL和Table的增强，优化了网络栈;社区也比较活跃，共有3700多个star，保持5个月左右一次大版本发布的频率。在流计算领域，Flink绝对是强有力的竞争者。

　　Gartner看衰言论解读：看事情的角度不同可能造成结果差异!

　　经过十多年的发展，Hadoop已经比较成熟且运行稳定，生态也相对完善，在海量数据存储和分析领域已经成为事实标准。至于Gartner的唱衰论调，苏宁易购认为，Hadoop就好比日常生活中的水电煤，因为太普遍反而引不起特别关注，或者，Gartner报告中所说的Hadoop是指狭义上的Hadoop，也就是原始的HDFS和MapReduce组合。如果单看这两大组件的发展，MapReduce确实在逐渐退出舞台，被Spark/Flink所取代。

　　苏宁易购认为，Hadoop失宠前提一定是出现更强大的可替代大数据解决方案，现在来看，并没有这样的方案出现。存储和计算领域确实持续出现了一些受追捧的新组件，比如OLAP领域的Druid和Clickhouse，就是用来弥补Hadoop在海量数据多维实时分析场景下的不足。比如Flink，采用流处理、批处理统一API编程模式解决两种模式、两种API带来的不统一、编程门槛高等问题。

　　短期内，苏宁易购没有颠覆性调整大数据底层平台架构的计划，仍然以Hadoop生态系统为核心，并对Hadoop的未来充满信心，但会在一些Hadoop覆盖不到的场景中引入其他组件并持续投入，比如Druid\Elasticsearch。

　　笔者点评：

　　在前期的多份采访中，笔者曾一再表明，Hadoop的关注度确实在下降，而关注度确实是Gartner报告的一个重要考察因素。但是，KDnuggets报告明确表明Hadoop的使用率也在下降。当然，这两大报告的受访主体以美洲和欧洲用户为主，亚洲用户参与率较低，这也是前期不少用户在评论区留言表明国内外数据量的规模差异是造成该结论并不适用国内的重要原因。到底多大的数据量可以被称为大数据，这个标准在国内外确实是有差异的。如果数据量不大，确实可能对Hadoop没有需求，但国内的数据量显然大于国外，这可能是国内对Hadoop需求较大的重要原因。

　　其次，Hadoop生态内组件级别的替换淘汰是很正常的，但这暂时还不会上升到生态层面。正如苏宁易购所言，在没有更加强大的替代品出现之前，Hadoop生态的地位依旧稳固。