《实时大数据平台规划设计方案》.docx

《《实时大数据平台规划设计方案》.docx》由会员分享，可在线阅读，更多相关《《实时大数据平台规划设计方案》.docx（17页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、实时大数据平台规划设计方案实时大数据平台规划设计方案本文我们探讨了实时数据平台 RTDP 的相关概念背景和架构设计方案。在架构设计方案中，我们尤其着重讲了 RTDP 的定位和目标，整体设计架构，以及涉及到的具体问题和考量思路。一、相关概念背景1.1 从现代数仓架构角度对待实时数据平台现代数仓由传统数仓进展而来，比照传统数仓，现代数仓既有与其一样之处，也有诸多进展点。首先我们看一下传统数仓图 1和现代数仓图 2的模块架构：图 1 传统数仓图 2 现代数仓传统数仓大家都很生疏，这里不做过多介绍，一般来说，传统数仓只能支持T 1 天时效延迟的数据处理，数据处理过程以 ETL 为主，最终产出以报表为主

2、。现代数仓建立在传统数仓之上，同时增加了更多样化数据源的导入存储，更多样化数据处理方式和时效支持 T0 天时效，更多样化数据使用方式和更多样化数据终端效劳。现代数仓是个很大的话题，在此我们以概念模块的方式来呈现其的特性力量。首先我们先看一以下图 3 中 Melissa Coates 的整理总结：在图 3Melissa Coates 的总结中我们可以得出，现代数仓之所以“现代”，是由于它有多平台架构、数据虚拟化、数据的近实时分析、灵敏交付方式等等一系列特性。在借鉴 Melissa Coates 关于现代数仓总结的根底上，加以自己的理解，我们也在此总结提取了现代数仓的几个重要力量，分别是：数据实时

3、化实时同步和流式处理力量 数据虚拟化虚拟混算和统一效劳力量 数据平民化可视化和自助配置力量 数据协作化多租户和分工协作力量1) 数据实时化实时同步和流式处理力量数据实时化，是指数据从产生更至业务数据库或日志到最终消费数据报表、仪表板、分析、挖掘、数据应用等，支持毫秒级秒级分钟级延迟严格来说，秒级分钟级属于准实时，这里统一称为实时。这里涉及到如何将数据实时的从数据源中抽取出来；如何实时流转；为了提高时效性，降低端到端延迟，还需要有力量支持在流转过程中进展计算处理；如何实时落库；如何实时供给后续消费使用。实时同步是指多源到多目标的端到端同步，流式处理指在流上进展规律转换处理。但是我们要知道，不是全

4、部数据处理计算都可以在流上进展，而我们的目的，是尽可能的降低端到端数据延迟，这里就需要和其他数据流转处理方式协作进展， 后面我们会进一步争论。2) 数据虚拟化虚拟混算和统一效劳力量数据虚拟化，是指对于用户或用户程序而言，面对的是统一的交互方式和查询语言，而无需关注数据实际所在的物理库和方言及交互方式异构系统异构查询语言的一种技术。用户的使用体验是面对一个单一数据库进展操作，但其实这是一个虚拟化的数据库，数据本身并不存放于虚拟数据库中。虚拟混算指的是虚拟化技术可以支持异构系统数据透亮混算的力量，统一效劳指对于用户供给统一的效劳接口和方式。图 4 数据虚拟化图 1-4 均选自“Designing

5、a Modern Data Warehouse + Data Lake ” - Melissa Coates, Solution Architect, BlueGranite3) 数据平民化可视化和自助配置力量一般用户无专业大数据技术背景的数据从业人员，可以通过可视化的用户界面，自助的通过配置和 SQL 方式使用数据完成自己的工作和需求，并无需关注底层技术层面问题通过计算资源云化，数据虚拟化等技术。以上是我们对数据平民化的解读。对于 Data Democratization 的解读，还可以参见以下链接：文中提到技术层面如何支持数据平民化， 并给出了几个例子： Data virtualizati

