实时大数据平台规划设计方案

实时大数据平台规划设计方案一、有关概念背景1.1从当代数仓架构角度看待实时数据平台当代数仓由传统数仓发展而来，对比传统数仓，当代数仓现有与其相似之处，也有诸多发展点。首先我们看一下传统数仓（图1）和当代数仓（图2）的模块架构：图1传统数仓图2当代数仓

传统数仓大家都很熟悉，这里不做过多介绍，普通来说，传统数仓只能支持T＋1天时效延迟的数据解决，数据解决过程以ETL为主，最后产出以报表为主。

当代数仓建立在传统数仓之上，同时增加了更多样化数据源的导入存储，更多样化数据解决方式和时效（支持T＋0天时效），更多样化数据使用方式和更多样化数据终端服务。

当代数仓是个很大的话题，在此我们以概念模块的方式来呈现其新的特性能力。首先我们先看一下图3中MelissaCoates的整顿总结：在图3MelissaCoates的总结中我们能够得出，当代数仓之因此“当代”，是由于它有多平台架构、数据虚拟化、数据的近实时分析、敏捷交付方式等等一系列特性。

在借鉴MelissaCoates有关当代数仓总结的基础上，加以自己的理解，我们也在此总结提取了当代数仓的几个重要能力，分别是：数据实时化（实时同时和流式解决能力）数据虚拟化（虚拟混算和统一服务能力）数据平民化（可视化和自助配备能力）数据协作化（多租户和分工协作能力）1)数据实时化（实时同时和流式解决能力）

数据实时化，是指数据从产生（更新至业务数据库或日志）到最后消费（数据报表、仪表板、分析、挖掘、数据应用等），支持毫秒级／秒级／分钟级延迟（严格来说，秒级／分钟级属于准实时，这里统一称为实时）。

这里涉及到如何将数据实时的从数据源中抽取出来；如何实时流转；为了提高时效性，减少端到端延迟，还需要有能力支持在流转过程中进行计算解决；如何实时落库；如何实时提供后续消费使用。实时同时是指多源到多目的的端到端同时，流式解决指在流上进行逻辑转换解决。

但是我们要懂得，不是全部数据解决计算都能够在流上进行，而我们的目的，是尽量的减少端到端数据延迟，这里就需要和其它数据流转解决方式配合进行，背面我们会进一步讨论。

2)数据虚拟化（虚拟混算和统一服务能力）数据虚拟化，是指对于顾客或顾客程序而言，面对的是统一的交互方式和查询语言，而无需关注数据实际所在的物理库和方言及交互方式（异构系统／异构查询语言）的一种技术。顾客的使用体验是面对一种单一数据库进行操作，但其实这是一种虚拟化的数据库，数据本身并不寄存于虚拟数据库中。

虚拟混算指的是虚拟化技术能够支持异构系统数据透明混算的能力，统一服务指对于顾客提供统一的服务接口和方式。图4数据虚拟化（图1-4均选自“DesigningaModernDataWarehouse+DataLake”-MelissaCoates,SolutionArchitect,BlueGranite）3)数据平民化（可视化和自助配备能力）普通顾客（无专业大数据技术背景的数据从业人员），能够通过可视化的顾客界面，自助的通过配备和SQL方式使用数据完毕自己的工作和需求，并无需关注底层技术层面问题（通过计算资源云化，数据虚拟化等技术）。以上是我们对数据平民化的解读。

文中提到技术层面如何支持数据平民化，并给出了几个例子：Datavirtualizationsoftware，Datafederationsoftware，Cloudstorage，Self-serviceBIapplications等。其中数据虚拟化和数据联邦本质上是类似技术方案，并且提到了自助BI这个概念。

4)数据协作化（多租户和分工协作能力）技术人员应当多理解业务，还是业务人员应当多理解技术？这始终是公司内争论不休的问题。而我们相信当代BI是一种能够深度协作的过程，技术人员和业务人员能够在同一种平台上，发挥各自所长，分工协作完毕日常BI活动。这就对平台的多租户能力和分工协作能力提出了较高规定，一种好的当代数据平台是能够支持更加好的数据协作化能力的。

我们但愿能够设计出一种当代实时数据平台，满足以上提到的实时化、虚拟化、平民化、协作化等能力，成为当代数仓的一种非常重要且必不可少的构成部分。

