zoukankan      html  css  js  c++  java
  • Druid: A Real-time Analytical Data Store

    Druid一种实时数仓,针对的场景和目的,如下比较明确

    Druid was originally designed to solve problems around ingesting and exploring large quantities of transactional events (log data).

    Our goal is to rapidly compute drill-downs and aggregates(roll-ups) over this data.

     

    这篇文章主要内容是描述Druid的架构,对实时数仓的设计是否有借鉴作用

     

    存储上,

    Mysql用来存储元数据配置

    Zookeeper用于分布式一致性,选主

    Deep Stroage,比如S3,用来放历史数据

    节点上,

    Real-time Nodes

    主要是用于消费和查询实时数据的,

    数据会先在内存中建立index,避免oom,到达一定行数阈值,会presist到磁盘,presist的时候会由行存变换到列存格式

    一个后台程序会不断的把磁盘上的indexes,进行merge,并且上传到deep storage

    下面举了个例子,

    何时会flush,presist?何时会merge,上传?

    这里还考虑了late data,但是一旦窗口结束,该时间段的数据完成merge和上传,实时节点会拒绝too late 数据

     

     Druid实时节点的scalability和availability,都是依赖kafka来保障的,降低druid本身的设计成本

    Historical Nodes

    这个节点的设计比较简单了,不涉及写入

    只是不变数据segments的加载和查询,为了加载效率,需要实现local cache

    Brokers

    routers,把查询分解,分别去查询real-time和historical节点

    还需要在返回前,merge不同节点的数据,这里merge不是怎么简单的,论文并没有写详细的过程,比如top10,怎么merge

    为了提升查询性能,

    会增加查询cache,这里只会对historical node的查询结果进行cache,不会cache real-time节点的返回,因为变的太快

    Coordinator Nodes

    中控节点

    管下面这些事,

    综合一下,本论文,主要描述冷热数据分离,读写分离的一套实时数仓的架构

  • 相关阅读:
    F2. Same Sum Blocks (Hard) 解析(思維、前綴和、貪心)
    E. Copying Data 解析(線段樹)
    B. Nauuo and Circle 解析(思維、DP)
    POJ3436-ACM Computer Factory(最大流)
    A.牛牛扔牌(双端队列)/B.疯狂过山车(最长上升子序列)/C.牛牛的棋盘(容斥原理)
    CodeForces 665E. Beautiful Subarrays(字典树)(贪心)(异或前缀和)
    CodeForces 455C.Civilization(并查集)(树的直径)
    CodeForces 1021B. Chemical table(并查集)
    CodeForces 961E. Tufurama(主席树)
    CodeForces 1024C. Array Product(模拟)(分类讨论)
  • 原文地址:https://www.cnblogs.com/fxjwind/p/12049469.html
Copyright © 2011-2022 走看看