随着移动互联网的发展，以微博等为代表的社交媒体已经成为日常生活中必不可少的交流工具。发生灾害时，社交媒体由于其方便及时的特点，能够满足公众信息搜集和情感交流的需求，还能作为交流救援信息和组织救灾资源的媒介，提高救灾过程的效率^[1]。因此，有必要对微博数据进行一定的处理和分析(分类、时序统计、时空分析等)，在灾害应急响应中发挥作用。Qu等^[2]对2010年玉树地震相关的新浪微博数据进行抽样分类和统计，基于统计结果在内容、时间趋势和信息传播等方面做了分析。Takahashi等^[3]利用2013年台风海燕侵袭菲律宾时的Twitter数据，除了进行抽样和分类统计外，还用回归等方法对统计结果与发推人的地理位置、发推时间、身份等的关系进行了分析。Murthy等^[4]对2012年飓风桑迪袭击美国期间的Twitter数据分类后分别根据时间和空间进行统计分析。

微博由用户连续不断地产生，是一种比较典型的流数据。在处理灾害相关的微博数据时，其需求者往往期望能够实时地获知被处理的数据和处理的结果^[5]，因此就需要建立一个实时的处理框架。国外在灾害微博实时处理框架方面的研究相对深入。Yin等^[6]提出的系统架构通过在Twitter数据流上进行突发事件探测、根据信息价值分类、在线话题聚类、地理标记等处理，提供近实时的处理结果，从而为强化态势感知提供帮助；Imran等^[7]将处理过程分成自动处理、众源处理、通信流、数据和控制流4个部分，提出了一种CSP(crowdsourced stream processing)系统的设计框架，并以Twitter数据源为例进行了实现^[5]。本文提出一种灾害相关的微博实时处理框架，利用历史信息对微博进行实时分类统计，并以2017年九寨沟地震和林芝地震为例实现原型系统。

1 灾害微博实时处理 1.1 框架整体结构

框架主要包括数据获取、历史数据处理、实时数据处理3个模块，如图 1所示。

数据获取模块获取的微博数据包括历史数据和实时数据两部分，主要采用关键词搜索的方式获取。由于灾害事件之间相对独立，历史数据根据采用的关键词和数据的时间范围区分数据集，存入数据库进行管理，供历史数据处理模块使用。实时数据没有明确的时间范围，在获取到后及时将数据输出到消息队列，供实时数据处理模块使用。不论是历史数据还是实时数据，在进一步处理前都需要进行预处理。

历史数据集经预处理后需要从中取样本进行人工的类别标注，并使用标注结果训练文本分类模型。经预处理后的实时数据就可以基于训练好的文本分类模型进行类别预测，从而将预测结果加入到实时的统计结果中，使所得结果可以随时输出进行分析。

Storm、Spark、Flink等框架为数据流的实时处理提供了高效、开源的解决方案。以Spark结构化流计算引擎(structured streaming)^[8]为例，它将数据组织为一种名为Dataset的分布式数据结构。相较于另一种分布式数据结构弹性分布式数据集(resilient distributed dataset, RDD)^[9]，它包含了列名、数据类型等描述信息，类似一张结构化的数据表。因此，基于Dataset，Structured Streaming将它处理的流数据看作是一张长度无限的表，对新产生的数据以“微批次”的形式进行处理，将一定时间范围(一般以ms为单位)内收集到的数据进行批处理，并将结果附加在流数据表后。

1.2 微博数据预处理

由于微博数据具有来源广泛、数量庞大、内容口语化、常包含特殊符号等特点，因此需要进行预处理。预处理步骤如下：

1) 去重。获取数据时使用的搜索关键词一般有多组，每组关键词对应数据的获取一般会分别进行，使得这些数据间可能存在交集。为了避免最终得到的数据中存在重复的微博而影响后续文本分类相关步骤，就需要使用去重来删除重复的微博文本数据。

2) 清洗。由于微博是一种来源不可控的数据源，这就使得获取到的原始微博文本无法在语言、格式等方面形成一致，从而影响最终结果。为了减少这种不一致性，就需要对文本进行清洗，尽可能地统一其语言、格式。

3) 分词。分词的主要任务是将文本序列依据词进行切分，常见的算法有条件随机场、隐马尔科夫模型等。目前，分词是进行包括分类在内的大多数中文自然语言处理任务的前提。因此需要将它作为预处理中的一个步骤。

