数据分析与大数据课件2-数据采集技术

数据采集的重要性故善战者，立于不败之地，而不失敌之败也。——先求不败而后求胜数据分析的根源是数据源，构建好数据源是为数据分析的打好根基。——数据采集是基础数据采集的挑战传统数据源对数据采集支持较差：业务数据库是为了支撑业务，数据表关联复杂，且一般针对高并发及低延迟的小操作进行设计；Web日志往往是为了方便业务调试来做。数据团队与业务团队配合困难：数据分析让路产品升级；对于业务团队而言，数据采集属于额外工作。数据采集遵循法则大全细时海量数据，包括业务的各个角度。按需求将不同维度的数据都进行采集。多种数据源，全量数据，全面覆盖。强调时效性，实时采集保障分析价值。常用数据采集的手段埋点——用户行为数据采集ETL——系统业务数据整合网络爬虫——互联网数据采集ApacheFlume——日志数据采集ApacheKafka——数据分发中间件其他常用数据采集的手段埋点——用户行为数据采集ETL——系统业务数据整合网络爬虫——互联网数据采集ApacheFlume——日志数据采集ApacheKafka——数据分发中间件其他埋点什么是埋点？埋点：在正常的业务逻辑中，嵌入数据采集的代码。埋点方法的来源：早期的网站统计，往往只能收集页面的打开；通过谷歌分析定义好的可扩展接口，编写少量javascript代码实现自定义事件和自定义指标的跟踪和分析。埋点埋点优势：数据是手动编码产生的，易于手机，灵活性大，扩展性强。埋点劣势：必须十分清楚目标，即需要收集什么样的数据必须提前确定；容易发生漏埋现象；产品迭代过程中，忽略了埋点逻辑的更改。埋点埋点方式有哪些？无埋点：“全部采集，按需选取”；在产品中嵌入SDK，做个统一埋点，一般用于采集APP的用户行为。代码埋点：前端代码埋点和后端代码埋点。更适合精细化分析的场景，采集各种细粒度数据。埋点基于无埋点技术的第三方统计工具无埋点优势：技术门槛低，部署使用简单；用户友好性强；收集的是全量数据，不会出现漏埋、误埋等现象。无埋点劣势：适用通用场景、标准化采集，自定义属性采集覆盖不了；采集全量数据，给数据传输和服务器增加压力；兼容性有限等。埋点埋点采集数据的过程需求收集和分析确定场景和目标针对需求制订数据采集规划方案埋点采集数据的具体实施数据质量的评估及数据分析设计优化方案实施优化方案评估解决方案的效果重点环节：梳理产品，清晰产品的脉络和架构收集统计，明确统计目的和意义收集事件，设置事件的参数和参数值数据团队与开发团队的沟通埋点常用app数据分析工具GrowingIO百度移动统计神策分析腾讯移动分析谷歌GA未来的王牌职位——首席增长官常用数据采集的手段埋点——用户行为数据采集ETL——系统业务数据整合网络爬虫——互联网数据采集ApacheFlume——日志数据采集ApacheKafka——数据分发中间件其他ETL(Extract-Transform-Load)什么是ETL？ETL：用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。是BI的重要一环，在BI项目中占至少三分之一的时间。ETL(Extract-Transform-Load)ETL的设计分为三部分：数据的抽取、数据的清洗转换、数据的加载。花费时间最长的是Transform（清洗转换）部分，一般情况下是整个ETL的2/3。ETL常用的三种实现方法：借助ETL工具；SQL方式实现；ETL工具和SQL相结合。ETL工具解决的问题：数据来自不同物理主机、数据来自不同数据库或者文件、异构数据处理等。ETL——数据抽取数据抽取：把源数据抽取到数据仓库中，为处理及展示奠定基础。需要思考的问题：数据来自哪些业务系统？各个业务系统的使用哪种DBMS？是否存在外部数据，数据量有多大？是否存在非结构化的数据？如何实现增量抽取？ETL——数据转换数据转换：对数据进行清洗，进行一些业务规则的计算和聚合，针对数据仓库进行数据转换。需要思考的问题：空值处理，规范化数据格式，拆分数据，数据验证，统一数据标准，数据粒度的转换，商务规则的计算，等等。ETL——数据加载数据加载：把清洗好的数据加载到数据仓库中，服务后续使用，或者进行可视化展示。需要思考的问题：明确所执行操作的类型；明确需要加载的数据量；设计加载数据的最佳方法。ETL(Extract-Transform-Load)常用的ETL工具Kettle：一款国外开源的etl工具，纯java编写，数据抽取高效稳定(数据迁移工具)。Apatar：开源ETL项目，模块化架构，支持所有主流数据源，提供灵活的基于GUI、服务器和嵌入式的部署选项。Scriptella：一个开源的ETL工具和一个脚本执行工具，支持跨数据库的ETL脚本。ETLAutomation：提供了一套ETL框架，重点是提供对ETL流程的支持。常用数据采集的手段埋点——用户行为数据采集ETL——系统业务数据整合网络爬虫——互联网数据采集ApacheFlume——日志数据采集ApacheKafka——数据分发中间件其他网络爬虫网络爬虫：是一种按照一定的规则，自动抓取万维网信息（网页）的程序或者脚本。为搜索引擎从万维网上抓取网页，是搜索引擎的重要组成部分。搜索引擎基本框架网络爬虫网络爬虫可分为通用网络爬虫和聚焦网络爬虫通用网络爬虫基本工作流程1.选取部分种子URL放入待抓取队列。2.取出待抓取URL，进行相应处理。3.将处理过的URL，放入已抓取队列。4.将未处理过的新URL，放入待抓取队列。网络爬虫网络爬虫可分为通用网络爬虫和聚焦网络爬虫聚焦网络爬虫基本工作流程与通用爬虫相比，通过增加新模块实现有目的地爬取。新增：目标的定义、无关链接的过滤、下一步要爬取的URL地址选取。网络爬虫网络爬虫视角下的网页：处理完的待处理的可以被爬取的无法爬取下载的网络爬虫网络爬虫的抓取策略：深度优先遍历策略：从起始页开始，一个个链接跟踪下去。宽度优先遍历策略：抓取当前网页中链接的所有网页，再从待抓取队列中选取下一个URL。反向链接数策略：反向链接数是指一个网页被其他网页链接指向的数量。使用这个指标评价网页的重要程度，从而决定抓取先后顺序。基于优先级计算的策略：针对待抓取网页计算优先级值，通过排序来确定抓取顺序。如：PartialPageRank，OPIC等。大站优先策略：对于待抓取队列中的所有网页，根据所属的网站进行分类，对于待下载页面数多的网站优先下载。网络爬虫网站往往是实时更新的，在网页更新后，需要对网页进行重新爬取。问题——什么时候更新合适？定期更新策略历史参考策略：在网页的历史更新数据基础上，利用建模等手段，预测网页下一次更新的时间，确定爬取周期。用户体验策略：依据网页多个历史版本的内容更新、搜索质量影响、用户体验等信息，来确定爬取周期。聚类分析策略：首先对海量的网页进行聚类分析，每个类中的网页一般具有类似的更新频率。通过抽样计算，确定针对每个聚类的爬行频率。网络爬虫网络爬虫系统架构：往往是一个分布式系统。主从式系统架构负责网页下载工作维护待抓取URL队列负责爬取工作分发负责Slave负载调节网络爬虫网络爬虫系统架构：往往是一个分布式系统。对等式系统架构所有服务器分工相同获取URL计算主域名的hash值计算Hmodm的值得到处理该URL的主机编号思考：是否存在问题？网络爬虫网络爬虫系统架构：往往是一个分布式系统。对等式系统架构基于一致性哈希运算，将URL的主域名映射为一个指定范围内的某个数。根据事先的分配策略，判断由哪台服务器来进行抓取该URL。网络爬虫一致性哈希算法：1997年由麻省理工学院提出把服务器通过hash算法映射到环上；把URL通过hash算法映射到环上，按顺时针方向找到处理该URL的服务器服务器增删，对系统影响较小，架构扩展性强一般被用来解决分布式系统中负载均衡的问题常用数据采集的手段埋点——用户行为数据采集ETL——系统业务数据整合网络爬虫——互联网数据采集ApacheFlume——日志数据采集ApacheKafka——数据分发中间件其他Flume什么是Flume？分布式、可靠、和高可用的海量日志采集、聚合和传输的日志收集系统。由Cloudera公司开源，连接数据源和数据存储系统的管道，屏蔽数据源和数据存储系统异构性的中间件。Flume-OG(originalgeneration)：初始发行版本Flume-NG(nextgeneration)：重构后的版本，被Apache纳入旗下FlumeFlume-OG基本架构Agent：代理节点，从各个数据源收集日志数据Collector：收集节点，收集来自各个代理的日志数据，汇总至存储节点。Master：主节点，负责管理agent和collector的活动Agent与Collector都称为node，由source、sink组成，数据是从source传送到sink。Flume基于Flume-OG的美团日志收集系统每个机器部署一个进程，负责单机的日志收集部署在中心服务器上，负责接收日志，并根据规则写到相应的存储层提供永久或者临时的日志存储服务，或者将日志流导向其它服务器。FlumeFlume-NG基本架构外部（Client）数据，发送Event到SourceSource捕获Event，进行特定格式化，再把Event推入单个或多个Channel中Channel可以看作是一个缓冲区，保存Event直到Sink处理完Sink负责将Event传输到下一跳或最终目的地，成功完成后将Event从Channel移除FlumeFlume-NG核心概念Event：Flume数据传输的基本单元，由可选的header和载有数据的bytearray构成，bytearray可以携带日志数据。Client：将原始日志文件包装成Events并发送它们到一个或多个Agent实体，由独立的线程运行。Agent：Flume的运行实体，包含Source,Channel,Sink等组件。利用这些组件将Events从一个节点传输到另一个节点或最终目的地。每台机器运行一个Agent。Source：负责接收Event或通过特殊机制产生Event，并将Events批量的放到一个或多个Channel。Channel：连接Source和Sink，类似event的缓存队列。Sink：接收Event，进行下一步转发。FlumeFlume-OGV.SFlume-NGFlume-OG有三种角色的节点，Flume-NG只有一种角色节点，降低臃肿性，更加灵活。在OG版本中，Flume的使用稳定性依赖zookeeper；而在NG版本中，不再需要zookeeper对各类节点进行协调。在Flume-NG中，agent节点的组成也发生了变化，由source、sink、channel组成。FlumeFlume拓扑结构多Agent串联：前一个Agent的Sink和下一个Agent的Source相连，Sink指向Source的主机名（或IP地址）和端口。一般情况下，应该控制这种顺序连接的Agent的数量。FlumeFlume拓扑结构单Source，多Channel、Sink：并行配置多个Channel，Sink与Channel一一对应，通过不同的Sink将数据发送到不同的地方。也称为多级流模式FlumeFlume拓扑结构聚合模式：每个集群都会产生日志文件，为了将每个日志文件进行收集，就采用该模式。每个节点都配置一个Agent来单独收集日志数据，数据最终汇聚到一个对接存储系统的Agent上。FlumeFlume拓扑结构Agent1可看成是一个路由节点，将Event均衡到多个Sink组件上负载均衡模式：适用于大容量数据处理。将大容量数据拆分给多个Agent来处理。常用数据采集的手段埋点——用户行为数据采集ETL——系统业务数据整合网络爬虫——互联网数据采集ApacheFlume——日志数据采集ApacheKafka——数据分发中间件其他数据分发中间件前端数据采集后，需要送到后端进行分析处理。前端采集与后端处理往往是多对多的关系。之间需要数据分发中间件负责消息转发，保障消息可靠性，匹配前后端速度差。分布式系统构件之间通过数据分发可以解除相互之间的功能耦合，从而减轻子系统之间的依赖，使得各个子系统或构件可以独立演进、维护或者重用。为什么需要数据分发？数据分发中间件数据分发解决方案——消息队列消息队列是在消息传输过程中保存消息的容器或中间件，主要目的是提供消息路由并保障消息可靠传递。目前常见的消息队列中间件产品包括：ActiveMQ、ZeroMQ、RabbitMQ和Kafka。一般消息中间件支持两种模式：消息队列模式及Pub-Sub模式。KafkaKafka：分布式发布-订阅消息系统（Pub-Sub模式），最初由LinkedIn公司开发，之后成为Apache项目的一部分。具有极高的消息吞吐量，较强的可扩展性和高可用性，消息传递低延迟，能够对消息队列进行持久化保存，且支持消息传递的"至少送达一次"语义。Kafka架构：消息生产者：产生指定Topic(主题)的消息并将其传到代理服务器集群。代理服务器集群：在磁盘上存储并维护各种Topic的消息队列。消息消费者：订阅某个Topic，从代理服务器集群中拉取(Pull)出新产生的消息并对其进行处理。KafkaBroker和Consumer都会在Zookeeper中进行注册，Zookeeper保障负载均衡。Kafka基本概念——Topics&PartitionTopics是消息的分类名（或Feed的名称），一个Topic可以认为是一类消息，每个topic将被分成多个partition(区)。partition是以log文件的形式存储在文件系统中，任何发布到partition的消息都会被直接追加到log文件的尾部。Logs文件根据配置要求,保留一定时间后删除来释放磁盘空间。Partition： Topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列。partition中的每条消息都会被分配一个有序的id（offset）。KafkaPartition设计目的：通过分区,可以将日志内容分散到多个server上,来避免文件尺寸达到单机磁盘的上限,每个partiton都会被当前server(kafka实例)保存可以将一个topic切分多任意多个partitions,来提升消息保存/消费的效率越多的partitions意味着可以容纳更多的consumer，有效提升并发消费的能力基本概念——Topics&PartitionKafka基本概念——ProducerProducer将消息发布到指定的Topic中,同时Producer也能决定将此消息归属于哪个partition;比如基于"round-robin"方式或者通过其他的一些算法等消息和数据生产者，向Kafka的一个topic发布消息的过程叫做producers。异步发送：批量发送可以很有效的提高发送效率。Kafkaproducer的异步发送模式允许进行批量发送，先将消息缓存在内存中，然后一次请求批量发送出去。Kafka基本概念——Consumer消息和数据的消费者，订阅相关topics，并处理Producer发布的消息。允许consumergroup（包含多个consumer）对一个topic进行消费，不同的consumergroup之间独立订阅。每个consumer属于一个consumergroup；发布的消息,只会被订阅此Topic的每个group中的一个consumer消费。同一个group中不能有多于partitions个数的consumer同时消费,否则将意味着某些consumer将无法得到消息。Kafka基本概念——BrokerBroker：缓存代理，Kafka集群中的一台或多台服务器统称为broker。为了减少磁盘写入的次数，broker会将消息暂时buffer起来，当消息的个数(或尺寸)达到一定阀值时，再flush到磁盘，这样减少了磁盘IO调用的次数。Broker不保存订阅者的状态，由订阅者自己保存。Broker没有副本机制，一旦broker宕机，该broker的消息将都不可用。Kafka基本概念——MessageMessage消息：是通信的基本单位，每个producer可以向一个topic（主题）发布一些消息。Kafka中的Message是以topic为基本单位组织的，不同的topic之间是相互独立的。每个topic又可以分成几个不同的partition(每个topic有几个partition是在创建topic时指定的)，每个par