数据不再遥远——如何构建企业级的数据分析平台

前言：

马总说过这是一个DT的时代，一个从IT到DT转变的时代。确实这几年到处都能听到诸如“云计算”、“大数据”、“上云”的谈论，确实随着云计算的兴起，依托于相对低成本、高稳定性的云设施构建平台的成本越来越低，越来越多的公司都在推数据相关的平台、产品。如阿里、京东、百度、腾讯，以及一些打着大数据旗号的创业公司都有出自己的数据平台和产品，用户依托于平台确实大大降低了数据处理、使用的难度，降低了从数据挖掘价值的时间成本。但平台不会产生数据，平台只会降低使用方的成本，现在很少有平台能提供一站式的服务。没有数据的平台就如一台没有汽油的引擎，数据就是让引擎发动的燃料。那么如何打造一个闭环的数据平台，笔者在这里分享一下自己的经验。

涉及技术：

Python体系:

Python、Scrapy、django、sklearn、tensorflow、文本处理相关包等一些列包

Java体系:

Java、ElasticSearch、Kibana、Logstash、LogHub(阿里云)、ODPS(阿里云)

Spark体系:

Spark-streaming、elasticsearch-hadoop、MLLib

其他：

tor、Docker、redis、kafka

先举例说下已经解决的业务问题(链接)

这里选择三个不同行业的用户案例。

问题：我是一个传统纺织企业，我是做墙布生产的（诗画江南墙布），我们现在也要做网上销售，我要知道现在网上那些墙布卖的好，用户有什么评价，用户喜欢什么样的墙布。

解决方案：

结合国内各大电商网站的墙布数据(目前结合京东、淘宝、天猫)，统计指定搜索关键词对应的商品和店铺，爬取所有墙布商品的信息和评论信息、爬取所有销售墙布的店铺的信息。对商品和店铺进行汇总、让用户看到那些商品卖的最好、那些店铺卖的最多。对评论做分析，剔除不可用评论、无用评论，分析出正向评论和负面评论，最正向和负面做聚类，让用户看到为什么好、为什么不好.

问题：我是房产中介，我要尽可能的知道租户的需求，我要知道我这片区有那些用户需要租房，租什么样的、价格是多少

解决方案：

对租房相关社区做挖掘(这里选择豆瓣)，挖掘租房小组的相关帖子，首先识别出租房帖还是出租帖子，并分别在评论中挖掘出潜在的租房者，将处理后的信息(租房者、租房区域、价格、要求等)展示给中介。

问题：我是跨境电商的运营，现在负责选品工作，我想知道现在国外那些商品比较流行，我选什么商品可能流行

解决方案：

挖掘国外潮流、电商、社交网站，对图像和文本进行算法处理，目前针对服饰(主要是女装、首饰)这个大的一级类目，得到潮流的搭配和商品。

看了上面三个不同行业的案例，针对不同的需求基本上都需要经过数据爬取、算法处理、可视化。那么我们要解决的问题主要集中在这三个大的方向上。

具体说说我们要解决的问题是什么？

1. 数据获取
2. 数据结构化处理
3. 数据挖掘
4. 数据可视化
5. 数据实时性的问题
6. 稳定、灵活、扩展性

针对第一个问题，数据获取一直是一个相对重要的问题，如果数据采集不够(不一定是量上的不足，还可能是覆盖性的不足)，那么最终的结果可能也会相对失真。数据的获取可以分为内部数据获取和外部数据获取两部分。针对内部的数据如何将数据接入平台这大部分还只是一个适配的问题，对于外部数据的获取，一方面可以购买，更过的是采用爬虫的方式获取。这里笔者要解决的问题主要是内部数据的适配问题和外部数据的爬取问题。

数据结构化处理，一直都是一个脏活累活，但又不得不面对的问题。一方面涉及一些建模问题，建模的目的是为了更灵活的应用数据，使得模型能够尽可能的满足变化的也无需求。另一方面又涉及到存储问题，这里笔者采用ElasticSearch作为开放数据存储，使用ODPS作为全量数据存储，后文这一部分不做过多赘述。

数据挖掘，这部分主要是对现有数据的挖掘，涉及的是算法知识，这里不对具体算法做展开，我们的平台最开始是依赖sklearn做算法工作，随着数据量和业务需求的不同，慢慢将一些任务迁移到Spark平台上处理，随着tensorflow的开源，我们将一些图像、文本挖掘的任务转移到了tensorflow上来，现在是sklearn、Spark-MLLib、tensorflow共存。