6、on software ， Data federation software ， Cloud storage ， Self-service BI applications 等。其中数据虚拟化和数据联邦本质上是类似技术方案，并且提到了自助 BI 这个概念。4) 数据协作化多租户和分工协作力量技术人员应当多了解业务，还是业务人员应当多了解技术？这始终是企业内争论不休的问题。而我们信任现代 BI 是一个可以深度协作的过程，技术人员和业务人员可以在同一个平台上，发挥各自所长，分工协作完成日常 BI 活动。这就对平台的多租户力量和分工协作力量提出了较高要求，一个好的现代数据平台是可以支持更好的数据协作化

7、力量的。我们期望可以设计出一个现代实时数据平台，满足以上提到的实时化、虚拟化、平民化、协作化等力量，成为现代数仓的一个格外重要且必不行少的组成局部。1.2 从典型数据处理角度对待实时数据处理典型的数据处理，可分为 OLTP, OLAP, Streaming, Adhoc, Machine Learning 等。这里给出 OLTP 和 OLAP 的定义和比照：图 5 选自文章“ Relational Databases are not Designed for MixedWorkloads”-Matt Allen从某种角度来说，OLTP 活动主要发生在业务交易库端，OLAP 活动主要发生在数据分

8、析库端。那么，数据是如何从 OLTP 库流转到 OLAP 库呢？假设这个数据流转时效性要求很高，传统的 T1 批量 ETL 方式就无法满足了。我们将 OLTP 到 OLAP 的流转过程叫 Data Pipeline数据处理管道，它是指数据的生产端到消费端之间的全部流转和处理环节，包括了数据抽取、数据同步、流上处理、数据存储、数据查询等。这里可能会发生很简单的数据处理转换如重复语义多源异构数据源到统一 Star Schema 的转换，明细表到汇总表的转换， 多实体表联合成宽表等。如何支持实时性很高的Pipeline 处理力量，就成了一个有挑战性的话题，我们将这个话题描述为“在线管道处理”(OLP

9、P, Online Pipeline Processing)问题。因此，本文所争论的实时数据平台，期望可以从数据处理角度解决 OLPP 问题， 成为 OLTP 到 OLAP 实时流转缺失的课题的解决方案。下面，我们会探讨从架构层面，如何设计这样一个实时数据平台。二、架构设计方案2.1 定位和目标实时数据平台Real-time Data Platform，以下简称 RTDP，旨在供给数据端到端实时处理力量毫秒级秒级分钟级延迟，可以对接多数据源进展实时数据抽取，可以为多数据应用场景供给实时数据消费。作为现代数仓的一局部，RTDP 可以支持实时化、虚拟化、平民化、协作化等力量，让实时数据应用开发门槛

10、更低、迭代更快、质量更好、运行更稳、运维更简、力量更强。2.2 整体设计架构概念模块架构，是实时数据处理 Pipeline 的概念层的分层架构和力量梳理，本身是具备通用性和可参考性的，更像是需求模块。图 6 给出了 RTDP 的整体概念模块架构，具体每个模块含义都可自解释，这里不再详述。图 6 RTDP 整体概念模块架构下面我们会依据上图做进一步设计争论，给出从技术层面的高阶设计思路。图 7 整体设计思想由图 7 可以看出，我们针对概念模块架构的四个层面进展了统一化抽象： 统一数据采集平台统一流式处理平台 统一计算效劳平台 统一数据可视化平台同时，也对存储层保持了开放的原则，意味着用户可以选择

11、不同的存储层以满足具体工程的需要，而又不破坏整体架构设计，用户甚至可以在 Pipeline 中同时选择多个异构存储供给支持。下面分别对四个抽象层进展解读。1) 统一数据采集平台统一数据采集平台，既可以支持不同数据源的全量抽取，也可以支持增加抽取。其中对于业务数据库的增量抽取会选择读取数据库日志，以削减对业务库的读取压力。平台还可以对抽取的数据进展统一处理，然后以统一格式公布到数据总线上。这里我们选择一种自定义的标准化统一消息格式 UMSUnified Message Schema做为统一数据采集平台和统一流式处理平台之间的数据层面协议。UMS 自带 Namespace 信息和 Schema 信

