CDH／HDP国产替换之路

CDP/开源封封装产品装产品

CMP封装产品

架构

流转链路与数据一致性

•链路冗长，使用散装架构，开发运维成本高，数据需要导入导出，数据一致性难以保证。

•链路简单，统一架构，一体化建设，开发运维成本低。统一的计算引擎，避免数据导入导出。统一的分布式存储管理系统:有效保障数据一致性

跨库关联分析

•跨库关联的复杂分析场景需要数据的导入导出，过程繁琐，分析延迟高。

•通过统一SQL编译器、统一计算引擎，统一元数据的湖仓一体能力即可支持Inceptor, ArgoDB，Scope等跨库关联复杂分析场景，简单易用，时效性高。

国产信创

兼容性

•CDH/HDP/CDP以及开源相关组件没有对国产生态做过适配，兼容性差

•适配华为&飞腾ARM架构、龙芯MIPS架构、神威Alpha架构

•适配中标麒麟、银河麒麟、UOS等

•支持X86与ARM架构混合部署

•与符合信创的国产软硬件兼容性好，且拿到相关互认证书

•满足信创验收要求

数据湖能力

一体多模数据支持

•Hive、Impala等CDP组件在构建数据湖应用的时候没有统一入口，对于不同类型的数据需要开发不同的作业，开发复杂。

•在SQL编译器层支持多模数据的存储，对外提供统一SQL编程模型，构建数据湖应用方便快速。

存储能力

•HDFS分布式文件系统在数据湖应用中存在技术上的局限性，写入性能差，且因为小文件和Block Report等问题不能管理数据湖海量文件

•自研的TDFS分布式文件系统使用更先进的元数据管理架构，支持的文件数能够达到百亿级别。

使用分布式一致性协议算法，提高写入数据可靠性的同时写入性能也得到了提升

数据治理

•Atlas等开源的数据血缘、数据治理工具在治理功能和粒度上支持有限，且不支持数据标准、数据质量、数据发布等维度的治理能力

•自研的TDS产品在数据治理上的功能得到了增强，支持实时更新血缘、字段级别的血缘分析

•提供数据质量、数据标准、数据商城、数据发布等模块，加强对数据湖中数据的治理能力

数据仓库能力

SQL编译技术

•Hive、SparkSQL、ImpalaSQL等使SQL无统一规范，对ANSI SQL标准和传统关系型数据库方言支持度较低。企业业务迁移成本高

•支持的存储过程编译技术主要是HPL兼容的语法比较有限

•支持SQL 2003标准与存储过程，降低开发难度；兼容Teradata，Oracle，DB2等方言，方便业务平滑迁移，降低迁移成本

•提供存储过程支持，降低开发大型复杂数据业务系统的技术门槛

SQL优化技术

•Hive、Impala等基于规则和代价的优化器不够丰富，不能满足不同场景的使用

•改进了代价CBO优化器，丰富了RBO的优化规则，适用场景更广泛

•实现多模优化器，针对不同数据模型和使用场景能够自动适配优化算法

分布式一致性

•HDFS、ElasticSearch等开源产品使用多机器间数据复制方式，可靠性差，且写入性能较差

•TDFS、ArgoDB、Scope等产品广泛使用分布式一致性协议保障数据的一致性，提高了数据可靠性、系统可用性以及扩展性

分布式事务

•Hive、Spark等在2018年之后才开始陆续支持事务能力，但是隔离级别支持一般，且事务并发不高

•Inceptor在2015年就已经支持分布式事务，且隔离级别支持丰富，支持乐观和悲观的并发控制策略，支持全局一致性快照，能够快速回滚数据，具备技术领先性

性能指标

•Hive性能弱，难以满足企业高性能要求

•Inceptor 全球首个通过TPCDS测试，TPC-DS查询性能是Hive的7X~25X

数据集市能力

索引支持

•Impala不支持二级索引，难以满足企业灵活查询性能要求

•支持二级索引、全文索引等多种索引类型，提高查询速度，满足企业灵活查询性能要求

OLAP高并发

•OLAP并发度低，水平扩展能力有限，难以满足OLAP高并发需求

•支持1000+用户同时在线分析，且并发能力可随节点数量增加

服务开放能力

•集群无法对大规模业务人员开放其查询分析服务能力

•数据服务对外开放，赋能业务人员自助式查询分析。

性能指标

•Impala TPC-H OLAP查询分析性能弱。

•ArgoDB TDP-H查询分析性能是Impala的2X~6X

实时计算能力

实时数据入库分析能力

•延迟高，难以满足企业复杂场景的落地即分析场景

•ArgoDB与Slipstream无缝衔接，落地即分析，秒级响应

实时流SQL开发便捷性

•Flink 以API开发为主，SQL支持有限，对企业的实时流开发门槛要求高，运维复杂

•基于SQL开发流任务，支持通过SQL方式实现复杂事件处理，实现复杂业务逻辑。SQL代码可移植性高，降低企业开发运维门槛

全文检索能力

功能/性能差异

•Solr和ES只支持实时写入，不支持批量加载，入库过程中需要生成索引文件，资源开销大，入库性能不高

•Scope支持大批量离线数据加载，并且多副本下，只会生成一份索引文件，性能更好

单机容量

•ES硬件资源利用率低，单节点单实例存储约10TB

•Scope为企业节省IT硬件成本投入，单节点单实例存储约50TB

故障恢复时间

•ES故障恢复时间久，恢复时间为小时/天级别

•Scope恢复时间短，保证业务的连续性分钟级别(<10min)

高并发读写

跨库分析

•Phoenix on Hbase的方案在异构数据分析上存在缺陷，包括流表与Hbase关联分析等支持不够

•Inceptor中独创的HyperDrive表和GLKJoin技术，支持OLAP和实时数仓场景下，跨库的关联分析

图计算和分析能力

数据联邦能力

•Neo4j不支持跨数据库查询，不支持异构模型数据关联查询

•支持多个图之间的跨数据库查询能力，并且与Inceptor中结构化数据可以关联查询

扩展性和可靠性

•Neo4j 还是集中式系统，不支持分布式图算法，扩展能力差

•可扩展性强，数据多副本分布式存储，支持分布式图算法

时空轨迹分析

轨迹分析能力

•PostGIS等开源组件暂未提供相关轨迹数据的分析文档

•Spacture支持原生轨迹数据类型，融合空间、时间、属性等多维数据，提供特定的存储格式

•支持常见的轨迹处理算法，兼容OGC Moving Features标准分析函数

时空索引

•PostGIS等开源组件暂未提供相关时空索引的分析文档

•Spacture提供多种时空索引，能够加速空间查询和时空查询

时序数据分析

标准SQL支持程度

•使用Hbase和Phoenix组件结合做时序数据的分析，只支持一种数据类型，且不支持自定义函数

•TimeLyre支持标准的SQL查询语言，且支持多达15种数据类型

数据处理分析能力

•Phoenix和InfluxDB对分析函数的支持不够，且对数据关联分析能力弱