CN106570152B - 一种手机号码的海量提取方法及系统 - Google Patents

一种手机号码的海量提取方法及系统 Download PDF

Info

Publication number
CN106570152B
CN106570152B CN201610970408.0A CN201610970408A CN106570152B CN 106570152 B CN106570152 B CN 106570152B CN 201610970408 A CN201610970408 A CN 201610970408A CN 106570152 B CN106570152 B CN 106570152B
Authority
CN
China
Prior art keywords
text data
data
mobile phone
file system
telephone number
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201610970408.0A
Other languages
English (en)
Other versions
CN106570152A (zh
Inventor
欧阳涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huzhou Yinglie Intellectual Property Operation Co ltd
Original Assignee
Jinhua Zhizhen Communication Equipment Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jinhua Zhizhen Communication Equipment Co Ltd filed Critical Jinhua Zhizhen Communication Equipment Co Ltd
Priority to CN201610970408.0A priority Critical patent/CN106570152B/zh
Publication of CN106570152A publication Critical patent/CN106570152A/zh
Application granted granted Critical
Publication of CN106570152B publication Critical patent/CN106570152B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2471—Distributed queries
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Probability & Statistics with Applications (AREA)
  • Computational Linguistics (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Fuzzy Systems (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明公开了一种手机号码的海量提取方法，包括以下步骤：S10、利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；S20、将所述本地文件池内累加得到的号码文本数据上传至hadoop的云端分布式文件系统hdfs1；S40、利用hadoop的数据仓库工具hive从所述云端分布式文件系统hdfs1内号码文本数据中分布式提取URL的手机号码。本发明在大数据应用场景下，将各子文本数据汇聚到本地文件池中后，将号码文本数据上传到云端分布式文件系统中，再利用hive进行分布式计算来进行分布式提取；从而实现高效提取海量手机号码，且具有消耗资源低等优点。

Description

一种手机号码的海量提取方法及系统
技术领域
本发明属于数据提取技术领域，尤其涉及手机号码的海量提取方法及系统。
背景技术
在互联网飞速发展的今天，对用户在使用网络资源时所表现出来的规律、个性化的习惯进行分析(也称用户行为分析)后；提取并了解到用户的兴趣。一方面，可以对用户个性化定制与推送，为网站访问者提供更加主动的、智能化的服务。另一方面，从用户行为的不同表现，发现其兴趣和偏好，可以优化页面之间组织关系，完善网站系统架构，从而减轻用户寻找信息的负担，使其操作更加简单，节约时间和精力。
然而，在向用户进行个性化定制与推送时，需要提前知道用户终端的身份信息(手机号码)后，才能向该用户终端推送相关信息。目前，是在用户终端上网时，从URL中提取用户终端的手机号码。
由于在线用户数量庞大，直接利用本地关系数据库技术、以及传统的提取方法，会消耗大量资源和内存，并且效率低下，不能很好满足手机号码的海量提取。
发明内容
本发明提供的技术方案如下：
本发明提供一种手机号码的海量提取方法，包括以下步骤：S10、利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；S20、将所述本地文件池内累加得到的号码文本数据上传至hadoop的云端分布式文件系统hdfs1；S40、利用hadoop的数据仓库工具hive从所述云端分布式文件系统hdfs1内号码文本数据中分布式提取URL的手机号码。
进一步，所述步骤S20进一步包括：S21、对所述本地文件池内的子文本数据进行提取、清洗后，累加合并成文本数据；S22、判断所述文本数据中是否存在电话号码；S23、当所述文本数据中不存在电话号码时，则对所述文本数据进行过滤检测并删除。
进一步，所述步骤S20进一步还包括：S24、当所述文本数据中存在电话号码时，则对所述文本数据中的电话号码进行正则匹配处理；S25、判断所述文本数据中的电话号码是否为新电话号码；S26、当所述电话号码为新电话号码时，则按照所述云端分布式文件系统hdfs1的块的大小，对存在新电话号码的文本数据合并成号码文本数据；S27、利用本地分布式文件系统hdfs2将所述号码文本数据上传至所述云端分布式文件系统hdfs1。
进一步，所述步骤S21进一步包括：S211、提取所述子文本数据的文件名中的路由器MAC和时间戳；S212、识别出所述路由器MAC和时间戳是否遇到乱码；S213、当所述路由器MAC和时间戳遇到乱码时，则对所述乱码进行清洗，累加合并成文本数据后，跳转至步骤S22；否则，直接跳转至步骤S22。
进一步，还包括以下步骤：S30、所述数据仓库工具hive向开源计算框架TEZ发送计算请求；S31、所述开源计算框架TEZ对所述号码文本数据进行压缩编码处理成压缩文本数据，并存储在所述云端分布式文件系统hdfs1的数据库中。
进一步，所述步骤S40进一步包括：S41、利用所述数据仓库工具hive的UDF函数从所述压缩文本数据中提取URL的手机号码。
进一步，在所述步骤S10之前还包括：S01、搭建Hadoop的集群环境，并配置所述数据仓库工具hive、云端分布式文件系统hdfs1、本地分布式文件系统hdfs2；S02、在所述集群环境中各节点处搭建web服务器分布式集群，并添加负载均衡；S03、实现所述数据仓库工具hive、云端分布式文件系统hdfs1、本地分布式文件系统hdfs2的建表关联；重构所述数据仓库工具hive的UDF函数。
进一步，在所述步骤S01进一步包括：S011、在Hadoop上搭建第一预设个数的主节点master、第二预设个数的从节点slave；各个主节点master之间相互连接，每个主节点master分别与各个从节点slave相连。
进一步，所述步骤S01进一步还包括：S012、每个主节点master上组建有元数据服务组件metastore、关系数据库mysql。
本发明还提供一种手机号码的海量提取系统，包括：分布式web服务器框架，利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；本地分布式文件系统hdfs2，将所述本地文件池内累加得到的号码文本数据上传至hadoop的云端分布式文件系统hdfs1；数据仓库工具hive，利用hadoop的数据仓库工具hive从所述云端分布式文件系统hdfs1内号码文本数据中分布式提取URL的手机号码。
与现有技术相比，本发明提供的手机号码的海量提取方法及系统，具有以下有益效果：
1)本发明中在大数据应用场景下，将各子文本数据汇聚到本地文件池中后，将号码文本数据上传到云端分布式文件系统中，再利用hive进行分布式计算来进行分布式提取；从而实现高效提取海量手机号码，且具有消耗资源低等优点。
2)本发明中对文本数据进行累加合并成文本数据后；再判断文本数据中是否有电话号码；当文本数据中没有电话号码时，删除文本数据；可防止无效文本书数据过多，降低手机号码提取效率，给分布式文件系统造成堵塞。
3)本发明中当文本数据中存在手机号码时，按照云端分布式文件系统的块的大小，将该文本数据合并成号码文本数据后上传；从而保证上传到云端分布式系统中的号码文本数据是有效的，不仅可以减少占用空间，还能提升手机号码的提取效率。
4)本发明中对号码文本数据进行压缩编码处理，压缩后的号码文本数据可以减小占用空间，有效地解决了本地关系数据库的资源消耗问题和内存问题；编码后的号码文本数据可以使得有序提取手机号码，保证提取过程能够顺畅运行。
5)本发明中在文本数据的文件名中提取进行路由器MAC和时间戳，当遇到乱码时，对其进行清洗；为顺利提取手机号码提供保障。
附图说明
下面将以明确易懂的方式，结合附图说明优选实施方式，对一种手机号码的海量提取方法及系统的上述特性、技术特征、优点及其实现方式予以进一步说明。
图1是本发明一种手机号码的海量提取方法的流程示意图；
图2是本发明中步骤S20的流程示意图；
图3是本发明中步骤S21的流程示意图；
图4是本发明另一种手机号码的海量提取方法的部分流程示意图；
图5是本发明又一种手机号码的海量提取方法的部分流程示意图；
图6是本发明中步骤S01的流程示意图；
图7是本发明一种手机号码的海量提取系统的结构示意图；
图8是本发明再一种手机号码的海量提取方法的示意图；
图9是本发明再一种手机号码的海量提取方法的组成结构示意图；
图10是本发明提取出手机号码的效果示意图。
具体实施方式
为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对照附图说明本发明的具体实施方式。显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图，并获得其他的实施方式。
为使图面简洁，各图中只示意性地表示出了与本发明相关的部分，它们并不代表其作为产品的实际结构。另外，以使图面简洁便于理解，在有些图中具有相同结构或功能的部件，仅示意性地绘示了其中的一个，或仅标出了其中的一个。在本文中，“一个”不仅表示“仅此一个”，也可以表示“多于一个”的情形。
如图1所示，根据本发明的一个实施例，一种手机号码的海量提取方法，包括以下步骤：S10、利用Flume采集、聚合成子文本数据，并对子文本数据进行传输；再利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；
S20、将所述本地文件池内累加得到的号码文本数据上传至hadoop的云端分布式文件系统hdfs1；hadoop是分布式系统基础构架。
S40、利用hadoop的数据仓库工具hive从所述云端分布式文件系统hdfs1内号码文本数据中分布式提取URL的手机号码。
具体的，Flume是Cloudera提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传输的系统，Flume支持在日志系统中定制各类数据发送方，用于收集数据。同时，Flume提供对数据进行简单处理，并写到各种数据接受方(可定制)的能力。
hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供完整的sql查询功能，可以将sql语句转换为MapReduce任务进行运行。hive使用的是hadoop的HDFS(hadoop的分布式文件系统)，hive使用的计算模型是mapreduce。
如图1、图2、图3所示，根据本发明的另一个实施例，一种手机号码的海量提取方法，包括以下步骤：S10、利用Flume采集、聚合成子文本数据，并对子文本数据进行传输；再利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；
S21、对所述本地文件池内的子文本数据进行提取、Python的清洗后，累加合并成文本数据；Python是一种面向对象、直译式计算机程序设计语言。
优选的，所述步骤S21进一步包括：S211、提取所述子文本数据的文件名中的路由器MAC和时间戳；
S212、识别出所述路由器MAC和时间戳是否遇到乱码；
S213、当所述路由器MAC和时间戳遇到乱码时，对所述乱码进行清洗，累加合并成文本数据后，跳转至步骤S22；否则，直接跳转至步骤S22。
S22、判断所述文本数据中是否存在电话号码；
S23、当所述文本数据中不存在电话号码时，对所述文本数据进行过滤检测并删除。
S24、当所述文本数据中存在电话号码时，则对所述文本数据中的电话号码进行正则匹配处理；
S25、判断所述文本数据中的电话号码是否为新电话号码；
S26、当所述电话号码为新电话号码时，则按照所述云端分布式文件系统hdfs1的块的大小，对存在新电话号码的文本数据合并成号码文本数据；否则，将存在电话号码的文本数据合成另一号码文本数据，或者将文本数据进行过滤检测并删除。
S27、利用本地分布式文件系统hdfs2将所述号码文本数据上传至hadoop的云端分布式文件系统hdfs1；hadoop是分布式系统基础构架。
S40、利用hadoop的数据仓库工具hive从所述云端分布式文件系统hdfs1内号码文本数据中分布式提取URL的手机号码。
具体的，hadoop和mapreduce是hive架构的根基。Hive架构包括如下组件：CLI(command line interface)、JDBC/ODBC、Thrift Server、WEB GUI、metastore和Driver(Complier、Optimizer和Executor)，这些组件可以分为两大类：服务端组件和客户端组件。
服务端组件：1、Driver组件：该组件包括Complier、Optimizer和Executor，它的作用是将我们写的HiveQL(类SQL)语句进行解析、编译优化，生成执行计划，然后调用底层的mapreduce计算框架。
2、Metastore组件：元数据服务组件，这个组件存储hive的元数据，hive的元数据存储在关系数据库里，hive支持的关系数据库有derby、mysql。元数据对于hive十分重要，因此hive支持把metastore服务独立出来，安装到远程的服务器集群里，从而解耦hive服务和metastore服务，保证hive运行的健壮性。
3、Thrift服务：thrift是facebook开发的一个软件框架，它用来进行可扩展且跨语言的服务的开发，hive集成了该服务，能让不同的编程语言调用hive的接口。
客户端组件：1、CLI：command line interface，命令行接口。
2、Thrift客户端：上面的架构图里没有写上Thrift客户端，但是hive架构的许多客户端接口是建立在thrift客户端之上，包括JDBC和ODBC接口。
3、WEBGUI：hive客户端提供了一种通过网页的方式访问hive所提供的服务。这个接口对应hive的hwi组件(hive web interface)，使用前要启动hwi服务。
如图1～图4所示，根据本发明的再一个实施例，一种手机号码的海量提取方法，包括以下步骤：S10、利用Flume采集、聚合成子文本数据，并对子文本数据进行传输；再利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；
S21、对所述本地文件池内的子文本数据进行提取、Python的清洗后，累加合并成文本数据；Python是一种面向对象、直译式计算机程序设计语言。
优选的，所述步骤S21进一步包括：S211、提取所述子文本数据的文件名中的路由器MAC和时间戳；
S212、识别出所述路由器MAC和时间戳是否遇到乱码；
S213、当所述路由器MAC和时间戳遇到乱码时，对所述乱码进行清洗，累加合并成文本数据后，跳转至步骤S22；否则，直接跳转至步骤S22。
S22、判断所述文本数据中是否存在电话号码；
S23、当所述文本数据中不存在电话号码时，对所述文本数据进行过滤检测并删除。
S24、当所述文本数据中存在电话号码时，则对所述文本数据中的电话号码进行正则匹配处理；
S25、判断所述文本数据中的电话号码是否为新电话号码；
S26、当所述电话号码为新电话号码时，则按照所述云端分布式文件系统hdfs1的块的大小，对存在新电话号码的文本数据合并成号码文本数据；否则，将存在电话号码的文本数据合成另一号码文本数据，或者将文本数据进行过滤检测并删除。
S27、利用本地分布式文件系统hdfs2将所述号码文本数据上传至hadoop的云端分布式文件系统hdfs1；hadoop是分布式系统基础构架。
S30、所述数据仓库工具hive向开源计算框架TEZ发送计算请求；
S31、所述开源计算框架TEZ对所述号码文本数据进行压缩编码处理成压缩文本数据，并存储在所述云端分布式文件系统hdfs1的数据库中。其中，压缩为ORC压缩；文件存储格式为ORC。
S41、利用所述数据仓库工具hive的UDF函数以正则匹配和处理方式从所述压缩文本数据中提取URL的手机号码。
具体的，Tez是Apache最新的支持DAG作业的开源计算框架。Tez并不直接面向最终用户——事实上它允许开发者为最终用户构建性能更快、扩展性更好的应用程序。Tez项目的目标是支持高度定制化，这样它就能够满足各种用例的需要，让人们不必借助其他的外部方式就能完成自己的工作，如果Hive和Pig这样的项目使用Tez而不是MapReduce作为其数据处理的骨干，那么将会显著提升它们的响应时间。Tez构建在YARN之上，后者是Hadoop所使用的新资源管理框架。
hive文件存储格式：1.textfile为默认格式，存储方式：行存储，磁盘开销大，数据解析开销大；压缩的text文件hive无法进行合并和拆分。2.sequencefile，二进制文件，以<key,value>的形式序列化到文件中；储方式：行存储，可分割，压缩；一般选择block压缩，优势是文件和Hadoop api中的mapfile是相互兼容的。3.rcfile，存储方式：数据按行分块，每块按照列存储；压缩快，快速列存取；读记录尽量涉及到的block最少；读取需要的列只需要读取每个row group的头部定义。读取全量数据的操作性能可能比sequencefile没有明显的优势。4.orc，存储方式：数据按行分块，每块按照列存储；压缩快，快速列存取；效率比rcfile高，是rcfile的改良版本。5.自定义格式。用户可以通过实现inputformat和outputformat来自定义输入输出格式。
其中，textfile存储空间消耗比较大，并且压缩的text无法分割和合并；查询的效率最低，可以直接存储，加载数据的速度最高。sequencefile存储空间消耗最大，压缩的文件可以分割和合并，查询效率高，需要通过text文件转化来加载。rcfile存储空间最小，查询的效率最高，需要通过text文件转化来加载，加载的速度最低。
如图1～图5所示，根据本发明的又一个实施例，一种手机号码的海量提取方法，包括以下步骤：S01、搭建Hadoop的集群环境，并配置所述数据仓库工具hive、云端分布式文件系统hdfs1、本地分布式文件系统hdfs2；对Namenode HA和ResourceManager HA进行设置。
S02、在所述集群环境中各节点处搭建web服务器分布式集群，并添加负载均衡；负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
S03、实现所述数据仓库工具hive、云端分布式文件系统hdfs1、本地分布式文件系统hdfs2的建表关联；重构所述数据仓库工具hive的UDF函数。
S10、利用Flume采集、聚合成子文本数据，并对子文本数据进行传输；再利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；
S21、对所述本地文件池内的子文本数据进行提取、Python的清洗后，累加合并成文本数据；Python是一种面向对象、直译式计算机程序设计语言。
优选的，所述步骤S21进一步包括：S211、提取所述子文本数据的文件名中的路由器MAC和时间戳；
S212、识别出所述路由器MAC和时间戳是否遇到乱码；
S213、当所述路由器MAC和时间戳遇到乱码时，对所述乱码进行清洗，累加合并成文本数据后，跳转至步骤S22；否则，直接跳转至步骤S22。
S22、判断所述文本数据中是否存在电话号码；
S23、当所述文本数据中不存在电话号码时，对所述文本数据进行过滤检测并删除。
S24、当所述文本数据中存在电话号码时，则对所述文本数据中的电话号码进行正则匹配处理；
S25、判断所述文本数据中的电话号码是否为新电话号码；
S26、当所述电话号码为新电话号码时，则按照所述云端分布式文件系统hdfs1的块的大小，对存在新电话号码的文本数据合并成号码文本数据；否则，将存在电话号码的文本数据合成另一号码文本数据，或者将文本数据进行过滤检测并删除。
S27、利用本地分布式文件系统hdfs2将所述号码文本数据上传至hadoop的云端分布式文件系统hdfs1；hadoop是分布式系统基础构架。
S30、所述数据仓库工具hive向开源计算框架TEZ发送计算请求；
S31、所述开源计算框架TEZ对所述号码文本数据进行压缩编码处理成压缩文本数据，并存储在所述云端分布式文件系统hdfs1的数据库中。其中，压缩为ORC压缩；文件存储格式为ORC。
S41、利用所述数据仓库工具hive的UDF函数以正则匹配和处理方式从所述压缩文本数据中提取URL的手机号码。
具体的，负载均衡英文缩写SLB，它的主要算法如下：加权轮询(WRR)算法：为每台分配一个权重，权重表示相对于其他服务器，自身能处理连接的能力。权重为n表示SLB为下一服务器分配流量之前，要为这台服务器分配n条新连接。
加权最小连接(WLC)算法：SLB会将新连接分配给活动连接数最少的真实服务器。为每台真实服务器分配权重m，服务器处理活动连接的能力等于m除以所有服务器权重之和。SLB会将新连接分配给活动连接数远少于其能力范围的真实服务器。
使用加权最小连接(WLC)算法时，SLB使用一种慢启动的方式来控制对新加真实服务器的访问。“慢启动”限制了新连接的建立频率并允许逐渐增加，以此来防范服务器的的过载。
Namenode HA的配置，具体如下：
1.1将hadoop-2.3.0-cdh5.0.0.tar.gz解压到/opt/boh/下，并重命名为hadoop，修改etc/hadoop/core-site.xml。
1.2修改hdfs-site.xml。
1.3编辑/etc/hadoop/slaves；添加hadoop3，hadoop4。
1.4编辑/etc/profile；添加HADOOP_HOME＝/opt/boh/hadoop；PATH＝$HADOOP_HOME/bin:$HADOOP_HOME/sbin:$PATH；将以上配置复制到所有节点。
1.5启动各项服务；
1.5.1启动journalnode；在hadoop0、hadoop1、hadoop2上执行sbin/hadoop-daemon.sh start journalnode；
1.5.2格式化zookeeper；在hadoop1上执行bin/hdfs zkfc-formatZK；
1.5.3对hadoop1节点进行格式化和启动；bin/hdfs namenode-format；sbin/hadoop-daemon.sh start namenode；
1.5.4对hadoop2节点进行格式化和启动；bin/hdfs namenode-bootstrapStandby；sbin/hadoop-daemon.sh start namenode；
1.5.5在hadoop1和hadoop2上启动zkfc服务；sbin/hadoop-daemon.sh startzkfc；此时hadoop1和hadoop2就会有一个节点变为active状态；
1.5.6启动datanode；在hadoop1上执行命令sbin/hadoop-daemons.sh startdatanode；
1.5.7验证是否成功；打开浏览器，访问hadoop1:50070以及hadoop2:50070，两个namenode一个是active而另一个是standby。然后kill掉其中active的namenode进程，另一个standby的naemnode将会自动转换为active状态。
ResourceManager HA的配置，具体如下：
2.1修改mapred-site.xml。
2.2修改yarn-site.xml。
2.3将配置文件分发至各节点。
2.4修改hadoop2上的yarn-site.xml。
2.5创建目录并赋予权限：
2.5.1创建本地目录；
2.5.2启动hdfs后，执行下列命令；创建log目录；创建hdfs下的/tmp；如果不创建/tmp按照指定的权限，那么CDH的其他组件将会有问题。尤其是，如果不创建的话，其他进程会以严格的权限自动创建这个目录，这样就会影响到其他程序适用。hadoop fs-mkdir/tmp；hadoop fs-chmod-R 777/tmp。
2.6启动yarn和jobhistory server；
2.6.1在hadoop1上启动：sbin/start-yarn.sh；此脚本将会启动hadoop1上的resourcemanager及所有的nodemanager。
2.6.2在hadoop2上启动resourcemanager：yarn-daemon.sh startresourcemanager；
2.6.3在hadoop2上启动jobhistory server；sbin/mr-jobhistory-daemon.shstart historyserver。
2.7验证是否配置成功。打开浏览器，访问hadoop1:23188或者hadoop2:23188。
如图1～图6所示，根据本发明的又又一个实施例，一种手机号码的海量提取方法，包括以下步骤：S01、搭建Hadoop的集群环境，并配置所述数据仓库工具hive、云端分布式文件系统hdfs1、本地分布式文件系统hdfs2；对Namenode HA和ResourceManager HA进行设置。
所述步骤S01进一步包括：S011、在Hadoop上搭建第一预设个数(例如第一预设个数为4)的主节点master、第二预设个数(例如第二预设个数为7)的从节点slave；各个主节点master之间相互连接，每个主节点master分别与各个从节点slave相连。
S012、每个主节点master上组建有元数据服务组件metastore、关系数据库mysql、HiveServer2。通过HiveServer2，客户端可以在不启动CLI的情况下对Hive中的数据进行操作，连这个和都允许远程客户端使用多种编程语言如java，python等向hive提交请求，取回结果。HiveServer2都是基于Thrift的，HiveServer2支持多客户端的并发和认证，为开放API客户端如JDBC、ODBC提供更好的支持。
S02、在所述集群环境中各节点处搭建web服务器分布式集群，并添加负载均衡；负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
S03、实现所述数据仓库工具hive、云端分布式文件系统hdfs1、本地分布式文件系统hdfs2的建表关联；重构所述数据仓库工具hive的UDF函数。
S10、利用Flume采集、聚合成子文本数据，并对子文本数据进行传输；再利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；
S21、对所述本地文件池内的子文本数据进行提取、Python的清洗后，累加合并成文本数据；Python是一种面向对象、直译式计算机程序设计语言。
优选的，所述步骤S21进一步包括：S211、提取所述子文本数据的文件名中的路由器MAC和时间戳；
S212、识别出所述路由器MAC和时间戳是否遇到乱码；
S213、当所述路由器MAC和时间戳遇到乱码时，对所述乱码进行清洗，累加合并成文本数据后，跳转至步骤S22；否则，直接跳转至步骤S22。
S22、判断所述文本数据中是否存在电话号码；
S23、当所述文本数据中不存在电话号码时，对所述文本数据进行过滤检测并删除。
S24、当所述文本数据中存在电话号码时，则对所述文本数据中的电话号码进行正则匹配处理；
S25、判断所述文本数据中的电话号码是否为新电话号码；
S26、当所述电话号码为新电话号码时，则按照所述云端分布式文件系统hdfs1的块的大小，对存在新电话号码的文本数据合并成号码文本数据；否则，将存在电话号码的文本数据合成另一号码文本数据，或者将文本数据进行过滤检测并删除。
S27、利用本地分布式文件系统hdfs2将所述号码文本数据上传至hadoop的云端分布式文件系统hdfs1；hadoop是分布式系统基础构架。
S30、所述数据仓库工具hive向开源计算框架TEZ发送计算请求；
S31、所述开源计算框架TEZ对所述号码文本数据进行压缩编码处理成压缩文本数据，并存储在所述云端分布式文件系统hdfs1的数据库中。其中，压缩为ORC压缩；文件存储格式为ORC。
S41、利用所述数据仓库工具hive的UDF函数以正则匹配和处理方式从所述压缩文本数据中提取URL的手机号码。
具体的，Master/Slave相当于Server和agent的概念。Master提供web接口让用户来管理job和slave，job可以运行在master本机或者被分配到slave上运行。一个master可以关联多个slave用来为不同的job或相同的job的不同配置来服务。
Hive的metastore组件是hive元数据集中存放地。Metastore组件包括两个部分：metastore服务和后台数据的存储。后台数据存储的介质就是关系数据库，例如hive默认的嵌入式磁盘数据库derby，还有mysql数据库。Metastore服务是建立在后台数据存储介质之上，并且可以和hive服务进行交互的服务组件，默认情况下，metastore服务和hive服务是安装在一起的，运行在同一个进程当中。也可以把metastore服务从hive服务里剥离出来，metastore独立安装在一个集群里，hive远程调用metastore服务，可以把元数据这一层放到防火墙之后，客户端访问hive服务，就可以连接到元数据这一层，从而提供了更好的管理性和安全保障。使用远程的metastore服务，可以让metastore服务和hive服务运行在不同的进程里，这样也保证了hive的稳定性，提升了hive服务的效率。
如图7所示，根据本发明的一个实施例，一种手机号码的海量提取系统，包括：搭建Hadoop的集群环境，并配置所述数据仓库工具hive、云端分布式文件系统hdfs1、本地分布式文件系统hdfs2；对Namenode HA和ResourceManager HA进行设置。
在Hadoop上搭建第一预设个数(例如第一预设个数为4)的主节点master、第二预设个数(例如第二预设个数为7)的从节点slave；各个主节点master之间相互连接，每个主节点master分别与各个从节点slave相连。
每个主节点master上组建有元数据服务组件metastore、关系数据库mysql、HiveServer2。通过HiveServer2，客户端可以在不启动CLI的情况下对Hive中的数据进行操作，连这个和都允许远程客户端使用多种编程语言如java，python等向hive提交请求，取回结果。HiveServer2都是基于Thrift的，HiveServer2支持多客户端的并发和认证，为开放API客户端如JDBC、ODBC提供更好的支持。
在所述集群环境中各节点处搭建web服务器分布式集群，并添加负载均衡；负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。
实现所述数据仓库工具hive、云端分布式文件系统hdfs1、本地分布式文件系统hdfs2的建表关联；重构所述数据仓库工具hive的UDF函数。
分布式web服务器框架，利用Flume采集、聚合成子文本数据，并对子文本数据进行传输；再利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；
分布式web服务器框架，对所述本地文件池内的子文本数据进行提取、Python的清洗后，累加合并成文本数据；Python是一种面向对象、直译式计算机程序设计语言。
优选的，分布式web服务器框架，提取所述子文本数据的文件名中的路由器MAC和时间戳；识别出所述路由器MAC和时间戳是否遇到乱码；当所述路由器MAC和时间戳遇到乱码时，对所述乱码进行清洗，累加合并成文本数据。判断所述文本数据中是否存在电话号码；当所述文本数据中不存在电话号码时，对所述文本数据进行过滤检测并删除。当所述文本数据中存在电话号码时，则对所述文本数据中的电话号码进行正则匹配处理；判断所述文本数据中的电话号码是否为新电话号码；当所述电话号码为新电话号码时，则按照所述云端分布式文件系统hdfs1的块的大小，对存在新电话号码的文本数据合并成号码文本数据；否则，将存在电话号码的文本数据合成另一号码文本数据，或者将文本数据进行过滤检测并删除。
本地分布式文件系统hdfs2，利用本地分布式文件系统hdfs2将所述号码文本数据上传至hadoop的云端分布式文件系统hdfs1；hadoop是分布式系统基础构架。
数据仓库工具hive，所述数据仓库工具hive向开源计算框架TEZ发送计算请求；
开源计算框架TEZ，所述开源计算框架TEZ对所述号码文本数据进行压缩编码处理成压缩文本数据，并存储在所述云端分布式文件系统hdfs1的数据库中。其中，压缩为ORC压缩；文件存储格式为ORC。
所述数据仓库工具hive，利用所述数据仓库工具hive的UDF函数以正则匹配和处理方式从所述压缩文本数据中提取URL的手机号码。
如图8、图9、图10所示，根据本发明的再一个实施例，一种海量URL的数据提取方法，包括：搭建Hadoop2.7.1的集群环境(部署4个master，7个slave)，并配置好HIVE、HDFS等环境与配置(Hive Metastore、mysql、hiveserver2等组建在一台master上)。并设置好Namenode HA和ResourceManager HA，使分布式系统满足高可用性！
各节点搭建tomcat分布式集群，添加负载均衡。
实现hive、hdfs的建表关联，开发相对应的hive的UDF函数，并且测试提取功能正常。
完成基于hive的电话号码匹配的正则表达式程序，通过UDF函数编译完成功能结合。
通过分布式的web服务器框架，将文本数据收集到本地文件池；通过对文件池里的文件进行清洗、提取、合并；按照HDFS的块的大小进行累加合并，合并完利用local HDFS完成数据的高效上传；再通过自己开发的Hive的UDF函数getNUM来完成对数据中的URL的电话号码进行正则匹配和处理，完成URL海量数据的高效提取。
相同的用户电话号码，对应四个不同的终端MAC，和四个不同的家庭路由器MAC，并计算出用户电话在不同路由器下的不同终端的出现次数，这样通过高效的分布式计算，能从海量的用户数据里得到用户真正的终端访问情况，并以此精准到用户的使用终端，为用户带来更优质的服务。
运行清洗、合并、上传、高压缩编码、分布式提取的程序。
将结果输出和进一步深入分析。
hive：是apache开源的技术，数据仓库软件提供对存储在分布式中的大型数据集的查询和管理，它本身是建立在Apache Hadoop之上。Hive SQL代表的是以传统基于Mapreduce为核心的SQL语言。
在大数据应用场景下，随着数据海量增加，直接利用本地计算对原始数据的进行提取，会消耗大量资源和内存，并且效率低下，但利用hive调用Hadoop进行分布式计算来进行正则匹配手机号码，效率高且消耗资源低。本发明主要是在通过hive的UDF自适应开发功能与Python的清洗、合并、上传及hive的ORC压缩结合，形成了一个高性能的手机号码提取方法。
应当说明的是，上述实施例均可根据需要自由组合。以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (9)

