盘点2019年晋升为Apache TLP的大数据相关项目

Apache Rya 是一个基于云的大数据三元组存储（subject-predicate-object）数据库，并提供毫秒级别响应查询时间。这个项目是由 The Laboratory for Telecommunication Sciences（美国的马里兰大学）开发，并于2015年09月进入提交给 Apache 孵化器，2019年09月24日 Apache 基金会正式宣布其成为 Apache 顶级项目。

Apache Rya 主要是用于存储 RDF 的数据，RDF 是 Resource Description Framework 的简写，即资源描述框架，其本质是一个数据模型（Data Model）。它提供了一个统一的标准，用于描述实体/资源。简单来说，就是表示事物的一种方法和手段。RDF 形式上表示为 SPO（subject-predicate-object）三元组，有时候也称为一条语句（statement），知识图谱中也称其为一条知识。

Apache Rya 是一个可伸缩的 RDF 数据管理系统，构建在 Apache Accumulo 之上。同时还实现了 MongoDB 后端。Rya 使用了新颖的存储方法、索引方案和查询处理技术，可以跨多个节点扩展到数十亿个三元组。Apache Rya 通过 SPARQL （一种用于RDF数据的传统查询机制）提供了对数据的快速、轻松的访问。

Apache SINGA：通用的分布式深度学习平台

Apache SINGA 是一个通用的分布式深度学习平台，面向训练大规模数据集上的大型深度学习模型。该项目最初于2014年在新加坡国立大学开发，并于2015年3月提交给 Apache 孵化器，2019年10月16日 Apache 基金会正式宣布其成为 Apache 顶级项目。

Apache SINGA 设计基于一种直观的编程模型，即深度学习中层（layer）的抽象。Apache SINGA 支持大部分深度学习模型，包括卷积神经网络（CNN）、受限波尔兹曼模型（RBM）和循环神经网络（RNN）等，为用户提供许多可直接使用的内建层。Apache SINGA 架构灵活，支持同步训练、异步训练和混合式训练。为了并行地训练深度学习模型，SINGA支持不同的神经网络划分机制，即批次维度划分（batch dimension partition），特征维度划分（feature dimension partition）和多维度混合划分（hybrid partition）。

作为一个分布式系统，Apache SINGA 的首要目标就是具有良好的可扩展性。换言之，Apache SINGA 希望在准确度一定的情况下，通过利用更多的计算资源（即计算机）减少模型的训练时间。

Apache SINGA 的另一个目标是易用性。对程序员来说，开发和训练深层的复杂结构的深度学习模型十分困难。分布式训练又进一步增加了程序员的负担，比如：数据和模型划分，网络通信等。因此，提供一个易用的编程模型是十分重要的，可以让程序员在实现自己的深度学习模型和算法时不必考虑底层的分布式平台。

Apache Hudi：大数据增量处理框架（孵化中）

Apache Hudi（Hoodie）是 Uber 为了解决大数据生态系统中需要插入更新及增量消费原语的摄取管道和 ETL 管道的低效问题，该项目在2016年开始开发，并于2017年开源，2019年1月进入 Apache 孵化器。

Hudi (Hadoop Upsert Delete and Incremental) 是一种分析和扫描优化的数据存储抽象，可在几分钟之内将变更应用于 HDFS 中的数据集中，并支持多个增量处理系统处理数据。通过自定义的 InputFormat 与当前 Hadoop 生态系统(包括 Apache Hive、Apache Parquet、Presto 和 Apache Spark)集成，使得该框架对最终用户来说是无缝的。

Hudi 的设计目标就是为了快速增量更新 HDFS 上的数据集，它提供了两种更新数据的方式：Copy On Write 和 Merge On Read。Copy On Write 模式就是我们更新数据的时候需要通过索引获取更新的数据所涉及的文件，然后把这些数据读出来和更新的数据进行合并，这种模式更新数据比较简单，但是当更新涉及到的数据比较大时，效率非常低；而 Merge On Read 就是将更新写到单独的新文件里面，然后我们可以选择同步或异步将更新的数据和原来的数据进行合并（可以称为 combination），因为更新的时候只写新的文件，所以这种模式更新的速度会比较快。

有了 Hudi 之后，我们可以实时采集 MySQL、HBase、Cassandra 里面的增量数据然后写到 Hudi 中，然后 Presto、Spark、Hive 可以很快地读取到这些增量更新的数据，如下：

Apache DolphinScheduler：分布式工作流任务调度系统（孵化中）

Apache DolphinScheduler 是一个分布式易扩展的可视化 DAG 工作流任务调度系统，致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。Apache DolphinScheduler 是由易观平台自主研发的大数据分布式调度系统，之前称为 Easy Scheduler，于2019年03月28日正式开源，2019年08月29日进入 Apache 孵化器。Apache DolphinScheduler 的主要目标如下：

以DAG图的方式将Task按照任务的依赖关系关联起来，可实时可视化监控任务的运行状态

支持丰富的任务类型：Shell、MR、Spark、SQL(mysql、postgresql、hive、sparksql),Python,Sub_Process、Procedure等

支持工作流定时调度、依赖调度、手动调度、手动暂停/停止/恢复，同时支持失败重试/告警、从指定节点恢复失败、Kill任务等操作

