本文共 6186 字，大约阅读时间需要 20 分钟。
在当前信息大爆炸的时代，“大数据”已成为互联网行业人人谈论的热词和话题，比如近几年快速发展的基于大数据进行精准用户定向的程序化广告，以及去年马云提出的利用大数据重塑商品的生产 - 流量 - 销售流程的“新零售”模式等。大数据已经渗透到众多的行业，为许多企业带来了变革性影响。那么，何为“大数据”呢?大数据(Big Data)，可以简单的理解为无法在一定时间范围内用常规手段进行处理的海量数据集合。所有企业的业务分析都是基于数据的，每家企业对数据的收集、整合及处理能力在一定程度上决定了企业的业务发展水平。因此，提升数据分析性能也是当前许多企业共同面临的重大挑战。
行业现状
目前，行业中的大数据分析架构一般使用基于 Hadoop 体系的分布式计算引擎 + 分布式存储系统架构(如下图)。
Hadoop 体系的架构特点是上层解决计算问题，下层解决存储问题。它可以让开发者在不了解分布式底层细节的情况下，进行分布式程序的开发。但是，这种架构同时也存在一些问题：
1.整合工作量大
分布式存储目前的标准比较统一，一般使用 HDFS。HDFS 能有效解决海量数据的存储问题，并且有多种方便的工具链。但是，分布式计算引擎为了适应不同场景，会有不同特性的数据仓库工具，仅 Apache 就有 Hive、Spark、Drill、Impala、Presto 等产品，除此之外，还有独立于 Hadoop 体系之外其它产品项目(如 ClickHouse、Kudu、Druid 等)。由于每个产品都有各自的特性，当需要利用多个产品来解决不同问题时，就需要额外的整合工作，降低了工作效率。
2.数据交换速度慢
由于计算层必然是驻于内存的，从存储层到计算层的速度限制就成了系统的普遍瓶颈。有些系统为了加快速度全部使用内存存储(比如内存数据库、基于 Spark 的 SnappyData)，这种方式在数据量较大时会造成巨大的成本压力，因此目前还远未成为主流。
3.数据实时分析性差
由于文件系统的天然限制，数据一般是批量导入系统的。导入的时间会依据数据量的大小而有所不同，在数据量较大时常会出现入库滞后现象，从而影响了数据分析的及时性。
因此，我们需要一个可以充分解决以上问题的大数据储存格式，也就是笔者接下来要为大家介绍的 IndexR 开源大数据存储数据库。
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 具有六大特性：自带索引、灵活性强、实时性高、速度快、省资源、预聚合。
1. 自带索引：存储格式自带索引。
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)里，然后再在具体的集合了里做细致的索引。
2. 灵活性强：双存储模式，适应不同场景。
3. 实时性高：支持流式导入，实时分析。
目前的 Hadoop 生态对于实时的数据分析还是比较困难。Storm、Spark Streaming 等系统属于对数据进行预计算，在业务频繁改动或需要对原始数据进行启发式分析(Ad-hoc)的情况下没法满足需求。而 Druid、Kudu 等系统虽然支持实时写入，但其体系自成，在实际运用中常会出现部署、整合甚至性能方面的问题。
IndexR 支持实时数据写入，比如从 Kafka 导入，并且数据到达系统之后可以立刻被分析。它与 Hadoop 生态的无缝整合也使得它在业务设计上非常灵活。目前 IndexR 单表单节点入库速度每秒超过 3w 条数据，入库速度会随着节点数量呈线性增加，每个表使用单独线程，表间互不影响。此外，对于 OLAP 型的多维分析场景，IndexR 还支持实时、离线预聚合处理，将指标基于维度进行预先组织，大大减少了数据量，数据分析更加快速。
4. 速度快：媲美内存数据库。
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，使用默认参数。
柱状图：
柱状图：
5. 省资源：减少内存使用量
为了避免 Java 中对象和抽象的开销，IndexR 的代码大量使用了 Code C In Java 的编程风格(调侃)，通过内存结构而非接口进行解耦。紧凑的内存结构减少了寻址开销，且非常利于优化 JVM 的运行。IndexR 在保证了高性能、有效索引的基础上极大地节省了内存，与使用 Parquet 格式查询时的内存使用量差不多，不会出现像 CarbonData 需要配置超大内存的情况。但是为什么不直接使用 C 或者 C++ 呢?因为目前 Hadoop 生态最适合的开发语言还是基于 JVM，JVM 语言可与其他系统无缝集成，在工具链支持方面也是最全面的。
6. 易整合：深度整合 Hadoop 生态。
IndexR 通过与 Hadoop 生态的深度整合，适合用来搭建海量数据场景下的数据仓库。
IndexR 与行业通用方案对比：
使用以上测试相同集群，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，使用默认参数。
转载地址：http://slrfx.baihongyu.com/