一、大数据的4v特征
- 数据量大
- TB->PB->ZB
- HDFS分布式文件系统
- 数据种类多
- 结构化数据
- Mysql为主的存储和处理
- 非结构化数据
- 图像、音频等
- HDFS、MR、Hive
- 半结构化数据
- XML形式、HTML形式
- HDFS、MR、Hive、Spark
- 结构化数据
- 速度快
- 数据增长速度快
- TB->PB->ZB
- HDFS
- 数据处理速度快
- MR、Hive、PIG、Impala（离线）
- Spark、Flink（实时）
- 数据增长速度快
- 价值密度低
- 价值密度=有价值数据/全部数据
- 价值高
- 机器学习算法解决的问题
二、项目架构
项目名称：电信日志分析系统
项目表述：
- 电信日志分析系统是以电信用户上网所产生的数据进行分析和统计计算，数据主要来源于用户的上网产生的访问日志和安全日志，通过Hadoop大数据平台完成日志的入库、处理、查询、实时分析、上报等功能，达到异常IP的检测、关键词过滤、违规违法用户的处理 等，整个项目数据量在1T-20T左右，集群数量在10台到100台。
项目架构分析
- 数据采集层
- 用户访问日志数据（ftp）
- 数据格式：地区码201|用户ip|目的ip|流量|。。。
- 数据采集的方式：采用ftp方式上传到服务器
- 数据上传的时间：每小时上传一个小时的数据
- 小文件合并：通过shell完成小文件合并
- 监控文件：JNotify
- 用户的安全日志数据（socket）
- 当用户触犯电信部门制定的制度，违反国家法律法规
- 数据采集方式用：Socket—C++完成数据采集。先缓存到内存再到磁盘
- 数据格式：加密码，加密形式 abc：79217979web
- 网卡配置：千兆或万兆网卡
- 用户访问日志数据（ftp）
- 数据存储层
- HDFS分布式文件系统
- 数据分析层
- MapReduce
- 1.完成数据清洗的工作，如：缺失字段的处理，异常值的处理等
- 2.使用MR和Redis进行交互完成地区码201和地区名字的转化
- 3.使用MR处理好的数据进一步加载到Hive中做处理
- 4.使用MR 将数据入库到HBASE完成固定条件查询
- 5.给到Spark中实时查询
- 覆盖map函数
- k：v——地区码：地区名字
- Hive
- 1.基础的实时性要求不高，统计需求
- 2.一些小文件的合并
- 3.将Hive处理后的数据进一步加载到其他业务系统处理
- Impala
- 实时性较高的需求
- Impala+Hive传递
- 通过JDBC传到Web、SSM
- 通过Sqoop传到oracle
- HBASE
- 完成固定条件的查询
- 通过协处理器+thrift传到Web、SSM
- Spark
- 解决了单一数据源再40个指标的情况下完成内存中计算和topn
- OOZIE
- 任务调取
- Mysql
- Hive元数据存放
- OOZIE元数据存放
- 接口机
- 用于提交任务的机器
- OOZIE任务（MR、Hive、IMAPLA）
- Spark任务
- MapReduce
- 机器学习层
- 机器学习位于大数据上层，完成的是在大数据基础的数据存储和数据计算之上，通过数据结合机器学习算法构建机器学习模型，利用模型对现实事件做出预测
- 数据展示层
- SSM、Web-》oracle
项目职责
- 重点负责：实时or离线
- 处理分析了哪些字段，通过何种手段分析？
- 项目有无优化？
项目优化
- HDFS+Spark（一站式分析平台）
存储方案
- 结构化存储方案
- 对应解决方案
- 关系型数据库
- 数据的解析
- 传统的关系型数据库、行数据，存储于关系型数据库，可以用二位逻辑结构表示
- 使用成熟的方案
- Oracle数据库、Mysql数据库基于开源数据库的商用产品
- 典型数据举例
- 医院首页、三测表、医嘱信息
- 可扩展性
- 支持在线平滑扩容
- 对应解决方案
- 半结构化和非结构化存储方案
- 对应解决方案
- NoSql非关系型数据库
- 数据解析
- 半结构数据的数据结构和内容混杂在一起，非结构化数据不能用二维逻辑表示，无结构性
- 使用成熟的方案
- 基于Hbase、Hive等商用nosql数据库，集成Impala、Spark等数据处理框架
- 典型数据举例
- 出入院信息、病程记录、手术记录
- 病人肖像照片、医学影像、病历扫描件
- 可扩展性
- 支持在线平滑扩容
- 对应解决方案
层任务分析
- 数据采集
- 结构化数据采集
- 半结构化和非结构化数据采集
- 数据存储
- 基于Nosql数据库存储
- Mysql存储
- Hbase列式数据库存储
- 基于Nosql数据库存储
- 数据ETL
- 数据库外的ETL应用
- 数据清洗
- 数据抽取
- 数据转换
- 数据加载
- 数据库外的ETL应用
- 数据分析
- 基于Hadoop平台的分析
- MapReduce
- Hive
- Impala
- Spark
- 基于Hadoop平台的分析
- 数据挖掘
- 基于业务的建模和深度挖掘
- 复杂报表
- 趋势分析
- 精准营销
- 自助建模
- 基于业务的建模和深度挖掘
- 业务应用
- 业务层应用
数据传递结构
- 构建医疗大数据平台
- 医疗大数据托管服务
- 数据可视化服务
其他
- 医疗大数据库集成共享
- 医疗大数据库处理分析
- 离线处理
- 在线处理
- 实时分析
- 数据存储
- 结构化数据存储
- 半结构化数据存储
- 非结构化数据存储
- 统一资源池
处理方案
- 离线批处理方案
- 对应解决方案
- 并行数据挖掘系统
- 能力需求
- 需要提供海量数据批处理功能，以支持大数据转小数据，将非结构化数据转换为结构化的知识，将口径不同的数据归一化处理，将离散数据整合等功能
- 技术选型
- 基于Hadoop的并行框架
- 典型数据举例
- 复杂统计报表生成、疾病流行趋势预测、医疗收费与客户满意度相关分析
- 对应解决方案
- 在线分析技术方案
- 对应解决方案
- 大数据仓库系统
- 能力需求
- 需要提供针对大规模数据的高性能即席查询能力，需要解决大规模（PB级别以上）、查询响应时间段、系统兼容性强等技术难题
- 技术选型
- 基于Hbase、Hive框架
- 典型数据举例
- 病例填写时，病史信息自动反馈与记录，特定专科门诊诊疗检查方案自动弹出备选药品价格查询
- 对应解决方案
- 实时计算方案
- 对应解决方案
- 流计算技术
- 能力需求
- 提供流式数据快速处理（聚合和监测两种），需要解决数据量大（日均百亿以上），实时性要求高（分钟级别），系统通用性强（业务灵活）等技术难题
- 技术选型
- 开源流计算框架
- 典型数据举例
- 实时接诊压力检测（分流就诊人群）、病人状况实时监控
- 对应解决方案
配置规则
- 1.主节点互备（NN和RM）
- 2.需要较大网络带宽的机器通常配置两块网卡，至少是千兆网，并且分别属于不同的网段（接收数据和put数据不能在一个网段）
- 3.需要较大内存的服务组件最好不要集中在一台机器上
- 4.cpu消耗较高的组件一定要单独在一台机器上
- 5.采集机同时可当接口机使用
- 6.若有非Hadoop组件需要使用，建议单独分配机器或者直接使用hadoop普通存储机
- 7.组件的元数据库一定要有备份机，最好不要使用hadoop机器
- 8.根据删除数据的重要性可以考虑是否使用垃圾桶机制（节省存储空间)