大数据江湖之即席查询与分析(上篇)--即席查询与分析的前世今生

原创 2017年03月05日 12:04:43
如今,大数据领域新技术层出不穷,可谓百家争鸣,甚是红火。不乏有些玩家动辄搞出个大数据平台,可谓包罗万象,号称无所不能。小弟则以为在大数据江湖中如能修炼好独门绝技,有能拿得出手的看家本领已然实属不易。小弟有幸从2010年投身于大数据,并先后就职于阿里和腾讯,见过世面之后,自知才疏学浅,仅专注于大数据即席查询与分析技术。在此将多年所学所做汇聚成文,留下“大数据江湖之即席查询与分析”三部曲,为大数据即席查询与分析的后来者所用。
       提到大数据即席查询与分析,各位同学可能心中会画下一个问号,大数据即席查询与分析是个什么鬼?小弟我这里想先强调是,大数据中的“量(Volume)”,由于每个人所接触的工作环境和业务场景的不同,大家对大数据中“量”的理解可能有所不同。小弟处理的或者说所瞄准的数据量级为万亿总量,每天千亿增量,这样一个级别。小弟也真正在老东家搭建过几百台节点的集群的生产系统,处理过这个级别的数据;创业之后,协助客户和合作伙伴搭建过若干个几十台、上百台的集群,数据量也多则千亿,少则几十亿到数百亿不等。令小弟欣喜的是大数据真正在互联网行业以外的各个行业被逐步应用起来,这激励着小弟在创业路上不断前进。
       之所以要强调这个“量(Volume)”,一个原因是有不少伙伴由传统IT转来做大数据,很多业务系统多以OLTP为主,尤其以Oracle,MySQL什么的,数据量级多在几十万到数百万条,数据过了千万,恐怕就要分库分表了,过了亿级,即便再牛逼的硬件,再牛逼的DBA去优化,恐怕其性能就不能尽如人意了,有时候即便做个常规GroupBy,TopN都要累的要死,更不必说模糊检索,复杂查询,多维分析,数据碰撞之类的了,这个倒不是说这些技术和产品有多差,OLTP毕竟被设计用来做在线事务处理,这种OLAP干的活,交给大数据技术来处理就显得轻松的多。Google的三篇论文,GFS、Bigtable、MapReduce,可为大数据发展的基石,大数据生态基于此枝繁叶茂,发展出各个门派,让我们面对如此“量”的数据具备了存的下,管的了,算得出的能力。
        强调这个“量(Volume)”另外一个原因是,小弟创业这几年越发感到,随着物联网,智能硬件,移动互联网等技术蓬勃发展,在不知不觉中,你的位置数据,你支付的每笔交易,你所购买的商品及服务,你所搜索的每一个关键字,你在网站或APP上每一次操作,你的每一句网络聊天、吐槽评论,甚至你的每次电话交谈都在被时刻记录,还有数都数不清的各种传感器采集着各种数据、状态,每一个人正在被打上成百上千的标签,甚至每一个物体都跑不掉,无论是一台自行车还是家里的小猫小狗。这背后是我所关注的大数据的“量(Volume)”,这些数据确实为各行各业带来了无限的价值,当然也给各行业使用这些数据带来了诸多挑战。
       前文已经提到,受益于大数据生态的发展,尤其是Hadoop相关技术的走向成熟, Hadoop被越来越多的应用于生产系统,这是一个重要的里程碑,标志着Hadoop的稳定性,可靠性,可维护性,易用性等种种指标已经达到了商用的级别,已不再是社区爱好者玩玩的工具了。每一分每一秒,各个数据源通过在线,离线等各种方式导入Hadoop,这些数据就像一车车的金矿石,先被放到一个巨型的仓库中存了起来。发现金矿,采集矿石,运回仓库,这些过程可能都不是最精彩的,大家最期盼的是如何将矿石变成金子,也就是“炼金”。
       大数据“炼金术”,发现数据的潜在价值,从数据分析的不同使用场景来看,可以分为以下三类:批处理(Batch),即席查询与分析(Ad-hoc),流计算(Stream)。
       批处理通常是离线计算,对计算时效性要求不高,主要用来啃又大又硬的骨头,一个任务可以撇给它几十个T甚至上P的数据,它都吃得消,它的计算方式可以说是“很稳健”,无论是第一代计算引擎MapReduce,还是第二代计算引擎Spark,都是采取的“很黄很暴力”的方式,一个百亿规模的数据分析,MapReduce的计算时间可能长达数小时,Spark也要跑个几分钟到几十分钟不等,即便执行一些相对轻量级的数据分析请求,Spark通常也是在分钟级别完成。
        再来看流计算,流计算是在数据流入的同时即把相应的计算操作完成,有极高的时效性,非常适用于实时统计,根据预设规则预警,结合各种算法做预测等数据分析需求,在各类系统中已经应用非常广泛。但流计算本质属于预计算分析,必须预先知道想要统计分析的数据或维度,跟业内其他预计算引擎的短板一样,就是灵活度受到了极大限制。