1.3 类别标注和文本分类模型

常见的文本分类模型包括非监督模型与监督模型两大类。非监督的文本分类模型也可称为聚类模型，无需标注数据，可用于从文本流中提取潜在的活跃话题^[6]，但难以解决根据较明确的标准分类的问题。因此，本文采用监督的文本分类模型从历史数据中提取特征信息用于实时数据分类，该过程需要标注数据用以训练分类模型。

不同类型的灾害相关的微博具有不同的文本特征，因此针对不同类型灾害的历史数据集可以定义不同的类别标注方案。但是，对于同类型灾害，在需要的时候可以将新收集到的历史数据和旧数据合并，训练新的模型替换旧的模型，以获得更好的处理效果。本文中的标注主要从微博在发生灾害时能够为公众满足信息和情感的需求这一点出发，将信息相关类和观点相关类作为分类中最主要的两个大类，其他类别划分则结合获取到的灾害数据集的特点进行。

目前，常见的文本监督分类模型主要基于词向量(word embedding)进行设计，词向量是一类利用海量语料进行训练，从而将语料中所有词都抽象为向量表示的模型，TextCNN(convolutional neural network)^[10]和FastText^[11]等都是以词向量为基础的文本监督分类模型。以FastText为例，它采用称为“n-gram”^[12]的词的特征表示形式，首先在词的前后添加边界标记符号，然后将它本身与其中所有长度为n的字符序列都作为词的一个特征。如词“where”在n=3时的特征包括“ < wh”、“whe”、“her”、“ere”、“re>”、“ < where>”，其中“ <”和“>”是边界标记符号。在FastText的词向量模型中，词的每个n-gram特征都有一个对应的向量表示。

FastText文本分类模型算法可以看作是一个浅层的神经网络，包含输入层、隐藏层、输出层3层。在单次训练中，输入层包括待训练的某条文本中包含的所有n-gram特征，输出层则是文本的类别标注信息。模型的损失函数是：

$ -\frac{1}{N} \sum\limits_{n=1}^{N} y_{n} \log \left(f\left(\boldsymbol{B} \boldsymbol{A} x_{n}\right)\right) $

(1)

式中，N是文本的条数；y_n是第n条文本的标签；f是softmax函数；B是隐藏层到输出层的权重矩阵；A是词的向量表示的查找矩阵；A x_n是第n条文本中所有n-gram特征对应向量的均值。上述模型训练的计算复杂度为O(hk)，其中k是类别数量，h是词向量的维数，在此基础上，FastText还采用了层次softmax的优化方法，将其减少为O(hlog₂k)。

为了获得质量更高的词向量，需要以微博语境下的大量数据作为基底语料。本文将基底语料与历史数据合并成词向量训练集，作为训练文本分类模型所需的词向量。

2 框架实现

本文基于2017年九寨沟地震和林芝地震案例实现了灾害微博实时处理原型系统。该原型系统主要包括3个模块：①数据获取模块获取历史和实时数据; ②历史数据处理模块利用基底语料和历史数据训练词向量模型和文本分类模型; ③实时数据处理模块利用模型预测实时数据类别并进行统计。

2.1 数据获取模块

常用的微博数据获取方式包括应用程序接口(application programming interface, API)和爬虫两种。API方式获取的数据质量较高，所需的清洗操作较少，但在API开放的功能、API的请求频率、单次请求可获取到的数据量上均有所限制。相比之下爬虫方式更灵活，能够以较低的成本获取到更多的数据。因此本文采用爬虫的方式获取数据。

本文使用的数据主要由数据获取模块中的爬虫从新浪微博的高级搜索页面抓取而来，包含2017-08-08九寨沟地震和2017-11-18林芝地震2个数据集。前者用关键词“九寨沟”、“地震”进行搜索，时间范围为2017-08-08T21:00~2017-12-01T0:00，共475 805条；后者用关键词“林芝”、“地震”进行搜索，时间范围为2017-11-18T06:00~2018-02-01T0:00，共72 361条。上述数据保存在MySQL数据库中进行管理。

