大数据实时分析案例.docx

永洪科技大数据实时分析永洪科技基于自有技术研发的一款数据存储、数据处理的软件Yonghong Z-Data Mart是一款专业的数据集市软件。Hadoop Map Reduce适合通过批处理方式访问海量数据，但无法满足海量数据的实时处理的需求。实时商业智能建设的主要目标是支持实时决策，这就对海量数据处理的即时、快速、稳定提出了更高的要求。Yonghong Z-Suite Map Reduce解决方案更好的实现了这些特点：完全放弃了心跳机制，采用实时信息交换底层，进行实时的Map-Reduce任务分配与执行。这一信息交换底层能够保障几十甚至上百个节点之间的高效信息交换，使得实时的Map-Reduce任务分配与执行能够在毫秒级完成任务分解与派发工作。Map Reduce任务服务于海量数据处理，任务清晰。通过在Map Node中预先部署Map的数据处理和数据分析功能的代码文件集，在Reduce节点中预先部署Reduce的数据处理和数据分析功能的代码文件集，在运行Job之前，每个Map和Reduce节点已经具备了相应的数据处理和分析能力。这种方式极大地减少了实时传输和部署的时长。直接在各节点之间传输中间结果和最终结果(Stream Computing)。由于Map-Reduce采用了具有自主知识产权的高效率的实时信息交换底层，这一底层保障了大量传输Map的中间结果、Reduce的中间结果及最终结果的实效性。本文档主要介绍两个案例，一个是互联网行业大数据案例，一个是电信行业的大数据案例。互联网大数据案例案例背景某著名咨询公司用户行为分析系统面临问题：实时分析的数据量大，基于Hive 的分析系统不够实时，但预算有限。问题解决步骤1. 首先提出了测试方案：90 天细节数据约50 亿条导入YonghongDM，再定制Dashboard 分析。2. 简单测试：先通过5 台PCServer，导入1-2 天的数据，演示如何ETL，如何做简单应用。3. 按照提出的测试方案开始导入90 天的数据，在导入数据中解决了如下问题： 解决步长问题，有效访问次数，在几个分组内，停留时间大于30 分钟。 解决HBase 数据和SQLServer 数据的关联问题。 解决分组太多，Span 过多的问题。4. 数据源及数据特征分析： 90 天的数据，Web 数据7 亿，App 数据37 亿，总估计在50 亿。 每个表有20 多个字段，一半字符串类型，一半数值类型，一行数据估计2000Byte。 每天5000 万行，原始数据每天100G，100 天是10T 的数据。 抽取样本数据100 万行，导入数据集市，数据量在180M。 50 亿数据的若全部导入需要900G 的量，压缩比在11:1。 假设同时装载到内存中分析的量在1/3,那总共需要300G 的内存。5. 设计方案： 总共配制需要300G 的内存。 硬件：5 台PC Server，每台内存：64G，4 CPU 4 Core。 机器角色：一台Naming、Map，一台Client、Reduce、Map，其余三台都是Map。6. ETL 过程: 历史数据集中导：每天的细节数据和SQL Server 关联后，打上标签，再导入集市。 增量数据自动导：先删除近3 天的数，再导入近3 天的数。 维度数据被缓存；细节数据按照日期打上标签，跟缓存的维度数据关联后入集市；根据系 统配置调优日期标签来删除数据；清洗出有意义的字段。7. 系统配置调优： 内部管理内存参数： c.count=8 mem.serial.mem=5120 mem.result.mem=10240 JVM 内存管理参数配置： JAVA_OPTS=-XX:NewRatio=3 -XX:SurvivorRatio=1 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxGCPauseMillis=6000 -XX:GCTimeRatio=19 -XX:ParallelGCThreads=16 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=1 -XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintHeapAtGC-XX:+PrintGCDetails -Xms61440m-Xmx61440m-Djava.awt.headless=true8. 前端展现：互联网用户行为分析: 浏览器分析：运行时间，有效时间，启动次数，覆盖人数，等等。 主流网络电视：浏览总时长，有效流量时长，PV 覆盖占有率，UV 占有率，等等。 主流电商网站：在线总时长，有效在线总时长，独立访问量，网站覆盖量，等等。 主流财经网站：在线总时长，有效总浏览时长，独立访问量，总覆盖量，等等。报表截图 案例测试结果 90 天数据，近10T 的原始数据，大部分的查询都是秒级响应。 实现了Hbase 数据与SQL Server 中维度表关联分析的需求。 预算有限，投入并不大，又能解决Hive 不够实时的问题。性能卓越的交互式BI 呈现，非常适合分析师使用。电信大数据案例案例背景某省移动CMNET 流量分析与控制系统面临问题：数据量特别大，但预算特别有限，基于DW的分析系统完全无法支持。问题解决步骤1.首先提出了测试方案：100 天数据约60 亿条导入YonghongDM，再定制Dashboard 分析。由于预算特别有限，硬件上定制6 个节点的PC 集群(1 CPU 4 Core)。2. POC （Proof of Concept）: Demo：工作原理，和BI 的展现能力，从功能上基本可以认可项目的可行性。 测试大数据量下多查询，多用户并发访问的响应速度。经过测试，结果符合需求。3. 第一阶段技术服务支持： 解析日志：不单是某些文件块，而是整个文件系统下所有日志文件。清洗：维度关联，维度清洗，日期的清洗，等等。应用展现：各维度的月，日，年分组展现。4. 出现严重问题： 一天的数据分成N 个链路，288 块数据，每5 分钟一个块。 一天的数据, 原始DAT 文件大概有3G，关联入库后大概是20G 数据，至少3 亿条数据。 问题：100 天数据量大于300 亿条，是当初估算数据量的6-7 倍!5. 问题解决方式： 降维！做两小时汇总，给细节数据加上两小时时间的字段 。3 天细节数据，汇总数据分为App与非App的数据20G数据，汇总后的总量2G，大概下降10倍。重构前端。6. 最终方案: 配置180G 的JVM 内存。硬件：6 台PC，每台内存：32G，1 CPU 4 Core。历史数据集中导：按照两小时打标签，和维度表关联生成细节数据，再汇总入库。增量数据自动导：每5 分钟导入数据，每两小时生成汇总数据。系统保留3 天细节数据和100 天汇总数据供BI 前端消费。7. 系统配置调优: 内部管理内存参数： c.count=4 mem.serial.mem=5120 JVM 内存管理参数配置： JAVA_OPTS=-XX:NewRatio=3 -XX:SurvivorRatio=1-XX:+UseParNewGC-XX:+UseConcMarkSweepGC -XX:MaxGCPauseMillis=6000 -XX:GCTimeRatio=19-XX:+UseConcMarkSweepGC -XX:MaxGCPauseMillis=6000 -XX:GCTimeRatio=19-XX:ParallelGCThreads=4 -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=1 -XX:CMSInitiatingOccupancyFraction=80-XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled-XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintHeapAtGC -XX:+PrintGCDetails-Xms30720m-Xmx30720m -Djava.awt.headless=true“8. 前端展现：CMNET 流量分析与控制系统:各网间出口的流量统计，分地市，分运营商。各网间出口的流量的流向统计，分运营商，分省。各网间出口的流量的业务量统计，分地市。各网间出口的流量的业务量TOPN 排名，分大类业务，具体应用的小类业务。热点域名的TOPN 排名报表截图 案例测试结果数据量非常大，100 天超过300 亿条日志。预算非常有限，投入6 台PC，几万块硬件，软件性价比也很高。日志解析清洗过程难度较高，随着降维的需求加入，展现层难度相应提高。为了达到十几秒的交互式响应，进行了多个层面的优化。永洪科技BI：驱动模式：业务驱动。开发模式：以敏捷开发模式建设BI系统。交付周期：交付周期偏短，项目失败率低；乐意在客户现场做