大数据技术应用思考

引言：

如何应用大数据技术，从事大数据工作多年，这是一个自问，也是一个讨论。

我15年上学的时候，在导师的引导下开始接触大数据，当时映像深刻的是两个故事：一个是沃尔玛通过大数据分析，得出啤酒和尿布放在一起会加大销量；另一个是在飓风天气，面包、水、电池、罐装食品的销量会大幅增加。这两个故事用大数据技术还原，第一个可描述成A/B测试找到最佳运营方式；第二个可以还原成，通过数据的透视分析，找到了商品与天气维度间的关联关系。

后续逐渐深入对大数据技术的理解和应用，有了一些自己的感悟和思考，这里通过分享一些思考，系统的总结使用经验，能给深耕在大数据领域的伙伴一些参考。

一、大数据的发展

上世纪90年代末，随着互联网的兴起，传统OLTP数据库在应用上遇到痛点：数据量太大，单机中间件在大数据量的冲击上遇到性能瓶颈；当时就有人提出大数据的概念；

2000年初，谷歌由于自己市场应用产生大量数据，急迫的需要新的技术支撑自己庞大数据的存储和分析处理；谷歌三驾马车横空出世：mapreduce、gfs以及列式存储bigtable；堪称大数据技术领域的鼻祖，mapreduce思想是分布式计算，将一个整体的计算逻辑，拆分成多个小计算逻辑，对拆分计算的结果再做合并计算；gfs是对文件的分布式存储；bigtable利用列存的思想，将数据的存储和计算合并到一起；

后续多种大数据多种均在这三种技术思想的基础上发展而来，随后20年，多套大数据开源组件都有这三种技术的影子。

二、大数据的存储问题

最近二十年，大数据的发展百花齐放；并发展出各种用于大数据数据存储的开源组件；

存储组件的发展是由于需求，计算机的基本数据交流方式就是文件：

大数据的第一代存储方式就是S3，HDFS等文件存储系统；最基础也是可用性最高的方式，对结构化。非结构化，二进制对象均可以表达成文件存储，这种方式也有弊端，需要利用特有的计算引擎转换和处理；在第一代存储引擎上，原生的是mapreduce计算模型；

第二代存储引擎就如Hbase,自定义存储格式，通过组件自身的DSL语言，分析数据，这列存储引擎带有很强的应用属性，比如用于随机读写的Hbase、多类类型文档存储的MongoDB、用于大数据搜索的ES/solr、用于OLAP分析的kylin、ClinkcHouse、doris/StarRocks等，通过自己设计存储方式，适配自己应用功能的计算引擎；

三、大数据计算问题

第一代大数据计算模型是mapreduce，只有两个阶段的计算；第二代是tez,还是批处理，在第一代的基础上加长了计算拓扑；第三代是计算功能内置的计算拓扑，例如saprk;第四代是实时流计算，例如Flink；这几类都是可以自己编写计算逻辑，独立的计算引擎，高度可适配各种场景；主要通过功能分类。这些高度可灵活计算的计算引擎，串起了数据和各组组件应用能力。面向各种大数据应用场景的应用组件，自身内部会对数据做加工处理。

四、大数据应用场景总结

从业务视角分析：

大数据在公司运营和领导层：主要是分析，需要数据处理+指标统计；

在运维和生产环境：数据管道，数据分析；

从技术角度：

需要基础文件存储能力：HDFS （分布式文件系统）

数据快速随机读写能力：Hbase类（key-value能力的分布式列存组件）

快速value匹配搜索：ES （大数据量的内容过滤搜索）

离线数据处理：Spark、mapreduce

离线数仓分析：HIVE

实时数据处理：Storm、Flink

实时数仓分析：doris/starRockes

高QPS/TPS维度读写：Redis、Mysql

实时业务支撑：FLINK引擎计算+Redis/mysql高QPS组件，ClinkcHouse/Doris自身引擎即席查询（低QPS）