分享
C/C++ 是否存在大数据生态圈，为什么？
现在一提起大数据，基本就等同于 Hadoop / Spark / Storm 等一系列 JVM 体系下的开源架构；而如果说要用 C/C++ 的话，基本就是还在造轮子的阶段，差距十分悬殊。是不是有一天也会像 Nginx 的诞生一样，在 Apache 如日中天的时候，有一个神秘的 C 高手团队造就了 Nginx 现在的地位。个人的臆想是，在 Linux 文件系统上再用 C 做一个文件管理层（据我了解阿里云和百度已经是这样干的），分布式通信可以借鉴 Thrift 这样的 RPC 框架，shell 层可以考虑使用 C++ / Python等相对敏捷的语言来实现，还有 MySQL、Redis 这样的亲戚可以一并拉入来实现部分文件索引工作。计算引擎方面，实现像 Spark 那样实时的流式计算，无非就是把数据和索引建在内存里，提供一些类似 MLlib 的算法包。任务调度和负载均衡可以借鉴 Nginx 然后根据实际计算需求加以平衡。曾经用 C++ 写过一个较为轻量级的分布式计算引擎，相比起 Spark 而言，时间性能提升1到2个数量级，内存减少四到五倍。但是为何业界还是一致地在追求 JVM 体系下的大数据架构？只是功利性地考虑了用人成本、技术成本、维护成本吗？或者是牛逼的企业已经做了，只是都不愿意公开？
回复 ( 10 )
请兹辞 DMLC Distributed (Deep) Machine Learning Common · GitHub
我其实不太懂大数据。只提一些个人看法。
不同的领域各个任务的优先级和当时的状况都不太一样。
C/C++的优势在于性能，缺点在于开发速度和难度。所以只有以性能为优先的场景，C和C++才会有足够的优势。更加具体的分析在这里：
纯C语言的工作有前（钱）景吗？ – 编程
但是这个阶段的大数据：需求没有完全实现，迭代速度快，热钱多，问题并行性很好对性能密度没有要求。所以显然 C/C++ 并不是什么很好的选择。
反观Nginx所针对的Web Server，已经褪去了高速发展期，需求已经相对稳定（也就是产品规划稳定），所以降低了C/C++开发的难度，同时大家也开始收缩这个方面的投入，有一个性能更高的软件也会减少硬件方面的投入，甚至还能解决一些不宜伸缩的部分的性能问题。
所以长期来看，我认为C/C++在Big Data中的推广，可能和Nginx一样，在大数据的热潮即将褪去的时候，给大家一个更具性价比和性能潜力的软件方案。
楼主这个设想非常不错，谷歌的三宝（GFS,MapReduce,BigTable）应该就是通过c++实现的，可惜就是不开源。
Scylla DB
性能优化,应该放在最后才做.
现在大数据领域,还在战国时代,百家争鸣,远远没有达到稳定,以我的了解,这个方向坑深的程度现在还远远没有到.反观题主说的apache/nginx的例子,那是在apache以及HTTP协议已经稳定多年,另外新的技术(epoll)出现的情况下,旧有 的apache还在采取一个请求一个线程的处理(对apache不算熟悉,如有错误请指出)的模型,所以才有了Nginx的横空出世.
而现在,在争夺话语权快速验证模型的情况下,显然开发效率/社区完善度是更重要的,几个先发的大数据相关软件已经占了先机,短时间还看不到拿C++来重写的可能.
java 把写大规模并发程序的难度降低了，但是把问题挪到了JVM上面，虽然内存分配省心了，但是问题在JVM上面表现出来了。
C++ 是写的时候难了，但是用起来爽
GO 的话，并发解决了， GC问题还是没解决 和java 一样一样的！
没能力用C＋＋写就苦逼着吧， 在nginx之前， 你们用apache 那么多年 不也都忍了吗？
补充一点：
如果系统性能的瓶颈不在语言上，没有必要用c和c++来写。如Haddop这种基于磁盘的批处理，基本上性能就卡在网络和磁盘IO上，为啥自找麻烦用c来写。
如果语言是瓶颈（如JVM系的会带来GC的开销），可以采取折中的方案阿，自己维护off-heap的storage（Spark的tungsten）。
另外，比较活跃的开源分布式系统大部分都是jvm系的吧，至少说明在性能和易用性方面大家都选后者。说明这点语言带来的性能开销大家还都能忍。啥时候不能忍了，就到了c/c++系的崛起的时候。
另外说到内存的计算引擎，如果真的在乎性能，就应该直接上MPI，让搞HPC的人来做。
cloudera自己的大数据生态就是C++的, 比如Impala,kudu
不是业界有C++的实现方案，Apache Mesos么？Apache Mesos
看了这问题和楼里的诸多答案。觉得阿里的飞天真是栽了。