"大数据分析“ 还有必要存在吗？初听TIDB 公开课

近一直在听批的TIDB 的公开课(试)，其中前面课程讲授了TIDB 的设计理念与架构体系，这里TIDB 要求不希望在课程期间透露内容，这里就不进行透露，但初听的感想还是要谈谈的。 当然题目不大友好，但实话实说，如果这个理念推行下去，大数据分析这个行业呵呵。

HADOOP ,  SPARK, HDFS, FLINK 等等都是大数据专有名词， 而产生大数据的动力主要有两个， 

1 数据量的问题  ”大“

2 数据实时计算的问题 ”时效性“

所以催生出各种解决方案，目前好像火热的是FLINK 这样的流式解决方案. 当然大数据行业存在的  架构"重", 实施"难", 数据获取"ETL" 方式多，等困难等问题,以及大数据计算的 "大拆小", 等等问题应该到目前还是存在的.

在听课的这一段,尤其是TIDB 的设计理念, 可以强烈感受到设计师的逐步演进与巧妙的心思，敏感的产品力的野心. 为什么会有大数据行业, 主要的原因是 "慢",  通俗的话就是数据库行业无法解决,数据量大的情况下,进行快速的数据计算的问题.

反观大数据行业主要的解决方案可以用这几个词来总结

1  分布存储

2  分布计算

TIDB 本身的一体化的解决方案,给这个混乱的市场一个新的思路, 那就是数据库本身就是一个分布式存储, 分布式计算, 行与列两种引擎 混合计算的数据处理单元.

数据在进入数据库同时,已经将数据分成  行  与  列两种存储的方式, 同时还有两种不同的数据计算引擎对擅长的 OLAP  以及 OLTP 进行计算. 在这样的情况下, 数据本身的存储被分布式存储化解. 并行计算也通过分布式存储中添加计算单元的方式化解了, 随之OLAP中的列式存储擅长数据库分析的特性也被放入自身, 这哪里是什么分布式数据库，这就是一个大型的要一统天下的数据库与大数据整体解决方案。

这样的思路设计出的产品, 如果还称为数据库那就太小瞧 TIDB了, 这是一个生态, 从数据的进入,到数据的分析,一条龙在TIDB 的生态中就化解了. 当然如果在把类似于MONGODB 这样的JSON 处理数据的引擎加入进来, OMG

反观大数据行业,因为数据在各种不同种类的数据库内, 数据的存储的方式不统一,并且处理起来很难, 主要面临的问题

1   数据分散存储不利于统一的数据处理,所以需要ETL 将数据放入统一的平台,统一处理，则需要大量的精力来处理本身大数据不应该负责的事情。

2   数据量大,所以需要分布式存储,来解决数据存储的问题，而数据到分布式存储又会涉及 1 中的问题。

3   并行计算, 因为数据量大,数据分布式存放,必然需要并行计算提高处理数据速度，而并行计算与分布式存储在整体大数据行业的解决方案其实并不是特别成熟。（这里没有说MPP架构）

4   众多数据需要统一的数据处理平台，而目前的大数据分析，你去每个企业都有自己的方式，就和看王子复仇记，“哈姆雷特”的身高，体重，外形是千变万化

ETL 数据抽数也是一个问题,一个公司不同的数据库种类多, 合并起来的确是困难的, 而ETL 抽数本身不是一个实时性很高的方法. 所以截止目前来说,实时计算本身能服务的地方在大数据行业一直是技术的"高点".  

对于数据库行业本身，实时就是平常的功能,数据库一个SQL下去结果就是实时的计算.  （实时的数据+实时的计算+实时的结果）

TIDB 这样设计的理念其实在开始瓦解, 数据库与大数据的界限, 让数据处理变得更加的简单和高效,且成本非常低, 我们不在需要什么写各种难搞的JAVA ,SCALA 这样的语言,  数据处理行业会走向统一, SQL , SQL 会是大数据和数据库行业统一的语言.  对未来的行业的导向也是一种风向标, 一个行业的重构合并,重组, 可能就此会改变. 

 He who has hope has everything.

目前也正在学习TIDB ,也在写相关的感受,  待成熟了,会进行发布