CN107133342A - 一种IndexR实时数据分析库 - Google Patents

一种IndexR实时数据分析库 Download PDF

Info

Publication number
CN107133342A
CN107133342A CN201710355812.1A CN201710355812A CN107133342A CN 107133342 A CN107133342 A CN 107133342A CN 201710355812 A CN201710355812 A CN 201710355812A CN 107133342 A CN107133342 A CN 107133342A
Authority
CN
China
Prior art keywords
data
indexr
real
time
node
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201710355812.1A
Other languages
English (en)
Inventor
李华煜
韦万
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Guangzhou Shun Fei Mdt Infotech Ltd
Original Assignee
Guangzhou Shun Fei Mdt Infotech Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Guangzhou Shun Fei Mdt Infotech Ltd filed Critical Guangzhou Shun Fei Mdt Infotech Ltd
Priority to CN201710355812.1A priority Critical patent/CN107133342A/zh
Publication of CN107133342A publication Critical patent/CN107133342A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/13—File access structures, e.g. distributed indices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/172—Caching, prefetching or hoarding of files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/182—Distributed file systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/221—Column-oriented storage; Management thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/22—Indexing; Data structures therefor; Storage structures
    • G06F16/2228—Indexing structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2465—Query processing support for facilitating data mining operations in structured databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0241—Advertisements
    • G06Q30/0242—Determining effectiveness of advertisements
    • G06Q30/0246—Traffic
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2216/00—Indexing scheme relating to additional aspects of information retrieval not explicitly covered by G06F16/00 and subgroups
    • G06F2216/03—Data mining

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computational Linguistics (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Computing Systems (AREA)
  • Mathematical Physics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Fuzzy Systems (AREA)
  • Game Theory and Decision Science (AREA)
  • Probability & Statistics with Applications (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种IndexR实时数据分析库；IndexR实时数据分析库实现了一种可部署于分布式环境，可并行化处理，带索引的，列式的结构化数据格式。基于这种数据格式，IndexR构建了一个数据仓库***(Data Warehouse)，基于Hadoop生态，可以对海量数据集做快速统计分析(OLAP)，数据可实时导入并且对于查询零延迟。IndexR为解决大数据场景下分析缓慢、数据延迟、***复杂等问题而设计。本发明的IndexR实时数据分析库把数据存放于HDFS，使用Zookeeper在集群中通讯和交涉，使用Hive方便的管理分区数据，可以通过Kafka高速实时导入数据，查询层使用优秀的分布式查询引擎Apache Drill。

Description

一种IndexR实时数据分析库
技术领域
本发明属于互联网技术领域，尤其涉及一种IndexR实时数据分析库。
背景技术
程序化广告业务需要对接全网的各大媒体，每秒产生上百万的分析数据。这些数据对广告投放活动的过程进行了精细的追踪和描述，比如创意的展示量、点击量，活动产生的注册数、回访数等。我们需要对这些数据进行实时分析处理，用于包括客户报告，投放优化，欺诈分析，收费结算等。数据使用者的查询模式是非固定的，无法预测的，并且随着业务量的激增，数据量也急剧增长。我们需要一种新的技术来解决这些需求：1、超大数据集，低查询延时：查询模式无法预测，无法预计算；表数据量普遍超过1亿，甚至上百亿千亿，过滤条件有可能会命中大量数据；数据在查询的同时还会有大量的更新，每秒入库几万的数据。要保证较低的查询延时，一般情况下查询延时要求在5s以内，常用高频查询要求1s以内。2、准实时：数据从产生到体现在分析结果延时几秒以内。时效性对于某些业务至关重要，并且越实时的数据，价值越大。3、可靠性，一致性，高可用：这些数据是公司最重要的数据之一，任何错误和不一致可能会直接体现在客户报表中，对公司的业务和品牌形象产生影响，至关重要。4、可扩展，低成本，易维护：业务会快速发展，会产生新的数据源，加入新的表，旧的数据不能删除，这带来巨大的成本压力，和运维压力。典型的更新如加列、列值更新等操作不能影响线上服务，不能带来入库或者查询延迟。5、SQL支持：全面支持SQL，要像Mysql一样好用，功能强大。不仅仅支持常见的多维分析，还需要支持复杂的分析查询，如JOIN，子查询等，支持自定义函数(UDF，UDFA)。6、与Hadoop生态整合：Hadoop生态的蓬勃发展给大数据处理带来越来越强的处理能力，如果能与它的工具链深度结合，会极大扩展***的价值。7、多维分析、Ad-hoc查 询：大部分的查询结果是基于一个或多个维度组合的汇总，并且要求短时间内响应，最好全面支持SQL和UDF。
目前提供相似功能的产品，有些通过使用传统的关系型数据技术，或者通过预先建Cube加速查询。这些方式可能会带来一些问题，比如运维困难，数据量瓶颈，或者模式不够灵活，无法支持业务变化。有些方案使用内存存储技术，使用上成本比较高，而且在大数据分析场景并无特别大的速度优势。近年出现的一些时序数据库，解决了一些入库延迟方面的问题，但是在查询性能，可用性，可扩展性等方面存在一些问题。
现有的技术解决方案如MySQL，PostgreSQL等关系型数据库，它们一般都有非常完整的功能支持，但无法支持超大量数据，统计分析的性能也不好，一般作为T+1架构的实时库。Hbase，或者Redis等K-V数据库，上层一般有一个SQL查询层，比如Phoenix，上游由Spark、Storm等流式框架预聚合数据。这类架构限制非常多，很难支持复杂及频繁修改的业务。Kylin也属于这一类，离线预聚合。Infobright，Greenplum，MemSQL等各有特点的数据库，有开源社区版本。在一定条件、数据量下能满足特定需求，但是缺点较多，有些不支持更新，或者运维困难，数据量支持小等。Hana,Vertica，以及云服务等收费数据库。我们没有选择这个方向，认为把分析***构建在这类第三方封闭***上，与目前现有数据工具的整合相对困难，担心对后续扩展、迁移的影响。最近几年较火的所谓时间序列数据库，代表为Druid，Pinot，Influxdb等。笔者曾经比较深入的研究过，甚至在项目中有过部署，但最终认为都不适合。有些项目并不成熟，或者对硬件要求极高，缺少弹性，有些架构上有比较大的问题，实际应用时表现的非常不稳定。其他开源分析工具，如Impala，Drill，或者SparkSQL。它们一般专注于计算层，缺少一个合适的数据格式，并且它们通常是分析静态文件的，没法做到分析实时数据。目前的arquet，ORC等数据格式通常有不错的扫描、压缩性能，但缺少有效的 索引和必要的灵活性。
发明内容
本发明的目的在于提供一种IndexR实时数据分析库，以解决上述背景技术中提出的问题。
本发明的目的是通过下述技术方案予以实现：一种IndexR实时数据分析库,包括：***构架、部署架构、存储结构和实时模块；
所述***构架负责文件存储格式，包括索引和数据，数据的实时导入、表定义操作，查询优化，以及数据缓存等。分布式计算框架(Drill/Spark)负责在IndexR数据上的具体查询操作，以及其他计算任务，Hadoop以及周边工具-提供分布式文件存储，离线批量计算，离线数据管理，以及各种离线ETL任务，IndexR与Hadoop完美结合，可以作为一个高度压缩、自带索引的文件格式，兼容Hive的所有操作，Kafka-消息队列，数据经过kafka流入IndexR，Zookeeper-集群状态管理；
所述部署架构在Hadoop***的环境下，在现有集群上部署IndexR通常可以在半小时之内完成，只需要在所有Hadoop的DataNode(和NameNode)节点上部署一份带有IndexR插件的Drill节点，只有几项必须配置项，并且所有节点的配置都是一样的，IndexR的服务逻辑嵌入了Drillbit进程，无需额外启动服务；
所述存储结构以列式存储数据，并分片存储，分片称为Segment，每一个Segment都是自解释的，包括Schema，数据以及索引，Segment通常是固定不变的，这极大简化了数据管理，便于分布式处理；
所述实时模块可以极高效率的导入实时数据，并且数据可以立刻被查询，可以多节点同时导入，实时导入的数据叫做Realtime Segment，在达到一定阀值后，IndexR会将它们合并成历史Segment，并上传到HDFS，之后数据就可以被离线分析工具所使用和管理，Realtime Segment具体实现参考了 LSM-Tree，通过在磁盘上的commitlog文件保存所有更新操作，最新数据放在内存中以快速入库和索引，周期性将内存数据dump到磁盘，IndexR进程可以随时被重启，或者直接杀死，不用担心数据丢失；
进一步的，所述IndexR实时数据分析库的测试硬件标准包括以下部分：
1)每个节点12核(24线程)CPU,60G内存,SATA接口7200转机械硬盘，
2)实时导入速度：超过30K消息/秒/节点/表，即，假如有10个节点，每个节点拥有10个表，可以在一秒钟之内消费3M条消息，一天轻松实时导入千亿数据，
3)扫描速度：通常一行内通常会读取多个字段，在现代CPU和计算框架的帮助下，可以同时对多个字段进行运算，从而获得比以下数据更好的性能，
4)冷数据-30M字段/秒/节点，
5)热数据-100M字段/秒/节点，
6)扫描速度约为Parquet的2.5倍，
7)OLAP查询：在我们的实际业务中，我们发现95％的查询延时在3s内，数据量规模为千亿级别，20个节点，
8)相同的Drill环境下约为Parquet格式的3～8倍，
9)压缩率：在我们的实际业务中，相对于CSV格式，压缩率约为10:1，有些表甚至达到20:1，
10)压缩后大小约为ORC格式的75％。
本发明的有益效果是：
1、快速统计分析查询：IndexR使用列式存储，对于超大量数据集，它提供高效的索引，通过过滤掉无关数据，快速定位有效数据，减少IO。它使用了优秀的Apach Drill作为上层查询引擎。特别适合于ad-hoc的OLAP查询。
2、数据实时导入：IndexR支持超高速实时导入数据。数据一到达IndexR节点，立刻可以被查询到。实时数据和历史数据可以一起查，再也不需要考 虑所谓T+1架构。且区分于其他有类似功能的***，IndexR永远不会主动丢弃任何数据。
3、高效硬件利用率：相较于其他***，IndexR可以跑在廉价的机器上。不需要昂贵的SSD硬盘，高端CPU，甚至小型机，你就可以获得非常好的性能，虽然在上面跑会更加快。虽然跑在JVM上，它手动管理几乎所有的内存，使用经过高度设计、紧凑的数据结构。
4、集群高可用，易扩展，易管理，简单：分布式***发展到现在，高可用和扩展性已经是标配了。IndexR的特点是结构非常简单可靠，且只有极少的必须配置项。
5、与Hadoop生态的深度整合：IndexR把数据存放于HDFS。这意味着你可以使用MapReduce，或者任何Hadoop工具处理这些文件。我们目前提供了Hive插件，用于各种ETL相关工作，或者跑离线任务。对接Spark的工作正在进行，将被使用于数据挖掘以及机器学习。
6、高度压缩的数据格式：IndexR以列式存储，并提供超高的压缩率，可以显著的减少IO以及网络开销。
7、方便的数据管理：IndexR可以方便的导入、删除数据，并且支持修改表Schema，如对列的添加、删除、修改等。
具体实施方式
具体实施例
一种IndexR实时数据分析库,包括：***构架、部署架构、存储结构和实时模块；
所述***构架负责文件存储格式，包括索引和数据，数据的实时导入、表定义操作，查询优化，以及数据缓存等。分布式计算框架(Drill/Spark)负责在IndexR数据上的具体查询操作，以及其他计算任务，Hadoop以及周边工具-提供分布式文件存储，离线批量计算，离线数据管理，以及各种离线 ETL任务，IndexR与Hadoop完美结合，可以作为一个高度压缩、自带索引的文件格式，兼容Hive的所有操作，Kafka-消息队列，数据经过kafka流入IndexR，Zookeeper-集群状态管理；
所述部署架构在Hadoop***的环境下，在现有集群上部署IndexR通常可以在半小时之内完成，只需要在所有Hadoop的DataNode(和NameNode)节点上部署一份带有IndexR插件的Drill节点，只有几项必须配置项，并且所有节点的配置都是一样的，IndexR的服务逻辑嵌入了Drillbit进程，无需额外启动服务；
所述存储结构以列式存储数据，并分片存储，分片称为Segment，每一个Segment都是自解释的，包括Schema，数据以及索引，Segment通常是固定不变的，这极大简化了数据管理，便于分布式处理；
所述实时模块可以极高效率的导入实时数据，并且数据可以立刻被查询，可以多节点同时导入，实时导入的数据叫做Realtime Segment，在达到一定阀值后，IndexR会将它们合并成历史Segment，并上传到HDFS，之后数据就可以被离线分析工具所使用和管理，Realtime Segment具体实现参考了LSM-Tree，通过在磁盘上的commitlog文件保存所有更新操作，最新数据放在内存中以快速入库和索引，周期性将内存数据dump到磁盘，IndexR进程可以随时被重启，或者直接杀死，不用担心数据丢失；
所述IndexR实时数据分析库的测试硬件标准包括以下部分：
1)每个节点12核(24线程)CPU,60G内存,SATA接口7200转机械硬盘，
2)实时导入速度：超过30K消息/秒/节点/表，即，假如有10个节点，每个节点拥有10个表，可以在一秒钟之内消费3M条消息，一天轻松实时导入千亿数据，
3)扫描速度：通常一行内通常会读取多个字段，在现代CPU和计算框架的帮助下，可以同时对多个字段进行运算，从而获得比以下数据更好的性能，
4)冷数据-30M字段/秒/节点，
5)热数据-100M字段/秒/节点，
6)扫描速度约为Parquet的2.5倍，
7)OLAP查询：在我们的实际业务中，我们发现95％的查询延时在3s内，数据量规模为千亿级别，20个节点，
8)相同的Drill环境下约为Parquet格式的3～8倍，
9)压缩率：在我们的实际业务中，相对于CSV格式，压缩率约为10:1，有些表甚至达到20:1，
10)压缩后大小约为ORC格式的75％。
IndexR存储结构化数据，比如以下是一个虚构的广告投放用户表Table A:
column name data type
date int
contry string
campaign_id long
impressions long
clicks long
数据文件称为Segment，一个Segment保存一个表的部分行，包含所有的列。
Segment文件是自解释的，它包含版本信息，完整的表定义，各个部分的元数据(offset)，以及索引。IndexR默认对所有的列进行索引。行顺序可以是入库的自然顺序，也可以是按照用户定义的字段排序。这样的设计可以简 化***架构，不需要额外的元数据存储，非常适合于分布式环境下的并行处理，也方便外部***如Hive直接使用。
Segment的行数据在内部会进一步细分为pack，每个pack都有独立的索引。pack内部的行数据是以列存储的，即某一列的数据会集中存放在一起。这种方式对于列数据的快速遍历，和压缩带来极大的优势。对于现代通用计算机架构，cache友好，方便vectorprocess，充分发挥现代多核CPU的性能。Segment的列数据使用特别优化的压缩算法，根据数据类型选择不同的算法和参数，通常压缩率10：1以上。
在实际业务数据测试中，IndexR每个节点每秒可以处理1亿个字段。测试机器配置：[Intel(R)Xeon(R)CPU [email protected]]x 2,60G RAM,SATA 7200RPM DISK。这个配置在目前服务器配置中算低端的，更强大的CPU会对IndexR有非常大的性能提升。
索引
IndexR采用粗糙集索引(Rough Set Index)，它能以极低的成本，很高的精确度定位到相关文件和位置。
比如我们的某一个数据块(pack)有以下数据，有date(int类型)和use_name(string)类型。
IndexR对于number和string类型有不同的索引方式，这里描述基本的思路。
对于number类型，会记录该列的最大值(max),最小值(min)，然后把它们的区间(max-min)进行分割成多个区间，每一个区间使用一个bit表示。然后把各个具体的值映射到这个区间之中。
bit index chunk value
0 20170101～20170102 1
1 20170103～20170104 0
2 20170105～20170106 0
3 20170107～20170108 1
4 20170109～20170110 1
如上表，value值为1表示这个区间存在一行或者多行的数据，为0表示不存在。我们只需要存储max，min，和value序列(5个bit)就完成了对这一列的索引。
比如查询
SELECT user_name FROM A WHERE date＝'20170106'
因为'20170106'属于区间2，value是0，即可以知道'20170106'不存在 于这个pack，可以直接跳过。这是一种类似于bloomfilter的过滤方式，索引不命中的pack一定不包含需要的数据
string类型的索引和number类似，不过更加复杂一点。
目前常见的索引有B+树索引，倒排索引，这些索引可以精确定位到具体行，在相对小数据量情况下很有效。这种方式通常没有特别有效的压缩，数据文件大小一般在原始数据的1～3倍之间，当数据量膨胀到一定程度，这类索引的代价就会被放大，甚至无法服务。
IndexR的粗糙集索引的优势是非常快速，索引文件足够小，可以低成本的方式load到内存，在极大数据量场景下仍然能有效的工作。由于数据通常是排序的内聚的，通过实际数据的观察，列的值基数(cardinality)通常比较小，这种方式是可以有效的过滤掉无关的pack。它会对所有的列进行索引，非常适合于业务不固定，或者数据分析场景的探索型分析。
实时入库
IndexR支持实时数据追加，但不支持数据在线更新，可以通过离线的方式使用Hive等工具更新数据，这样的设计和Mesa类似。它的入库速度非常快，通常单个节点单表可以达到30k消息/s。消息到达IndexR Node之后，可以立刻被查询。
IndexR的实时入库模块使用类似LSM-Tree的结构。使用commitlog文件保存消息，最新的数据存放于内存，在达到一定阀值之后会被写入硬盘。
内存中的数据周期性的存储到硬盘，时间一久会产生较多碎片文件，这些文件在达到一定阀值之后，会被整理合并。
行的存储顺序可以是自然入库顺序，也可以按照指定字段排序，类似于关系型数据库中的一级索引和HBase中的Column Family，这样做可以让数据更加内聚，对于查询非常有利。
类似于Mesa，如果需要，IndexR实时入库可以根据多维分析 (MultidimensionalAnalysis)的概念，把字段分成维度(Dimension)和指标(Metric/Measure)，具有相同维度的行会合并到一起，指标使用聚合函数(aggregation function,e.g.SUM,COUNT)，并且表之间可以设计成父子关系。
Table B与Table C可以可以认为是Table A的子表。Table A拥有三个维度(date,country,campaign_id)，可以表达最详细的信息。Table B与Table C通过减少维度，减少了数据量，可以更加快速的获得查询结果。
应用层只需要做简单的表路由，比如
SELECT date,country,SUM(impressions)FROM B WHERE country＝'CN'GROUPBY date,country
可以路由到Table B表，快速获得结果。如果需要下钻(Drill Down)查询，如
SELECT campaign_id,SUM(impressions)FROM A WHERE country＝'CN'and date＝'20170101'GROUP BY campaign_id
则会路由到Table A。
这种设计类似于关系型数据库中预聚合View。在OLAP领域，特别是多维分析场景，这种设计非常有效。
架构设计
IndexR的架构设计遵循简单可靠、易扩展的原则。它可以大规模集群部署，支持上千个节点。事实上IndexR的硬件成本相对来说很低，并且可以通过加节点线性扩展处理能力。
Apache Drill作为IndexR的查询层。Drill是一个全新的查询引擎，专注于SQL计算，使用了代码生成技术，vector process，列式计算，堆外内存(消除GC)等技术，有专门针对对于大数据集的优化。速度极快，并且支持标准SQL，没有迁移负担。从我们的使用经验来看，它非常稳定，工程质量 很高。
IndexR主要负责存储层，并且对具体的查询过程进行优化，比如常见的条件下推(predicate pushdown)，limit下推等，未来还将支持聚合下推(aggregation pushdown)。IndexR通过任务分配算法，结合数据距离、节点繁忙程度等，把计算任务分配到最合适的节点。
HDFS存储具体的数据文件，分布式文件***帮助构建节点无状态的服务。数据存放于HDFS中，可以方便的使用各种Hadoop工具进行其他复杂分析。我们对接了Hive，方便对数据进行离线处理。由于HDFS上的数据只有一份，可以同时被多个工具处理，省去了繁琐的同步步骤，在10：1的高压缩比上又节省一倍空间。
数据经过Kafka等队列高速导入IndexR。IndexR的实时导入非常灵活，可以随时增加或者删除导入节点。它拥有极高的导入性能(30k/s)，入库延迟的压力成为历史。
在IndexR集群中只有一种节点(IndexR Node)，有利于部署和维护，不需要对节点进行划分。目前IndexR作为Drill插件嵌入了Drillbit进程。
IndexR提供了indexr-tool工具，提供了完整的运维工具。比如可以在线更新表结构，在线添加、修改实时入库配置。
工程实现的挑战
算法和数据结构要真正落地，必须通过具体的工程来实现，而工程实现的质量决定了项目的最终效果。如果空有高超的设计图纸，而没有高质量的施工和合适的材料，高楼大厦是建不起来的。IndexR在工程上最求极致的性能，但又不失灵活的扩展性。
使用直接内存(Direct Memory))。IndexR主要使用Java8编写，而Java的堆内存(Heap)与垃圾回收(GC)的模式在大数据运算场景下面临比较大的挑战。在需要使用较大内存(超过32G)以及数据更新频繁时，JVM的GC 问题比较明显，容易造成性能不稳定，并且对象实例的内存模型通常很浪费内存。我们在IndexR项目中把所有的存储数据和运算临时数据存放于堆外，手动管理内存申请释放。这样提高了代码复杂度，但相比于传统的堆内存模式，节省了超过1/2内存，并且没有了GC代价，涉及大量数据的赋值操作通常可以使用内存拷贝，节省大量CPU循环。
充分利用现代CPU能力。IndexR的堆外内存模型对于充分发掘硬件潜能非常有益，它们通常是连续的内存块，没有类指针跳转，没有虚函数损耗，CPU寄存器和多级缓存都可以充分利用，而且对于使用vector processor非常便利，没有结构转换开销。
避免随机读取。通常磁盘的特点是连续读取非常快，因而Kafka可以使用磁盘做消息队列；而随机读取相对很慢，故传统数据库的瓶颈一般在IO。IndexR的索引方式对磁盘连续读取友好，并且它会对数据进行整理从而更加内聚。我们还特别对文件读取方式进行了细致的优化。
优化线程、IO调度。在任务非常繁忙的时候，CPU争抢带来的线程切换的开销变的不可忽视。并且由于数据库环境的特殊性，在做繁忙CPU任务的同时，还会进行网络、IO操作。如何做任务调度，合理安排线程数量和任务，对整体性能影响比较大。有时候单线程比多线程效率更高，并且更省资源。
关键性能点使用C++实现。它在同时涉及内存操作和复杂CPU运算场景时，运行效率优势明显。我们把关键的性能点，比如压缩算法，使用C++实现。
工具选型
IndexR是一个新的工具，如果你的项目有以下需求，或者之前已经有一些选型但是无法满足需求，可以考虑使用IndexR。
经典场景：
需要在海量数据之上做快速的统计分析查询。
要求入库速度非常快，并且需要实时分析。
存放超大量历史明细数据库。比如网站浏览信息，交易信息，安保数据，电力行业数据，物联网设备采集数据等。这类数据通常量非常大，数据内容复杂，存放时间比较久，且希望在需要时可以比较快速的根据各种条件做明细查询，或者在一定范围内做复杂的分析。这种情况下可以充分发挥IndexR的低成本，可扩展，适合超大数据集的优势。
典型选型：
使用Mysql，PostgreSQL等关系型数据库，不仅用于业务查询(OLTP)，也做统计分析，一般是在现有业务数据库上直接做一些分析需求。这种方式在数据量增长之后就会遇到性能问题，特别是分析查询会对业务查询产生极大影响。可以考虑把数据导入IndexR做分析，即把业务数据库和分析数据库分开。
ES，Solr等全文搜索数据库用于统计分析场景。这类数据库最大的特点是使用了倒排索引解决索引问题。对于统计分析场景通常没有特别优化，在大数据量场景下内存和磁盘压力比较大。如果遇到性能问题，或者数据量撑不住了，可以考虑使用IndexR。
Druid，Pinot等所谓时序数据库。在查询条件命中大量数据情况下可能会有性能问题，而且排序、聚合等能力普遍不太好，从我们的使用经验来看运维比较困难，灵活性和扩展性不够，比如缺乏Join、子查询等。在保存大量历史数据情况下需要的硬件资源相对昂贵。这种场景下可以考虑使用IndexR直接替换，不用担心业务实现问题。
Infobright，ClickHose等列式数据库。列式数据库本身非常适合于OLAP场景，IndexR也属于列式数据库。最大的区别在于IndexR是基于Hadoop生态的。
离线预聚合，建Cube，结果数据存放于HBase等KV数据库，如Kylin等。这种方式在只有多维分析场景且查询比较简单的情况下非常有效。问题就在 于灵活性不足(flexibility)，无法探索式分析，以及更复杂的分析需求。IndexR可以通过表配置达到预聚合的效果，并且聚合是实时，没有延迟的；可以保留原始数据或者高维度数据，通过表路由决定具体的查询表。
为了解决大数据量的即时分析问题，上层使用Impala，Presto，SparkSQL，Drill等计算引擎来做查询，存储层使用开源数据格式比如Parquet，基于Hadoop生态。这类架构和IndexR很相似。IndexR的优势在于更有效的索引设计，更好的性能，并且支持实时入库，秒级延迟。我们在相同环境下与Parquet格式做过查询性能对比，IndexR的查询速度提升在3～8倍以上。之后IndexR经历了很大的性能优化，估计会有更好的表现。
Kudu，Phoenix等既支持OLTP场景，又为OLAP场景优化等开源产品。通常很难两者兼顾，建议分成实时库和历史库，针对不同数据特点采用不用的存储方案。
内存数据库。
飞科技大数据平台组对于以上提到的大部分技术选型有着丰富的经验，即这些工具我们或者在生成环境中使用过，或者有过深入的调研和测试，这也促使了IndexR的诞生。
本发明的有益效果是：
1、快速统计分析查询：IndexR使用列式存储，对于超大量数据集，它提供高效的索引，通过过滤掉无关数据，快速定位有效数据，减少IO。它使用了优秀的Apach Drill作为上层查询引擎。特别适合于ad-hoc的OLAP查询。
2、数据实时导入：IndexR支持超高速实时导入数据。数据一到达IndexR节点，立刻可以被查询到。实时数据和历史数据可以一起查，再也不需要考虑所谓T+1架构。且区分于其他有类似功能的***，IndexR永远不会主动丢弃任何数据。
3、高效硬件利用率：相较于其他***，IndexR可以跑在廉价的机器上。 不需要昂贵的SSD硬盘，高端CPU，甚至小型机，你就可以获得非常好的性能，虽然在上面跑会更加快。虽然跑在JVM上，它手动管理几乎所有的内存，使用经过高度设计、紧凑的数据结构。
4、集群高可用，易扩展，易管理，简单：分布式***发展到现在，高可用和扩展性已经是标配了。IndexR的特点是结构非常简单可靠，且只有极少的必须配置项。
5、与Hadoop生态的深度整合：IndexR把数据存放于HDFS。这意味着你可以使用MapReduce，或者任何Hadoop工具处理这些文件。我们目前提供了Hive插件，用于各种ETL相关工作，或者跑离线任务。对接Spark的工作正在进行，将被使用于数据挖掘以及机器学习。
6、高度压缩的数据格式：IndexR以列式存储，并提供超高的压缩率，可以显著的减少IO以及网络开销。
7、方便的数据管理：IndexR可以方便的导入、删除数据，并且支持修改表Schema，如对列的添加、删除、修改等。
对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神或基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。
此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (2)

