大数据处理平台(实时/离线/机器学习计算)构建

背景

随着产品不断迭代,产品和运营同学需要更多的数据支撑,那么面对日益增多的数据,如何快速有效并且的计算数据非常重要;与此同时,AI技术的快速发展则给予了创造AI+产品功能的机会,那么作为计算密集型的任务在面对大量用户群体时如何解决处理也是新的问题。

在这个背景下,我们需要搭建自己的大数据处理平台来解决问题。

如果谈及这类问题处理的核心思想,那就是算法中的经典处理法则:分而治之。其实我们之前的业务服务开发时已经采用了这类的解决办法,比如我们的图像转换、视频转换处理以及我们垂直拆分用户群体分配到不同的服务实例上。没错,这个模型已经在我们的技术体系中有对应解决方案了,那么既然大数据处理平台是分而治之我们业务服务也是分而治之,为什么不采用统一的技术体系来实现呢?

问题的关键是在于大数据的大,到底是有多大?前面我们分发的业务任务都相对较小,基本在几s内可以完成,如果按照这个任务的复杂程度来说,用大数据处理平台来处理有点杀鸡宰牛刀的感觉,资源调度的时间费用都基本不止几s了。而如果想统计我们一天所有用户的活跃行为的话,假设几百GB/几TB日志这样的任务,就算分发到一个worker,那么估计算完处理完可能就86400s过去了,第二天新的任务就又来了,这种情况下我们的业务服务层面的任务就无法满足了。机智的你可能会想到如果把这个任务拆解拆分的更细点,比如按照24h每小时或者每10min拆分任务,那么就会获得超过144倍的加速。这样想确实是接下来谈及的大数据处理框架/系统的核心法则,但是我们再来考虑如果我们自己要实现的话,是不是要实现资源调度、任务拆解、任务分发、任务结果合并、监控、高可用等等设计目标,而这些设计目标基本上都是大数据处理平台的设计目标,这样算不算造轮子呢?

所以我们搭建的这个只是为了那些必须采用更加细致拆分才能更好解决的任务的通用型计算平台,使用业界主流的且成熟的解决方案来加速实现。

需求确定

  1. 大数据处理平台需要实现通用型的资源调度层面,最好能够融入K8S集群,这样能更加优化资源利用率
  2. 在计算类型上面希望能够不绑定计算任务类型,实时、离线、机器学习/AI 等更多任务类型可以支持,这样能充分利用集群优势,降低成本
  3. 任务的设计和使用希望足够简单,尽量以脚本/SQL等产品运营技术支持友好的方式来运行
  4. 支持的连接器类型要多,方便导入导出数据,希望支持数据源为kafka等队列、各类SQL、NoSQL数据库,导出不只局限于集群中文件
  5. 平台运行稳定,可用性要求要高,方便扩展,兼容性强,符合未来技术发展趋势。

技术选型

业界发展趋势

https://www.infoq.cn/article/O2WfZkiWfU*LNP3IJXGz

2004年Google的三架马车 GFS 、BigTable 和 MapReduce公开,其中GFS、BigTable都是具体的系统实现名称,而MapReduce准确说是一种解决方案,将问题通过拆解/map完成后,然后再进行reduce来实现数据的合并计算

GFS、BigTable 和 MapReduce 对应业界开源实现是HDFS、HBase和 Hadoop,其中MapReduce只是Hadoop中的默认的一种计算引擎,适合离线计算

后续Spark诞生,因为内存的迭代式计算和更优越的任务分解机制,使得Spark成为更加优越的计算引擎,后来Spark Streaming使得Spark同样适合流式/实时计算

Flink的诞生,这是一种新的将离线和实时计算统一起来新的计算引擎

以上便是经过几年发展后的主流的大数据平台的组成体系

大数据组图

值得关注的新技术

大数据分析技术的新晋成员 Pestro,可以完全使用SQL来编写大数据处理任务,Facebook出品

统一的计算模型Beam,将流式计算和实时计算组合起来用一套模型编写,不过底层可以转换为Flink、Spark等系统驱动运行

挑战kafka的Pulsar和Pravega

几种架构模式

