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

实时大数据平台规划设计方案实时大数据平台规划设计方案的具体问题和考量思路。一、相关概念背景从现代数仓架构角度对待实时数据平台〔1〕和现代数仓〔2〕的模块架构：1传统数仓2现代数仓传统数仓大家都很生疏，这里不做过多介绍，一般来说，传统数仓只能支持T＋1ETL化数据处理方式和时效〔＋0化数据终端效劳。3MelissaCoates3asMelissaCoates在此总结提取了现代数仓的几个重要力量，分别是：〔实时同步和流式处理力量〕〔虚拟混算和统一效劳力量〕数据平民化〔可视化和自助配置力量〕数据协作化〔多租户和分工协作力量〕数据实时化〔实时同步和流式处理力量〕数据实时化，是指数据从产生〔更至业务数据库或日志〕到最终消费〔数据报表、仪表板、分析、挖掘、数据应用等，支持毫秒级／秒级／分钟级延迟〔严格来说，秒级／分钟级属于准实时，这里统一称为实时。这里涉及到如何将数进展规律转换处理。后面我们会进一步争论。数据虚拟化〔虚拟混算和统一效劳力量〕〔异构系统／异构查询语言是一个虚拟化的数据库，数据本身并不存放于虚拟数据库中。对于用户供给统一的效劳接口和方式。4数据虚拟化〔1-4DesigningaModernDataWarehouseDataLake”-MelissaCoatesSolutionArchitectBlueGranite〕数据平民化〔可视化和自助配置力量〕一般用户〔无专业大数据技术背景的数据从业人员，可以通过可视化的用户界面，自助的通过配置和SQL方式使用数据完成自己的工作和需求，并无需关注底层技术层面问题〔通过计算资源云化，数据虚拟化等技术。以上是我们对数据平民化的解读。DataDemocratization文中提到技术层面如何支持数据平民化，并给出了几个例子：DatastorageBI数据协作化〔多租户和分工协作力量〕不休的问题。而我们信任现代BI是一个可以深度协作的过程，技术人员和业务人员可以在同一个平台上，发挥各自所长，分工协作完成日常BI活动。这就对以支持更好的数据协作化力量的。从典型数据处理角度对待实时数据处理OLAP〔图5选自文章“RelationalDatabasesarenotDesignedforMixedWorkloads”-MattAllen〕OLAP数据分析库端。那么，数据是如何从OLTP库流转到OLAP库呢？假设这个数T＋1ETL我们将P到P的流转过程叫ae〔数据处理管道，它是指据的生产端到消费端之间的全部流转和处理环节包括了数据抽取数据同步、流上处理、数据存储、数据查询等。这里可能会发生很简单的数据处理转换〔如据源到统一StarSchema的转换明细表到汇总表的转换，多实体表联合成宽表等。如何支持实时性很高的Pipeline处理力量，就成了一个有挑战性的话题，我们将这个话题描述为“在线管道处理” (OLPP,OnlinePipelineProcessing)问题。OLPP成为OLTP到OLAP实时流转缺失的课题的解决方案。下面，我们会探讨从架构层面，如何设计这样一个实时数据平台。二、架构设计方案定位和目标实时数据平台ea，旨在供给数据端到端实时处理力量〔毫秒级／秒级／分钟级延迟，可以对接多数据源进展实时数据抽取，可以为多数据应用场景供给实时数据消费。作为现代数仓的一局部，门槛更低、迭代更快、质量更好、运行更稳、运维更简、力量更强。整体设计架构概念模块架构，是实时数据处理Pipeline的概念层的分层架构和力量梳理，本身是具备通用性和可参考性的，更像是需求模块。图6给出了RTDP的整体概念模块架构，具体每个模块含义都可自解释，这里不再详述。下面我们会依据上图做进一步设计争论，给出从技术层面的高阶设计思路。7整体设计思想7统一数据采集平台统一流式处理平台统一计算效劳平台具体工程的需要，而又不破坏整体架构设计，用户甚至可以在Pipeline中同时选择多个异构存储供给支持。下面分别对四个抽象层进展解读。统一数据采集平台UMS〔UnifiedMessageSchema〕做为统一数据采集平台和统一流式处理平台之间的数据层面协议。UMSNamespaceSchema格式，这样做的好处是：整个架构无需依靠外部元数据治理平台；Topic,SparkStreamingm平台也支持多租户体系，和配置化简洁处理清洗力量。统一流式处理平台UMSJSONSQL支持配置化方式幂等落入多个异构目标库以确保数据的最终全都性支持多租户体系，做到工程级的计算资源／表资源／用户资源等隔离统一计算效劳平台统一查询语言〔L。由于平台可以统一收口效劳，因此可以基于平台打造统持多租户体系。统一数据可视化平台更能发挥各自所长来完成数据平台最终十公里的应用。OLPP具体问题和考量思路的问题考量和解决思路。功能考量PipelineETL我们知道，对于Storm／Flink这样的流式计算引擎，是按每条处理的；对于mini-batch〔范围维度。据往往指的是增量变更数据〔n；相对的批量处理面对的则是快照数据t。因此呈现形式是数据的另一个维度〔变更维度。SQLSQL具体支持状况如下：join：leftjoinleftjoinlookup〔通过下推，类hashjoin〕lookuplookup不行行的也是不合理的interjoinleftjoin＋filter，可以支持outerjoinrightjoin，因此不合理union：支持。可以应用在拉回局部范围数据做窗口聚合操作。aggunionfiltershuffle，格外适合。map：shuffle，格外适合。projectshuffle，格外适合。Joinshufflejoin〔leftjoin算资源和时间平摊在数据流转过程中，因此在流上做leftjoin是最划算的计算方式。简单的ETL并不是单一算子，常常会是由多个算子组合而成，由上可以看出单纯的流式处理并不能很好的支持全部ETL简单规律。那么如何在实时Pipeline中支持更多简单的ETL算子，并且保持时效性？这就需要“有限范围”和“全表范围”处理的相互转换力量。设想一下：流式处理平台可以支持流上适合的处理，然后实时落不同的异构库，计算效劳平台可以定时批量混算多源异构库〔时间设定可以是每隔几分钟或更短，并将每批计算结果发送到数据总线上连续流转，这样流式处理平台和计算ETL8数据处理架构演化图8给出了数据处理架构的演化，和OLPP的一种架构模式。其中wormhole和moonbox分别是我们开源的流式处理平台和计算效劳平台，后面会具体介绍。质量考量上面的图也引出了两个主流实时数据处理架构：LambdaKappa具体两个架构的介绍网上有很多资料，这里不再赘述。Lambda架构和KappaLambdaKappa会在起文章中具体探讨。问题，我们也会起一个的话题争论。稳定考量这个话题涉及但不限于以下几点，这里简洁给出应对的思路：HA整个实时Pipeline链路都应中选取高可用组件，确保理论上整体高可用；在数据关键链路上支持数据备份和重演机制；在业务关键链路上支持双跑融合机制SLA在确保集群和实时Pipeline高可用的前提下，支持动态扩容和数据处理流程自动漂移弹性反脆弱基于规章和算法的资源弹性伸缩支持大事触发动作引擎的失效处理监控预警集群设施层面，物理管道层面，数据规律层面的多方面监控预警力量自动运维能够捕获并存档缺失数据和处理特别，并具备定期自动重试机制修复问题数据上游元数据变更抗性✔上游业务库要求兼容性元数据变更Pipeline本钱考量这个话题涉及但不限于以下几点，这里简洁给出应对的思路：人力本钱通过支持数据应用平民化降低人才人力本钱资源本钱通过支持动态资源利用降低静态资源占用造成的资源铺张运维本钱通过支持自动运