跨区域、高可用性实践背景

数据处理平台提出的多维挑战

作为美国Comcast旗下领先的视频广告管理和投放平台，FreeWheel的数据来自于全球6大数据中心（美国东西海岸各两个、欧洲两个），每天产生10亿左右的广告投放展示日志，新增超过3TB的数据，并且有至少18个月的数据可以随时满足查询寻求。

在数据应用对实时性和可靠性要求逐渐增加的情况下，FreeWheel根据其自身数据特点和应用需求，采用了一套以Kafka、Hadoop和HBase为核心的Lambda处理架构。

其中，各个数据中心的广告服务器实时地将广告数据传输到本地Kafka集群。中心化的Kafka MirrorMaker将多数据中心的数据聚集到一个全局的Kafka集群。流式处理框架会从全局Kafka集群消费数据，处理之后一方面写回Kafka（为下游的各类实时应用服务）；一方面写入HBase，并由Hadoop离线作业将HBase的内容聚合转换成Parquet文件写入HDFS。构建于Presto之上的OLAP服务会同时查询HBase和HDFS，对外提供数据的实时或批量查询（整体架构见下图）。

FreeWheel部署的这一套数据处理系统，很好地实现了预期的设计目标。但过往几年里，随着数据量的不断增长和业务变化的需求，这种模式面临了如下挑战：

1．可扩展性：越来越多的数据产品接入到新的数据平台，对数据处理和查询服务的扩展性提出了严苛的要求。而在自建的数据中心，受限于规划和整体容量，很难根据需求灵活地扩展。同时，在“超级碗”这样大型赛事的直播带来流量瞬时波动的场景下，传统的数据中心也很难满足对容量的弹性需求。

2．高可用性：虽然像Hadoop这样的大数据基础设施本身可以保证一定程度的高可用性，但在遇到数据中心整体性故障时，依然会对服务造成影响。

3．开发和测试效率：大数据平台开发和测试中，基于真实环境的集成测试和性能测试可以覆盖单元测试和回归测试的盲区，这需要经常启停一些基础组件甚至整套端到端服务。但在自有数据中心里，受到资源限制，很难做到及时满足需求，因而也降低了开发和测试的效率。

理论上，上述挑战中的一部分可通过在另一个自建数据中心里再部署一套数据处理系统解决或缓解，但考虑到规划、扩容所需时长以及问题根治性等因素，在2016年底，FreeWheel决定与AWS合作，将数据平台和数据处理系统部署到云端。

选型过程并不复杂，FreeWheel主要从成熟程度、数据监管、可用区（AZ）数以及原生服务的数量与广度等方面考量，最终选择了AWS作为云服务商。

基于AWS原生服务的使用权衡

整体上，FreeWheel在AWS上也部署了一套Kafka MirrorMaker，同步所有数据中心的数据，再将数据处理平台基本原样搬到了AWS上。

但如何权衡是直接使用像Kinesis、DynamoDB这样的AWS原生服务，还是自己维护Kafka、HBase等基础设施？ FreeWheel也有一些思考。

张磊对此总结了两点。一是从平台需求出发。AWS许多原生服务在某种程度上的确能带来开发和维护成本的降低，但对于基础数据平台这类数据量极其庞大并且对稳定性要求很高的业务，AWS的原生服务能不能满足需求，能满足需求的情况下成本是不是可控，这些都会是最终影响选型的因素。二是需要考虑开发者自身对技术的把控。AWS的原生服务很多时候对使用者来说还是黑盒。当大家需要花大量时间去了解这些服务的内部运作原理，限制和故障处理时，不一定能降低时间和运维成本。

涉及到具体权衡与改造，姜冰也举例讲解了何时该选择自身维护：

以AWS原生服务Amazon EMR和Amazon Kinesis为例，映射到FreeWheel的数据处理系统中相应的是Hadoop Cluster和Kafka。基于FreeWheel以7*24小时流计算为主的业务类型，如果直接使用EMR及Kinesis，将面临如下问题：

· 原生服务开放程度较弱，因而开发者缺乏更多的机会维护和管理自身集群。例如从对外兼容性上看，Kafka下游接了多样的开源解决方案，与Spark、Flink等有天然集成，但Kinesis是闭源的托管服务，下游集成由AWS主导，日志记录的更新和变化将受制于AWS内部研发；

· EMR适合批处理的工作模式，在全天候不间断的运行状态下，基于AWS基础计算和存储资源自建的Hadoop集群能够提供更好的可用性，从而更好地应对流处理场景。

在上述场景下，FreeWheel并没有主动选择EMR或Kinesis原生服务，而是从成本、性能、开放程度、规模化和容错管理等维度与自身维护做了对比实践。但张磊也提到，在一般的使用场景下，对于AWS的原生服务，比如RDS、Athena等，FreeWheel会鼓励并尽可能地使用，这样才能更有效地满足高可用需求，并降低总体开发维护成本。

截至目前，经过测试和调整，FreeWheel已逐步把面向客户的的所有产品都迁移到AWS环境中，目前自有数据中心里只有极少数对内的服务在运行，而最终它们也都会迁移到AWS环境中。