石家庄建设厅网站,公司黄页企业名录在哪里查,湖北做网站公司,郑州企业建网站制作TableStore是阿里云自研的在线数据平台#xff0c;提供高可靠的存储#xff0c;实时和丰富的查询功能#xff0c;适用于结构化、半结构化的海量数据存储以及各种查询、分析。
爬虫数据特点
在众多大数据场景中#xff0c;爬虫类型的数据非常适合存储在TableStore。主要是…TableStore是阿里云自研的在线数据平台提供高可靠的存储实时和丰富的查询功能适用于结构化、半结构化的海量数据存储以及各种查询、分析。
爬虫数据特点
在众多大数据场景中爬虫类型的数据非常适合存储在TableStore。主要是因为爬虫类型数据的一些特征和TableStore和匹配
数据量大
爬虫数据一般都是抓取的互联网上的某个行业或领域的数据数据规模和这个行业的数据规模有关比如资讯类每时每刻都在产生大量新闻报道这个数据规模可能在10 TB到100 TB级别如果考虑到历史存量数据那么规模可能会更大。这么大量的数据存储已经不适合用单机的关系型数据库了也不适合分库分表了而需要一款分布式NoSQL数据库这样可以将数据按一定的路由规则分布到不同机器上实现自动的水平扩展非常适合存储海量数据尤其是爬虫类。
宽行和稀疏列
爬虫的数据一般来源于多个数据源比如资讯数据可以来自人民网、新浪或者腾讯每个数据源的数据特征不可能完全一样每家有每家的特殊性这样就会出现每一行数据的属性列有差异虽然可以归一化处理后可以将通用的属性列统一但是不同数据源还是会存在一定差异性。如果为每个数据源建立一张表那么工作量就会非常大也不适合。这时候就需要用到宽行和稀疏列功能既能保证列数无上限也能保证不同行不同列还可以不额外增加存储成本和运维成本。
查询类型多样
爬虫数据的存储后一般有两个出口一个是数据处理程序数据处理程序会读取最新的爬虫数据然后按照自定义的处理逻辑做数据加工处理完后会新数据写入原表或新表。
数据处理完之后数据可以提供给下游企业客户或终端用户使用了场景的查询需求有下列几种
多种属性列组合查询。比如全网简历信息里面通过年龄、学历、专长查询且每个人查询的条件可能都完全不一样需要多种属性列的自由组合查询。分词查询。不管是咨询类还是简历类都有大量的文本描述这部分内容都需要支持分词后再查询。排序能力。比如资讯类数据中查询某个新闻后需要按时间逆序返回越新的数据价值越大。随机读能力。如果是用来做全局数据分析或处理那么随机读是一种必须要有的能力。轻量级统计分析。比如资讯类想查看某个热点新闻的传播时间段和趋势就需要统计每个时间段的此类新闻出现次数。 这些查询能力在传统的关系型数据库或者开源NoSQL中都无法提供。
开源解决方案
爬虫数据存储的方案已经演进了将近二十年了千奇百怪的各种方案都有主要的差异来源于两点
当前能获取到的存储系统能力。自身对系统可靠性、可用性的要求高低。 我们下面以当前业界流行的开源系统为材料打造一个爬虫数据存储的系统。
当前业内的开源存储系统有两大类一类是开源的关系型数据库比如MySQL等一类是NoSQL比如HBase等。这两类数据存储系统都不能支持分词查询那么还需要一个全文检索的系统当前可选的有solr和Elasticsearch。
基于上述的素材我们就可以搭建一个存储爬虫的系统了
首先选择存储系统MySQL和HBase都可以如果使用MySQL则需要分库分表两者架构图差不多这里我们就选择HBase。再次选择查询系统可选的solr和Elasticsearch虽然是同一类型系统但是Elasticsearch的目前更流行那我们也选择Elasticsearch。 这样架构图大致如下大概解释下
流程爬虫系统将抓取的数据写入HBase离线集群然后数据处理系统周期性或流式的处理新到的数据将处理后的结果写入HBase在线集群。HBase在线集群存储所有属性列的值然后将需要查询的列通过co-processor发送给消息队列最后再将消息队列中的数据被Elasticsearch消费生成索引。最后用户通过索引查询到PK然后通过proxy到HBase在线集群读取这一行完整数据最后返回给用户。数据存储集群有两个一个是在线集群一个是离线集群原因是为了避免减少离线集群对在线查询的影响因为离线系统重吞吐而在线系统重延迟所以这里会分成两个集群目的是挺高系统可用性。消息队列的目的是削峰填谷减少对下游系统Elasticsearch的压力同时当Elasticsearch写入慢或者出故障后不至于影响上游系统目的也是为了提高系统可用性避免单点故障导致整个系统雪崩。Proxy的目的是减轻客户端工作量提高易用性的工具原因是爬虫数据是系数列这些列不可能全部都在Elasticsearch中创建索引只有部分需要查询、分析的属性列才会在Elasticsearch中建立索引但是查询的时候也需要未建立索引的字段这样就需要一个系统做反查和合并就是先查Elasticsearch获取到PK然后通过PK到HBase在线集群查询这一行完整数据。这个系统中需要运维6个不同开源系统运维压力比较大。
TableStore云解决方案
最开始我们说TableStore很适合存储爬虫数据在介绍了开源系统的解决方案后我们再来看一下TableStore的解决方案以及相对于开源系统可以为客户带来的收益。
也先看一下架构图 大概解释下
爬虫系统抓取的数据写入TableStore的离线表然后经过TunnelService的流式通道数据进入数据处理系统做处理加工再将加工后的数据写入在线表用户直接查询在线表即可。将离线表和在线表同时放在TableStore服务中会不会出现离线表干扰在线表的情况这个不会的TableStore服务内部有自动的负载均衡和隔离系统会自动处理这些问题。所有的查询都可以直接查询在线表及其索引提供了多字段组合查询、分词查询、排序和统计分析等功能完全可以满足用户对查询的需求。数据处理部分一般有两种处理方式一种是离线全量处理这种可以使用阿里云的MaxCompute系统MaxCompute可以直读TableStore的数据做计算不需要额外把数据导过去。另一种是流式实时处理TableStore提供了TunnelService系统可以获取到实时的Table中的数据更新记录然后将更新记录发送到函数计算、流式计算系统或者自己的应用、flink等系统处理。这个架构中用户只需要运维2个系统即可。
示例
我们接下来举一个简历类爬虫数据存储和查询的示例帮忙读者快速理解。
简历一般是一个PDF文档或者doc文档是一个文件但是我们可以从这些文件中抽取出结构化的信息比如姓名、电话号码、身份证、邮箱、毕业学校、学历、专业领域、项目经验、兴趣、期望薪水和工作年限等。
首先我们设计TableStore中主表结构
主键列属性列属性列属性列属性列属性列属性列属性列属性列属性列身份证姓名电话号码邮箱毕业学校学历专业领域项目经验兴趣期望薪水工作年限StringStringStringStringStringStringStringStringStringLongDouble61xxx5王一152xxx7aaxx.comMIT硕士[数据库MySQL]1.数据库binlog优化。[足球]200003.5
大概解释下
主键列需要一个唯一值用来唯一确定某个人这里我们用了身份证有些场景获取不到身份证那可以用手机号或其他ID。后面几个全部是属性列包括姓名电话号码等。期望薪水因为都是整数所以可以选择Long类型工作年限由于有小数所以可以是Double类型。通过这张表我们可以通过身份证查询到该用户的详细信息。但是无法通过属性列查询如果需要通过属性列查询则需要创建多元索引。
然后我们再创建多元索引多元索引的结构如下:
属性列属性列属性列属性列属性列属性列属性列属性列属性列姓名电话号码毕业学校学历专业领域项目经验兴趣期望薪水工作年限Text单字分词KeywordKeywordKeywordKeyword ArrayText多层语义Keyword ArrayLongDouble
解释下
上面的多元索引结构中包括9列比Table中少了2列是因为不需要通过“邮箱”和“身份证”两个属性列查询所以在建立index的时候就不需要为这两列创建index了。但是如果业务中确实需要通过邮箱查询那么多元索引创建时加上邮箱即可。姓名的类型是Text单字分词意思是类型是Text分词是单子分词这样好处就是我可以通过搜索“小刚”搜索到“王小刚”、“冯小刚”等。电话号码、毕业院校、学历都是Keyword类型对应Table中的String因为这些都字符串都比较短且查询方式是直接完全匹配或者前缀查询那么用String就可以了。专业领域和项目经验两个属性列是Keyword Array的因为是这两个属性列中会包括多个值查询的时候只要有一个满足就可以返回比如某个人的专业领域是数据库、MySQL那么我们查询“数据库”的时候希望这个人返回。期望薪水和工作年限是数字类型的Long和Double这样这两个属性列就可以支持范围查找比如查找工作年限大于2年小于5年且期望薪水小于2万的简历。
至此我们就把简历库的table和index都建好了用户就可以往Table中开始写数据数据写入后会异步同步到Index中这样就可以通过Index查询了。
总结
使用TableStore解决方案后相对于开源解决方案可以带来不少的收益
减少运维负担
使用开源系统的架构中需要运维6个系统包括了3个开源系统HBase、Kafka和Elasticsearch为了运维这三个开源系统需要有人对这三个系统比较熟悉否则很难运维好。就算比较熟悉也很难处理线上遇到的所有的问题总会碰到无法解决的棘手问题而影响生产环境。
如果使用了TableStore云解决方案那么就不需要运维任何开源系统只需要运维自己开发的两个系统同时关注TableStore中的两个表就可以了这两张表的运维全部是TableStore服务负责且提供SLA保障绝对比自己运维开源系统的可用性要高。
同时采用TableStore方案后由于TableStore支持实时自动扩容客户不再需要提前规划水位和集群容量也不用担心高水位和突发流量对系统的冲击将这些工作都交给了更擅长的云服务处理。
这样不仅降低了运维的工作量和压力同时也降低了系统风险提高了系统整体的可用性。
减少时间成本
TableStore云架构方案相对于开源方案系统更少从零开始到上线需要的开发时间更少同时TableStore是serverless的云服务全球多个区域即开即用可以大大降低客户的开发上线的时间提前将产品推出抢先争取市场领先优势。
同时TableStore支持按量付费用户完全可以根据真实使用量付费不再需要担心低峰期系统资源的浪费了一定程度上也能降低使用成本。
最后
目前已经有不少行业的客户在使用TableStore存储爬虫数据比如资讯类、生活类、文章类等等也有部分用户在小数据量级时使用MySQL等关系型数据库等数据规模大了后被迫迁移到TableStore存储。同时欢迎更多的客户开始使用TableStore存储你们的爬虫数据。
原文链接 本文为云栖社区原创内容未经允许不得转载。
