前言

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

[[167152]]

正如下面的一句话:

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

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

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

大数据本质是：

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

机器学习的本质是：

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

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

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

我们天天感叹：

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. 提高每个人的工作效率

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