标签 | 大数据 架构
作者 | 张逸
无论是采集数据，还是存储数据，都不是大数据平台的最终目标。失去数据处理环节，即使珍贵如金矿一般的数据也不过是一堆废铁而已。数据处理是大数据产业的核心路径，然后再加上最后一公里的数据可视化，整个链条就算彻底走通了。
数据处理的分类
如下图所示，我们可以从业务、技术与编程模型三个不同的视角对数据处理进行归类：
业务角度的分类与具体的业务场景有关，但最终会制约技术的选型，尤其是数据存储的选型。例如，针对查询检索中的全文本搜索，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），以便于快速查询或计算。
场景驱动数据处理
不同的业务场景（业务场景可能出现混合）需要的数据处理技术不尽相同，因而在一个大数据系统下可能需要多种技术（编程模型）的混合。
场景1：某厂商的舆情分析
某厂商在实施舆情分析时，根据基于需求，与数据处理有关的部分就包括：语义分析、全文本搜索与统计分析。通过网络爬虫抓取过来的数据会写入到kafka，而消费端则通过spark streaming对数据进行去重去噪，之后交给sas的ecc服务器进行文本的语义分析。分析后的数据会同时写入到hdfs（parquet格式的文本）和elasticsearch。同时，为了避免因为去重去噪算法的误差而导致部分有用数据被“误杀”，在mongodb中还保存了一份全量数据。如下图所示：
场景2：airbnb的大数据平台
airbnb的大数据平台也根据业务场景提供了多种处理方式，整个平台的架构如下图所示：
panoramix(现更名为caravel)为airbnb提供数据探查功能，并对结果进行可视化，airpal则是基于web的查询执行工具，它们的底层都是通过presto对hdfs执行数据查询。spark集群则为airbnb的工程师与数据科学家提供机器学习与流处理的平台。
大数据平台的整体结构
行文至此，整个大数据平台系列的讲解就快结束了。最后，我结合数据源、数据采集、数据存储与数据处理这四个环节给出了一个整体结构图，如下图所示：
这幅图以查询检索场景、olap场景、统计分析场景与深度分析场景作为核心的四个场景，并以不同颜色标识不同的编程模型。从左到右，经历数据源、数据采集、数据存储和数据处理四个相对完整的阶段，可供大数据平台的整体参考。