1.一种手机号码的海量提取方法，其特征在于，包括以下步骤：
S10、利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；
S20、将所述本地文件池内累加得到的号码文本数据上传至hadoop的云端分布式文件系统hdfs1，所述S20进一步还包括：
S24、当所述文本数据中存在电话号码时，则对所述文本数据中的电话号码进行正则匹配处理；
S25、判断所述文本数据中的电话号码是否为新电话号码；
S26、当所述电话号码为新电话号码时，则按照所述云端分布式文件系统hdfs1的块的大小，对存在新电话号码的文本数据合并成号码文本数据；
S27、利用本地分布式文件系统hdfs2将所述号码文本数据上传至所述云端分布式文件系统hdfs1；
S40、利用hadoop的数据仓库工具hive从所述云端分布式文件系统hdfs1内号码文本数据中分布式提取URL的手机号码。
2.如权利要求1所述的手机号码的海量提取方法，其特征在于，所述步骤S20进一步包括：
S21、对所述本地文件池内的子文本数据进行提取、清洗后，累加合并成文本数据；
S22、判断所述文本数据中是否存在电话号码；
S23、当所述文本数据中不存在电话号码时，则对所述文本数据进行过滤检测并删除。
3.如权利要求2所述的手机号码的海量提取方法，其特征在于，所述步骤S21进一步包括：
S211、提取所述子文本数据的文件名中的路由器MAC和时间戳；
S212、识别出所述路由器MAC和时间戳是否遇到乱码；
S213、当所述路由器MAC和时间戳遇到乱码时，则对所述乱码进行清洗，累加合并成文本数据后，跳转至步骤S22；否则，直接跳转至步骤S22。
4.如权利要求1所述的手机号码的海量提取方法，其特征在于，还包括以下步骤：
S30、所述数据仓库工具hive向开源计算框架TEZ发送计算请求；
S31、所述开源计算框架TEZ对所述号码文本数据进行压缩编码处理成压缩文本数据，并存储在所述云端分布式文件系统hdfs1的数据库中。
5.如权利要求4所述的手机号码的海量提取方法，其特征在于，所述步骤S40进一步包括：
S41、利用所述数据仓库工具hive的UDF函数从所述压缩文本数据中提取URL的手机号码。
6.如权利要求1～5中任意一项所述的手机号码的海量提取方法，其特征在于，在所述步骤S10之前还包括：
S01、搭建Hadoop的集群环境，并配置所述数据仓库工具hive、云端分布式文件系统hdfs1、本地分布式文件系统hdfs2；
S02、在所述集群环境中各节点处搭建web服务器分布式集群，并添加负载均衡；
S03、实现所述数据仓库工具hive、云端分布式文件系统hdfs1、本地分布式文件系统hdfs2的建表关联；重构所述数据仓库工具hive的UDF函数。
7.如权利要求6所述的手机号码的海量提取方法，其特征在于，在所述步骤S01进一步包括：
S011、在Hadoop上搭建第一预设个数的主节点master、第二预设个数的从节点slave；各个主节点master之间相互连接，每个主节点master分别与各个从节点slave相连。
8.如权利要求7所述的手机号码的海量提取方法，其特征在于，所述步骤S01进一步还包括：
S012、每个主节点master上组建有元数据服务组件metastore、关系数据库mysql。
9.一种应用在如权利要求1～8中任意一项所述的手机号码的海量提取方法的系统，其特征在于，包括：
分布式web服务器框架，利用分布式web服务器框架，分别将各URL中的子文本数据收集到本地文件池；
本地分布式文件系统hdfs2，将所述本地文件池内累加得到的号码文本数据上传至hadoop的云端分布式文件系统hdfs1；
数据仓库工具hive，利用hadoop的数据仓库工具hive从所述云端分布式文件系统hdfs1内号码文本数据中分布式提取URL的手机号码。
CN201610970408.0A 2016-10-28 2016-10-28 一种手机号码的海量提取方法及系统 Active CN106570152B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610970408.0A CN106570152B (zh) 2016-10-28 2016-10-28 一种手机号码的海量提取方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610970408.0A CN106570152B (zh) 2016-10-28 2016-10-28 一种手机号码的海量提取方法及系统

