【大话IT】海量数据处理最令你心烦的是什么？

王楠w_n

话题背景：

云计算与大数据为计算机科学领域注入了前所未有的活力，而大数据的实时处理更是为海量数据处理和数据挖掘带来了崭新的契机。从某种意义上讲，传统大数据的批处理方式已经一定程度上解决了我们所面临的问题，然而，客户的要求是永不满足的。他们想要更多的数据、服务、价值以及更多的便利。随着数据量的增加，对实时响应时间的需求也在提高，原本承载着海量数据处理任务的批处理系统在实时计算处理方面越发显得乏力。

这么说的原因很简单，像Hadoop使用的MapReduce这样的数据批处理技术，其设计初衷并不是为了满足实时计算的需求。数据批处理系统与实时处理系统在需求上存在着本质的区别。要做到实时性，不仅需要及时地推送数据以便处理，还要将数据划分成尽可能小的单位，而像HDFS存储推送数据的能力已经远不能满足实时性的需求。

Apache Storm的出现扭转了传统数据批处理系统的劣势，成为了真正意义上的实时数据处理系统。Storm实时处理系统实现了一个可靠的、高容错性的实时分布式处理平台，那么这些听起来十分抽象的概念到底是如何实现的呢？

今天，我们一起聊聊关于分布式实时处理系统是如何部署实践的？


讨论问题：

1.大家都在哪些场景中需要处理大量的数据？处理这些数据最令人心烦的事情是什么？
2.大家都使用过哪些工具来处理大量数据（比如Hadoop、Spark、Storm，什么类型的都可以）？具体是如何运用的？
3.请大家结合自己的实际工作吐槽一下对这些工具有什么不满的地方，希望他们做出什么改进。
4.在你们的应用场景中，你们觉得处理性能和工具接口的易用性哪个更重要？
5.在实际工作中有遇到过对大量数据处理的实时性要求非常高的场景吗？如果有你是怎么解决的


活动时间：2016年7月26日——8月26日


活动奖励：

话题结束后，我们将选取5个优质回复，各奖励技术图书《分布式实时处理系统：原理、架构与实现》一本。



作者： 卢誉声   
丛书名： 大数据技术丛书
出版社：机械工业出版社
ISBN：9787111539964
上架时间：2016-6-23
出版日期：2016 年6月
开本：16开
版次：1-1
所属分类：计算机 > 数据库 > 数据库理论 > 分布式数据库

内容简介：
全书分为3篇：第一篇详细讲解本书将要开发的分布式实时计算系统所涉及的相关技术，特别针对C++11的新特性着重介绍。第二篇剖析分布式计算系统编程细节，其中对每个重要的概念、模型和函数都加以阐述。第三篇主要关注实战用例，将编写数个极具实践价值的应用程序，为开发者提供参考。通过阅读本书，读者不仅能开发出一套基于C/C++实现的分布式实时计算系统，而且还可以以此学习和了解服务器编程接口设计以及UNIX服务器开发的多个重要主题，对未来实际应用与开发提供参考。

样章试读： 文前.pdf (865.84 KB, 下载次数: 37)

2016-07-26 15:55 上传

点击文件名下载附件

——————————————————————————————————————————————————————

参与以上话题讨论，更有机会获得SACC 2016大会门票一张哦~

只为一场完美的技术盛宴！

作为国内最受欢迎的架构师盛会，一年一度的中国系统架构师大会将于10月27-29日在北京万达索菲特大饭店撼世来袭！

大会以"架构创新之路"为主题，云集了国内外顶尖专家，共同探讨云计算和大数据等技术背景下，如何通过架构创新及各种IT新技术来带动企业转型增效。本届大会共设置两个主场分享时段，24个技术交流专场时段；邀请来自互联网、电子商务、金融、电信、政府、行业协会等20多个领域，150多位技术专家及行业领袖来分享他们的经验；并将吸引4000多名系统运维、架构师、及各种企业的IT决策人士参会，为他们提供最具价值的交流平台。

【大会详情】

官网链接：http://sacc.it168.com/

欢迎扫码关注SACC官方微信，获取最新信息！

laputa73

