BigData案例.pdf

永洪科技大数据实时分析 Big Data 大数据，谈的不仅仅是数据量，其实包含了数据量(Volume)、时效性 (Velocity)、多样性(Variety)、可疑性(Veracity)。 Hadoop 具备低廉的硬件成本、开源的软件体系、较强的灵活性、允许用户自己修改 代码等特点，同时能支持海量数据存储和计算任务。Hadoop Map Reduce 适合通过批处理 方式访问海量数据，但无法满足海量数据的实时处理的需求。 永洪科技基于自有技术研发的一款数据存储、数据处理的软件 Yonghong Z-Data Mart 是一款专业的 数据集市软件。实时商业智能建设的主要目标是支持实时决策，这就对海量数据处理的即时、 快速、稳定提出了更高的要求。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. 系统配置调优： 内部管理内存参数： mem.proc.count=8 mem.serial.mem=5120 mem.result.mem=10240 JVM 内存管理参数配置： J