剖析大数据平台的数据处理无论是采集数据,还是存储数据,都不是大数据平台的最终目标。失去数据处理环节,即使珍贵如金矿一般的数据也不过是一堆废铁而已。数据处理是大数据产业的核心路径,然后再加上最后一公里的数据可视化,整个链条就算彻底走通了。 如下图所示,我们可以从业务、技术与编程模型三个不同的视角对数据处理进行归类: 业务角度的分类与具体的业务场景有关,但最终会制约技术的选型,尤其是数据存储的选型。例如,针对查询检索中的全文本搜索,ElasticSearch会是最佳的选择,而针对统计分析,则因为统计分析涉及到的运算,可能都是针对一列数据,例如针对销量进行求和运算,就是针对销量这一整列的数据,此时,选择列式存储结构可能更加适宜。 在技术角度的分类中,严格地讲,SQL方式并不能分为单独的一类,它其实可以看做是对API的封装,通过SQL这种DSL来包装具体的处理技术,从而降低数据处理脚本的迁移成本。毕竟,多数企业内部的数据处理系统,在进入大数据时代之前,大多以SQL形式来访问存储的数据。大体上,SQL是针对MapReduce的包装,例如Hive、Impala或者Spark SQL。 Streaming流处理可以实时地接收由上游源源不断传来的数据,然后以某个细小的时间窗口为单位对这个过程中的数据进行处理。消费的上游数据可以是通过网络传递过来的字节流、从HDFS读取的数据流,又或者是消息队列传来的消息流。通常,它对应的就是编程模型中的实时编程模型。 机器学习与深度学习都属于深度分析的范畴。随着Google的AlphaGo以及TensorFlow框架的开源,深度学习变成了一门显学。我了解不多,这里就不露怯了。机器学习与常见的数据分析稍有不同,通常需要多个阶段经历多次迭代才能得到满意的结果。下图是深度分析的架构图: 针对存储的数据,需要采集数据样本并进行特征提取,然后对样本数据进行训练,并得到数据模型。倘若该模型经过测试是满足需求的,则可以运用到数据分析场景中,否则需要调整算法与模型,再进行下一次的迭代。 编程模型中的离线编程模型以Hadoop的MapReduce为代表,内存编程模型则以Spark为代表,实时编程模型则主要指的是流处理,当然也可能采用Lambda架构,在Batch Layer(即离线编程模型)与Speed Layer(实时编程模型)之间建立Serving Layer,利用空闲时间与空闲资源,又或者在写入数据的同时,对离线编程模型要处理的大数据进行预先计算(聚合),从而形成一种融合的视图存储在数据库中(如HBase),以便于快速查询或计算。 不同的业务场景(业务场景可能出现混合)需要的数据处理技术不尽相同,因而在一个大数据系统下可能需要多种技术(编程模型)的混合。 我们在为某厂商实施舆情分析时,根据客户需求,与数据处理有关的部分就包括:语义分析、全文本搜索与统计分析。通过网络爬虫抓取过来的数据会写入到Kafka,而消费端则通过Spark Streaming对数据进行去重去噪,之后交给SAS的ECC服务器进行文本的语义分析。分析后的数据会同时写入到HDFS(Parquet格式的文本)和ElasticSearch。同时,为了避免因为去重去噪算法的误差而导致部分有用数据被“误杀”,在MongoDB中还保存了一份全量数据。如下图所示: Airbnb的大数据平台也根据业务场景提供了多种处理方式,整个平台的架构如下图所示: Panoramix(现更名为Caravel)为Airbnb提供数据探查功能,并对结果进行可视化,Airpal则是基于Web的查询执行工具,它们的底层都是通过Presto对HDFS执行数据查询。Spark集群则为Airbnb的工程师与数据科学家提供机器学习与流处理的平台。 行文至此,整个大数据平台系列的讲解就快结束了。最后,我结合数据源、数据采集、数据存储与数据处理这四个环节给出了一个整体结构图,如下图所示: 这幅图以查询检索场景、OLAP场景、统计分析场景与深度分析场景作为核心的四个场景,并以不同颜色标识不同的编程模型。从左到右,经历数据源、数据采集、数据存储和数据处理四个相对完整的阶段,可供大数据平台的整体参考。 上一篇: 美国军方RFID标签使用指南
下一篇: RFID在高校图书馆中应用
|