1.2从典型数据解决角度看待实时数据解决典型的数据解决，可分为OLTP,OLAP,Streaming,Adhoc,MachineLearning等。这里给出OLTP和OLAP的定义和对比：从某种角度来说，OLTP活动重要发生在业务交易库端，OLAP活动重要发生在数据分析库端。那么，数据是如何从OLTP库流转到OLAP库呢？如果这个数据流转时效性规定很高，传统的T＋1批量ETL方式就无法满足了。

我们将OLTP到OLAP的流转过程叫DataPipeline（数据解决管道），它是指数据的生产端到消费端之间的全部流转和解决环节，涉及了数据抽取、数据同时、流上解决、数据存储、数据查询等。这里可能会发生很复杂的数据解决转换（如重复语义多源异构数据源到统一StarSchema的转换，明细表到汇总表的转换，多实体表联合成宽表等）。如何支持实时性很高的Pipeline解决能力，就成了一种有挑战性的话题，我们将这个话题描述为“在线管道解决”(OLPP,OnlinePipelineProcessing)问题。

因此，本文所讨论的实时数据平台，但愿能够从数据解决角度解决OLPP问题，成为OLTP到OLAP实时流转缺失的课题的解决方案。下面，我们会探讨从架构层面，如何设计这样一种实时数据平台。

二、架构设计方案2.1定位和目的实时数据平台（Real-timeDataPlatform，下列简称RTDP），旨在提供数据端到端实时解决能力（毫秒级／秒级／分钟级延迟），能够对接多数据源进行实时数据抽取，可觉得多数据应用场景提供实时数据消费。作为当代数仓的一部分，RTDP能够支持实时化、虚拟化、平民化、协作化等能力，让实时数据应用开发门槛更低、迭代更快、质量更加好、运行更稳、运维更简、能力更强。

2.2整体设计架构概念模块架构，是实时数据解决Pipeline的概念层的分层架构和能力梳理，本身是含有通用性和可参考性的，更像是需求模块。图6给出了RTDP的整体概念模块架构，具体每个模块含义都可自解释，这里不再详述。图6RTDP整体概念模块架构

下面我们会根据上图做进一步设计讨论，给出从技术层面的高阶设计思路。图7整体设计思想

由图7能够看出，我们针对概念模块架构的四个层面进行了统一化抽象：统一数据采集平台统一流式解决平台统一计算服务平台统一数据可视化平台同时，也对存储层保持了开放的原则，意味着顾客能够选择不同的存储层以满足具体项目的需要，而又不破坏整体架构设计，顾客甚至能够在Pipeline中同时选择多个异构存储提供支持。下面分别对四个抽象层进行解读。

1)统一数据采集平台统一数据采集平台，既能够支持不同数据源的全量抽取，也能够支持增强抽取。其中对于业务数据库的增量抽取会选择读取数据库日志，以减少对业务库的读取压力。平台还能够对抽取的数据进行统一解决，然后以统一格式公布到数据总线上。这里我们选择一种自定义的原则化统一消息格式UMS（UnifiedMessageSchema）做为统一数据采集平台和统一流式解决平台之间的数据层面合同。

UMS自带Namespace信息和Schema信息，这是一种自定位自解释消息合同格式，这样做的好处是：整个架构无需依赖外部元数据管理平台；消息和物理媒介解耦（这里物理媒介指如Kafka的Topic,SparkStreaming的Stream等），因此能够通过物理媒介支持多消息流并行，和消息流的自由漂移。平台也支持多租户体系，和配备化简朴解决清洗能力。2)统一流式解决平台统一流式解决平台，会消费来自数据总线上的消息，能够支持UMS合同消息，也能够支持普通JSON格式消息。同时，平台还支持下列能力：支持可视化／配备化／SQL化方式减少流式逻辑开发／布署／管理门槛支持配备化方式幂等落入多个异构目的库以确保数据的最后一致性支持多租户体系，做到项目级的计算资源／表资源／顾客资源等隔离

3)统一计算服务平台统一计算服务平台，是一种数据虚拟化／数据联邦的实现。平台对内支持多异构数据源的下推计算和拉取混算，也支持对外的统一服务接口（JDBC／REST）和统一查询语言（SQL）。由于平台能够统一收口服务，因此能够基于平台打造统一元数据管理／数据质量管理／数据安全审计／数据安全方略等模块。平台也支持多租户体系。