1.一种IndexR实时数据分析库,其特征在于，包括：***构架、部署架构、存储结构和实时模块；
所述***构架负责文件存储格式，包括索引和数据，数据的实时导入、表定义操作，查询优化，以及数据缓存等。分布式计算框架(Drill/Spark)负责在IndexR数据上的具体查询操作，以及其他计算任务，Hadoop以及周边工具-提供分布式文件存储，离线批量计算，离线数据管理，以及各种离线ETL任务，IndexR与Hadoop完美结合，可以作为一个高度压缩、自带索引的文件格式，兼容Hive的所有操作，Kafka-消息队列，数据经过kafka流入IndexR，Zookeeper-集群状态管理；
所述部署架构在Hadoop***的环境下，在现有集群上部署IndexR通常可以在半小时之内完成，只需要在所有Hadoop的DataNode(和NameNode)节点上部署一份带有IndexR插件的Drill节点，只有几项必须配置项，并且所有节点的配置都是一样的，IndexR的服务逻辑嵌入了Drillbit进程，无需额外启动服务；
所述存储结构以列式存储数据，并分片存储，分片称为Segment，每一个Segment都是自解释的，包括Schema，数据以及索引，Segment通常是固定不变的，这极大简化了数据管理，便于分布式处理；
所述实时模块可以极高效率的导入实时数据，并且数据可以立刻被查询，可以多节点同时导入，实时导入的数据叫做Realtime Segment，在达到一定阀值后，IndexR会将它们合并成历史Segment，并上传到HDFS，之后数据就可以被离线分析工具所使用和管理，Realtime Segment具体实现参考了LSM-Tree，通过在磁盘上的commitlog文件保存所有更新操作，最新数据放在内存中以快速入库和索引，周期性将内存数据dump到磁盘，IndexR进程可以随时被重启，或者直接杀死，不用担心数据丢失。
2.根据权利要求1所述的一种IndexR实时数据分析库，其特征在于， 所述IndexR实时数据分析库的测试硬件标准包括以下部分：
1)每个节点12核(24线程)CPU,60G内存,SATA接口7200转机械硬盘，
2)实时导入速度：超过30K消息/秒/节点/表，即，假如有10个节点，每个节点拥有10个表，可以在一秒钟之内消费3M条消息，一天轻松实时导入千亿数据，
3)扫描速度：通常一行内通常会读取多个字段，在现代CPU和计算框架的帮助下，可以同时对多个字段进行运算，从而获得比以下数据更好的性能，
4)冷数据-30M字段/秒/节点，
5)热数据-100M字段/秒/节点，
6)扫描速度约为Parquet的2.5倍，
7)OLAP查询：在我们的实际业务中，我们发现95％的查询延时在3s内，数据量规模为千亿级别，20个节点，
8)相同的Drill环境下约为Parquet格式的3～8倍，
9)压缩率：在我们的实际业务中，相对于CSV格式，压缩率约为10:1，有些表甚至达到20:1，
10)压缩后大小约为ORC格式的75％。
CN201710355812.1A 2017-05-16 2017-05-16 一种IndexR实时数据分析库 Pending CN107133342A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710355812.1A CN107133342A (zh) 2017-05-16 2017-05-16 一种IndexR实时数据分析库

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710355812.1A CN107133342A (zh) 2017-05-16 2017-05-16 一种IndexR实时数据分析库

