【技术总结类】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的优化，但其核心都是计算和汇总两步：
2.4.由大数据牵扯出的JAVA线程高级内容
大数据并不会直接牵扯出多线程的问题，只是聊到大数据的计算引擎就不得不聊流计算引擎。mapreduce、spark之类的都叫做批处理引擎，其核心理念是：
任务去找数据。
适合的场景是数据已经存在了，在数据上进行计算，但是有些时候数据是实时产生的，并不是已经提前准备好了，这种数据叫流数据，这类数据产生的量大，但不会被存储，只需要一个计算结果，流计算引擎用来处理流数据，核心理念是：
数据去找任务。
因为流数据里面是数据去找任务，数据量很大也就意味着任务是要并发被执行的，要有极为高效的调度和编排才行，这就需要对JAVA线程的编排很熟悉才行，于是引入了JAVA线程的各种高级编排和并发编程的内容：
聊完JAVA并发的高级内容后，我们进正式进入了流计算的内容，在这部分里面我们可以看到对JAVA线程编排的极致性能追求，我们会对JAVA的多线程有更高更深的认识：
3.第二条线，也是2025要继续的主线
终于聊到最后一条线了。在2024年博主完成了上面第一条线的内容后，开始回过头来进行另一个维度的思考。前面第一条线是在组件和技术上面追求技术选型的合适和性能的极致。上面是在追求深，接下来是追求广了。在软件中，除了合适的技术选项，还有一方面是值得我们注意的就是：
合理的工作流程。
在实际的开发过程中变化是永恒的，需求经常变动，有没有一种落地打法可以尽量的轻松一点去应对变化，而不至于狼狈?其实是有的：
利用真正的面向对象的方法进行真正合适的建模。
其实软件的本质是对现实世界的虚拟仿真，我们在建立逻辑关系的时候只要合理其实后期的改动影响就是局部的，如何进行这种逻辑关系的建立？这需要一套完整的打法，涉及：
1.从需求建模开始就要采用合适的描述方式描述好系统
2.基于需求建模建立出合理的领域模型，即概念间的关系
3.画出合理的原型
4.基于领域建模和原型设计好对象关系
于是博主开始进行DDD落地打法的探讨，已经创作一部分，2025年会继续深耕该系列：
