我每天都在思考,思考很重要,是一个消化和不断深入的过程。正如下面的一句话:
那么延生出来,我们有没有想过大数据本身?大数据到底是在做什么,为什么我做了这么多年的大数据,总是做不完呢?大数据本质是:
机器学习的本质是:
大数据最消耗工作量的地方是哪里呢?目前百分之八十的工作量都在于数据收集 清理和校验。 这个工作本身并不难,但是真的很繁琐,很费力。 我们天天感叹:
而让我们心灰意冷的是当一个新的需求来临时,现有的数据形态似乎不能满足需求,我们又要在现有的数据堆里,重新走数据收集,清理,校验的流程。 这似乎是一种诅咒,如同可怜的西西弗斯,被判要将大石推上陡峭的高山,每次用尽全力,大石快要到顶时,石头就会从其手中滑脱,又得重新推回去,幹著无止境的劳动。 大数据目前遇到的最大技术难点是什么?是海量数据的ad-hoc查询。当Hadoop刚刚兴起,我们可以通过它来操控越来越廉价的PC服务器价格,于是一种暴力弥漫了整个生态:
但是随着查询效率要求越来越高,我们不得不被迫做出改变。还记得我们以前的日志都是简单的Raw文本吗? 现在各种存储的格式慢慢开花结果:
总之,我们似乎没有找到一个奇妙的技术解决查询的问题,只能做某种折中: 为了加快查询速度,数据存储慢慢从早期的raw文本转为具备向量化,带索引,支持特定编码和压缩的列式存储结构,当然这种通过调整存储结构的方式必然以消耗数据进入时的时间和资源为代价。 也就是我们在存储和查询之间做了妥协。 如何让苦力干的更少前面我们提及了,我们可能80%的工作都花在了数据的采集,清洗和校验上了。但是我们该如何压缩这部分的工作呢? 答案是:
让所有的计算流动起来,就会让下面的事情变得简单:
而且我们希望流式计算的实现是结合了流式和批量语义的。为什么呢? 看看华为在Storm上做的StreamCQL,就知道,很多情况实时流式是很有局限的,因为未来我们在流式上能做的事情会非常多:
这就需要一定的灵活性,因为只有在数据集上,才会有譬如Ad-Hoc查询,才能高效的进行存储,才能适应一些机器学习算法。单条数据很多情况下,是没有太大意义的。 这块我一直是Spark Streaming的支持者。 那为啥我们需要一个流式计算上层建筑? 我们回顾下问题,数据的ETL过程是个苦力活,消耗掉大量程序员的工作时间,那么为了减少这种时间,我们有两个办法:
流式计算构建了整个基础,而其上的框架则使得上面两点成为可能。 作者:祝威廉 本网站文章均采集自互联网或为用户投稿经网站编辑整理后发表,文章观点为作者独立发表,不代表网站立场!如不小心侵犯版权请联系本网站删除:运营人 » 天天在做大数据,你的时间都花在哪了 |
|