Lambda架构(λ)http://lambda-architecture.net/

  • 这种架构总共由三层系统组成:批处理层(Batch Layer),速度处理层(Speed Layer),以及用于响应查询的服务层(Serving Layer)。在 Lambda 架构中,每层都有自己所肩负的任务。批处理层存储管理主数据集(不可变的数据集)和预先批处理计算好的视图。批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的,能够修复任何错误,然后更新现有的数据视图。输出通常存储在只读数据库中,更新则完全取代现有的预先计算好的视图。速度处理层会实时处理新来的大数据。速度层通过提供最新数据的实时视图来最小化延迟。速度层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整,但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后,在速度层的数据就可以被替代掉了。本质上,速度层弥补了批处理层所导致的数据视图滞后。比如说,批处理层的每个任务都需要 1 个小时才能完成,而在这 1 个小时里,我们是无法获取批处理层中最新任务给出的数据视图的。而速度层因为能够实时处理数据给出结果,就弥补了这 1 个小时的滞后。所有在批处理层和速度层处理完的结果都输出存储在服务层中,服务层通过返回预先计算的数据视图或从速度层处理构建好数据视图来响应查询。

Kappa架构

http://milinda.pathirage.org/kappa-architecture.com/

不同于 Lambda 同时计算流计算和批计算并合并视图,Kappa 只会通过流计算一条的数据链路计算并产生视图。Kappa 同样采用了重新处理事件的原则,对于历史数据分析类的需求,Kappa 要求数据的长期存储能够以有序 log 流的方式重新流入流计算引擎,重新产生历史数据的视图

与 Lambda 架构不同的是,Kappa 架构去掉了批处理层这一体系架构, 而只保留了速度层。只需要在业务逻辑改变又或是代码更改的时候进行数据的重新处理

两者架构区别

  • Kappa 不是 Lambda 的替代架构,而是其简化版本,Kappa 放弃了对批处理的支持,更擅长业务本身为 append-only 数据写入场景的分析需求,例如各种时序数据场景,天然存在时间窗口的概念,流式计算直接满足其实时计算和历史补偿任务需求;
  • Lambda 直接支持批处理,因此更适合对历史数据有很多 ad hoc 查询的需求的场景,比如数据分析师需要按任意条件组合对历史数据进行探索性的分析,并且有一定的实时性需求,期望尽快得到分析结果,批处理可以更直接高效地满足这些需求。

架构设计

架构概览

按照已有和未来的需求,构想的完整版架构如下

架构说明

  • 数据采集阶段: 数据来源可以是线上业务数据库、可以使被聚合的日志、行为事件或者消息队列中的消息,通过数据同步或者导入系统来实现业务平面和数据平面的分离。一般来说,数据库的话我们一般通过从库来同步数据,避免对线上业务的影响。我们需要多种Connector来做这种同步导入的事情
  • 计算处理阶段: 我们按照一个统一的流式/批处理统一的模型来编写计算任务,然后交付给大数据计算框架来处理工作,在计算过程中,可能需要更多的详细数据,一般会去前面阶段同步的数据仓库(元数据库)来获取必要的数据。计算后的结果或者中间产物可以根据需求来存储到大数据存储平台(某些文件)、线上业务数据库(计算必要数据)、OLAP数据库(方便后续进一步查询)
  • 数据输出与展示阶段: 这个阶段主要用于产品、运营同学分析所用,可能需要根据前面产生的结果进一步汇总查询,也可能用于大数据监控、宽表输出。数据源来源于前面阶段同步或者计算的结果

组件选型

结合我们现在实际情况和需要,技术选型如下:(/后代表根据具体需求选型,||后代表的是曾经对比过的)

  • 资源调度:K8S / YARN
  • 任务调度: Airflow
  • 通用计算模型:Beam  / Dataflow
  • 查询引擎:Pestro || Hive
  • 大数据计算框架: Hadoop(这个没法少)、Flink || Spark Streaming、MapReduce、Spark Structue Streaming
  • OLAP数据库:Clickhouse / MongoDB / Elasticsearch / MySQL / Hbase
  • 元数据库:  同上,没有区别
  • 大数据文件存储:HDFS / Ceph   ||  COS
  • 数据导入/同步:  Kafka / Sqoop / Canal / DataX ……这个很多,根据具体需要同步的数据源来定

至于编程语言选择,目前主流的就是Java、Python。这两个都要学会掌握的吧,后面可根据需求扩充Scala、Julia、R等语言

实施路线

分成三个阶段:

  • 第一阶段:  先搭建整体平台,完成基本的计算任务和统计需求
  • 第二阶段:规范化、平台化、自主化大数据平台,使之更加适用于运营、产品同学需要
  • 第三阶段:资源高效利用,扩充大数据计算框架,加入诸如人工智能、图形、视频处理、搜索、推荐等更加依赖大规模计算需求任务的支撑

当然了,我们现在处于第一阶段, 预计1-2个月左右的时间。

解决方案

考虑的技术选型的复杂程度以及潜在的技术需要,倾向于自建。结合现有的Cloud Native趋势,会将整个数据平台融入到我们的K8S集群中。