大数据平台应用17个知识点汇总，新人必看！！！

一、大数据中的数据仓库和Mpp数据库如何选型?

在Hadoop平台中，一般大家都把hive当做数据仓库的一种选择，而Mpp数据库的典型代表就是impala，presto。Mpp架构的数据库主要用于即席查询场景，暨对数据查询效率有较高要求的场景，而对数据仓库的查询效率要求无法做大MPP那样，所以更多地适用与离线分析场景。

Hadoop已经是大数据平台的实时标准，其中Hadoop生态中有数据仓库Hive，可以作为大数据平台的标准数据仓库，

对于面向应用的MPP数据库，可以选择MYCAT(mySql的分布式架构)或是impala(基于Hive和Hbase)，包括对称式和非对称式两种分布式模式

二、大数据分析中的实时推荐是如何实现的?

实时推荐需要使用实时处理框架结合推荐算法，从而做到对数据的实时处理和推荐。实时处理框架有Storm、Flink、SparkStreaming，组件可以对接Kafka，获取实时流数据，在实时框架内部实现对数据的处理过程。

1、实时推荐需要借助实时计算框架例如Spark或是Strom技术，

2、数据采集采用Flume+Kafka作为数据缓存和分发作用

3、同时还需要有非常适合的实时推荐算法，例如基于用户画像的实时推荐，或是基于用户行为的实施推荐、或是对商品相识度的实施推荐等不同的算法

三、数据治理有何高效的处理方法或工具?

数据治理没有具体的工具和方法，这是一项浩大的工程，可能牵扯到每个部门，既有技术人员参与，又要有业务人员参与，关键时刻还要有领导进行决策。每个公司的数据情况不同，处理方法也不尽相同，基本的方法是有的，暨通过对数据的梳理(元数据、主数据)，发现数据质量问题，再通过质量标准或组织协调的方式，对数据进行标准化处理的。

数据治理是一项人力和辛苦活，没有捷径和什么有效的工具，而且在一个大数据项目中，数据治理是非常重要的一个环节，因为只有数据质量满足前端应用需求，才有可能挖掘和分析出准确的结果。

具体数据处理方法还需要看实际业务情况，例如数据库、数据类型、数据规模等

数据治理的过程是一个对业务系统数据梳理的过程，过程中发现的问题会反馈给业务部门，同时还要制定统一的质量和稽核标准，就好比给每个业务系统数据生成线上增加一个质量监管员。

对大数据以及人工智能概念都是模糊不清的，该按照什么线路去学习，学完往哪方面发展，想深入了解，想学习的同学关注猿学，有大量干货（零基础以及进阶的经典实战）分享给大家，并且有清华大学毕业的资深大数据讲师给大家免费授课，给大家分享目前国内最完整的大数据高端实战实用学习流程体系 。

四、大数据分析中针对日志分析的框架如何选型?

elk 常用组件, 上层业务封装还需要求其他组件完成

日志分析 elk + redis + mysql 热点数据 , 热点分析

等等, 看你的业务是什么模式和 开发人员偏好

现在免费且主流的均已采用Elastic公司的ELK框架，均为轻量级组件，且简单易用，从采集到界面展示几乎用不了多少时间即可搭建完毕，Kibana界面效果优异，包含地图、报表、检索、报警、监控等众多功能。

五、请问在大数据平台搭建过后，大数据平台的运维监控主要关注哪些?

大数据平台的运维监控主要包括硬件和软件层面，具体如下：

1、主机、网络、硬盘、内存、CPU等资源。

在拥有几十台以上的集群环境中，大量的数据计算对硬件尤其是硬盘的损耗是较大的，在大量计算中，网络也往往会成为一个瓶颈，这些都需要时刻关注。

2、平台层面

主要监控平台各个组件的状态、负载情况，有异常及时报警。

3、用户层面

