• 改良海量数据存储的若干的手段-转变数据垃圾为黄金


    教材篇

    直到翻看了后面章节,才注意到封面上面的标语,中文意思是“禁止倾倒数据垃圾,违者务必读此书!”
    大致祖师爷对杂乱无序的数据垃圾深恶痛绝,在这点上大凡上了点年头的数据工作者都是深有体会~
    在这里插入图片描述

    直到翻看了后面章节,才注意到封面上面的标语,中文意思是“禁止倾倒数据垃圾,违者务必读此书!”
    大致祖师爷对杂乱无序的数据垃圾深恶痛绝,在这点上大凡上了点年头的数据工作者都是深有体会~在这里插入图片描述

    单向数据湖问题

    一开始数据湖信息在设计时并没有考虑未来的访问和分析,机构会发现这样的数据湖仅仅是数据量大而已,大部分数据并不能真正支持他们的业务,企业花费大量成本却没有带来任何收益
    在这里插入图片描述

    数据湖的改良目标

    改造数据沼泽从单向流动为成良性流动,迭代数据资产从青铜变成黄金未目标。比较喜欢沿用Delta Lake官网的图
    在这里插入图片描述

    数据湖改良篇

    改良一:基础属性的丰富,让数据湖具备洞察能力

    为了方式数据无序倾倒进数据湖,第一步其实对数据进行基础成分的扩充。
    1、元数据(metadata)
    数据湖是可以容纳结构/半结构/非结构信息的,所以元数据可以是不同形式。典型的我们对元数据表现形式包含记录、属性、键值、索引等,但是如果其他类型结构,我们则需要描述他内容信息,这点非常关键。
    表结构元数据 记录、属性、键值、索引
    文档型的 作者、字数、标题、章节等
    图片、视频等 作者、标题、时长、内容描述

    2、整合图谱(integration mapping)
    不同应用程序,通常有不同的语言编写、因为在线系统相对隔离,数据比较独立的放到数据湖中来,形成一个个瓦罐,这个时候为了让数据湖中的数据合理,就需要有一份“整合图谱”
    3、语境(context)
    语境表达的其实是需要描述清楚数据所处的上下文环境约束,数据内容脱离了上下文的意义不明确的数据,在很多情况下,不约束语境其实会造成错误。比如用户的身份信息,可以有多个都会产生:
    在这里插入图片描述

    4、元过程
    数据被如何处理,数据何时产生、数据谁产生的、数据规模多大、日增多大、是账务及还是交易及、有无精准日切
    数据如何被入湖的、是否有进一步的加工转换。
    值得强调的是数据应当一开始入湖的时候就有这些信息、否则如果中途补上的话会丢失历史信息,数据缺少历史的连续性,很影响使用者判断

    在这里插入图片描述

    改良二:对数据进行划分、关注数据生产特征,进行不同语义处理

    数据的产生特性其实代表对数据生命周期管理可以不一样的,比如我们的流量日志型数据和业务交易类型可能就不一样,,虽然数据的产生方式多种多样,但是按照生产规律来说还是可以划分的,因为数据具有如通用的特征,所以对数据的加工方式也可以抽象。
    常规的划分
    模拟信号数据 (analog data)
    日志型、监控型、诊断数据等都属于这一类,大体上这类数据是巨大且反复的,这一类数据除了数据内容本身
    应用程序数据 (application data)
    应用类型的数据主要是数据库的数据,比较有规律的schema
    文本数据 (textture data)
    这类包含大部分半结构、非结构化的数据,文本、音频、视频等,这类特征是不会按照特定的格式存储、需要进一步使用
    另一个视角划分
    按照重复性和非重复进行划分

    改良三:根据不同数据生产类型,定义数据池生命周期

    在这里插入图片描述

    改良四:良好的数据传承,更高级别定义数据流动以及更加详细定义池文档

    在这里插入图片描述

  • 相关阅读:
    智慧农业大数据平台:农业中的“大智慧”
    locust性能测试工作概述
    面试官让手撕红黑树,我直接向他秀一手手撕map与set
    串口占用检测工具
    arm ldrb指令
    看完这篇 教你玩转渗透测试靶机vulnhub——FunBox3(Easy)
    springboot引入redisson分布式锁及原理
    MySQL 事务常见面试题总结 | JavaGuide 审核中
    JAVA-反射+注解
    java多线程中的Fork和Join
  • 原文地址:https://blog.csdn.net/zhuxuemin1991/article/details/127929566