做网站编辑需要会什么,帮别人做网站赚钱,姜堰网络推广怎么做,写一个app多少钱一、概述WMDA是58自主开发的用户行为分析产品#xff0c;同时也是一款支持无埋点的数据采集产品#xff0c;只需要在第一次使用的时候加载一段SDK代码#xff0c;即可采集全量、实时的PC、M、APP三端以及小程序的用户行为数据。同时#xff0c;为了满足用户个性化的数据采集…一、概述WMDA是58自主开发的用户行为分析产品同时也是一款支持无埋点的数据采集产品只需要在第一次使用的时候加载一段SDK代码即可采集全量、实时的PC、M、APP三端以及小程序的用户行为数据。同时为了满足用户个性化的数据采集需求在无埋点之上WMDA又提供了手动埋点的数据采集方式。WMDA支持的统计、分析功能主要包括“概览”和“实时”模块用来监控网站的流量情况“圈选”定义重要的指标“单图”和“看板”可以统计不同维度、时间下指标的页面访问量和用户量等数据“漏斗”和“智能路径”用于分析不同指标下的转化率“留存”可以基于不同维度、分群来考察网站的用户流失率分析用户的忠诚度“用户细查”和“用户分群”用于分析所关心条件下的用户群体以及相关的用户行为明细。以上简单的介绍了WMDA功能模块接下来侧重于WMDA数据端的架构以及相关大数据技术栈的实践。二、架构设计在架构上WMDA遵循标准的数据分析模型将整体的架构分成数据采集、数据传输、数据建模/存储、数据统计/分析和数据可视化五个部分。架构如下图所示数据采集58的业务方覆盖PC、M、APP三端以及小程序。WMDA在数据收集阶段为PC、M、H5、提供SDK完成数据采集在APP端提供IOS SDK和Android SDK完成数据采集小程序也有相应的SDK来完成数据采集。数据传输主要包括数据收集服务完成前端上报数据的信息补全、脏数据过滤、设备标识等最后将数据格式化之后落地存储通过Flume收集到Kafka中完成实时总线和离线总线的拆分。数据建模/存储后端收集上来的数据经过ETL的清洗将上报的数据格式化之后保存在HDFS上供后续分析使用。同时Kafka分发一份数据到Spark Streaming中进行实时数据分析。数据统计/分析除了Spark Streaming的实时分析外落地到HDFS上的数据在Kettle的调度下由OLAP子系统、Bitmap子系统、分群计算子系统、智能路径计算子系统完成单图、漏斗、留存、分群、智能路径的最终计算。三、实时分析系统实时分析系统用于解决用户监控网站、APP实时流量需求采用SparkStreamingDruid来实现。实时ETL程序中设置5s为Spark Streaming处理批次间隔同时将圈选配置信息在实时ETL程序中定义为广播变量完成指标id的实时匹配最后将数据通过缓冲kafka摄入到Druid中。四、离线分析系统离线分析系统主要完成单图、漏斗、留存、智能路径、分群等数据分析工作是WMDA的核心组成也是数据建模/存储数据统计/分析的具体实践。基础数仓使用HDFS作为存储系统DWDMDA是标准的数据中台角度的数仓分层同时基于基础事件模型(Event)搭建基础数仓。Hive完成基础数仓的核心ETL。SparkETL完成数据圈选规则匹配、脏数据的过滤和标准日志格式化。离线计算集群包括OLAP系统、Bitmap计算系统、分群计算系统、智能路径计算系统主要完成单图、漏斗、留存、分群、智能路径相关计算工作。Kettle负责离线计算集群的调度。TaskServer任务执行系统负责执行由Kettle调度的Hive sql任务、MapReduce任务。数据服务接口层回溯接口层供可视化服务获取数据和指标变更回溯任务的触发。离线计算逻辑复杂保证系统容错性尤为关键WMDA离线和实时数据系统都遵循Lambda架构保证了系统较好的容错特性。4.1 基于Kettle的任务调度系统Kettle是基于java开源的ETL工具集可以在windows、Linux、Unix上运行数据抽取高效稳定。通过可视化界面设计ETL流程无需代码去实现。在Kettle中有两种基本的脚本文件job和transformationjob是完成整个工作流的控制transformation完成针对数据的基础转换。在job下的start模块有一个定时功能可以每日、每周等方式实现对ETL任务的定时调度。Kettle体系结构分为Kettle平台、各类插件其中Kettle平台是整个系统的基础包括UI、插件管理、元数据管理和数据集成引擎。UI显示Spoon这个核心组件的界面通过xul实现菜单栏、工具栏的定制化显示插件界面接口元素。元数据管理引擎kjb、ktr以及一些元数据信息插件通过该引擎获取基本信息。插件管理引擎主要负责插件的注册。数据集成引擎负责调用插件并返回相应信息。Kettle是众多“可供插入的地方”(扩展点)和“可插入的东西”(扩展)共同组成的集合体。在Kettle中不管是以后的扩展还是系统集成的功能本质上都是插件管理的方式和运行机制是一致的。系统集成的功能也均是实现了对应的扩展接口只是插接的方式略有不同。Kettle的扩展点包括step插件、job entry插件、Database插件、Partioner插件、debugging插件等。在Kettle中一个job代表ETL控制流中的一项逻辑任务。Job会按照连线的方式顺序执行每个job产生一个执行结果作为其他分支上job的条件。同时数据会从一个entry组件传递到另一个entry组件并在entry组件中进行相应的处理。在Kettle负责调度各个子计算系统ETL任务的同时TaskServer负责任务的执行这样使得任务的调度与任务的执行完全分离方便任务的管理以及任务执行的灵活性。在Kettle中集成TaskSever相关的组件需要关注Kettle中的两个接口JobEntryInterface和JobEntryDialogInterface。JobEntryInterface是Job Entry插件的主要实现接口主要的功能如下保存Job Entry设置实现类使用私有变量保存设置的参数通过get、set方法获取和设置。Dialog实现类会通过这些方法设置界面上的参数。同时需要提供一个深度拷贝的方法在保存的参数被修改时进行调用。序列化插件输出信息提供一个Job Entry支持三种类型的输出true、false和无条件。这三种情况不是所有的Job Entry都会同时支持例如dummy job entry仅支持true和false。通过JobEntryInterface接口的evaluates()方法可以设置一个Job Entry的输出结果是否支持true和falseisUnconditional()方法则是设置是否支持无条件执行。执行任务JobEntryDialogInterface接口负责构建和打开参数设置对话框。4.2 基于TaskServer的任务执行系统TaskServer是一个高可用的、可扩展性强的分布式任务执行系统。整体架构采用Master-Slave的设计模式支持横向扩展兼备资源隔离、服务容灾等功能为线上任务的运行提供可靠的执行环境。WMDA各个子计算系统中的Hive sql和MapReduce都在TaskServer上执行极大的确保WMDA离线任务的稳定性。TaskServer主要包括三个部分JobTracker集群、TaskTracker集群和Zookeeper集群。JobTracker负责任务接受、资源计算和任务分配。TaskTracker负责任务执行和保持心跳。TaskQueue任务队列。Zookeeper协同调度。在JobTracker中主要是资源的计算和任务分发一个任务被提交之后会由JobTracker中的任务分发器(Dispatcher)发给对应的事件处理器(EventHadler)事件处理器完成之后会将任务相关的元数据信息写入到Zookeeper中。TaskTracker监听并拉取Zookeeper中新增的任务信息抽象成TaskRunner放到线程池中运行同时TaskTracker中任务调度器(TaskScheduler)跟JobTracker保持心跳用来更新机器信息。如果JobTracker监听到某一个TaskTracker宕机会重新进行任务分配由其他的TaskTracker来执行。资源的隔离方面TaskTracker中采用硬性资源划分机制和分时资源扩容机制。硬性资源是指资源被某种方式划分之后就只会接受这一类任务。在TaskServer中就为WMDA的任务划分出来了WMDA Tier只服务于WMDA提交的任务。分时资源扩容是指可以按照不同时间段来分担其他Tier的任务。比如在9点到10点是WMDA任务量的高峰划分的WMDA Tier不足以满足当前任务所需要的计算资源此时利用分时资源扩容机制从Share Tier中扩容一些Tier来满足当前任务对计算资源的需求。4.3 Druid在OLAP计算系统的实践WMDA中主要涉及OLAP场景模块有概览、单图、即席圈选7日数据预览、热图、维度阅览以及用户行为统计。OLAP引擎在选择上尝试过kylin和Druid。Kylin采用预计算因为数据已经提前计算好所以在前端查询展示的时候相对较快。但是因为WMDA支持多个维度任意组合所以采用Kylin需要根据不同组合情况进行计算这就使得随着维度的增加计算量增大。Druid则需要根据查询条件即时计算查询相比Kylin慢但是优化后基本在1秒以内。WMDA最终基于Druid实现OLAP模块其包括的角色有Real-Time Nodes负责实时数据处理Historical Nodes负责加载非实时窗口内满足加载规则的所有历史数据SegmentCoordinator Nodes负责Druid集群中Segment的管理与发布包括加载新Segment丢弃不符合规则的Segment管理Segment副本以及Segment负载均衡Broker Nodes整个集群的查询入口提供查询路由和结果组装Indexing Service负责“生产”Segment的高可用、分布式、Master/Slave架构服务。Druid将数据的索引节点划分为HistoricalNodes和Real-Time Nodes切割了历史数据的加载与实时流数据处理因为二者都需要占用大量内存与CPU另一方面划分Coordinator Nodes和Broker Nodes切割了查询需求与数据如何在集群内分布的需求确保用户的查询请求不会影响数据在集群内的分布情况。在时间窗口内的数据会停留在Real-Time Nodes内存中而时间窗口外的数据会组织成Segment存储到Deep Storage中批量数据经过Indexing Service也会被组织成Segment存储到Deep Storage中WMDA使用HDFS作为Druid的Deep Storage同时Segment的元信息都会被注册到元信息库中Coordinator Nodes会定期(默认为1分钟)去同步元信息库感知新生成的Segment并通知在线的Historical Node去加载SegmentZookeeper也会更新整个集群内部数据分布拓扑图。当用户需要查询信息时会将请求提交给Broker NodesBrokerNodes会请求Zookeeper获取集群内数据分布拓扑图从而知晓请求应该发给哪些Historical Nodes以及Real-Time Nodes汇总各节点的返回数据并将最终结果返回给用户。4.4 Bitmap计算系统在WMDA中的实践Bitmap是漏斗、留存和分群数据分析中用来较快计算满足某些条件下用户数量的数据结构。Bitmap计算系统分为Bitmap计算模块和Bitmap检索模块Bitmap计算模块通过MapReduce从基础日志中计算出指标Bitmap、维度Bitmap和分群Bitmap并提交至WTable中。Bitmap检索模块则是通过BitMapEngine查询出符合查询条件的用户包。五、总结本文主要阐述了WMDA数据端的架构设计主要从数据采集、数据计算、数据应用、调度系统等方面逐一进行了介绍。当然大数据处理相关的架构以及技术选型并不是本文介绍的这一个方向好的架构应该是根据具体的业务来设计的而且是随着业务的拓展不断演变的。欢迎大家关注“58架构师”微信公众号定期分享云计算、AI、区块链、大数据、搜索、推荐、存储、中间件、移动、前端、运维等方面的前沿技术和实践经验。