支持工作流优先级、任务优先级及任务的故障转移及任务超时告警/失败

支持工作流全局参数及节点自定义参数设置

支持资源文件的在线上传/下载，管理等，支持在线文件创建、编辑

支持任务日志在线查看及滚动、在线下载日志等

实现集群HA，通过Zookeeper实现Master集群和Worker集群去中心化

支持对Master/Worker cpu load，memory，cpu在线查看

支持工作流运行历史树形/甘特图展示、支持任务状态统计、流程状态统计

支持补数

支持多租户

支持国际化

还有更多等待伙伴们探索

MasterServer：MasterServer 采用分布式无中心设计理念，MasterServer 主要负责 DAG 任务切分、任务提交监控，并同时监听其它 MasterServer 和 WorkerServer 的健康状态。MasterServer 服务启动时向 Zookeeper 注册临时节点，通过监听 Zookeeper 临时节点变化来进行容错处理。

WorkerServer ：WorkerServer 也采用分布式无中心设计理念，WorkerServer 主要负责任务的执行和提供日志服务。WorkerServer服务启动时向 Zookeeper 注册临时节点，并维持心跳。

ZooKeeper ：系统中的 MasterServer 和 WorkerServer 节点都通过 ZooKeeper 来进行集群管理和容错。另外系统还基于ZooKeeper进行事件监听和分布式锁。

Task Queue ：提供任务队列的操作，目前队列也是基于 Zookeeper 来实现。由于队列中存的信息较少，不必担心队列里数据过多的情况，实际上压测过百万级数据存队列，对系统稳定性和性能没影响。

Alert：提供告警相关接口，接口主要包括告警两种类型的告警数据的存储、查询和通知功能。其中通知功能又有邮件通知和SNMP(暂未实现)两种。

API：API接口层，主要负责处理前端UI层的请求。该服务统一提供RESTful api向外部提供请求服务。
接口包括工作流的创建、定义、查询、修改、发布、下线、手工启动、停止、暂停、恢复、从该节点开始执行等等。

UI：系统的前端页面，提供系统的各种可视化操作界面。

可以看出，Apache DolphinScheduler 和前面介绍的 Apache Airflow 功能有点类似，两者之间的详细区别请参见 https://dolphinscheduler.apache.org/ 这里就不详细介绍了。

Apache TubeMQ：分布式消息中间件系统（孵化中）

TubeMQ 是腾讯在 2013 年自研的分布式消息中间件系统，专注服务大数据场景下海量数据的高性能存储和传输，经过近7年上万亿的海量数据沉淀，目前日均接入量超过25万亿条。较之于众多明星的开源MQ组件，TubeMQ 在海量实践（稳定性+性能）和低成本方面有着比较好的核心优势。该项目于 2019年11月03日正式进入 Apache 孵化器。

TubeMQ 系统架构思想源于Apache Kafka。在实现上，则完全采取自适应的方式，结合实战做了很多优化及研发工作，如分区管理、分配机制和全新节点通讯流程，自主开发高性能的底层RPC通讯模块等。这些实现使得TubeMQ在保证实时性和一致性的前提下，具有很好的健壮性及更高的吞吐能力。

TubeMQ 非常适用于高并发、海量数据并允许在异常情况下少量数据丢失的场景，如海量日志采集、指标统计、监控等。TubeMQ 不适用于那些对数据可靠性要求非常严格的场景。

与其他消息队列系统一样，TubeMQ 也是基于发布-订阅模式构建的。也就是生产者将消息发布到主题，而消费者订阅这些主题。消费者处理完消息后，将给生产者发送确认。TubeMQ 的总体架构如下：

Portal： 负责对外交互和运维操作的 Portal 部分，包括 API 和 Web 两块，API 对接集群之外的管理系统，Web 是在 API 基础上对日常运维功能做的页面封装；

Master： 负责集群控制的 Control 部分，该部分由1个或多个 Master 节点组成，Master HA 通过 Master 节点间心跳保活、实时热备切换完成，主 Master 负责管理整个集群的状态、资源调度、权限检查、元数据查询等；

Broker： 负责实际数据存储的 Store 部分，该部分由相互之间独立的 Broker 节点组成，每个 Broker 节点对本节点内的 Topic 集合进行管理，包括 Topic 的增、删、改、查，Topic 内的消息存储、消费、老化、分区扩容、数据消费的 offset 记录等，集群对外能力，包括 Topic 数目、吞吐量、容量等，通过水平扩展 Broker 节点来完成；

Client： 负责数据生产和消费的 Client 部分，该部分我们以 Lib 形式对外提供，大家用得最多的是消费端，相比之前，消费端现支持Push、Pull两种数据拉取模式，数据消费行为支持顺序和过滤消费两种。对于 Pull 消费模式，支持业务通过客户端重置精确 offset 以支持业务 extractly-once 消费，同时，消费端新推出跨集群切换免重启的 BidConsumer 客户端；

Zookeeper： 负责offset存储的zk部分，该部分功能已弱化到仅做 offset 的持久化存储，考虑到接下来的多节点副本功能该模块暂时保留。