大数据平台建设是为了服务公司内部广大用户的，所以资源既是共享的，又需要是隔离的，所以需要对用户对平台资源的使用情况做好监控，及时发现异常使用情况，防止对其他用户产生不良影响，影响正常业务开展。

大数据平台搭建后，运维监控的主要内容包括

1、分布式架构的底层虚拟机的运行情况(CPU、内存、网络、硬盘等)

2、各个组件(HDFS 、MR、 SPark 、Hive 、Hbase、 IMpla、FLume、 Spooq等)的运行状态和告警信息

六、数据量大，数据类型繁杂的情况下，如何做性能保障?

如何保障大数据平台的处理性能，关键还是看应用场景和业务需求，不是每种业务都需要高性能。

1、在类OLTP场景下，大数据平台有像HBase一样的组件，保证数据读写具有极高的性能和吞吐量。

2、在OLAP场景下，大数据平台有像Impala、Kudu、Kylin、Druid这样引擎，通过内存或预计算的方式保证查询性能。

3、在离线分析场景，有像Hive、Spark、Mapreduce这样的引擎，分布式处理海量数据，在这种场景下，性能和响应时间已无法做到保证。

1、大数据的底层全部都是分布式架构，分布式架构具有很强的横向扩展能力，而且是使用廉价的PC服务器即可组件分布式架构，只有增加服务器数据，性能也可以横向扩展，

2、另外大数据平台在数据处理方面也均是采用分布式处理技术(例如 MR、 Hive、 Hbase 、 HDFS)

3、另外还有一些是基于内存的数据计算和处理架构Spark技术，大数据平台下对性能的要求没有和传统的交互式的响应不太一样，大数据分为实时和离线计算，实时计算要求响应时间，离线计算对于响应时间没有太高的要求。

七、数据预处理问题?

钢铁行业的数据比较复杂，对于对生产工艺不是特别了解的IT人员如何进行数据处理，或是应该由谁来进行数据处理?

数据预处理的过程包括数据的清洗、集成、整合、标准化等过程。

1、数据预处理的过程是由承建大数据项目的供应商来处理，或是专门做数据治理的公司来负责这项工作。

2、大数据项目中，数据的预处理会花费大量的时间，而且是手工工作量较多，如果对业务部太数据，势必会有很多问题，最好是由对业务相对了解的人员来参与数据的预处理的工作。

只有高质量的数据才会有分析的价值，所以预处理过程显得尤为重要。数据是业务的数字化形式，对于比较复杂的行业数据，技术人员是不会知道怎么处理才能满足业务分析的需求的，必须要业务分析人员提出具体的数据处理需求，技术人员才能设计满足相应需求。

八、从传统数仓向大数据平台迁移的规划?

传统数仓很多用oracle做的，现在想转入大数据平台，有什么好的迁移规划方案，以及迁移可能遇到的问题，谢谢!

1、数据仓库无论是用oracle，还是其他数据库，此类型的数据转入大数据平台都有个ETL的过程，将数据统一存放在HDFS分布式文件系统中，上层则借助于Hive构建数据仓库，用于离线数据跑批计算，Hbase，用于支持数据高并发在线查询和非结构化数据的对象存储来满足前段的应用分析需求

2、可以利用数据仓库中原有的数据共享交换平台，实时将数据推送到共享平台，例如Sqoop数据导入结构化数据，利用Flume和Kafka对非结构化类数据进行采集并将之转为结构化数据落地HDFS进行存储

九、传统数仓转向大数据平台的必要性?

如题，或者什么场景的的传统数仓适合转向大数据平台。转向大数据平台后都解决了什么样的问题，暴露出什么样的问题?

大数据平台采用分布式架构，用于解决海量数据的存储和分析问题，传统数仓无法解决上百TB及PB级的分析问题。大数据平台由于架构新，使用模式也不尽相同，有的使用SQL，有的使用spark编程，有的使用mapreduce编程，所以存在一定的学习成本;大数据平台还在逐步完善中，尤其是用户管理、安全、元数据管理等方面还存在一定问题，使用时需要注意。

