V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Livid
V2EX  ›  Hadoop

命令行工具用好了,在一定数据量下,不一定比 Hadoop 慢

  •  2
     
  •   Livid · 2015-01-18 17:20:18 +08:00 · 5557 次点击
    这是一个创建于 3633 天前的主题,其中的信息可能已经有所发展或是发生改变。
    21 条回复    2015-01-19 15:09:15 +08:00
    bombless
        1
    bombless  
       2015-01-18 17:30:12 +08:00
    xargs 大法好,退 Java 保平安。
    liprais
        2
    liprais  
       2015-01-18 17:35:17 +08:00
    "Hopefully this has illustrated some points about using and abusing tools like Hadoop for data processing tasks that can better be accomplished on a single machine with simple shell commands and tools. If you have a huge amount of data or really need distributed processing, then tools like Hadoop may be required, but more often than not these days I see Hadoop used where a traditional relational database or other solutions would be far better in terms of performance, cost of implementation, and ongoing maintenance."
    说的太好了....
    damngood
        3
    damngood  
       2015-01-18 17:36:24 +08:00
    还可以出一个 数据库 版本的
    est
        4
    est  
       2015-01-18 17:38:12 +08:00
    > Since the data volume was only about 1.75GB containing around 2 million chess games

    数据不比单机内存大就不要上hadoop啥的了。mmap啥的完爆所有工具。
    invite
        5
    invite  
       2015-01-18 18:04:17 +08:00
    hadoop ? 云计算那个? 这个本来就有它应用的局限性.
    hahastudio
        6
    hahastudio  
       2015-01-18 18:14:21 +08:00
    本来的,hadoop 启动起来就要花些时间,map 和 combine 也可以看成是“无意义”的时间消耗
    我觉得主要还是在于大数据被炒得很火,不管有没有那么多的数据都想耍一耍,提高逼格
    可你的数据一台机器就能放得下,为什么要用 hadoop 呢= =
    sivacohan
        7
    sivacohan  
       2015-01-18 18:28:52 +08:00 via Android
    任何一本讲并行计算的书都会提到一点。
    开销。
    指因算法并行化而相对串行算法产生的额外时间,空间。
    实际工程很多人都把开销自动忽略了。
    zhicheng
        8
    zhicheng  
       2015-01-18 18:43:05 +08:00
    可是这样就木有办法装逼了呀。
    glogo
        9
    glogo  
       2015-01-18 18:56:58 +08:00
    霸气!!!
    ob
        10
    ob  
       2015-01-18 19:04:01 +08:00
    @bombless
    这回复,让哥有一种深深的罪恶感。。
    nbndco
        11
    nbndco  
       2015-01-18 19:19:32 +08:00
    醉了,1.75G还要用hadoop……
    s51431980
        12
    s51431980  
       2015-01-18 21:44:27 +08:00   ❤️ 2
    不要单看数据大小,1G的图关系数据和1G的时间序列处理难度完全不一样,有些人既然不是这个领域就不要暴露自己的无知了
    adjusted
        13
    adjusted  
       2015-01-18 21:47:06 +08:00
    想起以前看过的“your data is not that big”
    binux
        14
    binux  
       2015-01-18 21:53:02 +08:00
    1.75G,12秒。。。别闹
    9hills
        15
    9hills  
       2015-01-18 22:35:38 +08:00 via iPad
    看了下,作者意识到数据是流式的,所以没用Hadoop
    monkeylyf
        16
    monkeylyf  
       2015-01-19 01:30:46 +08:00
    1.75gb用hadoop确实overkill了 尤其是这种仅仅是最简单的mapreduce
    235xfaster这种数字拿出来不怕被人打脸吗
    yuankui
        17
    yuankui  
       2015-01-19 09:23:11 +08:00
    当数据量到达 TB,PB级时再说吧。。
    hadoop本来就不是用来处理GB级数据的。。
    liprais
        18
    liprais  
       2015-01-19 12:32:40 +08:00
    oneoo
        19
    oneoo  
       2015-01-19 13:21:17 +08:00   ❤️ 1
    抛个题:UPYUN.com 的CDN系统有超过1000+台服务器的访问日志,总量800GB~1TB压缩内容,里面包含有10w个域名的URL,业务需要把这些日志按域名切分好,以提供给客户下载,另外再附加一个统计分析业务,分top1000 URL,top1000 referer, top1000 useragent, top1000 文件大小。

    你觉得:
    这是大数据吗?
    需要Hadoop等分布式处理吗?
    这个处理集群大概要多少台物理机?
    有更好的方式吗?
    zhimingcc
        20
    zhimingcc  
       2015-01-19 14:35:44 +08:00
    因为问题多样性,技术也应该多样性,不应该只用一种技术解决不同的问题,软件工程师们应该有更灵活的方案,不应该重复用一套轮子。。。。
    问题是,对各种技术理解深刻的软件工程师多么?
    xderam
        21
    xderam  
       2015-01-19 15:09:15 +08:00
    @oneoo 我感觉用前端机在业务低估(比如晚上),处理这些数据然后汇总比较好一些..
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2853 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 14:03 · PVG 22:03 · LAX 06:03 · JFK 09:03
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.