从0构建大数据平台，该考虑哪些事情？
今天聊一聊从0搭建大数据平台你该考虑哪些事情？
01公有云 or 私有云
我们在第一讲中介绍了大数据的基石——云计算。云计算分为公有云和私有云。那么在大数据平台选型时应该选公有云还是私有云，或是两者结合的混合云？我们认为有以下评估依据：
企业规模：小企业、创业公司建议使用公有云搭建大数据平台，甚至直接购买公有云提供的大数据PaaS和SaaS服务。中大型、超大型企业建议使用私有云或混合云。
数据安全和技术掌控：如数据安全要求极高（如和公有云提供商业务有竞争），或希望有强力技术掌控，建议使用私有云。否则可以考虑使用公有云或混合云。
服务SLA：能够接受云服务商设定的SLA，以及在故障时希望仅靠云服务商来处置的，可以使用公有云。如果有能力实现更好的SLA，希望自己为技术兜底的，建议使用私有云。
成本模式：能接受较高的固定成本（主要为硬件）和人力成本的，可以使用私有云。能接受较高的运营成本（主要为公有云租用费用）的，可以使用公有云或混合云。
业务灵活性：业务相对固定，可使用SaaS方案进行配置的，可使用公有云。业务更灵活，有自主开发能力的，建议使用私有云。
02社区版 or 发行版
社区版：指开源社区开发、编译出来的版本，通常遵守Apache 2.0或类似的协议，只要遵守协议即可免费用于各种商业目的。如Apache Hadoop。
发行版：一些厂商在开源代码的基础上，修复bug、加入自己的优化、整合管理工具，并提供相应的技术支持和培训认证等，如此产生的版本称为发行版。通常，发行版只有用于研究目的时可以免费试用，用于生产时必须付费。如Hadoop领域的发行版有Cloudera的CDH、Hortonworks的HDP（两家已合并）、MapR的MapR、国内华为的FusionInsight等。
还有一些组件，其社区版和发行版是由同一家公司维护的，如Elasticsearch就是由名为Elasticsearch B.V.的公司开发，并同时提供免费版本和不同级别的收费版本。
03物理机 or 容器化
时至今日，90%以上的Hadoop集群仍在使用物理机方式部署（如果使用云主机如ECS直接部署Hadoop，基本也可视为物理机方式部署）。这是由HDFS的一个设计思想决定的。
移动计算比移动数据划算：如果应用程序所操作的数据就在附近，那么这种应用计算的效率就比较高，特别是当数据集很大的时刻。这减少了网络拥塞，增加了系统的整体效率。这要求将计算放置到数据存储的附近，而不是将数据移动到计算程序处。HDFS提供了实现这种需要的接口。我们有时称之为“数据本地性”。
究其原因，2001年Google在创造GFS时，典型的HDD吞吐量约50MB/s，通过挂多硬盘的方式可以增加到1GB/s级别。而当时局域网主流带宽是100Mb/s，约合12MB/s，远程访问数据实在是太慢了。因此当时使用计算和存储耦合的架构是合理的。
近20年后，机房网络已普遍使用光设备，主流带宽是10Gb/s，增长了100倍。而HDD除了容量大幅增加外，读写速度并没有成倍的提高。大数据处理系统的瓶颈逐渐由IO变成了CPU/内存。
同时，存储计算耦合的部署方案还可能存在以下痛点：
1.不同批次采购的机器可能有不同的存储空间和计算能力配比，使得机器的资源管理问题比较复杂和纠结
2.当存储或计算资源不足时，只能同时对两者进行扩容，使得存在一定的资源浪费
3.无法实现真正的弹性扩缩容，因为计算节点同时也是数据节点，关闭闲置的计算节点会导致数据丢失
因为以上的现状和痛点，诞生了“存储计算分离”的架构模式。Cloudera在最新的Hadoop发行版CDP中，大力推广多云和混合云的支持特性，例如将HDFS节点部署在本地机房中，Yarn/Spark节点部署在容器中或云上。
某大型企业的测试案例：
使用存储计算分离的架构vs纯物理机部署的架构。在繁忙时段，存储计算分离方案比纯物理机方案有10-12%的性能损失。在空闲时段，存储计算分离方案可释放部分容器用于其他目的，而物理机方案仍然需要全部在线。
究竟是使用传统的全物理机部署方案，还是引入容器化做存储计算分离的方案，有以下一些评估依据：
1.集群规模。对于500甚至1000节点以上的大集群，使用存储计算分离来节约资源是有价值的。否则，需要权衡节约的资源和性能损失。
2.作业特性。存储计算分离方案比较适合有较多无状态、朝生夕灭的任务的集群，例如工作时间有大量Hive/Spark/Impala批处理任务的集群。如果集群的计算负载比较稳定，则没有分离的必要。
3.历史负担。存储计算分离方案需要从集群部署时就确定，包括合理的网络架构、Hadoop版本、容器支持等。因此通常只能用于新建集群时采用。如企业有较重的历史负担，只能做扩容，无法承担新投资一个集群的成本，则不适合存储计算分离。
04稳定版本组件 or 追新特性
案例：
某公司在建设大数据集群时，为追新特性使用了3.0的核心版本。上线后，由于运维人员的失误，使得HBase的数据存储目录也开启了纠删码（擦除码）特性，使得HBase的性能和稳定性急剧降低。由于整个团队对这一特性都不熟悉，经过大量排查和测试才定位到问题。
上述案例说明，选择组件版本需要考虑技术掌控能力，而不需要一味追新特性。例如Hadoop3.0后新加入的纠删码（擦除码）特性，最多可以将数据膨胀率降低到1.4，然而这一特性会产生巨大的CPU和网络IO开销，只适合冷数据使用，如误用可能会产生严重问题。
另有一项统计数据表明，使用CDH的公司中超过95%仍在使用5.x版本。这里当然有付费敏感的因素，但也从另一方面说明大部分企业都比较重视稳定性。
在组件版本的选择上，需要考虑的因素如下：
1.是否需要高版本Hadoop特性。如确实需要纠删码、多NameNode支持等新特性，则可以使用Hadoop3.x/CDH6.x，否则尽量使用Hadoop2.6后的稳定版本/CDH5.13后的稳定版本。
2.对CDH中没有内置的组件，是否具备一定的掌控力。如CDH5.x中没有Flink（CDH6.x中可以通过csd方式安装Flink1.9），如果确实需要安装Apache版的Flink，此时是选最新的1.10，还是选相对稳定的1.9或1.8，则取决于团队的能力。
3.组件社区的活跃程度。一般较为流行的组件，最新版本的问题暴露得较快，也较容易得到社区支持。冷门组件的新版本则很可能踩坑。
05批流分离 or 批流一体
大数据平台支持的重要应用之一就是数据仓库。今天，绝大多数企业都同时需要离线数仓和实时数仓，这就涉及到一个架构层面的决策，究竟是使用批流分离的架构还是批流一体的架构？这两种架构在实践中又被称为Lambda架构和Kappa架构。
Lambda架构：
数据来源于消息队列（如Kafka），进入Lambda架构后，会同时进入离线处理（Hadoop）和实时处理（Storm、SparkStreaming等）两个处理模块。离线处理进行批计算，将大量T+1的数据进行汇总。而实时处理则是进行流处理或者是微批处理，计算秒级、分钟级的结果。最后都录入到服务数据库（Serving DB）中进行汇总，暴露给上层服务调用。
优点：架构简单，结合了批处理和流处理的优点；稳定且实时计算部分成本可控；对数据订正友好
缺点：需要同时维护批处理和流处理两套代码，并保证处理结果是一致的
Kappa架构：
数据来源于消息队列（如Kafka），且在消息队列中需要保留更多周期的数据。数据处理部分只有实时处理，正常情况下消费消息队列中的实时数据，按周期将结果写入服务数据库（Serving DB）。当需要订正数据时，修正实时处理代码，重放数据，扩展实时处理系统的并发度，快速回溯历史数据。
优点：只有实时模块，避免了维护两套系统和保证数据一致性的问题；通过消息重放即可解决订正问题；无需离线和实时数据合并
缺点：消息队列缓存的数据量和回溯有性能瓶颈；多个实时流如需进行join，非常依赖实时计算系统的能力，并可能导致数据丢失
批流分离或批流一体的选择依据：
1.数据规模和计算能力。如果数据规模较大，但计算资源又较为缺乏，Lambda架构更为经济，因为T+1数据的批量计算非常节约资源，且算完即可释放（采用存储计算分离时），流计算部分只需要计算最多1天的数据，资源消耗较小。而Kappa架构需要频繁的数据重放（例如计算本月的去重UV、或流任务挂掉），对计算资源的要求更高。
2.对流计算组件的掌控度。这里说的组件不仅包含计算框架Spark/Flink，还涉及到消息队列如Kafka，因为在Kappa架构中这些组件内都需要堆积大量数据，产生问题的几率更高，也更难于修复。
3.是否需要中间结果。Kappa架构中，Spark/Flink内存中的流表都是无法被查询系统直接访问的，只把最终结果输出到服务数据库。如果流表中的数据也会被查询，需要单独落地，无形中增加了开发成本。如这种情况很多，建议采用Lambda架构，在离线部分使用分层的数据仓库，可轻松解决该问题。如不涉及此类问题，可以放心使用Kappa架构。
从0到1搭建大数据平台的系列文章：
来源：数据社
- EOF -
看完本文有收获？请转发分享给更多人
关注「大数据与机器学习文摘」，成为Top 1%
点赞和在看就是最大的支持❤️