本系列文章从生产实践的角度出发，分享一些直播电商实时数仓的建设思路及实践方法，给正在这方面探索的同学们提供一些经验和方法作为参考输入。相信大家对直播电商并不陌生，直播电商是基于直播的基础上诞生的新的商业模式。对于新的商业模式，大家有没有想过，如果自己负责建设公司的直播电商实时数据，会怎么建设呢？本系列文章主要介绍建设直播电商实时数据的关键步骤，如果对同学们有帮助的话，欢迎  点赞 + 收藏~ 1、建设背景 随着公司直播电商业务的发展，业务变得越来越复杂，营销活动也越来越多，在实时数据方面的诉求也越来越紧迫。如何快速有效地获取有价值、稳定的实时数据以帮助业务更好地进行产品迭代和支持运营及策略调整变得越来越重要和紧迫。有鉴于此，实时数仓也相应地提升建设优先级。 2、应用场景 实时OLAP分析：通过实时处理并将数据写入druid和ClickHouse等OLAP分析工具，提升OLAP时效性，使其具有较优的实时数据分析能力。实时数据看板：活动用的实时大屏数据展示需求。实时业务监控：公司核心指标实时监控。如订单指标、买家首页实时监控。实时数据接口服务：通过提供实时数据接口服务的方式，向其他业务线提供数据支持。如为推荐团队提供实时用户特征、直播间特征。实时ETL：实时消费数据进行清洗、转换、结构化处理用于下游计算处理。如为推荐团队提供商品曝光点击样品流、为商业化提供订单数据流。 3、建设目标 前面的建设背景和应用场景解释了建设实时数仓的必要性以及建设的收益点。假设你是该项目的主R，那么，在项目开始之前，你希望项目达到什么样的预期效果呢？我想这会是项目参与者和领导最关心的事情，所以，明确建设目标应该是一个前置动作。下面列举下我在「基于Flink的直播电商实时数仓建设」项目中期望的建设目标，接下来的系列文章也会围绕该建设目标展开叙述。小伙伴们也可以结合公司的建设现状进行借鉴和参考。设计一套体系化建设框架明确所需覆盖的业务过程，完成各层级数据规范化建设将通用的指标进行统一管理设计，明确口径定义、减少冗余开发、提升复用性对外输出可承诺的服务能力与标准 4、技术架构设计 好了，终于到了干货部分了。下面围绕直播电商实时数仓「数仓分层架构」和「技术架构」给大家展开介绍。 乍眼一看，是不是觉得和离线数仓的架构图，相差无几？其实二者差别还是很多的： 与离线数仓相比，实时数仓的层次更少一些从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部，但实时数仓中，app 应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离。应用层少建设的好处：实时处理数据的时候，每建一个层次，数据必然会产生一定的延迟。汇总层少建的好处：在汇总统计的时候，往往为了容忍一部分数据的延迟，可能会人为的制造一些延迟来保证数据的准确。举例，在统计跨天相关的订单事件中的数据时，可能会等到 00:00:05 或者 00:00:10 再统计，确保 00:00 前的数据已经全部接受到位了，再进行统计。所以，汇总层的层次太多的话，就会更大的加重人为造成的数据延迟。与离线数仓相比，实时数仓的数据源存储不同。在建设离线数仓的时候，目前公司整个离线数仓都是建立在 Hive 表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。比如常见的情况下，明细数据或者汇总数据都会存在 Kafka 里面，但是像商家、直播等维度信息需要借助 Hbase，MySQL 或者其他 KV 存储等数据库来进行存储。离线数仓建设的数据域也更丰富些，因为离线数仓的应用和分析场景比实时数仓丰富，所以对于基础数据建设的覆盖度要求比实时数仓要高。结合直直播电商的业务场景看，交易、营销、流量、内容这几个数据域的实时应用场景往往最多，因此建设优先级也往往是最高的。 技术架构图 在计算方面，采用的是Flink SQL+Flink Code的方式，原因是目前公司大数据平台的Flink SQL建设不完善，性能方面和Code相比仍有较大的优化空间。另外，一些复杂的逻辑处理仍需要使用Code。存储方面，采用Redis+Hbase。二者根据吞吐、时延要求按需使用。OLAP方面，采用的是Druid+ClickHouse。 下集预告 下集将分享直播电商实时数仓模型规范和实践细则 关于作者 作者就职于一线互联网公司负责离线、实时数据开发，每天支持处理千亿级别数据。坚持分享数仓理论、大数据开发技术干货，同时欢迎交流，关注公众号 "大数据开发指南"，回复：“联系作者”，添加你身边那位懂数据的朋友。