Publications (1)

Publication Number Publication Date
CN107133342A true CN107133342A (zh) 2017-09-05

Family

ID=59732495

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710355812.1A Pending CN107133342A (zh) 2017-05-16 2017-05-16 一种IndexR实时数据分析库

Country Status (1)

Country Link
CN (1) CN107133342A (zh)

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107784098A (zh) * 2017-10-24 2018-03-09 百味云科技股份有限公司 实时数据仓库平台
CN107943979A (zh) * 2017-11-29 2018-04-20 山东鲁能软件技术有限公司 一种数据库之间数据的准实时同步方法及装置
CN108549696A (zh) * 2018-04-16 2018-09-18 安徽工业大学 一种基于内存计算的时间序列数据相似性查询方法
CN108549683A (zh) * 2018-04-03 2018-09-18 联想(北京)有限公司 数据查询方法以及***
CN108875042A (zh) * 2018-06-27 2018-11-23 中国农业银行股份有限公司 一种混合联机分析处理***及数据查询方法
CN109101516A (zh) * 2017-11-30 2018-12-28 新华三大数据技术有限公司 一种数据查询方法和服务器
CN109726024A (zh) * 2018-12-28 2019-05-07 北京爱奇艺科技有限公司 一种消息延时投递方法、装置及设备
CN109840196A (zh) * 2017-11-29 2019-06-04 北京京东尚科信息技术有限公司 测试业务逻辑的方法和装置
CN110321388A (zh) * 2019-02-26 2019-10-11 南威软件股份有限公司 一种基于Greenplum的快速排序查询方法及***
CN110489476A (zh) * 2019-08-22 2019-11-22 金瓜子科技发展（北京）有限公司 数据处理方法、***及服务器
CN110674197A (zh) * 2019-10-09 2020-01-10 云南电网有限责任公司信息中心 一种业务操作的可视化配置与抓取***
CN110795428A (zh) * 2019-10-10 2020-02-14 中盈优创资讯科技有限公司 应用于工业物联网的时序数据存储方法和时序数据库
CN110990400A (zh) * 2019-11-20 2020-04-10 浙江大搜车软件技术有限公司 数据库查询方法、装置、计算机设备和存储介质
CN111026918A (zh) * 2019-11-12 2020-04-17 上海麦克风文化传媒有限公司 一种温数据大规模分析架构
CN111324670A (zh) * 2020-02-27 2020-06-23 中国邮政储蓄银行股份有限公司 基于HDFS与Vertica的计算存储分离部署的方法及***
CN111813777A (zh) * 2020-07-02 2020-10-23 上海微亿智造科技有限公司 Olap自动创建并写入mq数据的方法及***
CN111858654A (zh) * 2020-07-21 2020-10-30 威讯柏睿数据科技(北京)有限公司 一种基于内存计算的数据查询加速方法和设备
CN112148719A (zh) * 2020-09-11 2020-12-29 苏宁云计算有限公司 基于olap预计算模型的数据加工查询方法及装置
CN112559459A (zh) * 2020-12-15 2021-03-26 跬云(上海)信息科技有限公司 一种基于云计算的自适应存储分层***及方法
CN113157754A (zh) * 2021-03-22 2021-07-23 招银云创信息技术有限公司 流程表单数据展示方法、装置、设备及存储介质
CN113568936A (zh) * 2021-07-30 2021-10-29 多点生活(成都)科技有限公司 实时流数据存储方法、装置、终端设备
CN114077581A (zh) * 2021-11-24 2022-02-22 北京白板科技有限公司 一种基于数据汇聚存储方式的数据库

