Druid是一个分布式数据分析平台,也是一个时序数据库，也是一个集群系统，使用zookeeper做节点管理和事件监控，所以Druid一般搭配mysql使用
Druid是一个快速的列式分布式的支持实时分析的数据存储系统。它在处理PB级数据、毫秒级查询、数据实时处理方面，比传统的OLAP系统有了显著的性能改进。
注意：阿里巴巴也曾创建过一个开源项目叫作Druid（简称zxdyl），它是一个数据库连接池的项目。zxdyl和本文讨论的Druid没有任何关系，它们解决完全不同的问题。
Druid是一种能对历史和实时数据提供亚秒级别的查询的数据存储系统。Druid 支持低延时的数据摄取，灵活的数据探索分析，高性能的数据聚合，简便的水平扩展。适用于数据量大，可扩展能力要求高的分析型查询系统。其机制将热点和实时数据存储在实时节点（Realtime Node）内存中，将历史数据存储在历史节点（history node）的硬盘中，实时+伪实时的结构，保证查询基本都在毫秒级。高速摄入，快速查询正是满足了我们的需求，同时还有通用计算引擎团队的有力支持，在早期阿里选择了druid作为监控大盘的OLAP支持系统。
Druid使用过程中也暴露出一系列问题：
1）数据量摄入的瓶颈， 集团上云，流量的引入，随着数据量激增，数据写入出现了数次大故障
2）由于业务复杂多变，我们需要增加维度数据，Druid增加相对来说过程比较复杂
3）Druid的查询方式不友好，有一套自己的查询语言，对于SQL支持太差，浪费大量时间学习
4）不支持高并发，对于大促来说简直是灾难。有两年双十一，只能上线踢用户保证监控大盘可用。
（1）从超大数据的查询效率来看：
Druid > Kylin > Presto > Spark SQL
（2）从支持的数据源种类来讲：
Presto > Spark SQL > Kylin > Druid
随着暴露出的问题越来越多，我们也在寻找一款既能替代Druid解决当前问题，又能满足实时OLAP多维分析场景需求的产品。
也是在集团内其他部门沉淀的最佳实践中知道Hologres，并且了解到Hologres支持行存模式下的高并发点查和列存模式下的实时OLAP多维分析，觉得这一点很贴合我们网络监控系统的要求，于是就抱着试试的心态先去测试体验Hologres。通过全链路的测试和大量的场景数据验证，能满足我们场景需求，于是就决定上线Hologres至正式生产中。
改造后的新OLAP监控系统如下图所示，整体的数据流程大致如下：
- Kafka实时采集网络相关的监控指标数据，并写入Flink中轻度汇总加工
- Flink将初步加工完成的基础粒度的实时数据实时写入Hologres中，由Hologres提供统一的存储
- Hologres直接实时对接监控大屏，大屏实时展示多种监控指标的变化情况，不符合预期的数据实时报警，相应的业务人员立即排查问题并解决。
虽然Druid查询语言有所以差异但是在工业领域随着IOT及物联网数据爆发增长关系型数据库已经无法满足业务场景，目前选型有MongoDB和Druid
OceanBase是一个准内存数据库系统，独有的读写分离架构和面向SSD固态盘的高效存储引擎，为用户带来了超高性能的体验。
OceanBase定位为云数据库，通过在数据库内部实现多租户隔离，实现一个集群可以服 务多个租户，且租户之间完全隔离，不会相互影响。
OceanBase目前完全兼容MySQL，用户可以零成本从 MySQL 迁移到OceanBase。同时OceanBase在数据库内部实现了分区表和二级分区功能，可以完全取代MySQL常用的分库分表方案。
OceanBase本质上是一个基线加增量的存储引擎，跟关系数据库差别很大。 存储机制是LSM树（Log-Structured Merge Tree，日志结构合并树），这也是大多数NoSQL使用的存储机制。OceanBase采用了一种读写分离的架构，把数据分为基线数据和增量数据，其中增量数据放在内存里（MemTable），基线数据放在SSD盘（SSTable）。虽然不是刻意设计的，但OceanBase确实比传统数据库更适合像双十一、秒杀以及优惠券销售等短时间突发大流量的场景：
短时间内大量用户涌入，短时间内业务流量非常大，数据库系统压力非常大
一段时间（几秒钟、几分钟、或半个小时等）后业务流量迅速或明显回落
OceanBase更适合于在各类电商平台使用，不适用与工业领域，优势不明显。
当前主流数据框架
工业领域参考互联网领域主流架构，当前工业领域数据量随着物联网推进不断激增，原有技术架构已经无法满足需求，实时查询与离线查询都无法满足实际业务需求，参考互联网架构，可以对工业大数据进行优化，具体改造架构如下：
版权归原作者 张ruxiang 所有， 如有侵权，请联系我们删除。