2024Druid原理及产险实践

今天分享的内容分为两部分，第一部分是Druid原理，包括相关选型、原理、架构以及调优经验。第二部分是BDAS使用场景，是基于Druid做的监控日志报表系统。DruidMOLAPMMDBPreAGG，是一个如kafka插件、mysql插件、hdfs插件等。我们从去年五月份做技术选型，sparkSchemafree，之前不用最后没有选用spark是因为并发量上不去，因为我们业务并发量可能上千，使用spark很容易造成高温。ElasticSearch也是很热门的一个领域，大家常见的理解就是一个全文搜索的引擎，其实在分析方面也有很多新技术。其特性也是Schemafree，本身架构兼容这种数据格式，对比Druid的优点是会保存原始数据。同时拥有一个完整的技术栈（elk），非要做倒排索引，但是索引数据量和原始数据相差不大，最后舍弃。Druid亚秒级，数据可用毫秒级，基本满足需求；Lambda架构，扩张性、容错性高，我们选用Druid。SQLonHadoopMPP（大规模并行处理）CS（列式存储），特性，SQL支持良好，定制化硬件，天花板低（PB级别以下），非线性拓展，扩容需要停Druid，将其定位为实时可用一个上升的SaaS层服务，支持大型冷数据上的OLAP场景，实现对一个多维度高基数的亚秒缩。SegmentDruidtimestamp接下来讲一下Druid数据流转，流转图中有很多节点，每个节点都有自己的职责。中间有zookeeper，每一个节点都或多或少与其相连，zookeeperzookeeperBrokerREST些查询转发到Realtime和Historical节点。从这两个节点拿数据，然后将节点返回给HistoricalBroker在查询数据时现在本地找，然后在深度存储里查找，查找到后返回给Broker，没有与其他节点关联。在Zookeeper的管理下提供服务，并使用Zookeeper监视信号加载或删除互相不通信，同样利用zookeeper同步，将信息解耦开来。用、可复制，并且处于“最佳”配置。同时通过从MySQL读取数据段的元数据信息，来决定哪些数据段应该在集群中被加载，使用Zookeeper来确定哪个Historical节点存Zookeeper条目告诉Historical节点加载和删除新数据段。该节点可以是一个，多个的节点进行选举产生Leader，其余节点作为备份，一般两个也是满足需求的。实时节点Realtime是实时摄取数据，负责监听输入数据流并让其在内部的Druid系统立broker回给broker。如果Realtime和Historical节点同时返回同一种数据，Broker会认为身会存储数据，如果超过一段时间窗口会将数据传入深度存储，深度存储将数据提供给Historical节点。MySQLzookeeperDruidDeepStorageHDFSS3或本地磁盘，用来保存“冷数据”，有两个个数据来源，一个是批数据摄入,另一个来自实时节点；ZooKeeperMySQL局部过热，影响查询性能。没有绝对master丢弃掉，就会出现数据库性能问题。社区比较成熟的框架就是数据实时进来写到kafka，kafka数据两次消费，一次在存储节点上，一次在Hadoop上，如果数据不完整就再在Hadoop做一次embedding操作，补回数据。上面是一个推荐的架构，希望broker节点越多越好，Coordinator节点两个，overload对于broker消耗内存大户，建议20G-30G堆内存，历史节点除了内存还有硬盘消耗，希望用更多的内存去释放硬盘的IO，Coordinator消耗内存相对较小，只需要满足要求即可。查询时尽量做一些聚合优化，在摄入就做聚合，尽量少去groupbyHistorical和Realtime分离，Coordinator和Broker分离，在Broker上加Nginx做负，让Cognos（Oracle）处理清单报表，上线有十年历史。随着数据量的增长、以及分析处理的诉求增加，Cognos在cube过大时受限的DBASDruidhive分析，12Druid，实现多维分析功能。线上一共有数十个数据源，最大数据间<2s。接下来介绍下在HDFS下的使用场景，第一种是透视图概念，用户在某一定条件（不断衰减）查看数据大体概要，一般采用TopN查询，秒级响应。响应方式是在前端一个维度一个维度拖动，后端将上一次结果缓存，最后只查询几个维度。TopN查询第一次查询只查redis查询速度明显下降。我们引入单线程当初考虑了两种方式，第一种方式是依次将N个维度topNM*N*PtopN的时间，这样存在一个问题就是顺序不能保障。第二种方式采用递归的方式，并统一由线程池执行（是不是线程开线程？不是）AAB改为维度A+A1A+A2A+A1B+B1，这样可以充分利用Druid序，花费的时间可能多点，，大约需要N*M个topN的时间。都将其组装成一起，当超过4-5个维度就会效率很低。改进的方式也是采用多线程，前面b