十、大数据底层保持数据强一致性是如何实现的?

大数据底层的数据强一致性是通过HDFS的分布式架构中的冗余副本策略和心跳检测机制实现的。

1、冗余副本策略：HDFS处理节点失效的一个方法就是数据冗余，即对数据做多个备份，在HDFS中可以通过配置文件设置备份的数量,默认是3副本，只有数据在3个副本上均完成写成功，才返回。

2、心跳机制：检测节点失效使用“心跳机制”。每个 Datanode 节点周期性地向 Namenode 发送心跳信号。 Namenode 通过心跳信号的缺失来检测这一情况，并将这些近期不再发送心跳信号 Datanode 标记为宕机，不会再将新的 IO 请求发给它们。

N： 3 (数据备份的数目)

W： 1 (数据写入几个节点返回成功)，默认是1

R： 1 (读取数据的时候需要读取的节点数)

W + R < N

Hadoop没有办法保证所有数据的强一致性，但是通过副本机制保证一定程度的一致性，如果某一个datanode宕机，将会在其他datanode上重建一个副本，从而达到副本一致性的目的，且在写入的时候可以采用一次写入多个副本的方式保证即使某个副本对应机器挂掉，也不影响整个数据。

十一、大数据平台加入到灾备怎么做?有成熟的思路或者方案吗?

1、灾备解决的是业务连续性的问题，大数据平台本身提供多副本机制是保障业务的稳定和可靠运行的

2、目前大数据平台基本是都是部署在虚拟机或是容器之上，很少有直接部署在物理服务器+存储架构之上

3、这样虚拟化和容器本身就带来很强的业务连续性的功能，例如虚拟机的热迁移、HA、DRS等功能

十二、大数据底层平台对硬件的要求有哪些?

1、在企业内部，最好保证集群中所有机器的配置保持一直，否则容易出现一台机器运行较慢，从而拖慢整体任务运行速度的情况。

2、大数据平台对网络要求较高，在几十台机器的集群下，如果采用千兆网络，极其容易出现某一个大任务把带宽占满的情况。

3、平台对CPU、硬盘的需求相对网络要低点，但也不能太低，否则IO上不来，任务也会被拖慢。

4、平台对内存的要求高，尤其在一个平台内搭建Impala、Spark、MR、Hive、HBase等组件共享资源的情况下，更应该配备高内存。

支持楼上，X86分布式部署即可。尤其注意系统IO性能，可配置SSD。

大吞吐量、大容量，高带宽。

1、Hadoop现在已经是大数据的事实标准，而 Hadoop的出现就是运行在廉价商用服务器上，以集群之力，分而治之地解决先前传统数据库、传统存储、传统计算模型束手无策的问题，让大规模数据的处理成为了可能。

2、对于硬件没有太高的要求，普通的PC服务器即可，但是为了高更的性能，服务器内可以增加SSD固态硬盘或是内容等资源。

十三、大数据人才培养?

向大数据平台转型成功的关键，人才占了很大的比例，如何有效平滑的推动人才队伍的建设?

大数据涉及数据采集、数据的清洗集成、治理、大数据平台的安装调试和运维、大数据的开发、大数据的算法工程师、大数据的挖掘工程师等。

大数据人才需求是一种金字塔架构，最底层需求量最大的是数据采集、清洗和治理的人员(基本上以人工为主)，在上层就是数据平台的安装调试(必须有linux基础)，往上就是大数据的开放、算法和挖掘工程师了。

如果是用户单位，需要提前培养大数据的意识，要认识到大数据的重要性和可行性，培养可以为项目后期提供运维的人员为主。

十四、用户画像用到了哪些大数据技术和工具，做的时候应该注意什么?

所谓用户画像就是用多维度的数据来描述一个用户的整体特征，涉及到特征工程的提取，打标签的过程。