数据可视化，这部分主要是和用户交互的部分，要解决的是用户如何看数据的问题，由于team中缺少专业的前端、UED，所以这部分采用开源的Kibana作为展示的载体。

实时性问题，这个问题是数据平台要解决的问题，需要解决数据按照业务需求更新的问题、还要解决结果的实时性的问题。这里数据更新主要是依托爬虫的定时调度，实时性的问题主要通过流式计算来解决。

稳定、灵活、扩展性的问题，这主要涉及架构的问题，要解决系统的可扩展性、稳定性、高效、灵活部署的问题。

如何解决这些问题

数据获取——搭建高效的分布式爬虫平台

说道爬虫，很多人都不以为然，因为开源的爬虫平台就很多，而且这个技术有事很成熟的。的确爬虫技术确实入门很低，但真正能解决问题的爬虫平台却很少，很多人会分分钟丢出Nutch、scrapy等用的比较多的框架来反驳。确实这些框架可以解决一些问题，但我们还是需要对这些框架做很多开发性的工作，才能让这个爬虫平台更好的运行。我们在解决这个问题的时候选择了Scrapy,因为他是Python技术栈的，并且高效简单，通过插件的方式可扩展性比较好，Nutch是Java技术栈的真心太重了。

接下来说说我们要解决现有的爬虫的什么问题(去重、头部伪装等这些通用的就不介绍了)
1. 反屏蔽
2. 动态渲染问题
3. 流量控制问题

反屏蔽的问题目前的解决方式主要通过代理的方式来解决，通过不断的更改代理的方式来访问对方网站。对于防范措施更严重的目标网站我们使用tor来解决出口的问题(豆瓣的反爬取能力就比较强)。

目前我们积累了上万的代理，有专门的爬取任务爬取众多的国内外代理网站，该部分大致入下

负责爬取的任务不断爬取数据丢给redis，新来的数据都放到队列的尾部，校验服务不断的从队列头部拉取代理数据进行可用性校验，校验后存入新的redis队列中，供给其他爬虫使用。当然这里不是终结，爬虫使用过程汇总还会对Proxy做各种打标，标记处那些可用、那些不可用、速率等，后续使用或统计的时候，会根据标签做决定。

对于那些难搞的对手，如豆瓣、欧铁等，采用低质量的代理速率很慢很慢，慢到比人操作的还要慢很多很多。这种情况就采用tor这一匿名网络来搞这样的任务，同时这也能很好的避免法务问题，但这需要境外服务器，在天朝这个是不太好搞得。好在Amazon的服务器是按需收费的，我们需要的时候就启用境外的服务器进行爬取。关于tor的使用、配置这里不做介绍,国内更多叫洋葱头，可以参考https://www.torproject.org。

对于动态渲染的问题一直是爬虫的痛点，一般的爬虫处理的是down下来的html文本，但越来越多的网站现在才去动态渲染的方式，比如电商的活动页，所有的信息都是异步ajax渲染出来的，传统爬虫这就无能为力了。我们目前采用PhantomJS作为渲染引擎，这样下载的页面和所见的页面是一致的，可以进行数据的抽取。

还有一个比较核心的问题就是流量控制，如果不加以流控，对方很快就会查封你的IP(默认是不开启代理模式的，当检测到大量网络失败的情况才开启代理模式)，即使开启代理，鉴于代理质量问题，也不能疯狂的轮换代理，所以比较好的方式是动态控制爬取速率，好在Scrapy可以调节爬取速率，我们采用动态窗口的方式动态的调节爬取速率，使得在一个较好的速率下进行爬取。

数据初步处理与展示——基于ELK和LogHub、ODPS的一体化解决方案

有了数据如何将数据结构化处理、存储和展示也是一个要解决的问题，这里我们选择了开源的ELK(ElasticSearch、Logstash、Kibana)组合来解决这个问题.

通过Logstash将爬虫爬取的数据、已存在的其他数据、中间件中的数据、网络数据、DB数据等通过Logstash的数据处理pipline，最终将规格化后的数据写到ES集群中，供后续使用。同时对于一些有明确持久化需求的用户，我们采用阿里云的loghub，将我们的爬取数据同步到我们的ODPS对应的Project的表中，如果对方是基于阿里云的服务，那么可以直接配置同步任务，将我们的数据从我们的ODPS表中，同步到对方的ODPS表中。

注：上图中的数据流向是简化后的数据流向，实际比这个复杂，涉及到订阅消费等场景实际上还有一些中间件、流式计算的处理在里面。

