【应用实践】京东物流基于 Doris 的亿级数据自助探索应用
The following article is from DataFunTalk Author 刘笑言
分享嘉宾：刘笑言 京东物流 数据工程师
编辑整理：张进东
出品平台：DataFunTalk
导读：京东智慧物流在数据应用方面，主要是基于大数据预测分析技术实现智能化的调度、决策，提升物流效率，最终提升客户的体验。但面对亿级数据的业务场景，将会面临着不同的问题和不同的处理方案。今天讨论了京东物流在亿级数据管理和应用方面，利用Apache Doris进行的探索和实践。
首先和大家分享下京东物流业务的需求和亿级数据自助应用的背景。介绍京东物流经营数据发展路线，底层数据的演进思路，业务对于数据诉求迭代。
1. 业务需要什么
京东物流除了包括快递服务的仓、运、配三个环节外，它的一体化供应链物流服务，则更多是基于对商品销售和供应链的理解，合理规划仓网，分布库存，提前将用户需要的货物储存到其在全国范围数百个不同等级的仓库中。当用户下单后，商品将直接从最近的仓库送达站点，开始配送。用户下单后，快递公司会通过干线网络，将货物运输至对应的区域，再分发至配送站点进行配送。这些服务以一体化解决方案的形式提供予客户，满足客户的各种需求，业务极其复杂。
对于我们数据侧的建设工作者来说，会遇到各种各样的现实问题：
早：海量数据的多维查询已经成为常态，高时效保障是业务的最新追求，甚至要求实时；
散：数据存储在不同的业务系统，各个系统没有标准的数据规范， 数据重复建设；
重：日报、周报、半月报、月报等工作效率低，部分重复工作多，数据统计费时费力；
慢：全国区域、战区以及各产品群数据场景多样，无法快速响应数据变化；
缺：缺少统一的数据资产管理，运营人员无法方便、快捷地进行统一的数据分析；
难：领导获取数据难， 营销投入产出比衡量难，数据驱动业务难，数据价值挖掘难。
2. 当前有什么
① 生产系统
是指在正常情况下支持单位日常业务运作的信息系统。它包括生产数据、生产数据处理系统和生产网络。
② 数据仓库
是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它是单个数据存储，出于分析性报告和决策支持目的而创建。为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。
③ 数据集市
是基于京东数据仓库和大数据平台构建的面向各BG/BU的数据环境，为各BG/BU提供数据应用服务，包含CFO、CMO、COO、MOBILE等数据集市。
④ 应用系统
是指可以发挥数据价值去辅助用户更优地做决策（甚至行动）的一种产品形式。
3. 数据团队怎么做：业财数据体系建设
每个公司的业务数据和财务数据是天然割裂的状态。举例来说，一家全国规模的连锁店，每个店的店员的薪资和日程运营的费用（如水电费）怎么来反映到每一单上面去，如何把业务数据和财务数据打通，这有点像银行的分润，把业务数据规范到每一个环节对应的每个功能点上去，即成本因素和收支因素的影响点，再把数据再给分担上去。这也就是基础模型搭建的一个过程，最终会支撑到上游资金分析体系的客户的分析和成本支持。
标准化后的管理侧数据口径、颗粒度及维度将全面满足企业对精细化、实时化业财分析的要求，为业务财务出具专业的分析与报告提供数据支撑。同时，可复用的、具备公共能力的标准数据将支持企业在价值链条上建立多维分析架构，利用多层次、可交叉的分析直接加强企业对业务信息的钻取能力，推动业务洞察和管理智能化。
数据可视化、灵活分析迫在眉睫，权限管理，数据安全需要保障。
1. 数据可视化建设
在数据导出控制方面：
存在的隐患：
数据导出至本地电脑，并做分析；数据导出后，无法做跟踪控制。导出次数达3000次/周。
解决方案：
长远解决方案：用户需求反哺，沉淀方法论，线下分析报表化，支持自助探索。
短期解决方案：导出时，弹窗提醒法律风险；导出形成账单，并每月发送给区总了解。
在数据权限控制方面：
存在的隐患：
分析权限：因历史积累，访问大数据开发分析平台的权限不匹配当前安全要求。例如，有些业务分析师可以访问库内全量表，未区分区域；
指标权限：指标的访问权限控制散落在各系统管理，无法做到统一控制，容易混乱和遗漏。
解决方案：
分析权限：梳理BDP访问权限，按照业务特性缩小访问范围，并制定岗位权限白皮书；
指标权限：指标出口由统一数据API进行控制，指标查看权限设置由指标收口人在资产管理平台统一设置。
2. 工具论证
与业务用户代表组成调研小组，对后续工具选型进行调研：
内部工具调研，京东动力目前处于快速迭代阶段，调研现阶段支持功能，定制化开发的相应速度；
外部工具调研，从成本，市场成熟度，产品易用性，扩展性，性能等多维度交叉比对市场主流BI工具的优缺点；
内外部工具对比，业务方、产品经理以及研发三方组成专家评分组，对内外部工具进行评分；
工具对比结论，最终确定BI工具实施方案。
3. 目标现状分析
目前京东物流数据探索领域分析工具的目标以及当前目标现状的分析，包括：
现状情况：
京东动力作为分析工具
动力从商城数据中台引入
突出问题：
性能慢：分钟级，高峰期出不来
上卷、下钻等功能缺失
体验不友好，拖拽繁琐
临时方案：
提数，本地分析
隐患：数据导出后无法跟踪
长期方案：
引入更适合的工具
调研：动力的计划，Tableau、永洪BI等
分析工具目标：
提供便捷自助服务：一站式分析平台，集数据准备、报告制作、数据分析为一体，业务人员也能轻松、快速地制作并分析数据报告，带来业务驱动的数据分析工作模式。多维度下钻和上卷。
内嵌丰富组件，上线周期短，组件丰富，可以对所有数据源进行合并、搜索、交互和分析。
移动跨屏，无缝支持PC、iPhone、iPad和Android，并在这些终端设备上保持一致、易用的用户体验。
高性能，秒级计算，利用列存储和内存计算，实现千万级数据分析的秒级响应；提升性能，支撑更多的分析维度和更大的数据范围。
当前问题详解：
自主分析不便捷，加工链条过长，需要前端，UI，产品以及UI多方配合，资源协调困难，沟通成本较高；
定制化研发投入多，定制化开发，不同维度的分析需要开发不同的汇总以及前段展示界面，底表模型变更影响范围广；
图表组件不丰富，对于每种新的应用场景均需要不同的额开发集成，各功能模块之前需要联调测试，开发周期长，暂不支持移动端；
无法跨屏展示&性能低，现没有APP端展示；查询依托于大数据平台资源，在业务忙时查询性能低。
4. 分析工具功能矩阵
由前面的分析，总结了分析工具的功能矩阵：
数据从无到有，从有到准，从准到全，每个阶段都会面临不同的业务诉求，需要紧跟业务变化做迭代。
1. 数据引擎的变迁
2. 资源模式及架构优化
领航中分析师报表，为保证灵活性多通过报表工具（京东动力）配置实现，以Presto作为计算节点，以BDP大数据平台作为数据存储架构。但计算资源和存储资源均是共享模式，无法通过扩资源的方式有效的提升查询效率，严重影响用户体验，急需改变。
之前架构：领航+动力+PRESTO+BDP
弊端
Presto集群无法资源隔离，易出现资源竞争；无法按业务条线对资源进行扩容；
报表数据存放在BDP平台，当前集群任务多，任务运行贯穿正常工作时段，容易造成BDP平台繁忙导致报表数据读取慢的情况。
解决方案：领航+动力+ DORIS
引入新架构，资源独占；解耦BDP平台对数据展示影响
效果：已借助单票分析项目完成尝试及验证
查询从10秒+到秒级响应提升
独立资源管控，按需优化
3. Doris表管理
常用的表管理操作，包括：
① 表创建
② 添加分区
ALTER TABLE table_name ADD PARTITION IF NOT EXISTS p20200803 VALUES [('2020-08-03'), ('2020-08-04'));
③ 删除分区
TRUNCATE TABLE table_name PARTITION(p20200803,p20200804
注意事项：
规范分区，统一分区规则便于后续运维
导入时，会同时给所有Rollup 产生数据，过多的Rollup 会影响导入性能，评估Rollup创建个数
批量导入清理历史数据建议小范围多批次串行操作，合理利用资源
4. Doris数据导入：Hive2Doris通过Broker Load方式写入
常用的数据导入操作，包括：
① 转换导入表格式
② Broker Load
③ 追踪导入状态
show load from jddl_test where label = 'app_ea_pal_vender_all_sum_m_20201101_183213_19688970430' \G
注意事项：
LABEL：用于指定这一批次导入的label，用于后期进行作业状态查询等
max_filter_ratio：用于指定允许过滤不规范数据的最大比例，默认是0，不允许过滤,自定义指定应该如下：
'max_filter_ratio=0.2'，含义是允许20%的错误率
timeout：指定load 作业的超时时间，单位是秒。当load执行时间超过该阈值时，会自动取消。默认超时时间是86400 秒。
5. 数据自动导入管理
-t 表示的是待推送数据的表名【该参数是必选，如果不选会报错】
-c 表示的是待推送数据的列名【该参数是可选，如果不选会默认推送所有列，建议不选择】
-n 表示的是推送多长时间的数据【需要与参数-e联动使用，如果不填写，默认推送1天的数据】
-e 表示的是脚本数据推送的日期【默认是昨天，该参数一般是追历史数据时使用，比如今天是2020-05-08日，默认推送20200507日的数据，如果指定了-n参数的话推送的就会是20200507-n天至20200507】
-d 表示对doris数据库的表进行操作【默认参数是：db_null 不执行建表】db_get_crt：表示打印出doris建表语句，该逻辑会读取hive中的表结构，然后将HIVE中的字段为string类型的当成维，int，bigint，double类型的当成值生成建表语句【具体逻辑请参考脚本】
db_reset ：表示重建表，如果调整表结构后，需要使用这个参数重构doris表结构【如果指定了-c参数，记得增加列】
db_drop ：表示删除doris中对应的表，用于下线任务
db_create ：如果不存在对应的表就创建表，如果存在表就打印表结构下面，重点分享下纵向联邦学习和横向联邦学习。
注意事项：
数据库特性不同天然存在融合瓶颈，新技术的引入需要有充分的预案，做到各司其职，才能让其特性得到发挥
6. 自动报表实现
通过动力连接数据库，把对应的表按照权限管理配置成数据源，在数据源上创建应用，可以让业务人员在10分钟搭建起符合自己预期的分析报表。
7. 待优化点：子查询对应Rollup的影响
子查询如果没有生效rollup，外层是无法生效。
技术迭代是手段，对业务发展起促进作用才是目的，如何通过技术的升级实现业务技术相互促进。
1. 离线数据技术升级
BDP是一个公共平台，支持开发人员、分析师以及业务人员做数据查询，业务是不断变化增长的，业务部门分析也会随着对业务的理解程度不断深入，但是实际的物理资源不能无限制扩容。基于此，每天的重要任务SLA保障是数据团队面临的最大挑战，并且随着业务发展会愈发严重。这就需要做系统规划：
不断优化迭代底层模型，对数据做最优整合，对主题模型的数据引入生命周期管理，表现在两个方面：其一，模型随着业务有新增，也必须有消亡；其二，模型本身存储数据需要有生命周期管理，对于可追溯的分析数据制定数据保留策略，满足业务需求的同时尽量减少历史数据存储。
贴合平台优化加工策略，纵观调度平台全时段运行情况，在某些时段会出现资源利用波谷，通过并行任务合理利用资源。
新调度引擎引入，按照任务不同的加工场景选择不同调度引擎（Hive/Spark）,以最小代价实现调入任务跑数。
2. 业务迭代技术跟进
随着业务的不断成熟，对精细化运营有了新的要求，会涉及到各方业务系统的迭代，数据处理需要夯实底层架构。
通用化：业财一体化融合，对成熟的业务实现到单的融合；
体系化：通过各维度损益模型串联业务实际运营成本，支持业务分析，做全盘优化调优成本；
清晰化：看清每个经营动作成本，减少由于分摊造成“差异性“抹平，结合业务量、收入对不同环节进行改善；
灵活化：即席查询，利用新的OLAP计算框架，支持各个维度数据查看，实现不同业务层级数据的上卷、下钻。
3. 团队建设
独木不成林，任何一个项目的成功都是团队配合的结果。在团队建设之初，团队的人员相对较少，对接的业务也相对聚焦，从0到1的数据建设过程中一定是采用“纵向”的开发方式——一个数据开发对接一个条线，对当前条线从头到全盘负责，实现高速迭代。这个阶段会形成团队核心价值，当各业务方都认可这种数据分析思路，随之而来的就是业务需求膨胀，不同主题之间的横向拉通分析，组内人员的补充等。如何做到人员价值最大化，则需要投入精力在团队建设上，主要包括：
方法论建设：没有成熟的方法论，后续难以为继。
技术提升：离线实时数据全链路的技术结合,技术要求高。
项目管理：大项目周期以半年设置年计，项目投入产出科学衡量。
数据权限：数据访问的细粒度的控制，基础元数据补全。
人才队伍建设：需要人才梯队来保障持续数据迭代。
今天的分享就到这里，谢谢大家。
分享嘉宾：
关于我们：
【应用实践】Apache Doris在蜀海供应链的实践【Doris全面解析】Doris Stream Load原理解析
欢迎扫码关注：
Apache Doris(incubating)官方公众号
相关链接：
Apache Doris官方网站：
http://doris.incubator.apache.org
Apache Doris Github：
https://github.com/apache/incubator-doris
Apache Doris 开发者邮件组：
dev@doris.apache.org