百度基于宽表建模的自助查问零碎

frankrose

导读：现今互联网业务疾速迭代的趋向下，从全部多维剖析端到端，用户终究使用和剖析的角度来看，一方面需求有各种各样的数仓以及引擎来提供数据加工和查问计算的才能，此外，数据人员也会关注如何使用这些架构进行数据模型的建立，因而本文提出了基于宽表数据建模的思绪和运用理论，并经过相应的数据平台产品，给用户提供自助可视化数据剖析的产品才能，从而晋升了查问机能，并升高了数据的存储和使用本钱。
本文的分享会环抱上面四点展开：
业务配景面临的问题宽表建立自助可视化平台分享佳宾｜马皓 百度 资深研发工程师
编纂整顿｜每天 golden tech
出品社区｜DataFun
01
业务配景
从传统数据业务来看，经典数仓架构曾经被长时间普遍使用，尤为是数仓分层模型（ODS→DWD→DWS→ADS），基于数仓分层产出各种层级、粒度的数据，来反对下层的剖析报表、Adhoc 查问等，终究反对知足 BI 剖析运用。
1. 传统数仓业务


从上图中能够看出传统分层数仓次要是面向数据研发进程，次要优点在于：
总体查问机能较高出产本钱低保护本钱低2. 以后业务特性和开展趋向
在以后互联网开展趋向下，产品迭代速度愈来愈快，经营流动更为密集，跨业务数据剖析愈来愈多，也愈来愈繁杂，数据驱动业务愈来愈首要，因此数据剖析面向的更可能是产品人员而不是数据研发人员，如下图所示：


以上是对业务配景和开展趋向，数仓架构、建模现状做了根本的引见。接上去，会对目前传统的数仓架构所面临的一些问题进行剖析。
02
面临的问题
1. 详细问题
面临的详细问题如下图所示：


因为传统数仓架构采取分层的形式，象征着在传统数仓中会构建不同主题，不同粒度，不同维度的数据表。
数据表的范围会很大不同业务线的数据表数量会达到上百张至上千张。
口径不一致，查问繁杂因为数据表的数量很大，用户在使用这些表的过程当中，会发生使用口径的差别，而且对相干数据表的业务含意需求进行充沛了解，这样致使 SQL 或者查问变得繁杂。
依赖数据研发，开发周期长传统数仓中，个别会经过研发来制造报表或者跑数来知足数据需要，自助查问剖析才能较低，会对比依赖研发的排期，开发周期会对比长。
2. 解决计划的思考
关于上述面临的问题，在出产理论中，对业务线进行调研后，有如下思考：
增加数仓分层采取单层数仓宽表模型，增加表数量，用更少的数据表知足业务需要，例如一个主题对应一张宽表。
口径一致，简化查问明白数据表的使用形式，确保数据口径一致、目标明晰，升高沟通本钱，进步沟通效力。
减速数据自助查问基于更容易用的数据表，构建自助化运用，减速数据查问，疾速知足业务需要，助力数据驱动业务。
03
宽表建立
按照上述的思考，并通过业务调研，可行性剖析后，提出用宽表建模替代传统数仓维度建模的技术计划。
1. 宽表技术计划
在数仓建立中，用单层宽表来替代传统数仓中逐层建模的多分层数据表，终究的 Adhoc 即席查问场景能够间接使用宽表，如下图所示：


2. 宽表建立计划
按照实际业务场景，会把数据分为不同的主题，在各主题外部根据业务使用和定义进行宽表的建立，宽表的粒度介于传统数仓 ODS 和 DWD 之间，宽表字段会掩盖业务一切字段需要，包孕明细表一切字段、聚合表的维度字段以及运用层目标列。
采取列式存储，能够反对宽表数百列，再利用列紧缩和编码技术，升高数仓总体的存储空间，晋升 IO 效力。将各层之间的事实表繁杂字段（例如JSON嵌套字段）打平后与各维度表、目标等进行 JOIN 生成宽表，终究宽表列会分为公共属性列，业务属性列（业务维度）以及业务目标列。3. 宽表优缺陷
宽表优缺陷总体如下图所示：


