在熵简数据智能解决方案中，其中离用户最近的一环，是利用数据中台对外提供的数据服务做数据分析。
在金融、消费、工业等不同领域的场景中，数据分析的维度、方式、需求各不相同，不过其核心都离不开一个实时 OLAP 引擎，向用户实时提供各种维度和度量的上卷、下钻、切片、切块等类型的分析结果。
本文以实时 OLAP 引擎的优秀代表 Druid 为研究对象，详细介绍 Druid 的架构思想和核心特性。在此基础上，我们介绍了熵简科技在数据智能分析场景下，针对私有化部署与实时响应优化的实践经验。
作者信息
本文出自熵简科技大数据团队，团队致力于构建高效率、低成本和低运维的大数据处理系统，为熵简科技应用层及中台层各项服务提供海量的算力支持，涵盖数据清洗、数据融合、数据核验、数据建模等多种处理能力。
1、实时OLAP引擎
在熵简数据智能解决方案中，其中离用户最近的一环，是利用数据中台对外提供的数据服务做数据分析。在金融、消费、工业等不同领域的场景中，数据分析的维度、方式、需求各不相同，不过其核心都离不开一个实时 OLAP 引擎，向用户实时提供各种维度和度量的上卷、下钻、切片、切块等类型的分析结果。OLAP 的全称是 On-Line Analytical Processing，它与 OLTP (On-Line Transaction Processing) 的核心区别在于OLAP更适合于读多写少、针对大数据量的分析场景。
在不考虑横向扩展且数据规模不大的情况下，使用传统的关系型数据库如 MySQL，对数据加了正确的索引后，是能部分满足小数据量下的分析需求的。但实际场景中随着公司业务增长迅速，数据量越来越大，RDS 在存储和算力上有明显瓶颈，传统的数据库解决方案针对实时 OLAP 这一场景就显得无能为力。
为了解决这一问题，出现了几类不同架构的 OLAP 解决方案，大致可以分为以 SparkSQL 为代表的基于 MR 架构的离线 OLAP 引擎，以 Druid 为代表的基于 MPP 架构的实时 OLAP 引擎，和以 Kylin 为代表的预计算引擎。几种常见的OLAP引擎对比如下：
相比而言，SparkSQL 基于可靠的分布式存储，通过 MapReduce 进行迭代计算来查询批量数据，更适合大型任务的运行，但在对任务响应时间和实时性有严格要求的需求方面并不擅长；Kylin 在执行查询之前需要预先建立 Cube，不太适合高度灵活的探索性数据分析；而 ElasticSeach 虽然也是基于 MPP 架构，但其建立的倒排索引更适合数据检索，对于需要数据聚合的亚秒级响应支持不佳。在接下来的内容里，我们将重点介绍 Apache Druid 的架构、原理和应用实践。
2、Apache Druid
2.1 核心特性
Apache Druid 是一个开源的分布式的支持实时分析和实时摄入的数据存储系统，天然为分析而生。其中的每个 Druid 进程都可以独立配置和扩展，在集群上提供最大的灵活性。这种设计还提供了增强的容错能力：一个组件的中断不会立即影响其他组件。Druid 之所以可以实现大数量下的实时 OLAP，是因为它有如下核心特性：
2.1.1 列式存储
列式存储意味着只需要根据指定查询加载指定列，避免加载一些不必要的数据，提高查询的速度。除此之外，Druid 还对每列进行了优化存储，从而支持快速扫描和聚合。
2.1.2 可扩展的分布式系统
Druid 通常部署在数十到数百台服务器的群集中，并且可以提供每秒数百万条记录的接收速率，数万亿条记录的保留以及亚秒级到几秒的查询延迟。
2.1.3 并行计算
Druid 会根据摄入规则对数据进行分块和分段，计算时也会通过增加机器对不同的段文件并行计算来提高系统的算力。
2.1.4 高可用
由于每个 Druid 进程都可以独立配置和扩展，因此系统的读写是分离的，类似数据摄入、数据查询、压缩重建等不同的 task 都是相互独立的，甚至某一类进程中断后不会影响其他功能的持续服务。
2.1.5 快速过滤的索引
Druid 使用 Roaring 或 CONCISE 压缩的位图索引来创建索引，以支持快速过滤和跨多列搜索。
2.1.6 基于时间的分区
Druid 具有一部分时序数据库的功能，数据会先按照指定的时间维度字段进行分区，其次可以根据其他字段进行分区处理，这样的一个好处是，在按照时间维度进行过滤的时候，可以快速的定位到数据的位置，从而进行处理，这将大大提高基于时间的数据的性能。
2.1.7 近似算法
Druid 包含了一些近似算法，如 approximate count-distinct，approximate ranking，approximate quantiles，这些算法内存使用量比较小，计算通常比精确计算要快很多对于精度比速度更重要的情况，Druid 还提供了精确的算法，用户可以根据具体的业务场景来取舍。
2.1.8 预计算
Druid 通过 roll up 特性支持在数据摄取的时候进行预计算。
2.1.9 可插拔的查询系统
通常来说，一个查询系统需要实现存储和执行两个模块，大部分的查询系统的存储模块依赖于特定的存储系统。而 Druid 不依赖于特定的存储系统，只要 Druid 能找到这个存储基础设施，并可以从其中获取数据，那么这个存储基础设施就可以成为 Druid 的存储系统，不论是 AWS S3，还是 HDFS 等。这个特性可以很方便的利用起来目前公司现在的存储基础设施，而不用重新引进一套。
2.1.10 对离线数据和在线实时数据分析的支持
Druid 采用 Lambda 架构，通过冷热数据分离的方式做到这一点的，冷数据是指已经写入到 Druid 的数据，这类数据存在于计算节点的硬盘上。热数据是等待写入的数据，这类数据存在内存中，查询的时候，Druid 分别对冷数据和热数据进行查询，再把查询结果进行汇总返回给用户。它的解题思路就是各司其职，最后汇总即可。
2.2 组件和架构
2.2.1 核心概念
**Datasource：**类似于 RDBMS 中的 table，是一个逻辑概念，指每一个摄入规则执行后对应的数据源。
Segments：Druid 中数据的实际物理存储格式。Druid 通过对 Segment 实现了对数据对横纵向操作，将不同时间范围内的数据存储在不同的 Segment 数据块中，这是数据的横行切割，这带来的优点是，按照时间范围查询数据的时候，仅需要访问对应时间段范围内的 Segment 数据块，而不需要进行全表扫描。同时 Segment 文件也是经过精心设计的，面向列进行数据压缩存储，这是数据纵向切割，使用了 Bitmap 和倒排索引等技术对数据的访问进行了优化。Druid 使用三种不同的技术来最大化查询性能：
- 精简每个查询访问的段
- 在每个段中，使用索引标识必须访问哪些行
- 在每个段中，只读取与特定查询相关的特定行和列
2.2.2 核心服务
Druid 的核心服务都是跨节点集群分布的，可以在单个节点上运行多个（特别是用于测试）。
Coordinator：
用来管理集群中的数据可用性，主要负责 Segment 管理和分配，与计算节点进行通信，维持整个集群中各个计算节点的 Segment 的可用性和平衡。Coordinator 与计算节点并不直接通信，而是通过 Zookeeper 进行协调。
Overlord：
统治节点负责接收数据摄取任务，以及任务的分配（分配到集群的各个 Middle Manager 服务），统治节点可以配置成 local 和 remote 模式：
- local 模式：不仅负责分配任务，也可以在自己本地执行数据摄取任务。
- remote 模式：只负责分配任务。
Middle Manager：
负责接收统治节点分配的任务，然后启动相关苦工即独立的 JVM 来完成具体的任务
Historical：
计算节点，负责加载 Segment 文件，处理分布式查询。
Query Brokers：
处理查询请求，将查询分发到对应的计算节点上，然后汇总查询结果，统一返回给终端用户。
此外，Router 作为一个可选组件，用于将查询路由到不同的 Broker。默认情况下，Broker 根据规则设置路由查询。用户可以选择通过 Router 进行集群请求，达到查询隔离的目的，也可以直接将请求发送到上述对应组件上。
2.2.3 外部依赖
**Deep Storage：**深度存储是存储 Segment 文件的地方，这个是 Druid 不提供的机制，可以由用户自己选择，只要 Druid 能找到存储的地方并可以从中获取和存储数据就行，所有的计算节点都有一份存储在自己本地磁盘相关的 Segment 文件，那么有了 Deep Storage，即便所有的计算节点都挂掉了，那么我们的数据也不会丢失，可以从 Deep Storage 中恢复。
**Metadata Database：**用来存储元数据，而不是用来存储实际数据，如 Datasource 的信息，Segments 的存放位置，Rules 的配置，Task 的运行状态等相关信息。Druid 目前支持 MySQL， PostgreSQL，Derby 等数据库，当然也可以自己自定义配置。
**Apache ZooKeeper：**使用 Apache ZooKeeper 来管理集群当前的状态，用于服务发现，协调和领导者选举。
2.3 性能表现
大数据下的 OLAP 性能测试涉及的因素有很多，包括数据源，机器配置和部署方式等，因此很难有统一的业界标准，官方在 2014 年采用真实的工业数据进行的 benchmark，从截图可以看到，就查询性能而言，Druid 完胜 MySQL，查询时间缩小了 5-10 倍，随着数据量的增大，这种差距会越来越大。
3、应用实践
Druid 有着很成熟的用户群体，包括国内外的知名企业，国外的话当属 Airbnb，这家公司在内部大量使用 Druid 来做分析，包括他们开源的知名 BI 工具 Apache Superset，也在其中专门为 Druid 写了一套 Query Engine。国内公司像阿里、小米、58都在用。
在熵简数据智能解决方案中，我们利用 Druid 作为数据分析的最后一环：数据智能分析系统的核心引擎，为用户提供高度灵活的、亚秒级响应的探索性分析工具。这套系统的架构和 Druid 所扮演的角色如下图：
在这一套系统中，围绕 Druid 我们做了特定场景的优化来满足我们的需求。
3.1 引入 MinIO
MinIO 是业内最知名的开源对象存储服务，兼容 S3 协议，针对金融、政企客户，可以方便进行私有化部署。这里我们将多种异构数据源进行加工之后，存储到 MinIO，借助于 Druid 与 S3 的深度集成，可以很方便地将 MinIO 上的数据一键式摄入到 Druid 中，在这里，我们只需要发送一个 HTTP 请求，Druid 就可以自动从指定到 S3 上拉取数据和进行入库操作了 ，这样极大的提高了开发效率，不用自己再去手写入库程序了。
其次我们还采用 MinIO 作为 Deep Storage，可以将 Druid 的 Segment 文件放到 MinIO 上，这样某个计算节点宕机之后，Druid 可以从 MinIO 上拉取对应的 Segment 文件放到还存活的计算节点，进行数据恢复。
关于上述两点，不同的客户企业基础设施都是不一样的，不是所有的客户都有 Hadoop 生态，在这种情景下，MinIO 是目前我们最理想的选择，私有化部署和运维简单，性能强劲 。
3.2 数据源预处理
数据智能分析系统是一个针对用户数据源的只读分析系统。在数据智能分析系统中执行导入数据（一张 csv 表格数据，或一个 RDS 数据源等）之后，用户并不关心底层的存储和分析逻辑。
因此我们有机会借鉴预计算系统的处理逻辑，在用户向数据智能分析系统导入数据时，根据数据源的字段类型、字段名称等信息，向 Druid 中用不同摄取规则生成多个数据源，例如同时生成一个保持数据原样的明细数据源，和一个经过 roll up 操作的聚合数据源。当用户进行查询时，系统会根据不同的查询语句将实际执行的 SQL 路由到某一个最合适的数据源，以确保获取最优秀的响应性能。
3.3 基于 Pandas 的后处理
在数据智能分析系统中，Druid 可以帮助我们做大数据下的实时查询处理， 但是数据智能分析的场景是复杂多变的，Druid 计算完成的结果之后，我们可能还要在内存中做 post-process，这里一个经典的场景如“快速表计算”，在数据分析领域，知名开源库 pandas 是绕不过的一环，基本大家都会用 pandas 或者类 pandas（如 Dask）进行数据分析，Druid 提供的 PyDruid 就与 pandas 有着深度集成，可以将 Druid 返回的结果包装成 DataFrame，便于我们二次处理。虽然各个语言都有自己各自的数据分析库，但因为 Druid 的请求是 HTTP 协议的，所以我们可以针对不同的场景进行封装数据，便于二次分析。
3.4 定制 OLAP Adaptor
世界上没有能解决所有问题的银弹，在数据智能分析数据分析领域也是如此，没有能解决所有问题的 OLAP Engine，拿 Druid 举例，Druid 的 distinct count 算法是近似算法，它虽然也支持精确去重计算，但是一个查询，只能支持一列 distinct count，这显然对于产品来说，是不能接受的，一个产品的发展，最好是能减少这些外部依赖对其本身对接受，对于用户来说，也是不能接受的，一些需要精确的去重计算如果要近似的来代替，是要出问题的。
在这种情况下，定制 OLAP Adaptor 是一件很有必要，且有意义的事情，我们内部封装一套 OLAP Adaptor 协议，目前已经接入 Druid 和 ClickHouse，这样在私有化部署的时候，可以根据用户的选择，进行切换。
在 Druid 的基础上，我们建立了熵简自有的实时数据分析系统。这个系统在用户提供实时数据注入后，支持对已有数据进行实时多维度、多种类的探索，用户能够得到毫秒级、最长到数百毫秒级的实时响应。
4、总结
关于实时数据分析系统的技术选型，需要结合自己公司的技术栈来选择，像 Druid 属于一个很简单、灵活的数据分析系统，它的生态相对成熟，也不仅仅局限于在离线数据分析上，且功能于大部分系统相比，Druid 功能属于精简的，但性能是出众的，实时支持也是超群的，在实时数据分析领域能够发挥巨大的优势。
团队招聘
熵简科技大数据团队长期招聘后端工程师、大数据工程师，期待优秀的同学加入我们，Base 北京、上海。欢迎感兴趣的同学发送简历至：[email protected]。
关于熵简科技
熵简科技是一家数据智能公司，熵简科技围绕“数据采集-数据融合-数据计算-业务决策”的各个场景，运用自主研发的数据中台引擎，通过端到端的数据中台体系切实解决企业需求痛点。
更多技术干货文章，请关注熵简科技的公众号「熵简学院」