目前,行业中的大数据分析架构一般使用基于 Hadoop 体系的分布式计算引擎 + 分布式存储系统架构(如下图)。 Hadoop 体系的架构特点是上层解决计算问题,下层解决存储问题。它可以让开发者在不了解分布式底层细节的情况下,进行分布式程序的开发。但是,这种架构同时也存在一些问题:
因此,我们需要一个可以充分解决以上问题的大数据储存格式,也就是笔者接下来要为大家介绍的 IndexR 开源大数据存储数据库。 IndexR 是一个开源的大数据存储格式(下载地址 https://github.com/shunfei/indexr),于 2017 年 1 月初正式开源,目前已经更新至 0.5.0 版本。IndexR 旨在通过添加索引、优化编码方式、提高 IO 效率等各种优化方式来提高计算层和存储层的数据交换效率,从而提升整体性能。同时,IndexR 可以接收实时数据,并对上层提供统一的数据接口。数据一旦到达 IndexR 系统即可立刻进行数据分析。 基于 IndexR 系统的典型架构示例如下: 1.IndexR 为上层计算引擎提供数据,相当于对 IO 层做了整体的性能加速,提升了系统的分析能力。 2.IndexR 为下层数据存储解决了在线分析和数据调用的问题,同时还能解决实时数据和历史数据的分割问题。
IndexR 从开源至今,历经不同团队从调研、测试到最后部署生产环境的实践,已获得了国内外数十家团队的认可(如尼尔森、佰安信息等),包括广告、电商、AI 等领域的大型互联网公司和创业团队以及政府、咨询、物流等拥有超大数据集且对数据质量有极高要求的行业。其中:尼尔森(Nielsen-CCData)使用 IndexR 产品服务全面支撑了其六大产品线的核心业务,应对海量数据的在线监测、治理、分析以及复杂多变的智能化数据产品输出,专注于全媒体与受众研究业务。佰安信息则使用 IndexR 产品服务进行公共信息的明细查询与统计分析,单表数据量近 2 千亿,每日入库近 4 亿条数据。 下面列举几种常见的使用场景:
IndexR 具有六大特性:自带索引、灵活性强、实时性高、速度快、省资源、预聚合。 IndexR 包含三层索引,即粗糙集索引(Rough Set Index)、内索引(Inner Index)和可选的外索引(Outer Index)。 目前的 On Hadoop 存储格式如 ORC、Parquet 等都没有真正的索引,只靠分区和利用一些简单的统计特征如最大最小值等大概满足离线分析的需求。在服务在线业务时 On Hadoop 就显得非常力不从心,需要从磁盘中读取大量无用数据。事实上并不是每次查询都需要获取全部数据,特别是 Ad-hoc 类型的查询。而 IndexR 通过多层索引的设计,不仅极大地提高了 IO 效率,只读取部分有效数据,而且把索引的额外开销降到了最低。 一般传统数据库系统的索引设计是通过索引直接命中具体的数据行,但这种方式只适用于 OLTP 场景,即每次查询只获取少量数据,在 OLAP 场景下并不适合。OLAP 场景下每次查询可能要涉及上万甚至上亿行数据,这样的索引设计开销极大(内存、IO、CPU),并会带来磁盘随机读的问题,很多时候还不如直接对原始数据进行扫描更加快速。 IndexR 的索引设计是分层的。打个比喻,如果要定位全国具体的某个街道,传统的方式是把“省市 - 街道”组成一个索引,而 IndexR 是通过把“街道”映射在相应的“省市”的集合(Pack)里,然后再在具体的集合了里做细致的索引。
目前的 Hadoop 生态对于实时的数据分析还是比较困难。Storm、Spark Streaming 等系统属于对数据进行预计算,在业务频繁改动或需要对原始数据进行启发式分析(Ad-hoc)的情况下没法满足需求。而 Druid、Kudu 等系统虽然支持实时写入,但其体系自成,在实际运用中常会出现部署、整合甚至性能方面的问题。 IndexR 支持实时数据写入,比如从 Kafka 导入,并且数据到达系统之后可以立刻被分析。它与 Hadoop 生态的无缝整合也使得它在业务设计上非常灵活。目前 IndexR 单表单节点入库速度每秒超过 3w 条数据,入库速度会随着节点数量呈线性增加,每个表使用单独线程,表间互不影响。此外,对于 OLAP 型的多维分析场景,IndexR 还支持实时、离线预聚合处理,将指标基于维度进行预先组织,大大减少了数据量,数据分析更加快速。 IndexR 使用深度优化的编码方式,大大加快了数据解析,甚至可以媲美一些内存数据库。它的数据组织形式根据向量化执行的特点定制,把全部数据存放于堆外内存,并且优化到各个 byte 的组织方式,把 JVM 的 GC 和虚函数开销降到最低。 IndexR 是基于 Hadoop 的数据格式,意味着文件存放于 HDFS,这样可以非常方便地利用 HDFS 本身的高可用特性保证数据安全,并且可以方便的使用 Hadoop 生态上的所有分析工具。IndexR 对基于 HDFS 的文件读取做了大量的优化,把计算尽量分发到离数据最近的本地节点,HDFS 层的开销基本被剔除,与直接读取本地数据无异。 以下是使用 TPC-H 数据集,IndexR 与 Parquet 格式在相同的 Drill 集群上做的一个性能对比。 最大表 lineitem 数据总量 6 亿,5 个节点,节点配置 [Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz] x 2, RAM 64G(实际使用约 12G), HDD STATA with 7200RPM。 IndexR 与 Parquet 的 Hive 表 schema 都没有设置 TBLPROPERTIES,使用默认参数。
柱状图:
柱状图: 为了避免 Java 中对象和抽象的开销,IndexR 的代码大量使用了 Code C In Java 的编程风格(调侃),通过内存结构而非接口进行解耦。紧凑的内存结构减少了寻址开销,且非常利于优化 JVM 的运行。IndexR 在保证了高性能、有效索引的基础上极大地节省了内存,与使用 Parquet 格式查询时的内存使用量差不多,不会出现像 CarbonData 需要配置超大内存的情况。但是为什么不直接使用 C 或者 C++ 呢?因为目前 Hadoop 生态最适合的开发语言还是基于 JVM,JVM 语言可与其他系统无缝集成,在工具链支持方面也是最全面的。 IndexR 通过与 Hadoop 生态的深度整合,适合用来搭建海量数据场景下的数据仓库。 IndexR 与行业通用方案对比: Parquet,ORC - 他们与 IndexR 一样都属于存储格式,功能上比较类似。目前 IndexR 还不支持较复杂的数据格式,但额外支持索引、实时导入、预聚合等特性。 CarbonData - CarbonData 也是用于大数据分析场景的数据格式,并且支持索引,官方文档称适用于大量数据扫描和少量数据查询的场景,与 IndexR 在存储格式上的定位非常相近。同样 IndexR 还额外支持实时导入、预聚合等特性。笔者尝试使用 CarbonData 与 IndexR 在相同的 Hadoop 集群上做性能对比,发现 CarbonData 的表现不稳定,特别是 Q9 和 Q10,以下是测试结果,欢迎同行讨论。 使用以上测试相同集群,CarbonData 1.1.0, Hadoop 2.5.2, Spark 2.1.0. Spark 启动参数:bin/spark-submit --class org.apache.carbondata.spark.thriftserver.CarbonThriftServer --num-executors 5 --executor-cores 10 --executor-memory 31G carbonlib/carbondata_2.11-1.1.0-shade-hadoop2.2.0.jar hdfs://rttest/user/hive/warehouse/carbon.storeCarbonData 表 schema 没有设置 TBLPROPERTIES,使用默认参数。
IndexR 项目是由舜飞科技开发的,最早是为了解决公司内部程序化广告业务的大数据实时分析需求。目前,舜飞科技使用 IndexR 支撑了每日近千亿数据的实时入库及在线多维分析系统。IndexR 致力于成为 Hadoop 生态下快速分析查询的标准存储格式。希望它可以获得业界更多的关注和使用及社区的更多积极参与。 作者介绍深度访谈:华为开源数据格式 CarbonData 项目,实现大数据即席查询秒级响应
|
|