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