2.3 系统运行环境
2.3.1 硬件环境
在实际生产环境中，我们需要进行服务器的选型，服务器是选择物理机还是云主机呢？
1.机器成本考虑
物理机，以128GB内存、20核物理CPU、40线程、8TB HDD和2TB SSD的戴尔品牌机为例，单台报价约4万元，并且还需要考虑托管服务器的费用，一般物理机寿命为5年左右。
云主机，以阿里云为例，与上述物理机的配置相似，每年的费用约5万元。
2.运维成本考虑
物理机需要由专业运维人员进行维护，云主机的运维工作由服务提供方完成，运维工作相对轻松。
实际上，服务器的选型除了参考上述条件，还应该根据数据量来确定集群规模。
在本项目中，读者可在个人计算机上搭建测试集群，建议将计算机配置为16GB内存、8核物理CPU、i7处理器、1TB SSD。测试服务器规划如表2-12所示。
表2-12 测试服务器规划
2.3.2 软件环境
1.技术选型
数据采集运输方面，在本项目中主要完成三个方面的需求：将服务器中的日志数据实时采集到大数据存储系统中，以防止数据丢失及数据堵塞；将业务数据库中的数据采集到数据仓库中；同时将需求计算结果导出到关系型数据库方便进行展示。为此我们选用了Flume、Kafka和Sqoop。
Flume是一个高可用、高可靠、分布式的海量数据收集系统，可从多种源数据系统采集、聚集和移动大量的数据并集中存储。Flume提供了丰富多样的组件供用户使用，不同的组件可以自由组合，组合方式基于用户设置的配置文件，非常灵活，可以满足各种数据采集传输需求。
Kafka是一个提供容错存储、高实时性的分布式消息队列平台。我们可以将它用在应用和处理系统间高实时性和高可靠性的流式数据存储中，也可以实时地为流式应用传送和反馈流式数据。
Sqoop用于在关系型数据库（RDBMS）和HDFS之间传输数据，启用了一个MapReduce任务来执行数据采集任务，传输大量结构化或半结构化数据的过程是完全自动化的。其主要通过JDBC和关系型数据库进行交互，理论上支持JDBC的Database都可以使用Sqoop和HDFS进行数据交互。
数据存储方面，在本项目中主要完成对海量原始数据及转化后各层数据仓库中的数据的存储和对最终结果数据的存储。对海量原始数据的存储，我们选用了HDFS。HDFS是Hadoop的分布式文件系统，适合应用于大规模的数据集上，将大规模的数据集以分布式文件的方式存储于集群中的各台节点服务器上，提高文件存储的可靠性。对最终结果数据的存储，由于数据体量比较小，且为了方便访问，我们选用了MySQL。
数据计算方面，我们选用配置了Tez运行引擎的Hive。Hive是基于Hadoop的数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供SQL查询功能，将SQL语句转化为MapReduce任务进行运行，可以说在Hadoop之上提供了数据查询的功能，主要解决非关系型数据的查询问题。Tez运行引擎可以将多个有依赖的作业转换为一个作业，这样可以减少中间计算过程产生的数据的落盘次数，从而大大提升作业的计算性能。
即席查询模块，我们对当前比较流行的三种即席查询都进行了探索实验，分别是Presto、Druid和Kylin。三种即席查询各有千秋，Presto基于内存计算，Druid是优秀的时序数据处理引擎，Kylin基于预Cube创建计算。
面对海量数据的处理，对元数据的管理会随着数据体量的增大而显得尤为重要。为寻求数据治理的开源解决方案，Hortonworks公司联合其他厂商与用户于2015年发起数据治理倡议，包括数据分类、集中策略引擎、数据血缘、安全、生命周期管理等方面。Apache Atlas项目就是这个倡议的结果，社区伙伴持续地为该项目提供新的功能和特性。该项目用于管理共享元数据、数据分级、审计、安全性、数据保护等方面。
总结如下。
● 数据采集与传输：Flume、Kafka、Sqoop。
● 数据存储：MySQL、HDFS。
● 数据计算：Hive、Tez。
● 任务调度：Azkaban。
● 即席查询：Presto、Druid、Kylin。
● 元数据管理：Atlas。
2.框架选型
框架版本的选型要求满足数据仓库平台的几大核心需求：子功能不设局限、国内外资料及社区尽量丰富、组件服务的成熟度和流行度较高。待选择版本如下。
● Apache：运维过程烦琐，组件间的兼容性需要自己调研（本次选用）。
● CDH：国内使用较多，不开源，不用担心组件兼容问题。
● HDP：开源，但没有CDH稳定，使用较少。
笔者经过考量决定选择Apache原生版本大数据框架，一方面可以自由定制所需功能组件；另一方面CDH和HDP版本框架体量较大，对服务器配置要求相对较高。本项目中用到的组件较少，Apache原生版本即可满足需要。
笔者经过对版本兼容性的调研，确定的版本选型如表2-13所示。
表2-13 版本选型
