【技术总结类】2024，一场关于海量数据治理以及合理建模的系列写作

1.今年的创作路线

2.先说第一条线

2.1.由日志引出的海量文本数据存储和分析问题

2.2.监控以及监控的可视化

2.3.数据量级再往上走牵扯出了大数据

2.4.由大数据牵扯出的JAVA线程高级内容

3.第二条线，也是2025要继续的主线

1.今年的创作路线

今年的写作内容并不是碎片化的想到什么写什么，而是有起承转合关系的。为了方便大家阅读先抛出总结，总共两条线：

1.由海量日志存储引出ES、mongoDB、监控、可视化，大数据内容，在大数据里引出了JAVA线程相关内容。

2.用了小半年把上面那一套大数据的内容写完，然后转头决定写一个系列，如何用面向对象的思维来规范软件的开发周期，力求做到做出能很方便应对需求变动的代码。也就是从需求建模、UI设计、对象设计，到最后的编码，一套可靠的DDD落地打法。

2.先说第一条线

2.1.由日志引出的海量文本数据存储和分析问题

在23年的最后一篇文章里，我聊了一下分布式链路追踪技术：

分布式链路追踪技术其实就是基于日志来完成的，这个时候就引出了日志的存储问题，日志的存储问题其实就是一个海量文本型数据的存储问题，于是在24年开头，就引出了关于ES的系列文章：

一说到ES就不得不提另一个有名的文本数据库——MongoDB，于是写完ES的系列，马上就写了MongDB，顺势对比了一下二者各自的特点和各自的适用场景：

在对比的文章里我比对了各自的特点得出：

聊完日志的存储问题后，我们找到了合适的方法来存储日志，那么自然就会想到日志的分析问题，数据我们存储好了，需要进行数据的可视化，我决定用docker来搭建测试环境，于是先写了一下docker的快速使用手册，然后选择es的配套组件ELK全家桶来实现日志的可视化：

使用logstath对日志进行清洗，用kibana自带的快速配置的数据大屏来实现日志数据的可视化。

到这里日志的从存储到二次开发，可视化就完成了，但是既然都聊到日志的可视化了，自然就要聊一下其它的可视化。除了日志信息是需要采集的，业务系统的一些指标也是需要进行收集和进行可视化的，也就是监控问题。

2.2.监控以及监控的可视化

监控问题自然要从JAVA EE的标准，最原始的监控系统JMX开始聊，于是我从JMX到spring actutaor，结再到Prometheus聊了一下监控的问题，以及如何结合grafana快速搭建监控的数据大屏：

日志和监控加上可视化其实就完成了一个完善的业务系统运行情况的监测，能搭建出这样一套基本上能第一时间定位到线上生产问题。

2.3.数据量级再往上走牵扯出了大数据

一开始是为了存储海量日志数据牵扯出前面的内容，前面的内容确实能扛住很大的数据量，完成大量数据的存储和分析，但是如果数据量级再往上走，该怎么办喃？说的直白一点，ES和MongeDB能抗住的数据量级在几个GB到几TB之间，再大的话，其数据的操作就有点吃力了。既然一开始想的是海量数据的存储和分析问题，那么就再往上走直接推演到极限，数据量起步就是TB级别，这时候就要引入大数据技术了。

数据的使用无非要解决存储和计算两个问题，大数据无非就是要用合理的架构来解决海量数据的存储和计算问题。

大数据最核心的概念是Google的三驾马车：

GFS、bigtable、mapreduce。

这三驾马车就是大数据存储和计算的基础理念，可以说一切大数据技术都是基于三驾马车的思想演变出来的。于是我先去理了一下三驾马车的论文以及其经典的一些衍生。

首先是海量数据的存储问题——GFS：

GFS提出了大数据存储的核心打法：

1.将数据分块来将数据切小，从而使得数据可以被分布式的进行存储。

2.分布式存储后，利用一个目录来记录同一个数据分出来的块儿被存在哪些服务器上。

3.将数据复制成多分副本，以应对切块后数据可能存在的丢失问题。

4.在读写上做出一些约束，充分拉高数据的读写。

聊完GFS当然应该就要聊到Hadoop，Hadoop中的核心组件，分布式文件系统——HDFS，其实就是基于GFS的核心打法来实现的。

聊完分布式文件系统就要考虑数据操作的易用性，也就是用GFS作为底座，在上面封装出一个数据库出来便于用类SQL的方式对数据进行便捷的操作，于是写了分部式数据库bigtable以及基于其打法落地的经典分布式数据库——HBase：

聊完数据的存储和查询，自然就要聊数据的计算了，也就是大数据里的另一个核心——计算引擎。计算引擎的技术底座是Google三驾马车的其中一架——MapReduce。其核心思想就是：任务去找数据将任务分发到数据所在地，就地计算，然后将结果汇总。后面的诸如Spark之类的计算引擎也是对mapreduce的优化，但其核心都是计算和汇总两步：