HTAP数据库：Hubble实时计算场景的最优选择

实时流式计算适用场最大的特点就是及时，试想以下场景，如果没有流式计算系统，公司会损失多少MONEY：
需要实时异常检测的欺诈/风控等系统
需要实时查看交易额的交易系统
需要实时计算点击/计算分成的广告系统
需要实时更新用户标签的实时用户画像系统
需要实时根据用户喜好推荐商品的实时推荐系统

再试想以上场景，如果核心技术不是国产自研的，信息风险会有多高？

大数据兴起之初，Hadoop并没有给出实时计算解决方案。随后Storm，SparkStreaming，Flink等实时计算框架应运而生。六年前提起实时流式计算大家会想到Storm，三年前提起大家会想到Spark Streaming，去年提起那无疑是Flink了。可见技术世界的迭代是飞速的。

天云数据十余年深耕在分布式计算领域，自主研发的HTAP 数据库HUBBLE 在高并发实时流升级完成了Flink不能处理更多事实表的金融反欺诈和复杂权益服务。

高并发、实时流两个业务场景都对时效性要求特别高，几乎是需要毫秒级返回数据处理结果。Flink是流计算、批处理一体的计算框架，因此其自身不存储业务数据，输入数据需要依赖Kafka、hive等数据源。而Flink接口层只支持SQL，不支持通过JDBC/ODBC协议调用，需要通过Flink特有的API来调用。而且Flink依于计算框架做计算，计算框架本身不会对源数据做任何的优化，因此计算时需要对业务全生命周期的数据进统计分析，时效性可想而知。可以说，Flink自身的架构体系就丢失了很多时效计算的优势。

若将Flink拆开，流计算确实可以支持实时的毫秒级数据处理，但无法满足业务的复杂性；批处理确实可以满足复杂的业务逻辑，但无法满足业务的毫秒级数据处理，而且是不支持并发的。但这不符合市场业务的需求。

**已有产品的不完善、业务市场的迫切需求都给了Hubble数据库走进高并发实时计算的契机。**Hubble利用AI算法的优势，实现Hubble数据库分层设计。在数据存储层上,采用基于切片的行式存储、列式存储和KV存储的混合部署模式，在大规模数据同时支持密集AP计算和TP并发场景下, 基于数据切片的混布存储策略可以弹性适应IO特性，快速做库内转换。Hubble数据库可以通过JDBC/ODBC协议来调用，还可以在数据库上创建索引，在高并发大规模数据下完全可以毫秒级响应，更好的满足业务场景。

Hubble产品在某大型股份制银行信用卡业务系统上线后，经过银行业业务专家进行应用测试：在实时反欺诈场景中：实现了每天千万级交易数据数据实时并发入库；接近100个复杂欺诈规则分析，毫秒级返回分析结果。

值得一提的是，作为原创国产数据库在中国电子工业标准化技术协会信息技术应用创新工作委员会指导的全国首届信创信创产业生态大赛中获得一等奖的荣誉。

当下人类正在进入智能时代，数据已成为新的生产要素，数据库将成为金融、政府、公安、军政等国家命脉行业基础设施的支柱。近些年发生的“微软黑屏门”、“微软操作系统停更”、“棱镜门”等安全事件，敲响了我国 IT 产业的警钟，中国必须建立基于自己的 IT 底层架构和标准。就数据库产品而言，要想从根本上把握住国产数据库的“命门”就要自主设计研发。加持国家政策的支持，信创产业的推动，原创一定是国产数据库的最终宿命。