1.大家都在哪些场景中需要处理大量的数据？处理这些数据最令人心烦的事情是什么？
  一类是日志处理场景，基本以es为主，也是坑很多，开始经常出现节点挂，master阻，集群全挂的情况。
  二是更海量的日志加工计算场景，计算逻辑不复杂，特点是数据量吞吐大，目前以hadoop+pig为主。部分辅以spark.槽点同上，集群上100,每天出状况。
机器挂，机架挂，机房挂。。。。每天都在干运维的活。
2.大家都使用过哪些工具来处理大量数据（比如Hadoop、Spark、Storm，什么类型的都可以）？具体是如何运用的？
   简单批处理,性能要求不高，pig脚本还是比较方便。可惜pig没有计算逻辑，扩展自定义函数就失去灵活优点了。
   spark很好，可以scala,也可以python,但是数据在hdfs里，要加载进rdd，总觉得多一道。而且搞不好，集群也容易挂。
   storm,流计算，目前没啥应用。感觉必需配合kafka,先汇聚在分离。 现在比较倾向spark streaming.
3.请大家结合自己的实际工作吐槽一下对这些工具有什么不满的地方，希望他们做出什么改进。
  安装维护复杂，使用门槛高，希望演进为开源的一体化工具，而不是平台或者系统。最好应用层和java解耦。脚本，sql最好。写java代码，头疼。
  多数就是把grep,awk,sed perl单机干的活扩展到集群而已，搞得那么复杂。
  希望未来的大数据处理看起来就像是现在单机linux,直接对hdfs上的各个目录文件直接进行操作。需要复杂处理的，就弄个表映射，sql一下。
4.在你们的应用场景中，你们觉得处理性能和工具接口的易用性哪个更重要？
  性能是第一位的，硬指标，满足基本性能要求的前提下，易用性更重要。
5.在实际工作中有遇到过对大量数据处理的实时性要求非常高的场景吗？如果有你是怎么解决的
  没有。一般分钟级,s级足够，没有变态到ms级的。分钟以上的mr, s级的如即席查询，es.spark.

heguangwu

1.大家都在哪些场景中需要处理大量的数据？处理这些数据最令人心烦的事情是什么？
   日志数据、实时业务数据，这些数据最烦心的是不一致，各种日志数据不一，业务数据格式多样，夹杂大量错误数据和不(很)可(难)解释的数据

2.大家都使用过哪些工具来处理大量数据（比如Hadoop、Spark、Storm，什么类型的都可以）？具体是如何运用的？
   基本上就是kafka->storm->hbase  ===>hdfs->mapreduce->hive
   数据全部通过kafka来分发，一部分数据经过storm实时处理后写入到hbase中，另外经过kafka(经过flume或其它类似工具)到hdfs由MAPREDUCE处理(类etl操作)入hive表

3.请大家结合自己的实际工作吐槽一下对这些工具有什么不满的地方，希望他们做出什么改进。
   坑多，还是存在各种bug，易用性也不好，各种新老版本的配置参数变化太快，没有统一的参数调优指南

4.在你们的应用场景中，你们觉得处理性能和工具接口的易用性哪个更重要？
   看场景，一般情况下易用性更重要，但某些场合性能要求更高，尤其是不能提加硬件需求的情况下

5.在实际工作中有遇到过对大量数据处理的实时性要求非常高的场景吗？如果有你是怎么解决的
   一般storm足够解决，当前还没有遇到过其不能解决的，当前我们实时性要求本来就不高

yehuafeilang

1.大家都在哪些场景中需要处理大量的数据？处理这些数据最令人心烦的事情是什么？
    处理最多的还是交易流水、日志，包括系统日志、业务日志等；在具体的业务场景中，我们会用到诸如用户查询量，交易量，不同业务种类下的，业务量的一个排序，令人比较头疼的是，在巨大的数据量下，我们不可能在传统数据库中用个sql查询就了事，那样一天的数据量都够人查的了，而且，像日志数据也不可能记入库中，这个时候就需要用到数据仓库，那这个时候问题又来了，像日志文件这些结构化的数据可以映射为数据库表，那交易流水数据咋办？如何导入数据仓库中又是一个问题。

2.大家都使用过哪些工具来处理大量数据（比如Hadoop、Spark、Storm，什么类型的都可以）？具体是如何运用的？
    最先是用改造过的阿里的宙斯系统，它实际上也是基于hadoop的，任务调度用的zookeeper，水平有限，只能在现成的平台上进行修修补补的改造，坚持到了现在。