单层宽表建模交换传统数仓维度建模，经过较少的数据冗余，使得数据表数量更少，口径更为明晰一致，易于了解，同时业务使用更为便利，效力更高，如下图所示：


传统数仓层与层之间存在少量冗余，单层宽表取代多层数仓，在出产理论中数仓整体存储降落显著，勤俭了存储本钱。


4. 机能比较
传统数仓表和单层宽表存储相近的状况下，宽表使用了列式存储和统计滤波等技术，在简略查问场景，尤为是简略聚合查问会更快。传统数仓表和单层宽表存储相近的状况下，传统数仓中需求使用 explode 等函数进行的繁杂计算场景，在宽表中绝大部份需要经过 Count、Sum 便可实现，由于宽表会将业务目标下沉，繁杂字段拆分打平，虽然行数变多了，但防止了 explode，get_json_object 等耗时操作，查问机能更高。传统数仓表和单层宽表存储相差较大的状况下，宽表机能有一定的损失，但在业务可承受规模内，影响不大，详细如下图所示：


5. 宽表带来的应战
宽表模型在晋升数据易用性和查问机能的同时，也会带来一些应战：
开发本钱：宽表为了尽量多地知足业务需要，封装了少量的 ETL 处置逻辑以及关联计算，这会使宽表代码更为繁杂，开发迭代保护本钱更高。数据回溯本钱：在业务迭代过程当中，往往伴有着目标口径的降级、日志打点的变化，需求宽表回溯历史数据。而宽表自身数据量较大，计算逻辑繁杂，回溯时会额定损耗较多的计算资源，存在较高的回溯本钱。宽表产出时效：因为宽表自身下游数据源多、数据量大，当多个下游数据就绪时间不尽相反时，宽表的产出时效会泛起木桶效应。宽表提早是不是更大：宽表比较传统多层数仓表，尤为是 Adhoc 查问场景中，传统数仓也是大部份落在 DWD 和 ODS 层，这两层的 ETL 和目标封装才能不是很强，会致使少量使用繁杂字段，所以查问机能更低。然而宽表导入 ClickHouse 或者 Doris 等 OLAP 引擎，机能会达到毫秒级。


针对上述问题，结合业务虚际能够探究一些解决思绪：
开发本钱思考。次要缘故是宽表进行了更多的 ETL 操作和封装了更多的目标口径计算，这实质上实际上是开发本钱和使用本钱之间的衡量，将一部份上游用户使历时再计算的本钱提前封装到宽表中。而假如宽表的上游用户越多，这类开发本钱的晋升对总体业务本钱其实是降落的，本钱产生了转移，也就是所说的升高使用门坎、晋升自助化率。数据回溯本钱的思考。体当初原来只需回溯一个 DWD 或 ADS 层表，当初可能要回溯整张宽表。这里在实际出产中，咱们在技术上能够探究一些优化计划，包罗：将宽表设置不同的业务分区，回溯时只更新对应的分区数据；基于宽表作为输出，回溯所需字段，防止从新履行生成宽表的繁杂计算逻辑；利用空余的潮汐资源，进一步升高回溯资源开消。产出时效思考。针对下游多个数据源产出时效不同步的问题，能够斟酌经过下游数据流批一体化革新，晋升下游数据时效性；假如下游数据无奈提速时，能够斟酌分批产出不同分区的数据。04
自助可视化平台
在解决了传统数仓建模的问题之后，基于更容易用的多维宽表，能够构建一个更好用，更简略的自助可视化平台，用户能够经过这个自助可视化平台产品，来实现自助剖析进程，终究完成从数据出产到数据剖析这样一个端到真个剖析链路，从而进一步晋升业务剖析的效力和机能。
1. 传统 BI 架构的问题
接上去展现一下，对于自助可视化平台所做的一些任务，首先来看下传统 BI架构的一些问题，如下图所示：