Cited By (32)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107784098A (zh) * 2017-10-24 2018-03-09 百味云科技股份有限公司 实时数据仓库平台
CN107943979A (zh) * 2017-11-29 2018-04-20 山东鲁能软件技术有限公司 一种数据库之间数据的准实时同步方法及装置
CN109840196A (zh) * 2017-11-29 2019-06-04 北京京东尚科信息技术有限公司 测试业务逻辑的方法和装置
CN109101516A (zh) * 2017-11-30 2018-12-28 新华三大数据技术有限公司 一种数据查询方法和服务器
WO2019105420A1 (zh) * 2017-11-30 2019-06-06 新华三大数据技术有限公司 数据查询
CN109101516B (zh) * 2017-11-30 2019-09-17 新华三大数据技术有限公司 一种数据查询方法和服务器
US11269881B2 (en) 2017-11-30 2022-03-08 New H3C Big Data Technologies Co., Ltd. Data query
CN108549683A (zh) * 2018-04-03 2018-09-18 联想(北京)有限公司 数据查询方法以及***
CN108549696A (zh) * 2018-04-16 2018-09-18 安徽工业大学 一种基于内存计算的时间序列数据相似性查询方法
CN108875042A (zh) * 2018-06-27 2018-11-23 中国农业银行股份有限公司 一种混合联机分析处理***及数据查询方法
CN108875042B (zh) * 2018-06-27 2021-06-08 中国农业银行股份有限公司 一种混合联机分析处理***及数据查询方法
CN109726024A (zh) * 2018-12-28 2019-05-07 北京爱奇艺科技有限公司 一种消息延时投递方法、装置及设备
CN110321388A (zh) * 2019-02-26 2019-10-11 南威软件股份有限公司 一种基于Greenplum的快速排序查询方法及***
CN110321388B (zh) * 2019-02-26 2021-07-02 南威软件股份有限公司 一种基于Greenplum的快速排序查询方法及***
CN110489476A (zh) * 2019-08-22 2019-11-22 金瓜子科技发展（北京）有限公司 数据处理方法、***及服务器
CN110674197A (zh) * 2019-10-09 2020-01-10 云南电网有限责任公司信息中心 一种业务操作的可视化配置与抓取***
CN110795428A (zh) * 2019-10-10 2020-02-14 中盈优创资讯科技有限公司 应用于工业物联网的时序数据存储方法和时序数据库
CN111026918A (zh) * 2019-11-12 2020-04-17 上海麦克风文化传媒有限公司 一种温数据大规模分析架构
CN110990400A (zh) * 2019-11-20 2020-04-10 浙江大搜车软件技术有限公司 数据库查询方法、装置、计算机设备和存储介质
CN110990400B (zh) * 2019-11-20 2023-07-04 浙江大搜车软件技术有限公司 数据库查询方法、装置、计算机设备和存储介质
CN111324670A (zh) * 2020-02-27 2020-06-23 中国邮政储蓄银行股份有限公司 基于HDFS与Vertica的计算存储分离部署的方法及***
CN111813777B (zh) * 2020-07-02 2021-04-06 上海微亿智造科技有限公司 Olap自动创建并写入mq数据的方法及***
CN111813777A (zh) * 2020-07-02 2020-10-23 上海微亿智造科技有限公司 Olap自动创建并写入mq数据的方法及***
CN111858654A (zh) * 2020-07-21 2020-10-30 威讯柏睿数据科技(北京)有限公司 一种基于内存计算的数据查询加速方法和设备
CN112148719A (zh) * 2020-09-11 2020-12-29 苏宁云计算有限公司 基于olap预计算模型的数据加工查询方法及装置
CN112148719B (zh) * 2020-09-11 2022-11-18 苏宁云计算有限公司 基于olap预计算模型的数据加工查询方法及装置
CN112559459A (zh) * 2020-12-15 2021-03-26 跬云(上海)信息科技有限公司 一种基于云计算的自适应存储分层***及方法
CN112559459B (zh) * 2020-12-15 2024-02-13 跬云(上海)信息科技有限公司 一种基于云计算的自适应存储分层***及方法
CN113157754A (zh) * 2021-03-22 2021-07-23 招银云创信息技术有限公司 流程表单数据展示方法、装置、设备及存储介质
CN113568936A (zh) * 2021-07-30 2021-10-29 多点生活(成都)科技有限公司 实时流数据存储方法、装置、终端设备
CN113568936B (zh) * 2021-07-30 2023-06-13 多点生活(成都)科技有限公司 实时流数据存储方法、装置、终端设备
CN114077581A (zh) * 2021-11-24 2022-02-22 北京白板科技有限公司 一种基于数据汇聚存储方式的数据库