Publications (2)

Publication Number Publication Date
CN106570152A CN106570152A (zh) 2017-04-19
CN106570152B true CN106570152B (zh) 2020-12-22

Family

ID=58541640

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610970408.0A Active CN106570152B (zh) 2016-10-28 2016-10-28 一种手机号码的海量提取方法及系统

Country Status (1)

Country Link
CN (1) CN106570152B (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107145542A (zh) * 2017-04-25 2017-09-08 上海斐讯数据通信技术有限公司 从url中高效提取用户客户端id的方法和系统
CN107193903A (zh) * 2017-05-11 2017-09-22 上海斐讯数据通信技术有限公司 高效处理ip地址区域定位的方法和系统
CN112769801B (zh) * 2020-12-31 2023-05-02 深圳软牛科技有限公司 从云服务器提取备份的方法、装置、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103619005A (zh) * 2013-11-25 2014-03-05 中国联合网络通信集团有限公司 一种获取3g网络用户手机号码的方法及系统
KR101435789B1 (ko) * 2013-01-29 2014-08-29 (주)소만사 Ｄｌｐ 시스템의 빅데이터 처리 시스템 및 방법
CN105677842A (zh) * 2016-01-05 2016-06-15 北京汇商融通信息技术有限公司 基于Hadoop大数据处理技术的日志分析系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101435789B1 (ko) * 2013-01-29 2014-08-29 (주)소만사 Ｄｌｐ 시스템의 빅데이터 처리 시스템 및 방법
CN103619005A (zh) * 2013-11-25 2014-03-05 中国联合网络通信集团有限公司 一种获取3g网络用户手机号码的方法及系统
CN105677842A (zh) * 2016-01-05 2016-06-15 北京汇商融通信息技术有限公司 基于Hadoop大数据处理技术的日志分析系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
flume学习：flume将log4j日志数据写入到hdfs;xiaojun_0820;《https://blog.csdn.net/xiao_jun_0820/article/details/38110323》;20140725;全文 *
tez控制输出的文件是否压缩并指定文件名;chen476328361;《https://blog.csdn.net/thinking2013/article/details/48133137》;20150831;第1页 *

Also Published As

Publication number Publication date
CN106570152A (zh) 2017-04-19

Similar Documents

Publication Publication Date Title
US11711420B2 (en) Automated management of resource attributes across network-based services
CN108052681B (zh) 一种关系型数据库间结构化数据的同步方法及系统
CN109074377B (zh) 用于实时处理数据流的受管理功能执行
US10338958B1 (en) Stream adapter for batch-oriented processing frameworks
JP5298117B2 (ja) 分散コンピューティングにおけるデータマージング
US9426219B1 (en) Efficient multi-part upload for a data warehouse
Lai et al. Towards a framework for large-scale multimedia data storage and processing on Hadoop platform
CN102193917A (zh) 一种数据处理和查询方法和装置
CN111258978B (zh) 一种数据存储的方法
CN106570153A (zh) 一种海量url的数据提取方法及系统
CN106570152B (zh) 一种手机号码的海量提取方法及系统
CN103514205A (zh) 海量数据处理方法和系统
US10262024B1 (en) Providing consistent access to data objects transcending storage limitations in a non-relational data store
US11741144B2 (en) Direct storage loading for adding data to a database
CN116680040B (zh) 一种容器处理方法、装置、设备、存储介质及程序产品
CN110781505A (zh) 系统构建方法及装置、检索方法及装置、介质和设备
Xu et al. ZQL: a unified middleware bridging both relational and NoSQL databases
CN113282611A (zh) 一种流数据同步的方法、装置、计算机设备及存储介质
CN106570151A (zh) 一种海量文件的数据收集处理方法及系统
US9760576B1 (en) System and method for performing object-modifying commands in an unstructured storage service
CN109460389B (zh) 一种基于openresty的日志记录方法
De Luca et al. Distributed genomic compression in MapReduce paradigm
US10133713B2 (en) Domain specific representation of document text for accelerated natural language processing
CN106919574B (zh) 一种实时处理远程同步文件的方法
Gupta et al. Efficient query analysis and performance evaluation of the NoSQL data store for bigdata

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20201026

Address after: 318015 no.2-3167, zone a, Nonggang City, no.2388, Donghuan Avenue, Hongjia street, Jiaojiang District, Taizhou City, Zhejiang Province

Applicant after: Taizhou Jiji Intellectual Property Operation Co.,Ltd.

Address before: 201616 Shanghai city Songjiang District Sixian Road No. 3666

Applicant before: Phicomm (Shanghai) Co.,Ltd.

TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20201203

Address after: 12b12-1, building 4, Wanda Plaza, duohu street, Jindong District, Jinhua City, Zhejiang Province, 321015

Applicant after: Jinhua Zhizhen communication equipment Co.,Ltd.

Address before: 318015 no.2-3167, zone a, Nonggang City, no.2388, Donghuan Avenue, Hongjia street, Jiaojiang District, Taizhou City, Zhejiang Province

Applicant before: Taizhou Jiji Intellectual Property Operation Co.,Ltd.

GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right
TR01 Transfer of patent right

Effective date of registration: 20221229

Address after: 313000 room 1019, Xintiandi commercial office, Yishan street, Wuxing District, Huzhou, Zhejiang, China

Patentee after: Huzhou YingLie Intellectual Property Operation Co.,Ltd.

Address before: 12b12-1, building 4, Wanda Plaza, duohu street, Jindong District, Jinhua City, Zhejiang Province, 321015

Patentee before: Jinhua Zhizhen communication equipment Co.,Ltd.