• 数仓架构演进


    数仓架构演进


    1、介绍

    数仓架构演进,从一开始的离线数仓,到带实时数仓的Lambda架构,再到流批一体的Kappa架构,最终发展到多引擎混用。

     

    离线数仓架构


    2、Lambda

    lambda架构

    lambda架构基本介绍:

    • lambda架构最早是由storm的创始人,Nathan Marz进行提出并描述了我们目前所了解的lambda架构。

    • lamda架构先为主,已经适用在了绝大部分的公司里面了。绝大部分公司从刚开始发展大数据技术为主,到现在都是采用的lamda架构。

    • lamda架构说白了就是公司的离线和实时处理技术走两条线,离线的专门做离线数据处理(例如使用hive,impala,presto,sparkSQL等各种OLAP的技术框架),实时的就专门使用实时处理技术(例如storm,sparkStreaming,flink流处理程序等)。

     

    Lambda架构经历多年的发展,其优点是稳定,对于实时计算部分的计算成本可控,批量处理可以用晚上的时间来整体批量计算,这样把实时计算和离线计算高峰分开,这种架构支撑了数据行业的早期发展,但是它也有一些致命缺点,并在大数据3.0时代越来越不适应数据分析业务的需求。

    缺点如下:

    • 实时与批量计算结果不一致引起的数据口径问题:因为批量和实时计算走的是两个计算框架和计算程序,算出的结果往往不同,经常看到一个数字当天看是一个数据,第二天看昨天的数据反而发生了变化。

    • 批量计算在计算窗口内无法完成:在IOT时代,数据量级越来越大,经常发现夜间只有4、5个小时的时间窗口,已经无法完成白天20多个小时累计的数据,保证早上上班前准时出数据已成为每个大数据团队头疼的问题。

    • 数据源变化需要重新开发,开发周期长:每次数据源的格式变化、业务的逻辑变化都需要针对ETL和Streaming做开发修改,整体开发周期很长,业务反应不够迅速。

    • 服务器存储大:数据仓库的典型设计,会产生大量的中间结果表,造成数据急速膨胀,加大服务器存储压力。


    3、Kappa

    Kappa架构

     

    Kappa架构基本介绍:

    • 针对Lambda架构的需要维护两套程序等以上缺点,LinkedIn的Jay Kreps结合实际经验和个人体会提出了Kappa架构。

    • Kappa架构的核心思想是通过改进流计算系统来解决数据全量处理的问题,使得实时计算和批处理过程使用同一套代码。

    • 此外Kappa架构认为只有在有必要的时候才会对历史数据进行重复计算,而如果需要重复计算时,Kappa架构下可以启动很多个实例进行重复计算。

    Kappa架构的核心思想:

    • 用Kafka或者类似MQ队列系统收集各种各样的数据,需要几天的数据量就保存几天。

    • 当需要全量重新计算时,重新起一个流计算实例,从头开始进行处理,并输出到一个新的结果存储中。

    • 当新的实例做完后,停止老的流计算实例,并把老的一些结果删除。

    Kappa架构的优点在于统一了实时和离线代码,方便维护、统一了数据口径的问题。而Kappa的缺点也很明显

    • 流式处理对于历史数据的高吞吐量力不从心:所有的数据都通过流式计算,即便通过加大并发实例数亦很难适应IOT时代对数据查询响应的即时性要求。

    • 开发周期长:Kappa架构下由于采集的数据格式的不统一,每次都需要开发不同的Streaming程序,导致开发周期长。

    • 服务器成本浪费:Kappa架构的核心原理依赖于外部高性能存储redis、hbase服务。但是这2种系统组件,又并非设计来满足全量数据存储设计,对服务器成本严重浪费。

     


    4、Lambda、Kappa对比

    Lambda 存在的问题

    • 多套系统、多份数据、链路长且不可靠。简单来说,就是实时链路和离线链路是完全分开的,互相没有关系。那么相同的数据、逻辑都需要在两边各做一遍。逻辑对齐很困难。同时,链条中环节比较多,涉及到很多的同步任务。某个环节出问题的监控和定位都相对困难。

    • 数据业务化的能力很差,业务方必须要懂专门的实时计算知识才能开发相关的实时任务。这往往导致实时业务开发沦为实时平台团队的主要工作内容。

    • 响应业务变化的能力很差。一个新需求离线可能 1 天就开发完了,实时这边可能要一周甚至更长的时间。

    • 数据治理比较差。对于实时这边,数据治理一般都比较弱。因为存储、计算都是完全独立的,所以常规的数据治理手段在实时这边基本都不能用。这就导致实时链路的可靠性相对比较差。

     

     两者对比


    5、架构演进

    数仓发展趋势是数据实时化(Lambda架构),但是实时化引入实时数仓后有带来一些问题:

    • 比如实时数仓的数据治理、权限管理,是不是要单独做一套?

    • 如何统一实时数据和离线数据的计算口径?

    • 两套数据系统的资源浪费严重,成本提高?

    如果每个需求需要同时开发实时和离线任务,成本是较大的。

    此时又推动技术需要降低成本,即将实时、离线统一(Kappa架构)。


    参考

    http://www.woshipm.com/data-analysis/4151247.html

    https://www.infoq.cn/article/6aksl76pmzruyymrtulf

    https://cloud.tencent.com/developer/article/1738821

    https://developer.aliyun.com/article/769799

    https://www.cnblogs.com/tgzhu/p/13938159.html

    https://www.infoq.cn/article/uo4pfswlmzbvhq*y2tb9

    https://www.cnblogs.com/data-magnifier/p/14191809.html

  • 相关阅读:
    如遇临时表无法删除
    ORA-00054:resource busy and acquire with nowait specified解决方法
    查看用户建立详细原语句
    dbtool部署
    启动uiautomatorview 提示无法初始化主类
    运行虚拟机报错:CPU acceleration status: HAXM is not installed on this machine
    Appium-Python-Windows 环境搭建
    Vagrant安装Docker
    XPath
    Selenium之元素定位
  • 原文地址:https://www.cnblogs.com/GO-NO-1/p/14332234.html
Copyright © 2020-2023  润新知