大数据框架选型案例

一.业务分析

此次案例中，我们面临的业务需求时，有一张mysql表里存储了千万级别的数据，每次业务流程结束，这张表中就会增加至少8万条数据，而我们的系统要做的就是把这些数据按不同的需求统计展示，在代码中有大量的复杂计算和复杂sql语句，，并且该系统的业务会经常发生变化，这让整个系统变得缓慢和难以维护，即使在使用redis作为我们的缓冲层，也无法很好的解决查询效率问题，毕竟第一次加载真的太慢了，在面临大量用户使用的时候，给我们的不管服务端还是数据库都造成了巨大的压力

 

二.现有技术栈说明

编程语言: JAVA

框架: spring cloud , redis , mybits , mysql ,nacos

以上的语言或者框架是我们在接手这个系统时大致上使用的东西

 

三.我们的架构方案分析

1.首先我们想到的是迁移数据，从MySql迁移到MongoDB,但是我们很快的否定了这个方案，因为大数据的迁移不仅仅是数据安全难度系数很大，迁移之后还对整个系统的业务接口都产生了巨大的影响，所有的mysql查询都需要更换为MongoDB查询，大部分业务接口的复杂计算需要重新设计或者修改，这让整个我们整个优化周期在第一步时就变得不稳定并且时间更长

 

2.优化redis，在这一层面我们想过在每次生产数据入库后，调用所有的业务接口生成查询数据存入到redis中，持久化redis能让我们保证这些数据不会被轻易的在mysql中反复查询（缓存穿透），但会让我们的redis承载大量的数据，当然这是被允许的，并且redis拥有许多优秀的集群方案，使用这个方案这让我们此次的优化变得侵入性较低，并且后期只需要维护调用每个接口的程序，于是优化redis成为我们的首选项

 

3.就在我们准备使用优化redis的方案时，我们又对代码的可维护性和频繁变更的业务需求产生了想法，如果我们仅仅是使用了redis，那我们在面对频繁变更的业务需求时就需要维护两套代码，一套是业务代码，另外一套就是我们的调用接口把数据放入redis的代码，当我们被这个问题困扰时，我们想到了使用搜索引擎，频繁变更的业务需求不就是百变的搜索条件吗，而我们的业务代码不就是为我们的搜索引擎提供搜索数据吗，在详细探讨后，我们觉得逐步替换掉现有的开发模式，让我们的系统变得易维护，查询更快，扩展性更强，下一章中，我会详细介绍拟定的方案。

 

四.架构方案

图中展示了我们拟定方案的三个阶段

第一阶段就是我们现在整体数据的流向

第二阶段是一个过渡期，也是本篇文章的重点

第三阶段是在经过过度期时，我们理想中的数据流向

 

方案说明：

我们会在过渡期把所有的查询数据放入到搜索引擎中，这是为了应对频繁更变的业务需求导致的查询参数频繁变化，在过渡期就算新增了业务接口或者业务接口数据结构发生变动，只用维护搜索引擎的数据，虽然在此时我们已经能够体会到搜索引擎带来的查询效率的提升，但是我们的目的不限于此。

 

在第三阶段我们会建立静态数据仓库，这是非常重要的一点，我们使用ETL工具来保证静态数据仓库的全面性，稳定性，降低代码的开发成本。之后我们会根据业务需求来拆分更多的‘业务表’，这些‘业务表’只针对一个或者几个业务，我们要做的就是把业务数据从静态数据仓库加入到‘业务表中’，每个接口都会有专属的‘业务表’，这让我们的系统业务变得简单，当我们需要改动一个业务接口时，维护者只用关心‘专属表’的情况，每当新增业务时，同样为这个业务新增‘专属表’，这一点不管是新来的开发人员或者维护人员，这让他们能够迅速的接手他们负责的业务，能够‘心无旁骛’地进行业务开发

 

方案技术选型说明：

搜索引擎：Elasticsearch

是一个基于Lucene库的搜索引擎。它提供了一个分布式、支持多租户的全文搜索引擎，具有HTTP Web接口和无模式JSON文档。

使用它的好处是在我们的第三阶段，当我们的业务数据不再从一个数据源出发时，它能够为我们的多样化的查询条件建立索引，如果使用redis，我们可能在使用组合键的时候会发生重复等不可预先想到的问题，多样的搜索条件让能够匹配频繁变更的业务需求

 

ETL（数据抽取工具）：Kettle

适用于将多个应用系统的大批量的、异构的数据进行整合，有强大的数据转换功能

高效适配多种类型的异构数据库、文件和应用系统

快速构建复杂数据大集中应用、无需编码

使用etl工具是为了让我们的静态数据仓库更加灵活和健壮，不需要更多的代码来维护我们的静态数据仓库

 

方案技术实操说明：

搜索引擎：Elasticsearch

1.过渡期，我们会把业务接口的结果集（json数据）直接放入到

Elasticsearch中。

Elasticsearch索引：

 

1.我们只会建立一个索引条件，param中的存储值，就是查询接口参数对象的hashCode加上url地址，而我们储存的对象只需要一个param加上data（data内是业务结构返回的json）

这让我们的搜索引擎在目前阶段的使用变得像redis，但是没关系，这只是一个过渡期，真正的使用需要建立在时间上

 

2.成熟期，当我们拥有了不同的‘专属表’之后，我们的索引就开始变得复杂，我们的 /{A条件}/{B条件}这样的索引会变得多起来，每个索引都只会服务于自己的业务接口，在变得复杂的同时，也相对比较简单

 

ETL（工具）：Kettle

这个工具的使用，需要一定的时间积累，在这里我们之谈一谈它给我们带来好处，简化了数据来源的操作，维护人员只用专注于静态数据仓库的稳定，在保障其数据源时，业务表，业务接口的崩塌都不会影响到数据源，这让我们的架构更加稳定，从侧面来说，同时也增加了数据的安全性，因为对外暴露的接口都无法直接访问到源数据，数据经过业务的切分变得不在有更多的关系，这让入侵者很难找到漏洞

 

 

五.写在最后

我相信，这阅读这篇文章后，您会有更多的疑问，有太多技术和方案的细节，我说得不是很详细，但是由于一次性的汇总说明总是会有遗漏的地方，所以接下来，我们会针对这篇文章把大家的问题汇总，在后续文章中持续为大家解答，这篇文章不是结束，它只是个开始。

如若大家觉得感兴趣，请关注我的公众号，后续文章都会在公众号首发

下期内容预告：elasticsearch实操教程