一种IndexR实时数据分析库制造技术

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

【技术实现步骤摘要】
一种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通常是固定不变的，这极大简化了数据管理，便于分布式处理；所述实时模块可以极高效率的导入实时数据，并且数据可以立刻被查询，可以多节点同时导入，实时导入的数据叫做RealtimeSegment，在达到一定阀值后，IndexR会将它们合并成历史Segment，并上传到HDFS，之后数据就可以被离线分析工具所使用和管理，RealtimeSegment具体实现参考了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使用列式存储，对于超大量数据集，它提供高效的索引，通过过滤掉无本文档来自技高网...

【技术保护点】
一种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进程可以随时被重启，或者直接杀死，不用担心数据丢失。...

【技术特征摘要】
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通常是固定不变的，这极大简化了数据管理，便于分布式处理；所述实时模块可以极高效率的导入实时数据，并且数据可以立刻被查询，可以多节点同时导入，实时导入的数据叫做RealtimeSegment，在达到一定阀值...

【专利技术属性】
技术研发人员：李华煜，韦万，
申请(专利权)人：广州舜飞信息科技有限公司，
类型：发明
国别省市：广东,44