你准备好面试了吗？呀，需要Hadoop的知识！！不要慌！这里有一些可能会问到的问题以及你应该给出的答案。

Q1.什么是Hadoop？

Hadoop是一个开源软件框架，用于存储大量数据，并发处理/查询在具有多个商用硬件（即低成本硬件）节点的集群上的那些数据。总之，Hadoop包括以下内容：

HDFS（Hadoop Distributed File System，Hadoop分布式文件系统）：HDFS允许你以一种分布式和冗余的方式存储大量数据。例如，1 GB（即1024 MB）文本文件可以拆分为16 * 128MB文件，并存储在Hadoop集群中的8个不同节点上。每个分裂可以复制3次，以实现容错，以便如果1个节点故障的话，也有备份。HDFS适用于顺序的“一次写入、多次读取”的类型访问。

MapReduce：一个计算框架。它以分布式和并行的方式处理大量的数据。当你对所有年龄> 18的用户在上述1 GB文件上执行查询时，将会有“8个映射”函数并行运行，以在其128 MB拆分文件中提取年龄> 18的用户，然后“reduce”函数将运行以将所有单独的输出组合成单个最终结果。

YARN（Yet Another Resource Nagotiator，又一资源定位器）：用于作业调度和集群资源管理的框架。

Hadoop生态系统，拥有15多种框架和工具，如Sqoop，Flume，Kafka，Pig，Hive，Spark，Impala等，以便将数据摄入HDFS，在HDFS中转移数据（即变换，丰富，聚合等），并查询来自HDFS的数据用于商业智能和分析。某些工具（如Pig和Hive）是MapReduce上的抽象层，而Spark和Impala等其他工具则是来自MapReduce的改进架构/设计，用于显著提高的延迟以支持近实时（即NRT）和实时处理。

Q2.为什么组织从传统的数据仓库工具转移到基于Hadoop生态系统的智能数据中心？

Hadoop组织正在从以下几个方面提高自己的能力：

现有数据基础设施：

主要使用存储在高端和昂贵硬件中的“structured data，结构化数据”

主要处理为ETL批处理作业，用于将数据提取到RDBMS和数据仓库系统中进行数据挖掘，分析和报告，以进行关键业务决策。

主要处理以千兆字节到兆字节为单位的数据量

基于Hadoop的更智能的数据基础设施，其中

结构化（例如RDBMS），非结构化（例如images，PDF，docs）和半结构化（例如logs，XMLs）的数据可以以可扩展和容错的方式存储在较便宜的商品机器中。

可以通过批处理作业和近实时（即，NRT，200毫秒至2秒）流（例如Flume和Kafka）来摄取数据。

数据可以使用诸如Spark和Impala之类的工具以低延迟（即低于100毫秒）的能力查询。

可以存储以兆兆字节到千兆字节为单位的较大数据量。

这使得组织能够使用更强大的工具来做出更好的业务决策，这些更强大的工具用于获取数据，转移存储的数据（例如聚合，丰富，变换等），以及使用低延迟的报告功能和商业智能。

Q3.更智能&更大的数据中心架构与传统的数据仓库架构有何不同？

传统的企业数据仓库架构

基于Hadoop的数据中心架构

Q4.基于Hadoop的数据中心的好处是什么？

随着数据量和复杂性的增加，提高了整体SLA（即服务水平协议）。例如，“Shared Nothing”架构，并行处理，内存密集型处理框架，如Spark和Impala，以及YARN容量调度程序中的资源抢占。

缩放数据仓库可能会很昂贵。添加额外的高端硬件容量以及获取数据仓库工具的许可证可能会显著增加成本。基于Hadoop的解决方案不仅在商品硬件节点和开源工具方面更便宜，而且还可以通过将数据转换卸载到Hadoop工具（如Spark和Impala）来补足数据仓库解决方案，从而更高效地并行处理大数据。这也将释放数据仓库资源。

探索新的渠道和线索。Hadoop可以为数据科学家提供探索性的沙盒，以从社交媒体，日志文件，电子邮件等地方发现潜在的有价值的数据，这些数据通常在数据仓库中不可得。

更好的灵活性。通常业务需求的改变，也需要对架构和报告进行更改。基于Hadoop的解决方案不仅可以灵活地处理不断发展的模式，还可以处理来自不同来源，如社交媒体，应用程序日志文件，image，PDF和文档文件的半结构化和非结构化数据。

Q5.大数据解决方案的关键步骤是什么？

提取数据，存储数据（即数据建模）和处理数据（即数据加工，数据转换和查询数据）。

提取数据

从各种来源提取数据，例如：

RDBM（Relational Database Management Systems）关系数据库管理系统，如Oracle，MySQL等。

ERPs（Enterprise Resource Planning）企业资源规划（即ERP）系统，如SAP。

CRM（Customer Relationships Management）客户关系管理系统，如Siebel，Salesforce等

社交媒体Feed和日志文件。

平面文件，文档和图像。

并将其存储在基于“Hadoop分布式文件系统”（简称HDFS）的数据中心上。可以通过批处理作业（例如每15分钟运行一次，每晚一次，等），近实时（即100毫秒至2分钟）流式传输和实时流式传输（即100毫秒以下）去采集数据。