可能有的小伙伴要问了,难道就没一个计算引擎,既有很高的时效性,又有很高了灵活性的计算引擎?她可以让我们自由地驰骋在大数据的海洋中,从海量的数据中尽情地发挥数据分析师的想象力,我问一句,它答一句,想查什么就查什么,想算什么就算什么,不让宝宝们等太久,秒级响应各种数据查询及分析请求的计算引擎?她可以让各行业的大数据应用系统能够实现真正的交互式大数据查询分析功能,让业务人员、分析人员及行业专家时刻发现大数据背后的潜在价值,或使其工作效率倍增,或协助精准决策,或创造更多财富,或保一方平安!这就是小弟这七年间只做的一件事—即席查询与分析;即席查询与分析的计算模式兼具了良好的时效性与灵活性,是对批处理,流计算两大计算模式有力补充。
       从阿里的Mdrill,到腾讯的Hermes,再到延云的YDB,小弟始终坚持瞄准一个目标,就是打造业内首屈一指的“万亿数据秒级即席查询与分析引擎”。七年的积累和付出是值得的,延云已经看到,即席分析的业务场景正在应用于各行业的生产系统,尤其在互联网,公共安全,交通,电信,金融,车联网等领域有着极为强烈的需求。
       在下一篇里,小弟就要通过列举几个真实的项目案例,与各位小伙伴分享一下即席查询与分析在几个典型行业的应用。

大数据江湖之即席查询与分析(下篇)--手把手教你搭建即席查询与分析Demo

上篇小弟分享了几个“即席查询与分析”的典型案例,引起了不少共鸣,好多小伙伴迫不及待地追问我们:说好的“手把手教你搭建即席查询与分析Demo”啥时候能出?说到就得做到,差啥不能差人品,本篇只分享技术干货...

大数据江湖之即席查询与分析(上篇)--即席查询与分析的前世今生

如今,大数据领域新技术层出不穷,可谓百家争鸣,甚是红火。不乏有些玩家动辄搞出个大数据平台,可谓包罗万象,号称无所不能。小弟则以为在大数据江湖中如能修炼好独门绝技,有能拿得出手的看家本领已然实属不易。小...
  • vv8086
  • vv8086
  • 2017年02月20日 17:16
  • 1699

大数据江湖之即席查询与分析(中篇)--即席查询与分析的典型场景

上篇提到了大数据做数据分析的三种最为典型计算模式:批处理(Batch),即席查询与分析(Ad-hoc),流计算(Stream);对于批处理和流计算,虽然小弟也略知一二,早在Hive还没出来之前,也是从...

大数据江湖之即席查询与分析(中篇)--即席查询与分析的典型场景

上篇提到了大数据做数据分析的三种最为典型计算模式:批处理(Batch),即席查询与分析(Ad-hoc),流计算(Stream);对于批处理和流计算,虽然小弟也略知一二,早在Hive还没出来之前,也是从...
  • vv8086
  • vv8086
  • 2017年02月20日 22:59
  • 1106

大数据江湖之即席查询与分析(下篇)--手把手教你搭建即席查询与分析Demo

上篇小弟分享了几个“即席查询与分析”的典型案例,引起了不少共鸣,好多小伙伴迫不及待地追问我们:说好的“手把手教你搭建即席查询与分析Demo”啥时候能出?说到就得做到,差啥不能差人品,本篇只分享技术干货...
  • vv8086
  • vv8086
  • 2017年02月25日 17:35
  • 544

大数据前世今生

  • 2016年03月08日 09:02
  • 8.69MB
  • 下载

大数据的前世今生

  • 2014年05月23日 14:27
  • 134KB
  • 下载

浅谈数据分析师的前世今生

作者:Jo(qq:790964489),66team原创专稿,未经允许不得转载。 “小明,听说你是数学专业出身的?” “是的,领导。” “那你去把这些手抄报表录入到电脑里去。” ...

大数据学习-Spark前世今生

1、大数据体系结构概览: (1)注意Spark可代替Hadoop的哪些部分2、Spark整体架构 Spark Streaming:实时计算 GraphX:图计算 MLlib:机器学习3、Spa...

Spring事务管理的前世今生(转载于IT江湖)

1 Spring 事务属性分析 事务管理对于企业应用而言至关重要。它保证了用户的每一次操作都是可靠的,即便出现了异常的访问情况,也不至于破坏后台数据的完整性。就像银行的自助取款机,通常都能正常为客户...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:大数据江湖之即席查询与分析(上篇)--即席查询与分析的前世今生
举报原因:
原因补充:

(最多只允许输入30个字)