12、息，这是一种自定位自解释消息协议格式，这样做的好处是：整个架构无需依靠外部元数据治理平台；消息和物理媒介解耦这里物理媒介指如 Kafka 的 Topic, Spark Streaming 的Stream 等，因此可以通过物理媒介支持多消息流并行，和消息流的自由漂移。平台也支持多租户体系，和配置化简洁处理清洗力量。2) 统一流式处理平台统一流式处理平台，会消费来自数据总线上的消息，可以支持 UMS 协议消息， 也可以支持一般 JSON 格式消息。同时，平台还支持以下力量：支持可视化配置化SQL 化方式降低流式规律开发部署治理门槛支持配置化方式幂等落入多个异构目标库以确保数据的最终全都性支持多租户

13、体系，做到工程级的计算资源表资源用户资源等隔离3) 统一计算效劳平台统一计算效劳平台，是一种数据虚拟化数据联邦的实现。平台对内支持多异构数据源的下推计算和拉取混算，也支持对外的统一效劳接口JDBCREST和统一查询语言SQL。由于平台可以统一收口效劳，因此可以基于平台打造统一元数据治理数据质量治理数据安全审计数据安全策略等模块。平台也支持多租户体系。4) 统一数据可视化平台统一数据可视化平台，加上多租户和完善的用户体系权限体系，可以支持跨部门数据从业人员的分工协作力量，让用户在可视化环境下，通过严密合作的方式， 更能发挥各自所长来完成数据平台最终十公里的应用。以上是基于整体模块架构之上，进展了

14、统一抽象设计，并开放存储选项以提高敏捷性和需求适配性。这样的 RTDP 平台设计，表达了现代数仓的实时化虚拟化平民化协作化等力量，并且掩盖了端到端的 OLPP 数据流转链路。2.3 具体问题和考量思路下面我们会基于 RTDP 的整体架构设计，分别从不同维度争论这个设计需要面对的问题考量和解决思路。1) 功能考量功能考量主要争论这样一个问题：实时 Pipeline 能否处理全部 ETL 简单规律？我们知道，对于 StormFlink 这样的流式计算引擎，是按每条处理的；对于Spark Streaming 流式计算引擎，按每个 mini-batch 处理；而对于离线跑批任务来说，是按每天数据进展处

15、理的。因此处理范围是数据的一个维度范围维度。另外，流式处理面对的是增量数据，假设数据源来自关系型数据库，那么增量数据往往指的是增量变更数据增删改， revision；相对的批量处理面对的则是快照数据snapshot。因此呈现形式是数据的另一个维度变更维度。单条数据的变更维度，是可以投射收敛成单条快照的，因此变更维度可以收敛成范围维度。所以流式处理和批量处理的本质区分在于，面对的数据范围维度的不同，流式处理单位为“有限范围”，批量处理单位为“全表范围”。“全表范围”数据是可以支持各种 SQL 算子的，而“有限范围”数据只能支持局部 SQL 算子， 具体支持状况如下：join： left join

16、：支持。“限制范围”可以 left join 外部 lookup 表通过下推，类似 hashjoin 效果 right join ：不支持。每次从 lookup 拿回全部 lookup 表数据，这个计算是不行行的也是不合理的 inter join：支持。可以转化为 left join filter，可以支持 outer join：不支持。存在 right join，因此不合理union：支持。可以应用在拉回局部范围数据做窗口聚合操作。 agg：不支持。可以借助 union 做局部窗口聚合，但无法支持全表聚合操作。filter：支持。没有 shuffle，格外适合。map：支持。没有 shuff

17、le，格外适合。project：支持。没有 shuffle，格外适合。Join 往往需要 shuffle 操作，是最费计算资源和时间的操作，而流上 joinleft join将 join 操作转化成 hashjoin 的队列操作，将批量处理 join 的集中数据计算资源和时间平摊在数据流转过程中，因此在流上做 left join 是最划算的计算方式。简单的 ETL 并不是单一算子，常常会是由多个算子组合而成，由上可以看出单纯的流式处理并不能很好的支持全部 ETL 简单规律。那么如何在实时 Pipeline 中支持更多简单的 ETL 算子，并且保持时效性？这就需要“有限范围”和“全表范围”处理的

