大数据bik案例.docxVIP

Yonghong 大数据BI 案例 本文档主要介绍两个案例，一个是互联网行业大数据案例，一个是电信行业的大数据案例。互联网大数据案例案例背景某著名咨询公司用户行为分析系统面临问题：实时分析的数据量大，基于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. 系统配置调优： 内部管理内存参数： mem.proc.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. 第一阶段技术服务支持： 解析日志：不单是某些文件块，而是整个文件系统下所有日志文件。清洗：维度关联，维度清洗，