引言
Doris 作为一款优秀的 OLAP数据库，凭借其冷热分离等特性，在易用性和成本方面都有显著提升。基于 Doris 等存储引擎构建实时数仓的方案也越来越受到关注。我们需要客观地看待这一方案，因为基于存储的实时数仓既有优势，也有劣势。本文将结合实践经验，对这一方案进行分析和讨论。
为什么需要基于存储的实时数仓？
基于 Doris 等 OLAP 数据库实现实时计算的业务场景往往基于以下考虑：
开发难度较低：基于 Flink 等流计算框架开发实时任务的难度远高于离线任务，而基于 Doris 的存储实时数据开发可以显著降低开发门槛。
大窗口、大状态场景：Flink 并不擅长处理大窗口、大状态、灵活计算的场景。而在这些场景下，Doris 可以显著降低开发成本。
数据可观测性：Flink 的计算数据可观测性较差，状态数据不可见，排查问题和修复历史数据都存在困难。Doris 则可以提高数据的可观测性。
基于存储实时数仓的优势
开发门槛低：基于 Doris 开发实时任务的门槛较低，所有人员都可以轻松开发。
运维简单：无需考虑 Flink 状态的兼容性，也不需要大量资源长期占用，只在运行 SQL 时才需要调度资源。
开发效率高：无需深入理解 Flink，测试简单，无需启动调度容器。
数据调试方便：中间结果落地可见，所有数据都在表中可查。
基于存储实时数仓的劣势
延迟明显：基于 Doris 进行实时数据开发，通常会配合定时调度，一般调度周期在 30 秒以上，这意味着数据实时性大幅降低。
数据规模限制：Doris 在处理高 TPS 数据时并不擅长，单次扫描的数据规模也不能过大。
成本和运维中心：如果选择以 Doris 为主的实时数据开发，则需要严格的配套工具和资源监控，一旦这些成为瓶颈，会影响所有基于 Doris 的任务运行。
实践建议
在考虑基于存储的实时数仓方案时，需要注意以下几点：
数据规模：在亿级或数千万以下的数据规模下，基于 Doris 的实时数仓方案才能保证良好的性能。
实时性要求：如果需要高实时性的指标观测，例如实时 GMV、在线人数等，则不适合使用基于 Doris 的实时数仓方案。
配套工具：需要配套完善的报警、任务监控、调度和血缘能力等工具。
资源和 SQL 性能：需要密切关注资源和 SQL 性能，一旦成为瓶颈，会影响所有基于 Doris 的任务运行。
结论
基于存储的实时数仓方案有其优势和劣势。在选择这一方案时，需要根据实际业务场景进行谨慎评估。在亿级或数千万以下的数据规模、实时性要求不高的场景下，基于 Doris 的实时数仓方案可以显著降低开发和运维成本。但是，对于高实时性、大数据量或复杂计算的场景，则需要考虑其他方案，例如基于 Flink 的实时流计算。
Doris系列12-数据导入之Broker Load
Broker load 是一个异步的导入方式，支持的数据源取决于 Broker 进程支持的数据源。
用户需要通过 MySQL 协议 创建 Broker load 导入，并通过查看导入命令检查导入结果。
适用场景: 源数据在 Broker 可以访问的存储系统中，如 HDFS。 数据量在 几十到百GB 级别。
名词解释：
基本原理: 用户在提交导入任务后，FE 会生成对应的 Plan 并根据目前 BE 的个数和文件的大小，将 Plan 分给 多个 BE 执行，每个 BE 执行一部分导入数据。
BE 在执行的过程中会从 Broker 拉取数据，在对数据 transform 之后将数据导入系统。所有 BE 均完成导入，由 FE 最终决定导入是否成功。
语法：
示例:
创建导入的详细语法执行 HELP BROKER LOAD 查看语法帮助。这里主要介绍 Broker load 的创建导入语法中参数意义和注意事项。
导入任务的标识。每个导入任务，都有一个在单 database 内部唯一的 Label。Label 是用户在导入命令中自定义的名称。通过这个 Label，用户可以查看对应导入任务的执行情况。
Label 的另一个作用，是防止用户重复导入相同的数据。强烈推荐用户同一批次数据使用相同的label。这样同一批次数据的重复请求只会被接受一次，保证了 At-Most-Once 语义
当 Label 对应的导入作业状态为 CANCELLED 时，可以再次使用该 Label 提交导入作业。
数据描述类参数主要指的是 Broker load 创建导入语句中的属于 data_desc 部分的参数。每组 data_desc 主要表述了本次导入涉及到的数据源地址，ETL 函数，目标表及分区等信息。
下面主要对数据描述类的部分参数详细解释：
导入作业参数主要指的是 Broker load 创建导入语句中的属于 opt_properties部分的参数。导入作业参数是作用于整个导入作业的。
下面主要对导入作业参数的部分参数详细解释：
这里以列类型为 TinyInt 来举例：
这里以列类型为 Decimal(1,0) 举例:
Broker load 导入方式由于是异步的，所以用户必须将创建导入的 Label 记录，并且在查看导入命令中使用 Label 来查看导入结果。查看导入命令在所有导入方式中是通用的，具体语法可执行 HELP SHOW LOAD 查看。
示例:
下面主要介绍了查看导入命令返回结果集中参数意义：
当 Broker load 作业状态不为 CANCELLED 或 FINISHED 时，可以被用户手动取消。取消时需要指定待取消导入任务的 Label 。取消导入命令语法可执行 HELP CANCEL LOAD查看。
下面几个配置属于 Broker load 的系统级别配置，也就是作用于所有 Broker load 导入任务的配置。主要通过修改 来调整配置值。
min_bytes_per_broker_scanner/max_bytes_per_broker_scanner/max_broker_concurrency
前两个配置限制了单个 BE 处理的数据量的最小和最大值。第三个配置限制了一个作业的最大的导入并发数。最小处理的数据量，最大并发数，源文件的大小和当前集群 BE 的个数 共同决定了本次导入的并发数。
通常一个导入作业支持的最大数据量为 max_bytes_per_broker_scanner * BE 节点数。如果需要导入更大数据量，则需要适当调整 max_bytes_per_broker_scanner 参数的大小。
默认配置：
doris端创建表
准备load 命令
查看导入的进度
等待执行完成:
doris端创建表
准备load 命令
查看导入的进度
ApacheDoris助力网易严选打造精细化运营DMP标签系统...
导读：如果说互联网的上半场是粗狂运营，那么在下半场，精细化运营将是长久的主题，有数据分析能力才能让用户得到更好的体验。
当下比较典型的分析方式是构建用户标签系统，本文将由网易严选分享DMP标签系统的建设以及ApacheDoris在其中的应用实践。
作者｜刘晓东网易严选资深开发工程师
如果说互联网的上半场是粗狂运营，因为有流量红利不需要考虑细节。
那么在下半场，精细化运营将是长久的主题，有数据分析能力才能让用户得到更好的体验。
当下比较典型的分析方式是构建用户标签系统，从而精准地生成用户画像，提升用户体验。
今天分享的主题是网易严选DMP标签系统建设实践，主要围绕下面五点展开：平台总览标签生产：标签圈选&生产链路标签存储：存储方式&存储架构演进高性能查询未来规划平台总览
DMP作为网易严选的数据中台，向下连接数据，向上赋能业务，承担着非常重要的基石角色。
DMP的数据来源主要包括三大部分：自营平台的APP、小程序、PC端等各端的业务日志网易集团内部共建的一些基础数据京东、淘宝、抖音等第三方渠道店铺的数据
通过收集、清洗，将以上数据形成数据资产沉淀下来。
DMP在数据资产基础上形成了一套自己的标签产出、人群圈选和用户画像分析体系，从而为业务提供支撑，包括：智能化的选品、精准触达以及用户洞察等。
总的来说，DMP系统就是构建以数据为核心的标签体系和画像体系，从而辅助业务做一系列精细化的运营。
了解DMP系统，先从以下几个概念开始。
标签：对于实体（用户、设备、手机号等）特征的描述，是一种面向业务的数据组织形式，比如使用：年龄段、地址、偏好类目等对用户实体进行刻画。
人群圈选：通过条件组合从全体用户中圈选出一部分用户，具体就是指定一组用户标签和其对应的标签值，得到符合条件的用户人群。
画像分析：对于人群圈选结果，查看该人群的行为情况、标签分布。
例如查看【城市为杭州，且性别为女性】的用户在严选APP上的行为路径、消费模型等。
严选标签系统对外主要提供两大核心能力：标签查询：查询特定实体指定标签的能力，常用于基本信息的展示。
人群圈选：分为实时和离线圈选。
圈选结果主要用于：分组判断：判读用户是否在指定的一个或多个分组，资源投放、触点营销等场景使用较多。
结果集拉取：拉取指定的人群数据到业务方系统中，进行定制化开发。
画像分析：分析特定人群的行为数据，消费模型等，进行更精细的运营。
整体的业务流程如下：首先定义标签和人群圈选的规则；定义出描述业务的DSL之后，便可以将任务提交到Spark进行计算；计算完成之后，将计算结果存储到Hive和Doris；之后业务方便可以根据实际业务需求从Hive或Doris中查询使用数据。
DMP平台整体分为计算存储层、调度层、服务层、和元数据管理四大模块。
所有的标签元信息存储在源数据表中；调度层对业务的整个流程进行任务调度：数据处理、聚合转化为基础标签，基础标签和源表中的数据通过DSL规则转化为可用于数据查询的SQL语义，由调度层将任务调度到计算存储层的Spark进行计算，并将计算结果存储到Hive和Doris中。
服务层由标签服务、实体分组服务、基础标签数据服务、画像分析服务四部分组成。
标签的生命周期包含5个阶段：标签需求：在此阶段，运营提出标签的需求和价值预期，产品评估需求合理性以及紧迫性。
排期生产：此阶段需要数据开发梳理数据，从ods到dwd到dm层整个链路，根据数据建立模型，同时数据开发需要做好质量监控。
人群圈选：标签生产出来之后进行应用，圈选出标签对应的人群。
精准营销：对圈选出来的人群进行精准化营销。
效果评估：最后产品、数据开发和运营对标签使用率、使用效果进行效果评估来决定后续对标签进行改进或降级。
总的来说，就是以业务增长为目标，围绕标签的生命周期，投入合理的资源，最大化运营效果。
标签生产
接下来介绍标签生产的整个过程。
标签的数据分层：最下层是ods层，包括用户登录日志、埋点记录日志、交易数据以及各种数据库的Binlog数据。
对ods层处理后的数据到达dwd明细层，包括用户登录表、用户活动表、订单信息表等。
dwd层数据聚合后到dm层，标签全部基于dm层数据实现。
目前我们从原始数据库到ods层数据产出已经完全自动化，从ods层到dwd层实现了部分自动化，从dwd到dm层有一部分自动化操作，但自动化程度还不高，这部分的自动化操作是我们接下来的工作重点。
标签根据时效性分为：离线标签、近实时标签和实时标签。
根据聚合粒度分为：聚合标签和明细标签。
通过类别维度可将标签分为：账号属性标签、消费行为标签、活跃行为标签、用户偏好标签、资产信息标签等。
直接将dm层的数据不太方便拿来用，原因在于：
基础数据比较原始，抽象层次有所欠缺、使用相对繁琐。
通过对基础数据进行与、或、非的组合，形成业务标签供业务方使用，可以降低运营的理解成本，降低使用难度。
标签组合之后需要对标签进行具体业务场景应用，如人群圈选。
配置如上图左侧所示，支持离线人群包和实时行为（需要分开配置）。
配置完后，生成上图右侧所示的DSL规则，以Json格式表达，对前端比较友好，也可以转成存储引擎的查询语句。
标签有一部分实现了自动化。
在人群圈选部分自动化程度比较高。
比如分组刷新，每天定时刷新；高级计算，如分组与分组间的交/并/差集；数据清理，及时清理过期失效的实体集。
标签存储
下面介绍一下我们在标签存储方面的实践。
严选DMP标签系统需要承载比较大的C端流量，对实时性要求也比较高。
我们对存储的要求包括：支持高性能查询，以应对大规模C端流量支持SQL，便于应对数据分析场景支持数据更新机制可存储大数据量支持扩展函数，以便处理自定义数据结构和大数据生态结合紧密
目前还没有一款存储能够完全满足要求。
我们第一版的存储架构如下图所示：
离线数据大部分存储在Hive中，小部分存储在Hbase（主要用于基础标签的查询）。
实时数据一部分存储在Hbase中用于基础标签的查询，部分双写到KUDU和ES中，用于实时分组圈选和数据查询。
离线圈选的数据通过impala计算出来缓存在Redis中。
这一版本的缺点包括：存储引擎过多。
双写有数据质量隐患，可能一方成功一方失败，导致数据不一致。
项目复杂，可维护性较差。
为了减少引擎和存储的使用量，提高项目可维护性，在版本一的基础上改进实现了版本二。
我们第二版的存储架构如下图所示：
存储架构版本二引入了ApacheDoris，离线数据主要存储在Hive中，同时将基础标签导入到Doris，实时数据也存储在Doris，基于Spark做Hive加Doris的联合查询，并将计算出来的结果存储在Redis中。
经过此版改进后，实时离线引擎存储得到了统一，性能损失在可容忍范围内（Hbase的查询性能比Doris好一些，能控制在10ms以内，Doris目前是1.0版本，p99，查询性能能控制在20ms以内，p999，能控制在50ms以内）；项目简化，降低了运维成本。
在大数据领域，各种存储计算引擎有各自的适用场景，如下表所示：高性能查询
分组存在性判断：判断用户是否在指定的一个分组或者多个分组。
包括两大部分：第一部分为静态人群包，提前进行预计算，存入Redis中（Key为实体的ID，Value为结果集ID），采用Lua脚本进行批量判断，提升性能；第二部分为实时行为人群，需要从上下文、API和ApacheDoris中提取数据进行规则判断。
性能提升方案包括，异步化查询、快速短路、查询语句优化、控制Join表数量等。
还有一个场景是人群分析：人群分析需要将人群包数据同多个表进行联合查询，分析行为路径。
目前Doris还不支持路径分析函数，因此我们开发了DorisUDF来支持此业务。
Doris的计算模型对自定义函数的开发还是很友好的，能够比较好地满足我们的性能需要。
ApacheDoris在网易严选中已应用于点查、批量查询、路径分析、人群圈选等场景。
在实践中具备以下优势：在点查和少量表的联合查询性能QPS超过万级，RT99<50MS。
水平扩展能力很强，运维成本相对比较低。
离线数据和实时数据相统一，降低标签模型复杂度。
不足之处在于大量小数据量的导入任务资源占用较多，不过此问题已经在Doris1.1版本中进行了优化，Doris在1.1中大幅增强了数据Compaction能力，对于新增数据能够快速完成聚合，避免分片数据中的版本过多导致的-235错误以及带来的查询效率问题。
待Doris1.1.2版本正式发布后我们也会及时同步升级。
具体可以参考：ApacheDoris1.1特性揭秘：Flink实时写入如何兼顾高吞吐和低延时未来规划
提升存储&计算性能：Hive和Spark逐渐全部转向ApacheDoris。
优化标签体系：建立丰富准确的标签评价体系提升标签质量和产出速度提升标签覆盖率
更精准的运营建立丰富的用户分析模型从使用频次和用户价值两个方面提升用户洞察模型评价体系建立通用化画像分析能力，辅助运营智能化决策资料下载