3.请大家结合自己的实际工作吐槽一下对这些工具有什么不满的地方，希望他们做出什么改进。
    就像在回答第1个问题时提出的，能有个有效快捷的方法将传统数据库里的数据方便的导入到数据仓库中（我们用的是Hadoop生态系统的Hive数据仓库），还有就是最好是能够对我们现有的系统进行无缝衔接。

4.在你们的应用场景中，你们觉得处理性能和工具接口的易用性哪个更重要？
   都很重要，要选的话我们还是倾向于工具接口的易用性，因为性能再强大，一点也不友好，还是不愿意去使用的。

5.在实际工作中有遇到过对大量数据处理的实时性要求非常高的场景吗？如果有你是怎么解决的
   目前我们主要还是用于数据分析跟数据挖掘，还没有遇到对大量数据处理的实时性要求非常高的场景。

chenxing2

1.大家都在哪些场景中需要处理大量的数据？处理这些数据最令人心烦的事情是什么？
   一个场景是分析网站的跳出率（这类的）、查询条件的使用（因为加了好多，要分析用户实际怎么使用的，然后做优化）、根据用户常使用的功能给用推荐一些相似功能，以及一些数据。
   现在是处理移动端APP的操作日志。
   最心烦的是，要各个纬度、各种数据的统计....

   最最心烦的是，日志里加了个啥啥东西，统计又要加新的，或者改........

2.大家都使用过哪些工具来处理大量数据（比如Hadoop、Spark、Storm，什么类型的都可以）？具体是如何运用的？
   hadoop只是用来存日志文件的
   Storm用来实时计算结果的，结果存到关系型数据库中，直接用于查询统计
   flume用来收集日志
   kafka用缓冲日志消息

   APP每隔一段时间上传一个日志文件，服务器收到后写入一个目录。
   flume实时将日志文件发送出去，一个sink发送到hadoop存储，另一个sink发送到kafka，用于实时计算
   Storm从kafka拿数据，里面各种任务计算，但都是按照单个文件来统计计算的，不能混了。很多APP上传日志文件，最终会交叉到一起，所以用Storm处理，能按照单个文件来处理，之前是打算用Spark的，但是没找到解决方案。
   计算完结果，定时刷到DB中

3.请大家结合自己的实际工作吐槽一下对这些工具有什么不满的地方，希望他们做出什么改进。
   只是在表面用一下，未涉及太多，暂无不满的地方

4.在你们的应用场景中，你们觉得处理性能和工具接口的易用性哪个更重要？
   这俩其实都很重要，相比起来，还是易用性更重要些。
   之前试用过Zeroc ICE，说多么多么好，但用起来太费劲，直接没兴趣了.....

5.在实际工作中有遇到过对大量数据处理的实时性要求非常高的场景吗？如果有你是怎么解决的
   主要是APP操作日志分析，统计浏览时间、学习时间、某些功能的使用情况等等，这些要求能试试查看的。但毕竟不是业务系统，出点差错也没啥关系
本身这个日志有时上传也不是实时的

zhlin0054

1.大家都在哪些场景中需要处理大量的数据？处理这些数据最令人心烦的事情是什么?
主要是处理在医疗卫生的数据，最令人烦心的主是要电子病历的各种描述文字的处理，对于非结构化的数据处理起来费时费力，而且效果不是很理想。数据处理的效率偏慢，用户对数据的及时性不满意，目前对时间片断的最小只能以10分钟为单位且取得一小部分的业务数据信息，先满足关键活动的需求。

2.大家都使用过哪些工具来处理大量数据（比如Hadoop、Spark、Storm，什么类型的都可以）？具体是如何运用的？
Kettle是一款国外开源的ETL工具，主要处理一些文件如TXT，CSV，HTML格式的导入到数据表中，然后再利用SQL语句对数据进行二次的加工清理、统计处理。整体的运行效率也是很慢的。唯独比较好的就是作业流过程很清晰。目前自己在也自学Hadoop，后续也打算能加一些专业的培训学习以增强自己的能力水平。