例如用户的属性、偏好、生活习惯、行为、运动、作息等信息，抽象出来的标签化用户模型。通俗来讲就是给用户打标签，而标签是通过对用户信息分析而来的高度精炼的特征标识。

涉及到数据采集、数据建模、挖掘分析等，需要注意一下几点：

1、在画像创建之前需要知道用户关心的的特征维度和用户的行为等因素，从而从总体上掌握对用户需求需求。

2、创建用户画像不是抽离出典型进行单独标签化的过程，而是要融合边缘环境的相关信息来进行讨论。

3、用户画像有时候需要变化、分为短期内的画像、或是长期的画像等。

十五、一般一个大数据项目实施过程中应该注意什么?

这个过程与一般的项目没有本质区别，基本的需求、分析、设计、开发、测试都是要有的。不同的地方是大数据项目采用的技术不像传统的基于数据库的SQL开发那么简单，对编程能力的要求较高，同时对遇到问题的排查能力要求也较高，因为是分布式运行，导致问题排查变得非常复杂。

1、大数据项目实施过程中涉及到和客户的众多业务系统进行对接的，也就是数据的采集，到数据的清洗、集成、标准、数据治理、数据的建模、挖掘分析和最后的可视化等过程。

2、在和业务系统对接的过程中需要注意的必须拿到业务系统的数据字典(如果没有，拿到数据对数据的识别和分析非常困难)。

3、数据业务分析维度，需要项目经理进场需要客户明确的需求后确定系统的范围和边界(否则需求和范围不停的变，开发周期遥遥无期)。

4、准备好大数据平台要求的底层环境和资源(CPU、内存、硬盘、网络等)，大数据项目对于这些资源的要求还是相对比较高的，例如硬盘容量，例如要分析日志类的数据或是流水数据。

十六、企业级大数据平台如何选型?

现在，大数据平台基本特指Hadoop平台了，选型主要还是指Haoop管理平台。现在主流的厂商有cloudera和Hortonworks,国内有华为的fusion insight和星环科技的产品。相对来说，cloudera具有较大优势，市场占有率也较高，管理平台非常实用，对与平台管理人员来说是不可多得的好帮手

Hadoop现在已经是大数据的事实标准了，企业级大数据平台建议选择基于Hadoop开源的生态，目前对于Hadoop开源商业推广最大的两个场景及cloudera(CDH版本，适合于linux系统上运行)和Hortonworks(HDP版本，支持运行在windows系统上运行)，目前是一家公司了，可以选择其中一家产品即可

十七、大数据中的实时计算SPark和Storm优缺点是什么?分别适合于哪些场景?

SparkStreaming和Strom都属于实时计算框架，有点都是可以做到对数据的实时处理。SparkStreaming是基于Spark Core实现的，所以对数据的处理要形成RDD，暨要形成数据窗口，所以其处理过程可以称之为微批处理，而storm是可以做到实时处理每一条数据的，所以相对来说，实时性比sparkstreaming更高。所以storm更适合处理实时性要求极高的场景。

SPark体系中的 Spark Streaming严格意义上属于批处理计算框架，准实时，基于内存的计算框架，性能可以达到秒级，大数据除了实时计算之外，还包括了离线批处理、交互式查询等业务功能，而且实时计算中，可能还会牵扯到高延迟批处理、交互式查询等功能，就应该首选Spark生态，用Spark Core开发离线批处理，用Spark SQL开发交互式查询，用Spark Streaming开发实时计算，三者可以无缝整合，给系统提供非常高的可扩展性。

Storm是纯实时计算框架，来一条数据，处理一条数据，可以达到毫秒级，适合于要求可靠的事务机制和可靠性机制，即数据的处理完全精准，一条也不能多，一条也不能少，也可以考虑使用Storm。

形象点比喻，SPark就好比商城的直梯，Storm就好比商场的扶梯。