对于大部分任务我们通过LogStash可以处理目前大部分的数据源(包括自己的爬虫结果文件)，对于一些有特殊要求的用户，我们采用LogHub将数据同步到ODPS上进行存储(当然这部分费用用户自己承担，费用很低每天才几块钱)

数据由LogStash 直接投递到ES引擎中(投递规则通过我们的管理页面动态下发处理流程配置文件)。有了结构化的数据后，基于Kibana进行可视化展示，这样用户就可以看到最终结果了。

整体架构介绍

整体框架是ELK的框架，但目前由于接入的任务的不同，将Spark技术栈引入进来了，目前很好的解决了一些准实时的问题。
对于实时监控(如论坛挖掘)这样的任务，数据除了走主题流程之外，还增加了由LogStash投递到Kafka的流程，由kafka作为消息中间件，Spark Streaming消费kafka的消息，进行准实时的数据处理，数据延迟基本在10S内，对于目前平台承接的任务，这个延迟足够满足现有的需求了。处理后的结果按照不同的需求，将结果写入不同的载体。

注：框架中一些Python体系的解决方案并未体现，除了基于Spark的算法处理，我们也使用sklearn、tensorflow进行一些算法任务的处理。

对于一些离线的任务，我们也是通过Spark来进行处理，如商品评论的挖掘，虽然数据写到ES，但通过elasticsearch-hadoop插件，我们可以在Spark上直接爬任务，基于Spark的技术栈，大大降低了整体的使用难度、提高了处理效率。

对于有特殊需求的用户(用户数据本身就在ODPS上)，我们直接基于ODPS上的Spark进行处理，使用和我们自己的平台差不多，只是是在ODPS上跑罢了，但这部分费用需要用户自己承担(Spark on ODPS 按小时计费)

对于数据开放，目前我们还没推出自己的OPENAPI，我们正在计划将我们的数据进行开放，当然是有偿开放，用户可以通过restful API来获取自己想要的数据。

关于部署

我们采用Docker作为我们开发和部署环境，一直维护一个完整的image,所以开发和部署起来都非常方便，只需拉取一个image即可。有的同学可能会有疑问，这种基于ES的，当数据量大的情况怎么搞。的确当单机数据量过大时，ES反映会变慢，但我们现在是做场景的，针对不同的用户，随时建立单独的集群，每个用户的数据量其实并不大，几千万的数据量而已，三台机器完全OK的，对于量级更大的情况(本身ODPS承载我们的全量数据)，我们会基于ODPS做离线计算，对于单需求过大的情况，我们会在ES中存储聚合计算后的结果，而不是全量的结果，这样保证用户基于ELK的分析一直能有一个较块的响应。

数据展示案例

目前由于我们没有专门的对外展示平台，我临时搭建了一个简单的展示页面，抽取了部分样本数据，搭建了一套展示环境，供给用户做体验，关于展示平台，这是是我们一直想做的，但鉴于木有专业的前端，一直拖而未决，期待有相应技能的小伙伴一起加入，我们一起完善。点击展示平台进入展示平台。

目前抽取了125566条小区数据，供有需求的同学做统计分析，数据囊括了全国大部分省份(不含港澳台)，几乎所有城市的小区房价信息(5月份的数据)。

注：由于数据是抽样的，所以不代表真是结果，只为展示可视化结果。

第一幅图分析了杭州现有小区的TOP20的开发商

第二幅图分析了杭州小区数量TOP5的区中各个区的Top5开发商占比情况

第三幅图分承载了两个图，分别是统计的表格和折线图

表格展示的是每个省份TOP10的城市房价，按照省份最高和城市最高排序
折线图展示的是每个省份TOP1的城市房价的折线图(由于)

第四幅图展示了京东、聚美、蜜芽三个网站的抽样商品的分布情况

饼状图展示了三个网站中类目分布和各个类目下品牌的分布情况

表格展示了各个站点的商品按照类目统计的情况。

第五幅图展示了这几个网站(抽样)成交预测情况。

关于我们

我们是几个来自阿里和腾讯从事数据平台和算法的小伙伴，处于对数据的热情走到一起，希望用技术的力量降低使用数据的难度。欢迎更多的小伙伴加入我们(前端、后端、客户端、算法、运维…)，可以看介绍平台。

个人邮箱：hitxueliang@163.com
工作邮箱：xueliang.xl@alibaba-inc.com
微信：hit_0607
业务、技术合作联系：13588786932