传统 BI 架构依赖于数据研发进行数据加工，采取固化的报表或者模版，致使数据剖析不灵敏。研发排期较长，迭代对比慢。研发的人员缺乏，容易拖慢总体业务的效力。2. 自助可视化平台产品
基于以上问题，咱们提出构建自助可视化平台产品，经过可视化主题模版的构建，让用户经过拖拽，点选等操作，按照用户的选择配置拼装成对应的查问 SQL，并提交到后盾查问引擎，从而能够进行无需研发依赖，即配即用的自助查问和剖析，如下图所示。


下图展现了自助可视化平台关于用户使用的全部进程


数据研发人员进行数据加工和出产，实现宽表建模和开发，基于大量的宽表，业务人员能够对比明晰的了解数据和目标的含意，并经过自助可视化平台，实现闭环自助剖析。
下图是笔者公司外部自研的一个一站式自助可视化平台。


天天产品自助进行上万次的查问，查问速度通过引擎减速能够达到秒级，目前这个产品曾经掩盖到了外部 200 多个业务部门。
下图展现了该产品的使用功用门路，一个残缺的自助剖析进程分为下列4个步骤：


可视化自助查问用户能够自助点选需求的目标字段，并可视化的提交查问，这是一个查问的进程，详细如下图所示：


可视化数据加工和配置按照上一步查问的后果，一键创立数据集，这个进程是基于数仓宽表查问的后果，并将后果存入 OLAP 引擎（例如 ClickHouse 或者 Doris 等），后续进行毫秒级的可视化剖析。


图表拖拽剖析基于上一步查问后果集，会频繁的修正各种查问前提，通过图表的拖拽，进行可视化的剖析和探究，终究造成需求的剖析后果。


报表或者看板的配置和公布剖析后果保留之后，会造成残缺的图表，终究实现总体的规划。


经过自助可视化平台，从可视化查问开始，到终究自助报表的发生，只需求数非常钟就能实现。
下图是在笔者公司外部，在使用基于宽表模型的自助可视化平台产品之后的业务成果，能够看出业务自助化率有了显著的晋升，同时数据研发的需要排期和人力都有了改良。


05
总结和布局
企业数据运用大抵分为看板，报表，剖析三种，其中看板是重 ETL 轻查问，报表是 ETL 和查问偏重，剖析尤为是交互式剖析是重查问，灵敏性更强，宽表模型更合适剖析场景的运用。宽表建模是面向业务场景的，更合适疾速迭代的数据驱动型业务，不合适传统的 BI 报表业务场景。在笔者公司以后的业务虚践中，宽表模型在存储和用户端到端查问剖析机能方面比传统数仓更优。自助可视化平台在最初一步完成端到端查问剖析效力的晋升。在业务效力晋升的同时，宽表的建立会对数据出产研发和保护本钱有所晋升，然而会更多的升高业务使用本钱，需求均衡灵敏性和本钱，结合不同的业务虚践进一步优化探究。


将来的布局次要是引擎才能继续的晋升和凋谢云化助力更多业务。
明天的分享就到这里，谢谢大家。
｜分享佳宾｜


马皓
百度 资深研发工程师
20十一年结业并参加百度，长时间从事大数据开发相干任务，担任百度多个挪动产品的数仓建模、BI平台建立等。
｜DataFun新媒体矩阵｜


｜对于DataFun｜
专一于大数据、人工智能技术运用的分享与交流。发动于2017年，在北京、上海、深圳、杭州等城市举行超过100+线下和100+线上沙龙、论坛及峰会，已约请超过2000位专家和学者参预分享。其大众号 DataFunTalk 累计出产原创文章800+，百万+浏览，15万+精准粉丝。