2同行回答
1、大数据平台之所以基本都是部署在裸金属服务器上，最主要的原因是大数据平台通常都需要多台服务器共同完成一个计算任务。是一种将服务器能力叠加的技术。目前所有有效利用、调整资源的技术都是将服务器拆分的技术，这是设计理念上的根本差异。这也是为什么到现在为止大数据在容器化上始终踯躅不前的根本原因。但好在Kubernetes 技术其实是一种服务器拆分重组的概念，在重组这一部分能力上与大数据的需求仍然是一致的。因此大数据平台仍然有转向容器化的可能性。
2、在昨天分享的PPT中我介绍了一种趋势，就是将大数据平台的敏态与持久态拆分，Spark、Storm 等敏态技术，包括流式计算，数据的实时处理，实时分析，对新技术的耦合，比如大数据与AI/ML耦合等能力构建在敏态上层上。而持久态作为中层只负责宏观完整的数据大模型构架。衍生数据模型都存在于敏态层，而经过时间提炼的敏态层数据模型再通过整体DML执行框架沉淀到持久态层。最底层是传统存储持久化保障技术。这样有助于快速实现大数据平台面向敏态需求的能力，同时也能有效保护已有大数据资源的稳定和可执行度，提升整体支撑能力，提升整体资源利用率。
3、从目前全球技术趋势来看，也有一种猜测。大数据平台全面转向容器化的主流方案可能会在不久推出。这是因为随着Kubernetes Native Infrastructure （KNI）框架的整体成熟度不断提高。基于Ironic的裸金属调度整机容器有可能会成为大数据平台构建的基础框架。通过Stateful Set 接近整机容器的调度模式，调度裸金属的大数据节点部署。优势是，大数据节点更易于扩缩容，同时在计算资源闲余时间可以将计算资源调度用于其它计算目的。
4、对于监控来说，目前基于 Kuberenetes 的 Telemetry 技术正在成为热点，例如Redhat在新版本的OpenStack中就提供了基于 OpenShift 的全站 Telemetry 方案。可以支撑上万节点的统一监控。其中利用了Collectd+AMQ的采集技术，直接对接OpenShift上的监控体系。充分利用了OpenShift上预制整合的Prometheus+Grafana及其完整的的生态优势，快速建立高效率监控分析方案，并可以对此方案做自由扩展，实现快速插入定制化分析逻辑的目的。
收起大数据时代监控系统未来面临哪些挑战呢？从整个演进的过程来看，架构是随着业务不断的发展而发展的，主要讲解了以下三个重点：
第一：要整合大数据各个组件的通用监控告警系统。整个大数据平台的架构，肯定是从简单到复杂，随着业务的发展，旧的组件不能满足需求，然后引入新的组件，会有越来越多的组件加入到架构中。监控系统也需要覆盖到这些组件。怎么样做一套通用监控系统，而不用每个都去定制，每个都去写复杂的代码，这是面需要花时间关注的问题。
第二：整个监控系统和内部告警系统给对接，但是还有很多各种各样的系统。其中非常有特点调度系统，要怎么像对接监控系统一样，把调度系统对接起来，完成资源更好的利用，是后面需要研究的课题。
第三：有监控，有告警，能非常及时的发现问题。但发现问题没用，还要解决问题。现在都是采用人工去做的方式，那怎么样通过程序的方式，在监控系统里面自动触发恢复的操作，让问题响应时间从人工干涉的几分钟，甚至几个小时，变成程序自动恢复的几秒，甚至几毫秒？甚至更进一步，更方便好用及强大的监控系统，其实能发现很多之前传统的告警或人工没办法发现问题，可以在问题发生之前就发出预警。
根据监控对象的不同，监控系统可以分为系统监控、应用监控和业务监控。“实时交易监控系统”属于业务监控，主要用于监控客户的购买行为及订单情况，一般用于支持公司的日常运营决策和重大营销活动，如“双11”、“双12”及“双旦”等，对数据的实时性要求较高。
“实时交易监控系统”对数据的一般处理流程：实时捕获数据库中交易数据的变更、实时计算订单各维度的指标、再实时推送指标到浏览器大屏。通过采集、计算、展示三个阶段的实时性来保证整个监控系统的时效性，延迟可控制在秒级或亚秒级以内
通过“实时交易监控系统”的开发，来讲解典型的大数据实时解决方案的过程及原理，包括数据采集（kafka+canal）、数据计算（spark streaming/storm/kafka stream）、数据存储(hbase)、数据应用及可视化（echarts）等。
监控系统概述
包含要素:
全方位的监控指标
异常告警通知:告警触发阈值、告警监控对象、告警通知接收人以及发送渠道
可视化图表分析
监控规则配置化
应用场景:
业务质量实时关注
业务异常提前发现
业务精细化运营/运维
实施流程:
指标采集->指标加工->指标存储->指标可视化
收起