4)统一数据可视化平台统一数据可视化平台，加上多租户和完善的顾客体系／权限体系，能够支持跨部门数据从业人员的分工协作能力，让顾客在可视化环境下，通过紧密合作的方式，更能发挥各自所长来完毕数据平台最后十公里的应用。

以上是基于整体模块架构之上，进行了统一抽象设计，并开放存储选项以提高灵活性和需求适配性。这样的RTDP平台设计，体现了当代数仓的实时化／虚拟化／平民化／协作化等能力，并且覆盖了端到端的OLPP数据流转链路。

2.3具体问题和考量思路下面我们会基于RTDP的整体架构设计，分别从不同维度讨论这个设计需要面对的问题考量和解决思路。

1)功效考量功效考量重要讨论这样一种问题：实时Pipeline能否解决全部ETL复杂逻辑？我们懂得，对于Storm／Flink这样的流式计算引擎，是按每条解决的；对于SparkStreaming流式计算引擎，按每个mini-batch解决；而对于离线跑批任务来说，是按每天数据进行解决的。因此解决范畴是数据的一种维度（范畴维度）。

另外，流式解决面对的是增量数据，如果数据源来自关系型数据库，那么增量数据往往指的是增量变更数据（增删改，revision）；相对的批量解决面对的则是快照数据（snapshot）。因此呈现形式是数据的另一种维度（变更维度）。

单条数据的变更维度，是能够投射收敛成单条快照的，因此变更维度能够收敛成范畴维度。因此流式解决和批量解决的本质区别在于，面对的数据范畴维度的不同，流式解决单位为“有限范畴”，批量解决单位为“全表范畴”。“全表范畴”数据是能够支持多个SQL算子的，而“有限范畴”数据只能支持部分SQL算子，具体支持状况以下：join：✔leftjoin：支持。“限制范畴”能够leftjoin外部lookup表（通过下推，类似hashjoin效果）✔rightjoin：不支持。每次从lookup拿回全部lookup表数据，这个计算是不可行的也是不合理的✔interjoin：支持。能够转化为leftjoin＋filter，能够支持✔outerjoin：不支持。存在rightjoin，因此不合理union：支持。能够应用在拉回局部范畴数据做窗口聚合操作。agg：不支持。能够借助union做局部窗口聚合，但无法支持全表聚合操作。filter：支持。没有shuffle，非常适合。map：支持。没有shuffle，非常适合。project：支持。没有shuffle，非常适合。Join往往需要shuffle操作，是最费计算资源和时间的操作，而流上join（leftjoin）将join操作转化成hashjoin的队列操作，将批量解决join的集中数据计算资源和时间平摊在数据流转过程中，因此在流上做leftjoin是最划算的计算方式。

复杂的ETL并不是单一算子，经常会是由多个算子组合而成，由上能够看出单纯的流式解决并不能较好的支持全部ETL复杂逻辑。那么如何在实时Pipeline中支持更多复杂的ETL算子，并且保持时效性？这就需要“有限范畴”和“全表范畴”解决的互相转换能力。

构想一下：流式解决平台能够支持流上适合的解决，然后实时落不同的异构库，计算服务平台能够定时批量混算多源异构库（时间设定能够是每隔几分钟或更短），并将每批计算成果发送到数据总线上继续流转，这样流式解决平台和计算服务平台就形成了计算闭环，各自做擅长的算子解决，数据在不同频率触发流转过程中进行多个算子转换，这样的架构模式理论上即可支持全部ETL复杂逻辑。图8数据解决架构演化

图8给出了数据解决架构的演化，和OLPP的一种架构模式。其中wormhole和moonbox分别是我们开源的流式解决平台和计算服务平台，背面会具体介绍。2)质量考量上面的图也引出了两个主流实时数据解决架构：Lambda架构和Kappa架构，具体两个架构的介绍网上有诸多资料，这里不再赘述。Lambda架构和Kappa架构各有其优劣势，但都支持数据的最后一致性，从某种程度上确保了数据质量，如何在Lambda架构和Kappa架构中取长补短，形成某种融合架构，这个话题会在新起文章中具体探讨。

固然数据质量也是个非常大的话题，只支持重跑和回灌并不能完全解决全部数据质量问题，只是从技术架构层面给出了补数据的工程方案。有关大数据数据质量问题，我们也会起一种新的话题讨论。

3)稳定考量这个话题涉及但不限于下列几点，这里简朴给出应对的思路：高可用HA整个实时Pipeline链路都应当选用高可用组件，确保理论上整体高可用；在数据