Hadoop中使用的一个常用术语是“Schema-On-Read”。这意味着未处理（也称为原始）的数据可以被加载到HDFS，其具有基于处理应用的需求在处理之时应用的结构。这与“Schema-On-Write”不同，后者用于需要在加载数据之前在RDBM中定义模式。

存储数据

数据可以存储在HDFS或NoSQL数据库，如HBase。HDFS针对顺序访问和“一次写入和多次读取”的使用模式进行了优化。HDFS具有很高的读写速率，因为它可以将I / O并行到多个驱动器。HBase在HDFS之上，并以柱状方式将数据存储为键/值对。列作为列家族在一起。HBase适合随机读/写访问。在Hadoop中存储数据之前，你需要考虑以下几点：

数据存储格式：有许多可以应用的文件格式（例如CSV，JSON，序列，AVRO，Parquet等）和数据压缩算法（例如snappy，LZO，gzip，bzip2等）。每个都有特殊的优势。像LZO和bzip2的压缩算法是可拆分的。

数据建模：尽管Hadoop的无模式性质，模式设计依然是一个重要的考虑方面。这包括存储在HBase，Hive和Impala中的对象的目录结构和模式。Hadoop通常用作整个组织的数据中心，并且数据旨在共享。因此，结构化和有组织的数据存储很重要。

元数据管理：与存储数据相关的元数据。

多用户：更智能的数据中心托管多个用户、组和应用程序。这往往导致与统治、标准化和管理相关的挑战。

处理数据Hadoop的处理框架使用HDFS。它使用“Shared Nothing”架构，在分布式系统中，每个节点完全独立于系统中的其他节点。没有共享资源，如CPU，内存以及会成为瓶颈的磁盘存储。Hadoop的处理框架（如Spark，Pig，Hive，Impala等）处理数据的不同子集，并且不需要管理对共享数据的访问。“Shared Nothing”架构是非常可扩展的，因为更多的节点可以被添加而没有更进一步的争用和容错，因为每个节点是独立的，并且没有单点故障，系统可以从单个节点的故障快速恢复。

Q6.你会如何选择不同的文件格式存储和处理数据？

设计决策的关键之一是基于以下方面关注文件格式：

使用模式，例如访问50列中的5列，而不是访问大多数列。

可并行处理的可分裂性。

块压缩节省存储空间vs读/写/传输性能

模式演化以添加字段，修改字段和重命名字段。

CSV文件CSV文件通常用于在Hadoop和外部系统之间交换数据。CSV是可读和可解析的。CSV可以方便地用于从数据库到Hadoop或到分析数据库的批量加载。在Hadoop中使用CSV文件时，不包括页眉或页脚行。文件的每一行都应包含记录。CSV文件对模式评估的支持是有限的，因为新字段只能附加到记录的结尾，并且现有字段不能受到限制。CSV文件不支持块压缩，因此压缩CSV文件会有明显的读取性能成本。

JSON文件JSON记录与JSON文件不同；每一行都是其JSON记录。由于JSON将模式和数据一起存储在每个记录中，因此它能够实现完整的模式演进和可拆分性。此外，JSON文件不支持块级压缩。

序列文件序列文件以与CSV文件类似的结构用二进制格式存储数据。像CSV一样，序列文件不存储元数据，因此只有模式进化才将新字段附加到记录的末尾。与CSV文件不同，序列文件确实支持块压缩。序列文件也是可拆分的。序列文件可以用于解决“小文件问题”，方式是通过组合较小的通过存储文件名作为键和文件内容作为值的XML文件。由于读取序列文件的复杂性，它们更适合用于在飞行中的（即中间的）数据存储。

注意：序列文件是以Java为中心的，不能跨平台使用。

Avro文件适合于有模式的长期存储。Avro文件存储具有数据的元数据，但也允许指定用于读取文件的独立模式。启用完全的模式进化支持，允许你通过定义新的独立模式重命名、添加和删除字段以及更改字段的数据类型。Avro文件以JSON格式定义模式，数据将采用二进制JSON格式。Avro文件也是可拆分的，并支持块压缩。更适合需要行级访问的使用模式。这意味着查询该行中的所有列。不适用于行有50+列，但使用模式只需要访问10个或更少的列。Parquet文件格式更适合这个列访问使用模式。

Columnar格式，例如RCFile，ORCRDBM以面向行的方式存储记录，因为这对于需要在获取许多列的记录的情况下是高效的。如果在向磁盘写入记录时已知所有列值，则面向行的写也是有效的。但是这种方法不能有效地获取行中的仅10%的列或者在写入时所有列值都不知道的情况。这是Columnar文件更有意义的地方。所以Columnar格式在以下情况下工作良好

在不属于查询的列上跳过I / O和解压缩

用于仅访问列的一小部分的查询。

用于数据仓库型应用程序，其中用户想要在大量记录上聚合某些列。

RC和ORC格式是专门用Hive写的而不是通用作为Parquet。

Parquet文件Parquet文件是一个columnar文件，如RC和ORC。Parquet文件支持块压缩并针对查询性能进行了优化，可以从50多个列记录中选择10个或更少的列。Parquet文件写入性能比非columnar文件格式慢。Parquet通过允许在最后添加新列，还支持有限的模式演变。Parquet可以使用Avro API和Avro架构进行读写。

所以，总而言之，相对于其他，你应该会更喜欢序列，Avro和Parquet文件格式；序列文件用于原始和中间存储，Avro和Parquet文件用于处理。