3.请大家结合自己的实际工作吐槽一下对这些工具有什么不满的地方，希望他们做出什么改进。
首先是运行的效率低，业务任务无法并行执行，也无法多线程或多任务执行，更不用谈分布试的处理，目前采用的变通方法就是将不同的作业任务部署在不同的机子上，这个就服务器1执行A,B,C三个任务，服务器2执行D,E,F这三个任务……，任务的分配基本上在前期基本就是依靠经验来测算哪几个任务的用时是多少，把任务分成几组完成时间差相近的组，在执行一两个月后再根据运行日志分析，调整任务的分组情况，工作量很大，效果也不理想。其次相对比较复杂业务关系也是很难配置出来的，特别是多任务完成后才能执行下一任务的情况很难满足。

4.在你们的应用场景中，你们觉得处理性能和工具接口的易用性哪个更重要？
从用户体验来说性能更为重要，实时性要求高的必然对性能提出很高的要求，因为产品作出来是给用户使用，用户的体验是首要的，体验佳的用户为你说好，这才是最好的广告。工具的接口更多是给技术或工程人员使用的，这块有经过专业的培训后虽然易用性差一些，但不影响用户体验，另外技术或工程经常用一用也能熟能生巧。

5.在实际工作中有遇到过对大量数据处理的实时性要求非常高的场景吗？如果有你是怎么解决的。
实际中有遇到过这种情况。目前更过是建议用户有业务数据的备份服务器，一般就从备份服务器上获取数据，获取得数据也是由多台服务器同时处理，但每个服务处理的任务是不一样的，其实就是将任务分组后划分给不同的服务器去执行只能是一种伪分布，与真正意义上的分布式差距很大。

hellioncu

一看到海量数据、分布式这几个词，我下意识的以为这本书是Java相关的，仔细一看居然是C＋＋，难得。
实际工作中遇到的数据量不算很大，一天也就千万条这个级别，主要的挑战在于时间分布不均衡，对实时性要求高，每笔要求毫秒以内，越快越好，这样基本只能在内存中玩了。另外对可靠性要求也高，发生故障最好能不丢数据。有些基本是不可能的事情，只能在两者之间做取舍。

shang2010

最简单，最精辟，的一个字，穷

fenyun689

java 还没搞明白。C++更别说了，太深奥了。
学过Hadoop。

ning_lianjie

基于日志分析的需求,比较流行的方案应该算是ELK吧

王楠w_n

去年架构师大会有听过日志方面的演讲，但是具体的没怎么听懂回复 5# ning_lianjie


   

forgaoqiang

处理速度跟不上 服务阻塞 甚至导致其它业务停顿

大西瓜和大白菜

没钱啊 要不也是买买啊

sjf0115

我们部门最重要的就是数据，通过收集并分析数据，最终实现个性化推荐。这一点实时性要求比较高，因此使用的是spark。
同时，我们没有自己的产品，只能充分挖掘数据的可利用价值，分析用户行为数据，这一点对实时性要求不是很高，我们一般都是hadoop。

1.大家都在哪些场景中需要处理大量的数据？

市场预测、个人化商品推荐、老顾客维护CRM、改善消费者购物体验等应用。在我们这，主要是个性化推荐，通过大数据技术，可以为你量身 定制、进行个性化的推荐。因为你的所有需求，都可以被大数据“预测”出来，这种个性化的推荐，能够节省你在原来的生活方式中需要花费大量时间和精力去处理的繁琐工作，从而在提升生活效率 的同时，提升你的生活品质。   

2.请大家结合自己的实际工作吐槽一下对这些工具有什么不满的地方


（1）Hadoop非常受欢迎的理由在于，我们可以自由的下载、安装并运行。由于它是一个开源项目，所以没有软件成本，这使得它成为一种非常吸引人的解决方案，用于替代Oracle和Teradata。但是一旦进入维护和开发阶段，Hadoop的真实成本就会凸显出来。

（2）人们期望Hadoop可以圆满地解决大数据分析问题，但事实是，对于简单的问题Hadoop尚可，对于复杂的问题，依然需要我们自己开发Map/Reduce代码。这样看起来，Hadoop与使用J2EE编程环境开发商业分析解决方案的方式别无二致！

（3）Pig和Hive都是设计精巧的工具，它们可以让人迅速上手，提高生产力。但它们毕竟只是一种工具，用于将常规的SQL或文本转化成Hadoop环境上的Map/Reduce查询。Pig和Hive受限于Map/Reduce框架的运作性能，尤其是在节点通信的情况下（如排序和连接），效率更为低下。