永洪科技大数据实时分析永洪科技基于自有技术研发的一款数据存储、数据处理的软件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亿条导入Yonghong DM，再定制Dashboard分析。
2.简单测试：先通过5台PC Server，导入1-2天的数据，演示如何ETL，如何做简单应用。
3.按照提出的测试方案开始导入90天的数据，在导入数据中解决了如下问题：解决步长问题，有效访问次数，在几个分组内，停留时间大于30分钟。
解决HBase数据和SQL Server数据的关联问题。
解决分组太多，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，4CPU4Core。
机器角色：一台Naming、Map，一台Client、Reduce、Map，其余三台都是Map。
6.ETL过程:历史数据集中导：每天的细节数据和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:+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"8.前端展现：互联网用户行为分析:浏览器分析：运行时间，有效时间，启动次数，覆盖人数，等等。
主流网络电视：浏览总时长，有效流量时长，PV覆盖占有率，UV占有率，等等。
主流电商网站：在线总时长，有效在线总时长，独立访问量，网站覆盖量，等等。
主流财经网站：在线总时长，有效总浏览时长，独立访问量，总覆盖量，等等。
报表截图案例测试结果90天数据，近10T的原始数据，大部分的查询都是秒级响应。
实现了Hbase数据与SQL Server中维度表关联分析的需求。
预算有限，投入并不大，又能解决Hive不够实时的问题。
性能卓越的交互式BI呈现，非常适合分析师使用。
电信大数据案例案例背景某省移动CMNET流量分析与控制系统面临问题：数据量特别大，但预算特别有限，基于DW的分析系统完全无法支持。
问题解决步骤1.首先提出了测试方案：100天数据约60亿条导入Yonghong DM，再定制Dashboard分析。
由于预算特别有限，硬件上定制6个节点的PC集群(1CPU4Core)。
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，1CPU4Core。
历史数据集中导：按照两小时打标签，和维度表关联生成细节数据，再汇总入库。
增量数据自动导：每5分钟导入数据，每两小时生成汇总数据。
系统保留3天细节数据和100天汇总数据供BI前端消费。
7.系统配置调优:内部管理内存参数：mem.proc.count=4mem.serial.mem=5120JVM内存管理参数配置：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系统。
交付周期：交付周期偏短，项目失败率低；乐意在客户现场做POC(Proof of Concept)。
需求变化：可以应对变化，新需求交付周期很短；相关模块调整不大，交付周期在一两天之内。
成本：一站式平台提供数据集市和BI软件，无需购买MPP数据仓库，费用低。
自服务BI：能够形成自服务BI。
分析：展现只是起点，分析功能强大。
海量数据：X86通用平台，以Scale-out扩展模式处理海量数据。
基于CPU收费，具有较高性价。
数据集市：TB、PB级别数据查询秒级响应。