18、相互转换力量。设想一下：流式处理平台可以支持流上适合的处理，然后实时落不同的异构库， 计算效劳平台可以定时批量混算多源异构库时间设定可以是每隔几分钟或更 短，并将每批计算结果发送到数据总线上连续流转，这样流式处理平台和计算效劳平台就形成了计算闭环，各自做擅长的算子处理，数据在不同频率触发流转过程中进展各种算子转换，这样的架构模式理论上即可支持全部 ETL 简单规律。图 8 数据处理架构演化图 8 给出了数据处理架构的演化，和 OLPP 的一种架构模式。其中 wormhole 和 moonbox 分别是我们开源的流式处理平台和计算效劳平台，后面会具体介绍。2) 质量考量上面的图也引出了两个主流实

19、时数据处理架构：Lambda 架构和 Kappa 架构， 具体两个架构的介绍网上有很多资料，这里不再赘述。Lambda 架构和 Kappa 架构各有其优劣势，但都支持数据的最终全都性，从某种程度上确保了数据质量， 如何在 Lambda 架构和 Kappa 架构中取长补短，形成某种融合架构，这个话题会在起文章中具体探讨。固然数据质量也是个格外大的话题，只支持重跑和回灌并不能完全解决全部数据质量问题，只是从技术架构层面给出了补数据的工程方案。关于大数据数据质量问题，我们也会起一个的话题争论。3) 稳定考量这个话题涉及但不限于以下几点，这里简洁给出应对的思路：高可用 HA整个实时 Pipeline

20、链路都应中选取高可用组件，确保理论上整体高可用；在数据关键链路上支持数据备份和重演机制；在业务关键链路上支持双跑融合机制SLA 保障在确保集群和实时 Pipeline 高可用的前提下，支持动态扩容和数据处理流程自动漂移弹性反脆弱 基于规章和算法的资源弹性伸缩 支持大事触发动作引擎的失效处理监控预警集群设施层面，物理管道层面，数据规律层面的多方面监控预警力量自动运维能够捕获并存档缺失数据和处理特别，并具备定期自动重试机制修复问题数据上游元数据变更抗性上游业务库要求兼容性元数据变更 实时 Pipeline 处理显式字段4) 本钱考量这个话题涉及但不限于以下几点，这里简洁给出应对的思路：人力本钱通过

21、支持数据应用平民化降低人才人力本钱资源本钱通过支持动态资源利用降低静态资源占用造成的资源铺张运维本钱通过支持自动运维高可用弹性反脆弱等机制降低运维本钱试错本钱通过支持灵敏开发快速迭代降低试错本钱5) 灵敏考量灵敏大数据是一整套理论体系和方法学，在前文已有所描述，从数据使用角度来看，灵敏考量意味着：配置化，SQL 化，平民化。6) 治理考量数据治理也是一个格外大的话题，这里我们会重点关注两个方面：元数据治理和数据安全治理。假设在现代数仓多数据存储选型的环境下统一治理元数据和数据安全，是一个格外有挑战的话题，我们会在实时 Pipeline 上各个环节平台分别考虑这两个方面问题并给出内置支持，同时也可以支持对接外部统一的元数据治理平台和统一数据安全策略。本文我们探讨了实时数据平台 RTDP 的相关概念背景和架构设计方案。在架构设计方案中，我们尤其着重讲了 RTDP 的定位和目标，整体设计架构，以及涉及到的具体问题和考量思路。有些话题很大，可以后续单独形成文章进展专题争论， 但整体上，我们给出了一整套 RTDP 的设计思路和规划。在下篇技术篇中，我们会将 RTDP 架构设计具体化落地化，给出推举的技术选型和我们的开源平台方案，并会结合不同场景需求探讨 RTDP 的不同模式应用。