互联网大数据分析案例分享
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
假设同时装载 到内存中分析 的量在1/3, 那 总共需要 300G的内存
2014-1-8
6
互联网大数据案例
设计方案
总共配制需要300G的内存 硬件： 5台PC Server， 每台内存：64G， 4 CPU 4 Core 机器角色：一台Naming 、Map， 一台Client、Reduce、Map，其余三台都是Map
配置 2G 内存 2CPU WIN 7系统 Map Reduce Client Naming
配置 2G 内存 2CPU WIN 7系统
Map
配置 2G 内存 2CPU WIN 7系统
பைடு நூலகம்
Map
配置 2G 内存 2CPU WIN 7系统
Map
14
2014-1-8
5
互联网大数据案例
数据源及数据特征分析
每天5000万行， 原始数据每天 100G， 100天 是10T的数据
90天的数据， Web数据7亿， App数据37亿， 总估计在50 亿
每个表有20多 个字段，一半 字符串类型， 一半数值类型， 一行数据估计 2000Byte
抽取样本数 据100万行， 导入数据集 50亿数据的 市，数据量 若全部导入 在180M 需要900G的 量， 压缩比 在11:1
维度数据
细节数据
集市数据
DataCache
JoinJob Data Mart
Cached Data Detail Data From Date To Date Join Type
RemoveJob
RefreshJob
Cycling , Chained Jobs
8
2014-1-8
互联网大数据案例
系统配置调优
©2011-2013 Yonghong Technology Co.,Ltd.
Yonghong大数据BI案例的底层技术分享
2014.1.5
新浪微博@永洪科技BI
大数据的4V
1. 数据量大(Volume) 2. 速度快(Velocity) 3. 类型多(Variety) 4. 价值密度低(Veracity)
2014-1-8
10
互联网大数据案例
海量数据，实时分析
1.90天数据，近10T的原始数据，大部分的查询都是秒级响应 2.实现了Hbase数据与SQL Server中维度表关联分析的需求 3.预算有限，投入并不大，又能解决Hive不够实时的问题 4.性能卓越的交互式BI呈现，非常适合分析师使用
2014-1-8
内部管理内存参数： 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=true"
APP数据
5 台 PC Server 64G 内存 4 CPU (4 Core)
Hadoop
Data Mart Dashboard/Reporting
2014-1-8
4
互联网大数据案例
POC（Proof of Concept）
1.Demo： 5台PC Server 导入10天的数据，如何ETL，如何做简单应用。 2.POC： 导入近3个月的数据 解决步长问题，有效访问次数， 在几个分组内，停留时间大于30分钟 解决HBase数据和SQL Server数据的关联问题 解决分组太多，Span过多的问题 分析师做了些简单的应用报表
2014-1-8
2
目录
• 互联网大数据案例
– 海量数据，实时计算
2014-1-8
3
互联网大数据案例
某著名咨询公司用户行为分析系统
?
面临问题：实时分析的数据量大，基于Hive的分析系统不够实时，但预算有限 解决办法：90天细节数据约50亿条导入Yonghong DM，再定制Dashboard分析
WEB数据
11
架构分析
永洪BI / 其他可视化BI工具
JDBC 接口 ETL管理 备份管理 监控工具
连接池 多路、复用、异步
数据加载/卸 载
SQL优化
列
数据包 数据包 数据包
内存计算
库内计算
列
数据包 数据包 数据包
分布式计算
列
数据包 数据包 数据包
列 存 储
Windows系列
Linux系列
Unix系列
12
架构分析
2014-1-8
9
互联网大数据案例
前端展现：互联网用户行为分析
浏览器分析：运行时间，有效时间，启动次数， 覆盖人数，等等 主流网络电视：浏览总时长，有效流量时长， PV覆盖占有率， UV占有率，等等 主流电商网站：在线总时长，有效在线总时长， 独立访问量，网站覆盖量， 等等 主流财经网站：在线总时长， 有效总浏览时长，独立访问量，总覆盖量， 等等
Hadoop SQL Server 5 台 PC Server 64G 内存 4 CPU (4 Core)
Data Mart
Naming Map
2014-1-8
Client Map Reduce
Map
Map
Map
7
互联网大数据案例
ETL过程
历史数据集中导：每天的细节数据和SQL Server关联后，打上标签，再导入集市 增量数据自动导：先删除近3天的数，再导入近3天的数 维度数据被缓存； 细节数据按照日期打上标签，跟缓存的维度数据关联后入集市； 根据日期标签来删除数据；清洗出有意义的字段。
• 机器角色
– – – – Naming Node Client Node Map Node Reduce Node
• • • • •
通讯协议：ZIO 存储结构：ZFS 及其管理 计算框架：ZMR 及其管理 支持BI的存储格式 支持BI的计算框架
13
部署的考虑
• • • • 数据总量 数据特征 内存总量 CPU总量
2014-1-8
6
互联网大数据案例
设计方案
总共配制需要300G的内存 硬件： 5台PC Server， 每台内存：64G， 4 CPU 4 Core 机器角色：一台Naming 、Map， 一台Client、Reduce、Map，其余三台都是Map
配置 2G 内存 2CPU WIN 7系统 Map Reduce Client Naming
配置 2G 内存 2CPU WIN 7系统
Map
配置 2G 内存 2CPU WIN 7系统
பைடு நூலகம்
Map
配置 2G 内存 2CPU WIN 7系统
Map
14
2014-1-8
5
互联网大数据案例
数据源及数据特征分析
每天5000万行， 原始数据每天 100G， 100天 是10T的数据
90天的数据， Web数据7亿， App数据37亿， 总估计在50 亿
每个表有20多 个字段，一半 字符串类型， 一半数值类型， 一行数据估计 2000Byte
抽取样本数 据100万行， 导入数据集 50亿数据的 市，数据量 若全部导入 在180M 需要900G的 量， 压缩比 在11:1
维度数据
细节数据
集市数据
DataCache
JoinJob Data Mart
Cached Data Detail Data From Date To Date Join Type
RemoveJob
RefreshJob
Cycling , Chained Jobs
8
2014-1-8
互联网大数据案例
系统配置调优
©2011-2013 Yonghong Technology Co.,Ltd.
Yonghong大数据BI案例的底层技术分享
2014.1.5
新浪微博@永洪科技BI
大数据的4V
1. 数据量大(Volume) 2. 速度快(Velocity) 3. 类型多(Variety) 4. 价值密度低(Veracity)
2014-1-8
10
互联网大数据案例
海量数据，实时分析
1.90天数据，近10T的原始数据，大部分的查询都是秒级响应 2.实现了Hbase数据与SQL Server中维度表关联分析的需求 3.预算有限，投入并不大，又能解决Hive不够实时的问题 4.性能卓越的交互式BI呈现，非常适合分析师使用
2014-1-8
内部管理内存参数： 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=true"
APP数据
5 台 PC Server 64G 内存 4 CPU (4 Core)
Hadoop
Data Mart Dashboard/Reporting
2014-1-8
4
互联网大数据案例
POC（Proof of Concept）
1.Demo： 5台PC Server 导入10天的数据，如何ETL，如何做简单应用。 2.POC： 导入近3个月的数据 解决步长问题，有效访问次数， 在几个分组内，停留时间大于30分钟 解决HBase数据和SQL Server数据的关联问题 解决分组太多，Span过多的问题 分析师做了些简单的应用报表
2014-1-8
2
目录
• 互联网大数据案例
– 海量数据，实时计算
2014-1-8
3
互联网大数据案例
某著名咨询公司用户行为分析系统
?
面临问题：实时分析的数据量大，基于Hive的分析系统不够实时，但预算有限 解决办法：90天细节数据约50亿条导入Yonghong DM，再定制Dashboard分析
WEB数据
11
架构分析
永洪BI / 其他可视化BI工具
JDBC 接口 ETL管理 备份管理 监控工具
连接池 多路、复用、异步
数据加载/卸 载
SQL优化
列
数据包 数据包 数据包
内存计算
库内计算
列
数据包 数据包 数据包
分布式计算
列
数据包 数据包 数据包
列 存 储
Windows系列
Linux系列
Unix系列
12
架构分析
2014-1-8
9
互联网大数据案例
前端展现：互联网用户行为分析
浏览器分析：运行时间，有效时间，启动次数， 覆盖人数，等等 主流网络电视：浏览总时长，有效流量时长， PV覆盖占有率， UV占有率，等等 主流电商网站：在线总时长，有效在线总时长， 独立访问量，网站覆盖量， 等等 主流财经网站：在线总时长， 有效总浏览时长，独立访问量，总覆盖量， 等等
Hadoop SQL Server 5 台 PC Server 64G 内存 4 CPU (4 Core)
Data Mart
Naming Map
2014-1-8
Client Map Reduce
Map
Map
Map
7
互联网大数据案例
ETL过程
历史数据集中导：每天的细节数据和SQL Server关联后，打上标签，再导入集市 增量数据自动导：先删除近3天的数，再导入近3天的数 维度数据被缓存； 细节数据按照日期打上标签，跟缓存的维度数据关联后入集市； 根据日期标签来删除数据；清洗出有意义的字段。
• 机器角色
– – – – Naming Node Client Node Map Node Reduce Node
• • • • •
通讯协议：ZIO 存储结构：ZFS 及其管理 计算框架：ZMR 及其管理 支持BI的存储格式 支持BI的计算框架
13
部署的考虑
• • • • 数据总量 数据特征 内存总量 CPU总量