spark，机器学习，流式计算，spark和业务机器关系理解和梳理

1.刚接触spark等分布式技术的时候，有个很大的问题是spark是用来做什么的？他和分布式服务，分布式存储，分布式计算都是什么关系？

大数据(大公司)领域三个问题是高并发，大数据量的计算，大数据量的存储。

先说高并发，高并发的含义是是请求并发量高，这是业务后端开发常见的问题，基本解决方案就是负载均衡，通过集群多机器来进行服务。典型的是nginx请求转发，根据不同分流请求转发到不同机器上。这里又分不同的服务，每个服务可能又是一个小集群来支撑。所以需要根据不同服务找到不同的机器，即使同一个服务也要进行不同机器节点的状态维护，可用不可用，上架下架，请求路由等等，需要进行集中的控制和状态管理。

高并发的特点是请求量大，但是每个请求的计算的服务时间相对没有那么长，实时性响应速度要求高。高并发情况下为了让请求保持线性和保存请求资源和维护数据库数据处理逻辑正确性等，kafka这种消息队列服务几乎是必选项了。

 

大数据量存储

大量用户必然产生大量的数据，日志行为数据更为庞大了。不同类型数据存储方式不尽相同，用户业务数据放到mysql等传统数据库，分库分表这种分布式存储配套也要跟上，因为往往高并发情况下，响应速度的主要瓶颈在于数据库。日志数据等量大且优先级低的数据存到文件，最后拉到hadoop hdfs里面了。

 

大数据量的计算

1）机器学习的场景是需要一个用户尽可能全的特征数据来进行模型训练，而且尽可能需要更多的用户数据，所以这是一个海量数据的计算问题。

2）公司全局业务数据的统计，历史数据的多维度，多角度的深度统计分析也是在海量数据基础上的聚合统计运算。

spark等框架出现就是解决分布式计算问题，利用集群中的各个机器资源协同完成分布式存储，分布式计算问题。这和前面的高并发负载均衡就有明显区分了，前面是多个机器基本上是独立关系，每个机器是替代关系，并行关系。而spark分布式计算是协作关系，时而并行时而串行，最终一起完成整个计算任务。

 

流式计算

经过上面分析感觉各种场景都有对应工具了，流式计算有必要存在吗？个人理解流式计算是用在那种，业务要求时间没有服务那么高，但是spark那种计算又太慢的场景，而且数据量要求稍微大点。典型的一个场景就是实时推荐场景。当然若公司实时推荐响应要求时延低且在一定程度上可以不用stom,flink等流式计算框架，用java纯服务也可以。但这种情况下往往没办法做更大范围的召回，为了更大范围更全面的召回，大数据基础上的较快计算，流式计算的用途就体现出来了。他类似于实时服务，从kafka拿请求数据，从各种存储端拿需要的数据，进行相对全面的大数据量召回，进而进行推荐。可以这么理解，线上后端业务服务是秒级要求，spark离线任务是天级频次，而流式计算是分钟级别响应，也可以理解为近实时。

 

2.python和pyspark和spark关系

spark本身是一个java服务，当然这种服务基本上是在集群环境内部访问，不适合在外部访问，所以一般是将运行任务提交到spark集群上。你按照他的格式进行请求，就可以按照你的指令组织数据，进行计算和最终的存储等，大多数情况下是单向的指令，只拿取命令的执行状态，少部分情况下是collect，show等有数据返回的操作。pyspark是spark面向python的接口，就是它定义了python的函数，会将你的python函数写法翻译并提交给spark服务执行，并进行中间的数据传输和转换。

 

3.spark和机器学习包(库)之间的关系

spark本身无法支持python里面的那种自带的numpy, pandas，sklearn等，因为spark的dataframe或者rdd只是一种抽象表示，不代表实际的数据，也就是你把spark.dataframe对象给了numpy的函数，它也不会处理啊。所以支持的话，道理也很简单，就是给你个spark.dataframe你能接住且按照它的逻辑进行处理即可。spark.mllib进行机器学习也就是这样的道理。同样的道理，要想在spark上使用一些gbdt或者深度模型，要使用他们的分布式支持spark的版本，否则你自己实现一个也行。当然，这种情况下，没办法了，那就单机搞呗，而且机器学习海量数据的处理耗时在于前面的数据聚合统计且向量化(特征工程)的过程，真正的训练和预测瓶颈没有那么大，当然bert等超级模型除外。

以上是个人学习和思考和结合项目工作经验总结的，有疏漏之处，还望批评指正