数据预处理是在历史数据处理模块和实时数据处理模块中共同进行的步骤，但由于实际的预处理方式与数据源高度相关，所以在数据获取模块中一并介绍。新浪微博对每条微博均赋予一个全局唯一的ID，去重操作就是利用这个ID信息进行的；清洗主要使用正则表达式进行，主要步骤包括清除微博文本中的不可读字符、超链接、HTML标识符等影响进一步处理的内容，并过滤掉一部分过短的微博；分词使用Ansj工具进行，这是训练词向量、训练文本分类模型、对类别进行预测等处理操作的前提。

2.2 历史数据处理模块

本文将九寨沟地震数据集作为历史数据，抽取3 000条数据作为文本分类模型的训练集，经预处理后共2 974条。另外，基底语料使用2014年采用API方式获取的新浪公共微博数据集，共约2.3亿条。将标注类别分为5大类共13类，如表 1所示。

本文依据上述标注类别对训练集进行人工标注，将标注结果训练为FastText模型，并将模型文件进行保存，训练所需的词向量则由前述基底语料与九寨沟地震数据集合并后训练得到。

2.3 实时数据处理模块

本文采用Spark Structured Streaming实现原型系统中的实时数据处理模块，从消息队列中获取实时数据，执行预处理、类别预测、时序统计的处理流程并输出结果。类别预测基于历史数据处理模块训练得到的FastText模型进行预测，得到微博文本属于各类别的概率，将所有预测类别中概率最高的类别作为输出。

为了对该系统的实时处理模块进行验证，本文使用九寨沟地震数据集和林芝地震数据集模拟实际的灾害微博数据流，将数据集按发布时间排序，依次发送到消息队列中进行处理。同时，本文将时序统计的时间间隔设置为10 min，即对每10 min内的所有处理结果进行统计输出。

3 结果分析 3.1 模型评估

为了评估模型的效果，本文从两组数据集中分别再抽取500条数据作为测试集，同样依据上述类别进行标注，用于测试多分类的准确率。测试结果表明，模型在测试集上的分类准确率分别为76.2%和79.2%，证明该模型具有一定的可用性。

3.2 性能评估

Spark的流处理方式主要是“微批处理”，即将流数据以一定的时间间隔进行划分，对划分后的数据进行分布式处理。为了评估其性能，本文在固定的微批次时间长度下，将微博数据以不同的速率连续发送给实时数据处理模块，记录处理每个微批次的平均所需时间，估计系统的处理能力。实验环境如表 2所示。

取微批次长度为1 s，使用九寨沟地震数据集为测试样本，测试结果如图 2所示。在发送数据速率约为每秒1.7万条时，微批次处理所需时间达到1 s，即在本文的软硬件条件下，原型系统的处理能力上限约为每秒1.7万条微博数据。而由于Spark平台具有强大的可扩展性，可通过增加处理节点数来不断提高系统的处理能力。

3.3 处理结果分析

对九寨沟和林芝地震发生后3 d内的数据处理结果进行统计，结果如图 3、图 4所示。由于不同类别微博的数量存在较大差距，这里对微博数量以2为底取对数，使图形更加清晰。

图 3的具体时间范围为2017-08-08T21:20~2017-08-11T21:20，数据共114 581条。整体上，微博的数量在地震发生后约1~2 h内和11~13 h内出现了两个高峰，这与对九寨沟地震微博进行人工分析的相关工作^[13]是比较一致的。数据量在此之后逐天减少，这其中表达情感类和情况通报类微博所占比例最多。各类微博数量的时间趋势大致上和整体的趋势保持一致，但情况通报类和个人地震相关信息类的第一次高峰时间比其他类别早约1 h，宣传案例类的高峰时间则出现在地震发生后约17~19 h。

图 4的具体时间范围为2017-11-18T06:30~2017-11-21T06:30，数据共4 397条。林芝地震造成的舆论影响较小，微博数据远少于九寨沟地震，且基本以情况通报类为主，较少出现其他类型的微博。

4 结束语

基于灾害微博数据的特征和在灾害中可能发挥的作用，本文提出了灾害微博实时处理框架，包含数据获取、历史数据处理、实时数据处理3个模块，并基于2017年九寨沟地震和林芝地震案例实现了灾害微博实时处理原型系统。该系统从标注后的历史数据中提取分类信息，并基于流计算平台对微博流数据进行实时处理，最终对结果进行统计并输出。

除了文本分类和统计外，结合微博的地理位置属性等空间信息进行空间分析也是一种常见的微博处理方法^[14]，未来将考虑把此类处理方法加入到微博数据实时处理的流程中，丰富处理框架的功能。