开发者学堂课程【大数据实战项目：反爬虫系统（Lua+Spark+Redis+Hadoop 框架搭建）第三阶段）：数据预处理-数据解析-需求与思路】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/671/detail/11660
数据预处理-数据解析-需求与思路
内容介绍：
一、数据解析的需求
二、解析规则与思路
一、数据解析的需求
已经打完了单程还是往返的标签同时也看到了效果。接下来看下面的宏观流程，接下来要实现的目标叫做数据解析。
数据解析分为两种情况：查询类的数据解析，预定类的数据解析。在数据当中，企业的业务场景当中，数据会分为两种业务场景，一个是查询类的，一个是预定类的。
那么要做的第一件事情就是查询类的数据解析。
查询类的数据解析到底要做什么事？
解析查询类的数据的目标是来实现解析出数据当中出现的出发地、目的地、起飞时间，以及其他的信息，也就说最主要的目的就是为了解析这些数据，把它们解析出来。
这部分稍微有些复杂，因为采集的数据当中是没有出发地、目的地、起飞时间的，或者说有但是不能够通过原始数据一步解析出来。
需求：
截止到目前为止，已经对每一条数据进行了分类，计算出了它的标签，这些标签里面包括国内查询、国际查询、国内预定、国际预定，还有单程跟往返，这些已经计算好了，在解析数据里面我们会用到它们。
每一个不同的分类，也就是说国内查询、国际查询、国内预定和国际预定。
这是四种情况，那么不同的分类，它的请求参数的格式是不一样的。也就说解析这四种情况的出发地和目的地，它的解析参数是不一样的。那么同样，四种不听的业务场景解析数据的参数也是不一样的。
那么这些参数放在哪儿？
它们放在数据库中，四种情况分别有一个解析规则来一一去对应。
参数的配置放到了外部项目当中。
看上图所示页面，数据管理里有一个数据处理的页面，上面有国际国内查询，国际和国内的预定。
然后在这里面要解析出发地和目的地。
以南方航空为例，现在默认是广州到成都。8月15出发，9月15返回，这两个是日期。
日期选好以后来监控一下它的参数，点击查询，看下图，在网络流量当中，查询 Query，然后看到里面的参数有一个 depcity, 一个 arrcity 还有一个 flightdate 。
depcity 的就是出发地，arrcity 就是目的地，flightDate 是起飞日期，这就是要监控的数据，这些数据都在参数里面也就是 Body 里面。请求头里面是没有这些数据的。
要把它解析出来就要知道数据的 body 信息。那么数据的 body 有哪些？要去哪里又该怎么去解析？
看上图页面，业务场景分为查询类和预定类。而查询又分为国内查询和国际查询。预定又分为国内预定和国际预定。
目的是为了解析说出发地、目的地、起飞时间。也就是图中显示的 depCity、arrCity、flightDate，但是不能直接解析出来。
因为国内查询用的是 depCity、arrCity、flightDate 来标记出发地，目的地和起飞时间。
但是在国际查询，出发地是 dep ，目的地是 arr。起飞时间是 date ,这和国内查询完全不一样。同样国内和国际预定里面的出发地，目的地和起飞时间也是完全不一样的，也就是数据采集完之后可以拿到数据当中的 body 信息。但是拿到信息以后该怎么解析？
所以这个界面存在的意义就是明确的告诉我们，如果数据是国内查询的业务场景，那么针对每一条数据它会把你的飞行类型和操作类型打出来了。就是上面的四种情况，要知道具体的业务场景，然后再去找这个业务场景对应的解析规则。
解析出发地目的地起飞时间以及乘机人数是最终的目的，但不能一步到位，所以需要先找到业务场景。
再去确定该用哪一个解析规则。如果数据直接传过来，它可能有很多种解析方法，那么在多种的情况下就不能够解析出来。所以必须确定是哪一种情况。
先确定业务场景，再根据 url 的表达式以及其他的一些参数确定该用哪个来解析，这个就是需求，也是数据解析的最终目的。
二、解析规则与思路
需要从数据库当中读取出解析规则，根据数据打上的标签，就是国内查询、国际查询、国内预定跟国际预定，根据前面的标签，找到规则，再去解析里面的数据。这就是这个界面存在的意义。这里面是一个配置，它落到数据库里面，打开 analyzerule 这个表：
这个表里有很多字段，它们就是这个界面所存出来的结果，其中 BehaviorType 用来区分查询跟预定。
package com.air.antispider.stream.dataprocess.constants
//操作标记类别0-查询，1-预定，-1-其他
object BehaviorTypeEnum extends Enumeration{
type BehaviorTypeEnum = Value
val Query = Value(0,"Query")
val Book = value(1,"Book")
val Other = value(-1, "Other")}
这个数据表，从后往前会发现有很多的 Query ，这些都是查询的指标数据。
再往前看，直到看到预定的字段 book 。
上面的这些就是查询的相关指标的参数和预定的相关指标的参数。那么，查询跟预定前面的这些比如 flight_type,behavior_type 等是干什么的？
先看查询，先在查询类的业务场景当中，找到 query，这里有很多种情况。第三行是国内查询，第二行是国际查询，还有第四行的 c1,c2,d1。
也就是如果传过了一条数据，它是查询性的业务场景，那么要查询出发地和目的地，起飞时间这三个参数，以这三个为例，那么应该以那个为准。上图的表格能看到出发地和目的地，起飞时间都有三种选择，那么到底以哪个为准？按谁去解析？这时候就用到了前面的 flight_type,behavior_type，requestMatchExperssion 这些指标。
通过多个属性联合到一起确定出到底该用哪一个数据进行解析。
比如这里面的飞行类型 Flight_type，在 Flight_type 里，0代表国内，1代表国际。Behavior_type 的0代表查询，1代表预定。所以上表中第二三四行他们三个之间，如果进行国内查询，那么就从三种选择变成了两种选择。所以后面这几个属性的目的，都是为了确定，当有多个选择的情况确定出到底该用哪一个。这些前面的属性就是为了要确定这件事情。这件事情就是在数据库当中，数据管理界面当中的这些属性都存储在数据库中，也就是这张表。
下面在book解析的时候，他也有 book_idType,book_idCard 两种选择
那这两种选择该用哪一个？这也要用前面的这些属性来确定，如果是预定的业务场景，比如下图中的这个例子：
在预定的场景中，第一个跟第五个该用哪一个？就是通过前面这些属性来进行确定。
上面的就是解析数据的规则以及思路。
