一、背景引见
电商是移动互联网时代最关键的业务方式之一，目前干流的业务外形是B2C。在这个群雄逐鹿的年代，除了淘宝、京东、拼多多等头部电商以外，还生动着泛滥的中小规模电商平台。笔者所在公司的电商APP就是其中一个，目前注册用户超越2亿，月生动用户凑近2000万。
电商平台以APP作为载体，最关键的数据就是以订单为**的结构化数据和以日志流为**的半结构化数据，这也互联网业务最典型的运行场景。
订单业务包含下单、支付、发货、物流、评估、退货等业务流程，然而都可以经过order_id串联起来，数据保管在相关型数据库中。咱们这边经过MySQL分库分表打算承载订单相关的业务数据，目前积攒了自系统上线以来的1.5亿订单，目前日增长订复数为10万左右。
点击流数据则是APP上一切用户的操作行为埋点记载数据，是源源始终发生的半结构化数据。由于前期对APP埋点和日志流数据做过控制，所以目前数据格局比拟规范，数据输入也比拟稳固。点击流数据包含30+固定字段和一个扩大json字段组成，固定字段包含设施消息、会话消息、用户消息、网络消息、埋点编码等，扩大json字段内容则依据实践的页面状况生成，不同的页面或许埋点对应的扩大消息不同。点击流数据每日增量在10亿左右，ORC格局占用存储在1.16T左右。
笔者接手电商数仓名目时，恰逢公司推动数据控制名目，预备重建电商数仓。在我接手之前，公司数仓依照不同的业务模块划分不同的数据集市，电商业务有专门的电商集市，然而外部数据加工逻辑比拟复杂、没有明白的数据分层和明晰的数据处置逻辑，基本上是面向需求开发，重复逻辑比拟多，数据分歧性差。我接手电商数仓，依照规范的数仓分层重构了电商数仓，同步产出实时数据，满足了实时数据看板、自助剖析数据集、双十一大屏、每日业绩播报等多个数据运行。恰逢最近阅历了新一轮618大促的考验，因此予以总结，构成阅历分享给其余数仓开发的同行。
二、技术选型
数据中台作为公司一致的数据平台，承载着全公司大数据集群平台的基础才干，包含离线集群Hive、Hdfs、Yarn、Spark和Presto，实时集群Flink、ClickHouse，以及相关工具如自助剖析工具QuickBI、调度系统、画像系统、监控诉警系统、基于Zepplin的一致数据查问平台等。
公司的离线大数据有多台主机，基于Yarn框架启动一致的资源控制，计算资源分为离线计算、实时计算、实时查问等不同的资源队列，其中离线计算目前以Spark为主，局部高优先级的义务或许时效性较高的义务曾经切换到外部变革过的Presto计算引擎。目前公司大数据平台上运转的离线数据处置义务关键分为MySQL2Hive数据采集、Hive2Hive数据加工、Hive2MySQL数据散发和Hive2CK数据散发四种类型，义务数区分是1.0W、1.2W、6K、500。
实时数据处置分为实时数据采集、实时数据计算和实时数据查问三个方面。实时数据采集经过智能化性能，间接写入Hive数仓的rt_ods库，目前有凑近1000张表；实时数据计算目前关键是交给Flink成功，目前线上运转的大概500个义务；实时数据查问包含MySQL和Clickhouse，接入数据量不确定。
早期的数据结果查问都是基于MySQL分库分表来成功，2021年底开局引入ClickHouse作为交互式查问引擎。决定ClickHouse的要素关键是由于查问性能快、查问稳固，只需设置正当的分区，单表数据量可以到达百亿甚至千亿级别。目前公司在多个业务线引入了ClickHouse集群，在大数据线，ClickHouse集群关键替代MySQL分库分表打算，来成功数据的极速实时查问。大数据线的ClickHouse集群由28台节点组成14主*2正本集群，每台节点84核CPU+256G内存。
三、电商离线数仓
离线数仓总体上分为三层，即ODS、DW和DM层。
ODS层也叫数据采集层，数据起源于源系统，保管源系统概貌，为抢先逻辑层提供原始数据，隔离对源系统的影响。咱们这边分为SNAP、ODS、History三个数据库，区分寄存快照数据、增量追加数据和全量历史快照数据。关于全量采集的数据，间接抽取到SNAP库；关于增量采集的数据自动会依照修正日期抽取最近一天新增或许修正的数据，按日分区存入ODS库，而后依照库表主键兼并去重写入SNAP库；关于有保管历史快照数据需求的表，咱们还会将历史快照复制一份按日保管到History库。
DW层也叫数据仓库层，咱们分为DIM、DWD和DWS三个库。
DIM库用于保管公共维度数据，例如商品、商户、供应商、用户基础消息等。
DWS层也叫轻度汇总层，数据关键起源于DWD层，以目的加工为**，依照维度建模的思绪，加工分歧性目的和分歧性维度。DWS层也包含宽表层，所以DWS通常可以划分为两步启动数据加工，第一步聚焦于目的计算，一致加工业务目的，第二步关联维度消息，构成大宽表。有时刻会把大宽表叫做DWT层，然而咱们这边没有严厉的区分。DWS层的宽表通常都是同步到ClickHouse，用于自助剖析或许固定报表查问。
DM层也叫集市层或许数据运行层，数据起源关键来自DWS层，可按业务和运行主题分类，满足特定运行查问。DM数据关键保管在Hive数仓的DM库和对接数据运行的MySQL库、ClickHouse库。关于数据量超越千万的明细数据剖析，数据会间接同步到ClickHouse库；关于百万级以下的数据，则间接保管到MySQL数据库。此外，还有运行层的用户画像数据保管在HBase。DM层的大局部数据间接起源于DWS，也有有些数据是在DWS层的基础上启动二次加工，包含繁难汇总、计算同环比、多维汇总等，先写入DM层，再同步到外部数据库。
详细到电商数仓模块，咱们关键构建了以下几个模型表：
当然，实践名目上设计和树立的模型远不止这几张表，咱们还针对售后订单创立独自的表、依据埋点业务的运营位曝光和点击计算下单成交率、依据商品的介绍计算介绍模型的有效性，依据搜查的结果及点击计算不同入口的搜查成交状况等等。然而名目关键的**的订单和点击数据流就是这10张表，其中商品标签表和用户标签表还作为电商业务商品画像和用户画像的基础数据起源表，提供画像标签的一致进口。
四、电商实时数仓
在离线数据加工的基础上，业务用户提进去实时数据的需求，关键包含企业微信业绩播报机器人和实时买卖看板、实时成交监控、双十一大屏等。
最开局开发的是企业微信业绩播报机器人需求，每小时汇总一次性当日成交数据，并和历史成交启动对比，将数据写入MySQL，再由Java程序读取数据，依照指定的数据格局播报到企业微信群。
针对这个业务场景，咱们依照典型的Lambda架构设计，复用公司的Kafka写入Hive数据组件，经过性能化成功关键业务数据智能同步到Hive的rt_ods数据库。而后咱们经过Presto计算引擎简化订单业务的加工逻辑，只计算关键成交目的，加工到DWS，并和离线数据加工的DWS层数据启动兼并去重，保管最近13个月的订单明细。点击流数据不需去重，只保管当日、上月环期和去年同期三个日期的明细数据，并加工好关键目的，保管明细数据。最后一步是加工计算本期、同期、环期的不同目的，并区分依照商品维度和用户维度启动数据汇总，写入MySQL供JAVA运行查问。
将实时播报义务串联成上班流，依照一小时一次性的频率口头，截图如下：
实时播报满足了业务用户跟踪业绩停顿的需求，然而时效性比拟差，无法满足实时成交监控、实时看板和大促大屏的需求，于是咱们又进一步开发了新的实时链路，即Flink实时链路。
Flink实时链路关键由两个FlinkSQL义务组成，区分读取订单CDC日志流数据和点击埋点日志流数据，在启动繁难的数据转换关联离线加工的商品消息表（定时同步到HBase，全量1600万）失掉商品维度而后写入Clickhouse。在电商业务的多维剖析中，最关键的维度就是商品维度和用户维度，其中商品维度包含商户消息、商品层级消息、商品规格消息、商品业务归属、商品多少钱和进货渠道等，用户维度包含用户注册消息、用户基本属性、用户成交记载和用户衍生标签。在咱们的业务场景中，商品维度是千万级别，用户维度是亿级别，经过测试，在实时点击流中，由于数据流量比拟大，关联用户消息会发生查问超时造成关联不上的场景，由于咱们砍掉了实时数据的用户维度，而决定在ClickHouse启动结果数据查问时再应用Local Join的长处来关联用户维度。实时加工数据在ClickHouse中设置的TTL时期是3天，即仅保管最近三天的实时数据。
Flink实时链路的关键在于ClickHouse,咱们首先将离线加工好的订单宽表、点击流宽表和用户维度消息表在每天跑批成功同步到Clickhouse(其中订单宽表是每日全量同步最近三个人造年的数据，点击流每日增量同步昨日数据)，而后经过一个视图来兼并离线数据和实时数据，对外提供纯实时的分歧性数据结果。
在ClickHouse这边关键处置逻辑有以下几点：
实时数据关联用户维度，取用户注册时期和用户引流渠道等消息。基于ClickHouse的特性，咱们将一切接入的数据自动依照fuid的hash值启动数据分片，确保同一个用户的订单、点击数据和用户维度数据在同一个数据分片上，既可以成功Join的本地化，又能缩小用户数去重计算的资源消耗。为了强迫join在本地启动，咱们会间接在SQL中经常使用右表的local表启动关联。
依据订单和点击流的不同特点，承接订单实时数据的表咱们驳回ReplicatedReplacingMergeTree引擎表，点击流实时数据表则驳回ReplicatedMergeTree引擎表。在经常使用订单实时数据时，咱们会在表名后参与final关键字，确保读取到最新的数据。
Flink实时数据由于实时性高、数据完整度高并且基本上都是明细数据，可以满足各种业务场景，因此在这个数据集基础上咱们创立实时成交看板、实时监控预警和大促大屏等运行需求。下一局部，咱们将详细开展数据运行场景的打算解读。
五、数据运行
在电商数仓的基础上，咱们构建了自助剖析、固定报表、企业微信播报、标签画像、大促大屏等多个数据运行。其中，自助剖析和固定报表都是基于QuickBI成功的，企业微信播报是Java程序，标签画像是自研系统，大促大屏是基于VUE开发的Web运行。
首先是自助剖析，咱们基于订复数据和点击流数据各自构建了一个宽表并同步到ClickHouse，不同的类目运营用户和数据产品都可以基于这两个自主数据构建自己的看板，并分享给其余共事。自助剖析数据集依据用户的需求还在不停的追加字段，成功各种试验场景剖析、用户成交剖析和运营利润剖析。订单宽表曾经扩大到了256个字段，还有不少的用户标签和商品标签封装在fuser_label_json和fsku_label_json两个json字段中。目前，订单自助数据集是经常使用用户最多，运行最宽泛的数据集。
其次是固定报表。在自助剖析数据集的基础上，咱们构建了业务运营日报、KPI进度监控等固定报表，满足控制层运营数据剖析需求。这些报表关键在同环比、日周月年等维度上有一些不凡处置，造成须要做一些定制化开发，所以由咱们数仓成功。
第三个运行是前面提到的企业微信播报，这里只截取其中一局部内容展现。企业微信从早上9点到早晨24点，每小时播报一次性。其中最难的是24点的那次播报，须要做很多不凡处置，才干成功。
第四个运行是标签画像。咱们的标签画像系统允许用户和商品两个维度，在标签系统定义的基础标签都会换成成SparkSQL，加工同步到HBase。衍生标签在基础标签的基础上组合定义，结果数据也会加工到HBase。
标签系统提供单个用户查问标签值和标签组合圈决定户两特性能，前者用于在线接口调用，后者用于导出用户启动剖析或许广告投放。
第五个运行是大促大屏。咱们参照阿里双十一大屏，构建了实时大促大屏，包含实时成交额、大促时期累计成交额、用户分类成交金额及本同期对比、商品分类成交金额及本同期对比。
六、后续演进和流批一体探求
目前第二代实时架构曾经稳固运转了凑近一年时期，做过一些修修补补的微调，然而全体架构没有变化过。这两边遇到的痛点关键有：
面对以上这些疑问，咱们开启了第三代实时架构的设计和验证之路。第三代实时架构咱们引入了基于数据湖的流批一体形式和基于OLAP数据库的多维实时数据查问形式。在数据湖方面，经过多方对比，最终决定Hudi作为数据湖底座，继续沿用Flink启动流式数据加工，决定Doris作为查问引擎。
数据湖技术中Hudi目前最成熟，并且有很多案例分享。
决定Doris的要素有很多，例如允许多表关联、繁难扩大、允许多种数据模型、允许多种索引机制和查问提升，还允许存算分别迁徙历史数据到对象存储，间接查问外部数据源。更详细的关于Doris的特点和经常使用方法，欢迎购置笔者撰写的《Doris实时数仓实战》一书。有了Doris，最大的好处是咱们可以做到维度解耦，可以在查问的时刻才启动关联，一方面缩小了数据存储空间占用，另一方面防止了历史维度不分歧的状况。
总体来说，咱们的第三代实时数仓架构如下：
驳回这种流批一体的架构，可以处置流数据和实时数据切换时成交金额回退的状况；同时保管两边环节数据，可以逻辑变卦造成须要回溯历史重算的状况；引入独立的OLAP查问引擎，可以处置查问的性能疑问和多表关联疑问。
只管现实形态下，一切数据都经过Flink流式启动加工，然而经过调研，咱们还是有一些数据的逻辑无法做到纯流处置，比如用户下单时是新用户还是老用户，所以咱们还是保管了批处置的链路，批处置的数据经过Spark加工成功，间接写入Doris降级主键模型的局部列。
目前这个打算曾阅历证成功，正在启动配套平台的搭建和继续运转监控，估量Q4会片面铺开运行。
相比第一代架构和第二代架构，咱们最大的特点就是用Doris替代了ClickHouse。只管ClickHouse快并且稳固，然而其经常使用门槛较高、扩大性较差，元数据用ZooKeeper控制，在咱们这边曾经到达瓶颈，并且在实时数据高频写入的场景容易发生元数据控制意外造成数据写入失败的状况。
Apache Doris作为一款国产开源数据库软件，不只成功了向量化引擎、存算分别、Merge on Write等前沿性能，还开创性的融合了数据分桶、行列混合存储、多种索引允许、多种数据模型等性能到MPP数据库中，是OLAP和数据仓库畛域徐徐升起的新星。《Doris实时数仓实战》一书囊括Doris的基本操作、架构设计、进阶经常使用、运维控制、拓展运行等各方面的内容，还有少量的详细名目通常阅历剖析，十分适宜想经常使用Doris启动数仓开发的小同伴学习。目前Doris社区十分生动，性能还在始终迭代和演变中，Doris面前的商业公司飞轮科技也给予了Doris开展十分大的助力，Apache Doris必定能成为一款具有世界影响力的开源产品。