Similar Documents

Publication Publication Date Title
CN107133342A (zh) 一种IndexR实时数据分析库
US10691646B2 (en) Split elimination in mapreduce systems
US10860598B2 (en) Systems and methods for interest-driven business intelligence systems including event-oriented data
CN106844703B (zh) 一种面向数据库一体机的内存数据仓库查询处理实现方法
CN102737033B (zh) 数据处理设备及其数据处理方法
CN102521405B (zh) 支持高速加载的海量结构化数据存储、查询方法和***
CN105989129B (zh) 实时数据统计方法和装置
JP5580827B2 (ja) 列ベースデータエンコードされた構造のクエリに対する効率的な大規模フィルタリングおよび／または並べ替え
CN107038162A (zh) 基于数据库日志的实时数据查询方法和***
CN103678665A (zh) 一种基于数据仓库的异构大数据整合方法和***
CN102521406A (zh) 海量结构化数据复杂查询任务的分布式查询方法和***
CN107533551A (zh) 数据块级别的大数据统计
CN106030573A (zh) 半结构化数据作为第一等级数据库元素的实现
CN104850572A (zh) HBase非主键索引构建与查询方法及其***
CN105139281A (zh) 一种电力营销大数据的处理方法及***
CN101996102A (zh) 数据关联规则挖掘实现方法与***
US20150081353A1 (en) Systems and Methods for Interest-Driven Business Intelligence Systems Including Segment Data
US10977280B2 (en) Systems and methods for memory optimization interest-driven business intelligence systems
Buddhika et al. Synopsis: A distributed sketch over voluminous spatiotemporal observational streams
CN102479217A (zh) 一种分布式数据仓库中实现计算均衡的方法及装置
Zhao et al. A practice of TPC-DS multidimensional implementation on NoSQL database systems
Chambi et al. Optimizing druid with roaring bitmaps
Matei et al. Column-oriented databases, an alternative for analytical environment
Martin et al. Multi-temperate logical data warehouse design for large-scale healthcare data
CN110597929A (zh) 一种基于MapReduce的并行数据立方构建方法

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20170905

RJ01 Rejection of invention patent application after publication