大数据:天天在做大数据,你的时间都花在哪了


前言

我每天都在思考,思考很重要,是一个消化和不断深入的过程。

正如下面的一句话:


我们从出生开始如果没思考过人生本身这件事情,一切按照社会的习惯前行,那人生是没有意义的。因为你连人生都没有想过。

 

那么延生出来,我们有没有想过大数据本身?

大数据到底是在做什么,为什么我做了这么多年的大数据,总是做不完呢?

 

 

 


 

大数据本质是:

 

随着科学技术发展,更多的大数据能够被存储了,更多的大数据能被分析了。所以有了大数据的概念。

 

机器学习的本质是:

 

随着大数据变多了,量变导致质变,大数据足够大后其内部的隐含的规律会越来越精确和完整。机器学习则是将大数据内存存在的这种隐含关联给挖掘出来的一项技术。

 

大数据最消耗工作量的地方是哪里呢?

 

目前百分之八十的大数据工作量都在于大数据收集 大数据清理和大数据校验。 这个工作本身并不难,但是数以千万的大数据真的很繁琐,很费力。

 

我们天天感叹:

 

  1. 大数据在哪里?如何收集大数据

  2. 大数据要怎么进行清洗

  3. 无效大数据太多,如何去除

 

而让我们心灰意冷的是

 

当一个新的需求来临时,现有的大数据形态似乎不能满足需求,我们又要在现有的大数据堆里,重新走大数据收集大数据清理,大数据校验的流程。

 

这似乎是一种诅咒,如同可怜的西西弗斯,被判要将大石推上陡峭的高山,每次用尽全力, 大石快要到顶时,石头就会从其手中滑脱,又得重新推回去,幹著无止境的劳动。

 

大数据目前遇到的最大技术难点是什么?

 

是海量大数据的ad-hoc查询

 

当Hadoop刚刚兴起,我们可以通过它来操控越来越廉价的PC服务器价格,于是一种暴力弥漫了整个生态:

 

我们因为突然有了强大的算力,这就好比一个穷人突然有了一笔很大的钱。我们开始让强大的算力驾着最低效的程序去跑大数据,这是批处理时代的悲哀。

 

但是随着大数据查询效率要求越来越高,我们不得不被迫做出改变。还记得我们以前的日志都是简单的Raw文本吗? 现在各种存储的格式慢慢开花结果:

 

  1. Parquet, 数砖公司大力发展的一个存储技术

  2. ORC, Hive 常见的一种大数据存储格式

  3. CarbonData, 华为推出的一套可支持PB级别的大数据格式

 

总之,我们似乎没有找到一个奇妙的技术解决查询的问题,只能做某种折中:

 

为了加快查询速度,大数据存储慢慢从早期的raw文本转为具备向量化,带索引,支持特定编码和压缩的列式存储结构,当然这种通过调整存储结构的方式必然以消耗大数据进入时的时间和资源为代价。

 

也就是我们在存储和查询之间做了妥协。

 

如何让苦力干的更少

 

前面我们提及了,我们可能80%的工作都花在了大数据的采集,大数据清洗大数据校验上了。但是我们该如何压缩这部分的工作呢?

 

答案是:

 

  • 流式计算

  • 流式计算上层建筑

 

让所有的计算流动起来,就会让下面的事情变得简单:

 

我们可以在已经流动的大数据中的任何一个环节引入一个新的支流。当我要获取大数据时,我做的本质其实就是 连接两个或者多个节点,并且在其中对大数据进行转换。就如同河水,我们可以很方便的开一个支流,将水引入灌溉新的额农田。

 

而且我们希望流式计算的实现是结合了流式和批量语义的。为什么呢?

 

看看华为在Storm上做的StreamCQL,就知道,很多情况实时流式是很有局限的,因为未来我们在流式上能做的事情会非常多:

 

  1. 大数据处理

  2. Ad-Hoc查询

  3. 机器学习

  4. 报表

  5. 存储输出

 

这就需要一定的灵活性,因为只有在大数据集上,才会有譬如Ad-Hoc查询,才能高效的进行大数据存储,才能适应一些机器学习算法。单条大数据很多情况下,是没有太大意义的。

 

这块我一直是Spark Streaming的支持者。大数据天生就是流式的

 

那为啥我们需要一个流式计算上层建筑? 我们回顾下问题,大数据的ETL过程是个苦力活,消耗掉大量程序员的工作时间,那么为了减少这种时间,我们有两个办法:

 

  1. 将做些任务分散出去,使得每个人都可做,那么在总量不变的情况下,单个人就会变少了

  2.  

  3. 提高每个人的工作效率

  4.  

流式计算构建了整个基础,而其上的框架则使得上面两点成为可能。这里我依然推荐我现在正在做的一个开源项目: StreamingPro 。未来我们还会有一个更通用的基于流式计算的采集程序,敬请期待。

 

作者:祝威廉  

来源:简书