基于TB级的在线数据，支持缴费帐单明细在线查询。大家都知道，像银行帐单流水一样，查几年的流水是常有的事。
支持的维度查询：帐期、欠费状态、日期范围、费用科目类型、房屋分类、房屋所属项目、关联合同信息、统计列
什么是实时数据实时可以分为：实时采集、实时计算、高性能，底延时的产出结果数据。实时数据指从源系统中实时采集的数据，以及对实时采集的数据进行实时计算直接产生的中间数据或结果数据。实时数据具有时间有效性，随着时间的推移，实时数据会失效。
即时查询系统房屋租赁费用、水电费用、物业管理费用等数据的有效期，一般是不定的，比如办公租赁可能预交费用5年、10年。那么这种数据，对于业务来说，仍然属于线上数据，是不可归档的数据。 长时间无法归档数据，会造成数据越积越大，对于轻量级数据库MySQL来说，是个很大的挑战。就算做好分库分表的准备。条件复杂的查询在聚合的时候也一样容易搞爆内存。何况系统在dal层设计得有所欠缺。为满足流水查询而重构，太得不偿失。从需求来看，不涉及OLTP，只需实现OLAP的解决方案。为了不影响业务系统的改造、数据库重构等方面。决定引入了即时查询系统解决方案。
业务需求转化技术需求：
帐单明细查询可由七十多个条件的随机组合，不能使用类似kylin这样的预处理技术来解决。支持N年范围的在线查询
支持复杂条件查询，如：联合多表，嵌套多层left join
为减少业务侧的sql改动量，需要尽可能的支持标准SQL
频繁变更的业务数据需要实时同步更新
根据以上技术需求点和经过技术的筛选后，最终的技术架构是这样的：
debezuim：业务库使用的是MySql,如果在即时查询系统中查询到的结果与业务系统查询结果同等，需要实时同步业务数据，并实时提供查询能力。debezium是一个低延迟的流式处理工具，能够捕获数据库更改，并且利用Kafka和Kafka Connect记录到kafka中，实现了自己的持久性、可靠性和容错性。
Confluent Platform:Mysql到Kudu，需要稳定高效、可弹性伸缩、在异构数据源之间高速稳定同步能力的数据集成解决方案。基于红火的kafka之上，Kafka Connect是首选。它使得能够快速定义将大量数据集合移入和移出Kafka的连接器变得简单。当在distributed的工作模式下，具有高扩展性，和自动容错机制。confluent platform支持了很多Kafka connect的实现，为后续扩展数据集成服务提供了便利，debezium-connector就是其中之一。除此之外，confluent platform使用Kafka Schema Registry提供Avro序列化支持，为序列化提高了性能。但是Confluent平台的社区版本提供的功能还是比较有限的，比如提供监控界面化管理的confluent center是属于商业版的。为此，我们自研了含有监控运维功能的《数据集成服务》，后续文章将详细介绍并提供在线体验。
Kudu-connector:confluent platform中虽然提供了Kudu Connector (Source and Sink)，但是需要依赖Impala和Hive。而从需求和架构上看，并不需要这些东西，为遵守轻量原则、为避免太多依赖，我们自己实现了轻量级的Kudu-connector(源码地址：https://github.com/dengbp/big-well)。Kudu-Connector需要借助同步管理配置好需要同步的表、同步规则，并创建好目标表，最后创建连接器同步数据。Kudu-Connector暂时没有自动创建目标表能力。下个版本实现。
（网络图）
实时数仓—kudu分布式列式存储，支持行级更新，在OLAP场景下，能快速处理，跟其它大数据框架紧密集成(下文会与Hive Metastore集成，为上层开发访问下层数据的提供统一入口)，本身既具有高可用性，又是Cloudera家族的大数据生态圈成员，为系统自身扩展提供了极大空间。本次需求，主要是同步帐单表数据，和帐单查询信息用到的关联表数据，如：租赁合同数据、项目数据、房屋数据、帐单类型等数据。从业务数据特点分析，需要对帐单表ID和帐单类型做哈希分区，对帐单创建时间做范围分区来创建帐单目标表，这样既可以实现数据分布均匀，又可以在每个分片中保留指定的数据，同时对时间分区继续扩展。其它关联的数据表，根据查询关联特点，同样使用哈希分区和范围分区组合。