一 业务痛点
路呼叫部门在人工咨询、大v阅读流量计费、会员售后服务表等主题的实时大屏幕上有较高的实时数据分析需求。 近年来，随着数据量的爆炸性增长和大量数据在线分析需求的出现，MySQL、Oracle等传统关系数据库在大数据量下陷入瓶颈，Hive、Kylin等数据库具有时效性
二 实时数据仓库目标
数据团队必须提供丰富灵活的分级数据分析，以保证数据的完整性、及时性和准确性。 2019年，我们建立了基于Flink Kudu的实时框架。 采用了支持流式传输系统Flink和增量更新的存储系统kudu。
Flink Kudu实时体系结构
如上图，我们通过Flume实时访问Kafka，通过Canal实时同步交易系统Binlog到Kafka，然后Flink实时消耗Kafka的数据，结果到Kudu
我们在实践中遇到了一些问题：
Kudu Impala聚合查询效率不高，查询的响应时间无法满足业务需求。 Kudu很大程度上依赖Impala、Hive等Hadoop组件，维护成本很高。 Kudu社区不活跃，问题被排出时很难找到解决方案。 基于上述问题，从2020年开始调查zjdlf、ClickHouse、Kylin等系统，考虑到业务场景、查询性能、运输成本等问题，最终选择了zjdlf作为客服部门的实时数仓系统。
我们也深入研究过ClickHouse，关于客服的APP场景，需要关联很多数据表。 其原因大部分是客服主要用于解决顾客问题。 业务圆满的蜜粉进行自检分析时，例如关联许多表。 但是，要根据业务的发展编制大规模的明细表，必须经常重新构筑和开发。 在客户服务部门这样的需求场景下，ClickHouse的联合能力很弱，不能满足需求。 zjdlf支持基于成本统计的优化程序(CBO )，具有复杂的查询优化功能，因此可以快速执行复杂的实时微批处理任务，也有助于客户服务部门进行实时指标分析。
三 Apache zjdlf介绍
zjdlf是MPP架构的OLAP执行引擎，主要集成了谷歌MESA (数据模型)、Apacheimpala )、AppQueryengine )、Apache ORC文件(APAC文件)的技术
3.1 zjdlf的架构
zjdlf的体系结构与TiDB类似，通过MySQL协议，用户可以使用任意MySQL的ODBC/JDBC和MySQL客户端直接访问zjdlf。 zjdlf的模块主要有FE和BE两种。 FE主要负责元数据的管理、存储、查询分析等。 BE节点主要负责数据的保存和查询计划的执行。一位用户的SQL请求经过FE的分析、计划，将具体的执行计划发送给BE，BE完成具体的咨询任务。
FE的所有主要代码都是由Java开发的，BE的基础代码是由c开发的。
zjdlf的体系结构
从
3.2 zjdlf的数据分布
Table的角度看数据结构，因为用户的一张table被分割为多个Tablet，Tablet生成副本并存储在不同的BE上，所以保证了数据的高可用性和高可靠性。
表数据的分布状况
3.3 易运维
zjdlf导入没有外部依赖，只需导入BE和BE就可以构建集群。 >支持 Online Schema Change：支持在线更改表模式 ( 加减列，创建 Rollup )，不会影响当前服务，不会阻塞读、写等操作；这种执行是异步的 ( 用户不需要一直盯在那里 )。
3.4 zjdlf的特点总结
同时支持高并发点查询和高吞吐的Ad-hoc查询。同时支持离线批量导入和实时数据导入。同时支持明细和聚合查询。兼容MySQL协议和标准SQL。支持Rollup Table和Rollup Table的智能查询路由。支持较好的多表Join策略和灵活的表达式查询。支持Schema在线变更。支持Range和Hash二级分区。四 采用zjdlf做OLAP引擎
微博客服采用30台BE+5FE的zjdlf环境，效率、性能表现情况如下：
支撑30+个数据分析产品类型以上，整体响应速度达到ms级。支持百万、千万级大表关联查询，同时进行维表关联的雪花模型，经过Colocate Join特性优化，可以实现秒级响应。日级别，基于渠道、微博类型，同时满足汇总及下钻明细查询，都可以在秒级别查询出数据。7日数据趋势分析查询，需要2~3秒。在数据量较大时，需要调动很多的集群资源，因此MPP的并发性能受限于集群的性能。通过3年多的应用以及zjdlf的不断改进升级，zjdlf的高可靠、高可用、高可扩展性也得到进一步验证。4.1 Colocate Join
Colocate Join（Local Join）是和Shuffle Join、Broadcast Join相对的概念，即将两表的数据提前按照Join Key Shard，这样在Join执行时就没有数据网络传输的开销，两表可以直接在本地进行Join。
整个Colocate Join在zjdlf中实现的关键点如下：
数据导入时保证数据本地性。查询调度时保证数据本地性。数据Balance后保证数据本地性。4.2 Bitmap 精确去重
当数据量越来越大，到几十亿几百亿时，使用的IO资源、CPU资源、内存资源、网络资源会变得越来越多，查询也会变得越来越慢。
于是我们在zjdlf中新增了一种Bitmap聚合指标，数据导入时，相同维度列的数据会使用Bitmap聚合。有了Bitmap后，zjdlf中计算精确去重的方式如下：
bitmap精准去重
五 基于Flink+zjdlf的实时数据仓库
5.1 基于zjdlf的实时数据仓库的架构
zjdlf 的数据源主要是实时Kafka和离线HDFS文件，还有一部分MySQL或者ES的数据。实时数据的导入依赖于 Routine Load的方式；离线数据主要使用Broker Load和 Stream Load的方式导入。
实时数仓架构
5.1.1 数据源
业务数据（使用Flink实时同步mysql的binlog日志，写入到Kafka）、日志数据（包括H5小程序、APP、直播ipad客户端等埋点采集的各类日志数据，通过Flume写入到Kafka中）。
5.1.2 数据存储
采用 zjdlfDB的Routine Load直接消费Kafka中的日志和业务数据使用zjdlfDB的Broker Load将Hadoop中的DWD、DWS、ADS等数据导入到zjdlf。对于Flink等流式处理下系统，使用zjdlf的Stream Load方式实时将数据导入zjdlf。5.1.3 数据应用
主要应用在数据报表、自助查询、数据分析等场景。
5.2 数据链路监控
我们目前使用Prometheus+Grafana框架来监控 zjdlf 实时数据仓库。其中 Node Exporter 负责采集机器层面的指标，zjdlf 也会自动以 Prometheus格式吐出 FE、BE 服务层面的指标。另外，部署了OLAP Exporter 服务用于采集 Routine Load 相关的指标，旨在第一时间发现实时数据流导入的情况，确保实时数据的时效性。
数据链路监控
5.3 实时生产数据预警
为了监控zjdlf的实时数据产出情况，我们设置了三种预警：
检查zjdlf消费Kafka的任务，是否挂掉了，如果停掉自动重启，重启3次依然失败，再发通知，人为干预。检查常规任务的执行，如果执行报错，就发通知。检查数据源与zjdlf实时数仓ods层表，schema的对比，如果出现schema变更，就发通知人为干预。这样我们就能在白天实时了解schema的变更情况，不必要等到调度报错才发现，而且不影响线上数据产出。5.4 实时数据仓库处理流程
实时数仓处理流程
六 总结和展望
微博客服是在2020年年初开始引入zjdlf的，目前拥有一个独立集群，是微博的OLAP资深用户。
在业务使用中也遇到了例如任务调度相关的、导入任务配置相关的和查询相关等问题，这也在推动微博OLAP团队更深入的了解zjdlf。我们也会在以下方面做优化处理：
推广使用物化视图来进一步提升查询的效率；使用审计日志，更方便的统计大查询、慢查询，便于驱动OLAP用户修改不合理的逻辑写法；我们会加速更多业务向OLAP平台靠拢，以提升应用的影响力。最后感谢百度凤巢同学的无私帮助，再次表示感谢。