零代码、低成本快速创建采集表
基于大数据引擎，通过可视化组件、托拉拽式实现数据汇聚与集成开发
指标定义、指标建模、指标固化、指标分析，一体化完成指标的落地与应用
组件化、零sql实现各类复杂报表和丰富多样的图表分析
面向业务人员，简单拖拽即可生成可视化图表
内置150+特效组件，快速打造酷炫灵动的可视化大屏，支持在线编码，拓展视觉体验至极致
搭载自然语言分析引擎，引入AI大模型技术，通过简单的对话问答实现快速数据分析
移动采集、审批、分析一站式解决移动办公诉求
一站式数据分析平台
了解ABI
全程“零”编码，高效实现主数据模型、主数据维护、主数据分发、主数据质量的全过程管理，为企业主数据管理落地提供有效支撑，实现各业务系统间的主数据共享，保障企业主数据的唯一性、准确性、一致性。
内置多类主数据模版，可视化实现多视角模型定义，满足复杂规则的编码自动控制
多种数据接入方式，支持不同场景的审批管控，数据版本可回溯，满足主数据的全生命周期管理
拖拽式任务设计，内置丰富组件，支持主动式、被动式分发模式
全过程质量管控，支持内置及自定义规则，提供图表式质检报告
主数据管理平台
在线模型设计，深度融合数据标准，规范数据定义
自动化元数据感知，全链路血缘提取，理清数据资源
智能化标准推荐，一键式数据落标，树立数据权威
“零”编码规则搭建，全流程质量整改，高速数据质检
规范资产目录，自助式数据共享，释放资产价值
基于大数据引擎，通过可视化组件、托拉拽式实现数据汇聚与集成开发
超30+主流数据库、国产库、大数据库、文件、消息队列等接口之间极速交换结构化、非结构化数据
构建分级分类体系，动态数据脱敏，保障数据安全
全盘监控数据，决策数据周期，释放数据资源
智能数据治理平台
了解睿治
覆盖数据建模、采集、处理、集成、共享、交换、安全脱敏于一体，一站式解决数据开发所有的问题。
结合标准体系的可视化建模工具，支持模型的正、逆向构建
拖拽式任务编排，内置丰富组件，支撑亿级数据的快速处理与迁移
具备高并发、高吞吐量、低延迟的一体化任务编排能力，可视化设计、分布式运行
提供图形化的任务监控和日志跟踪，面向运维、管理人员的完善监控体系
数据工厂系统
纯web设计器，零编码完成基本表、变长表、中国式复杂报表、套打表、问卷调查表等制作；支持年报、月报、日报，以及自定义报表期等多种数据采集报送频率
提供在线填报和离线填报两种应用模式，也支持跨数据源取数；填报数据自动缓存在WEB浏览器中，即使宕机也不会丢失
内置灵活轻便的工作流引擎，实现了用户业务过程的自动化；支持层层审批、上级审批、越级审批、自定义审批等多种审批方式
对于下级填报单位上报的数据，上级汇总单位可将其进行汇总；支持层层汇总、直接下级汇总、选择单位汇总、按条件汇总、按代码组汇总、按关键字汇总、自定义汇总等
提供数据锁定机制，防止报表数据被意外修改；支持数据留痕，辅助用户过程追溯；未及时上报的用户自动催报；所见即所得的打印输出等
提供多种类型的数据接口，可以导入EXCEL、DBF、二进制、文本等格式的数据，可以将报表数据批量输出为HTML、EXCEL、XML、TXT等格式
数据采集汇总平台
统一指标定义，实现“一变多变、一数多现”的数据管理效果，为企业提供强有力的数字化保障和驱动效应。
采用可视化、导向式方式构建指标业务域，形成指标地图，全局指标一览在目
流程化自助式的定义、开发、维护各类指标，零建模，业务人员即刻上手
助力企业更好地查询、使用指标，提供共享、交换、订阅、分析、API接口等应用服务
指标管理平台
企业级智能体平台，低门槛搭建智能体，灵活编排流程，融合 LLM 实现“问数”、“问知识”
面向业务的对话式问数，即问即答，更懂你的诉求
理解数据，洞察数据，更懂数据内容，把数据见解讲给你听
动态地分析数据特点，提供最合适的图表类型展示，让数据展现更简单
完全是颠覆做表的方式，一句话看板创建，启发式内容制作
智能化生成包含深入分析和建议的报告，复杂数据简单化，释放数据潜力
数据跃然屏上的AI大屏汇报，让数据讲述故事
海量知识，一触即达，提供更智能的知识检索服务，快速找到“对”的人
不止于工具，更是随时待命的得力助手。一声指令，为您提供即时的数据分析和决策支持
智能数据问答平台
面向企业级数据资产交易运营场景，助力企业实现数据资产的价值挖掘、升值和资产变现。
提供上百类数据交换、汇聚、处理能力；零代码数据模型开发。
全链路数据治理，把控资产质量，理清资产血缘。
定义、盘点、规划无序的数据类和应用类资源，构建数据资产管理体系。
提供数据资源门户，及数据API、数据服务等快速检索能力；动态脱敏、加密保障数据安全。
提供用户注册、审批、订购等一体化管理，持续提升企业数据资产价值。
数据资产运营平台
从采、存、管、用四大方面构建数据治理体系，实现数字化经营
主数据全生命周期管理，保障主数据一致性、权威性、共享性，提高企业运营效率
以元数据管理摸清家底，以资产编目盘点数据资产，提供数据服务
集数据采集补录、数据ETL建模、数据实时存储、数据分析展现等应用场景于一体
集数据集成、数据治理、资产规划开发、资产运营等场景应用于一体
集元数据采集和规整、数据标准建立与评估、数据质量管控等场景应用于一体
面向业务和技术提供指标管理指标分析等服务的指标统一管理平台
涵盖数据存储、数据集成、数据交换、数据共享等方面，为企业用户提供云原生仓湖一体解决方案
提供数据全生命周期过程的数据服务手段，实现数据应用到数据运营
基于大模型AI的智能化低代码数据开发平台,助力企业高效构建现代化数据仓库、数据湖
基于大模型（LLM）与BI引擎深度融合的新一代数据智能平台，致力于打造会说话的数据助手
构建标准化的高质量数据集体系，打通从采集到训练的全链路
案例中心
学习中心
认证中心
培训活动
亿信社区
伙伴招募
供应商招募
了解亿信
亿信动态
亿信ABI
数据治理
产品解决方案
金融
租赁
医疗卫生
制造
能源
教育
央国企
其他
案例中心
学习中心
认证中心
培训活动
亿信社区
伙伴招募
供应商招募
了解亿信
亿信动态
IDC蝉联数据治理解决方案市场第一
数据倾斜出现的一个主要原因是数据分布不均，出现热点key。对于数据倾斜的处理方案，比较常见的有：优化参数，如增加reduce的个数、过滤一些异常值、赋随机值，或者按经验值设置固定阈值，把大于某阈值的数据单独处理。赋随机数的处理方式，当任务执行过程中，某个节点异常，切换新节点重新执行，随机数据会发生变化，导致数据异常。
全文会围绕以下三方面内容展开：
京东零售流量数仓架构
京东零售场景的数据处理
数据处理架构未来探索
01京东零售流量数仓架构
1. 京东零售——流量简介
① 什么是流量？
简单来说，流量就是用户作用在京东页面上，产生一系列行为数据的集合。
这些数据是如何流转到数仓的呢？
2. 京东零售——流量数据处理架构
3. 京东零售——流量数仓分层介绍
数据流转到数仓会进行一些统一化的管理，数仓是如何分层的呢？
受京东业务复杂度和数据体量的影响，整体分层较细，分为：数据缓冲层（BDM）、贴源数据层（FDM）、基础数据层（GDM）、公共数据层（ADM）、应用数据层（APP）五层。
① BDM层
是源业务系统的一些数据，会进行永久性保存。
② FDM层
③ GDM层
按照主题域进行标准化封装，整体会屏蔽生产系统干扰，同时会处理数据回灌事情。
④ ADM层
ADM是公共数据层，面向主题、面向业务过程的数据整合，目前划分成两层：ADM-D、ADM-S。
ADM-D负责统一的数据口径封装，提供各主题统一维度和指标的最细粒度数据；
ADM-S提供各主题统一维度和指标的聚合数据， 为各业务方提供统一口径的共享数据。
⑤ APP层
数据看板的数据整合，也可以进行一些跨主题的聚合数据处理。
⑥ 维度层
DIM层主要就是一些通用的维度数据。
基于以上的数仓分层方案，来看下京东流量数仓架构在离线和实时上别分是如何处理的。
4. 京东零售-流量离线数仓架构
① 基础数据层
离线数仓最下面一部分是基础数据，主要面向实体模型建设，按照数据渠道和不同类型做数据整合，例如渠道：app、pc、m等；日志类型：浏览、点击、曝光等。
② 公共数据层
③ 应用数据层
应用层主要是面向数据看板的建设，提供预计算和OLAP两种方式服务模式，这一层整体上会很薄，重点解决数据引擎查询效率问题，高频访问的维度提供预计算、低频应用的数据由OLAP方式提供数据服务。
④ 数据服务层
5. 京东零售——流量实时数仓架构
实时数仓与离线数仓的建设理念是基本一致的。
RDDM是分渠道、分站点、分日志类型的实时数据流，构建过程中主要考虑解耦，如果只消费部分数据，依然需要全量读取，对带宽、i/o都是一种浪费。同时，也方便下游按照业务实际情况进行数据融合。
以上主要介绍了京东流量场景的数据处理架构，接下来我们结合一个京东实际案例，讲述京东特殊场景下的数据处理方案。
02京东零售场景的数据处理
1. 京东零售——流量挑战
首先是数据爆炸式的增长。2015年至今，整体的数据量翻了约十几倍，但资源情况并没有相应成比例的增长。其次，业务的复杂度升高，包括新增了小程序、开普勒、线下店的一些数据以及并购的企业的数据等，因此整体的数据格式以及完备度上还是存在较大差异的。再次，随着业务发展，流量精细化运营的场景增多，但数据服务的时效并没有较大变化，需要我们在有限时间内处理一些更多更大体量的数据，以满足更多场景化应用。特别是京东刷岗这样的场景，对数据的范围、需要处理的数据量，以及数据时效都是一个比较大的挑战。
2. 海量数据更新实践——刷岗
什么是刷岗？将发生在该SKU的历史事实数据，按照最新的SKU对应运营人员、岗位、部门等维度信息，进行历史数据回刷。
刷岗在京东也经历了多个阶段，从最初数据量较小，采取全量刷岗的模式，后续逐渐升级成增量的刷岗。后续采取OLAP的刷岗模式，也就是将数据写到CK中，通过Local join进行关联查询。目前我们通过iceberg+olap的方式来实现数据刷岗。
首先构建iceberg表；其次、对流量商品表的更新处理，将所有会发生变化的字段拼接做MD5的转化，后续每天做这种差异化的判断，如果有变化就做upsert操作；最后，生成的流量商品表与事实表进行merge into，进而得到刷岗更新后的数据；同时在此数据基础上，针对不同应用频率的数据，采取了预计算和OLAP两种数据服务模式。
通过数据湖的方式来实现数据更新，相比于hive存储格式，支持多版本并发控制，同时支持ACID事务语义，保障他的一致性，数据在同一个批次内提交，要么全对，要么全错，不会更新一部分。另外，支持增量数据导入和更新删除能力，支持upsert操作，整天数据处理的复杂度要降低很多，同时在资源的消耗和性能以及数据处理范围上较hive端模式都有了极大的提升。
基于数据湖的模式进行刷岗目前还面临数据倾斜的问题需要解决。
3. 数据倾斜治理方案
① 数据倾斜的原因及处理方式
数据倾斜出现的一个主要原因是数据分布不均，出现热点key。对于数据倾斜的处理方案，比较常见的有：优化参数，如增加reduce的个数、过滤一些异常值、赋随机值，或者按经验值设置固定阈值，把大于某阈值的数据单独处理。赋随机数的处理方式，当任务执行过程中，某个节点异常，切换新节点重新执行，随机数据会发生变化，导致数据异常。通过这种经验值设定阈值的一个弊端是，在不同的场景下，不容易界定阈值大小，包括对于热点key的识别，通常也只能事后发现处理。
② 数据倾斜的解决方案
基于此，我们在探索的过程中建立了一套智能监测倾斜的任务。
首先，利用实时的数据，提前对数据进行监测，针对数据分布特点，通过3倍标准差确定离群点，离群点即倾斜阈值。
其次，根据倾斜阈值计算分桶数量。
最后，按照对列资源在不同时段的健康度进行作业编排。
③ 如何寻找热点key及倾斜阈值
热key寻找的核心思想，就是根据数据的分布特点，通过3倍标准差确定离群点，离群点即倾斜阈值，如下图所示，整体的数据是呈右偏分布，我们通过两次3倍标准差得到最后的倾斜阈值X2。
第二步计算分桶的数量，根据整体的数据分布情况看，第一阶段的拒绝域面积与第二阶段的拒绝域面积相等。根据积分原理，频率绝对数与频次绝对数呈反比，因概率密度分布曲线未知，所以用两次离群点的频次均值比例，代表两次抽样数据量比例，进而得到分桶数。
④ 数据分桶作业
最后是作业编排，一次性起多个任务会出现资源获取不到，一直处于等待状态，同时对其他的任务也会产生较大影响，并发少了又会带来资源浪费，针对这类问题，我按照对列资源的健康度，对执行的任务做了编排，由整体串联执行和固化并发，调整为按资源健康度动态扩展，实现资源利用最大化。
03数据处理架构未来探索
1. 未来探索方向
首先，目前我们基于Flink+Spark的方式来做流批一体的探索。图中可以看到传统的Lambda数据架构有一个很大的特点：实时和离线是两套不同的数据链路。整体的数据处理过程中，研发的运维成本相对较高，而且两条不同的数据链路，会容易导致数据口径上的差异。
后续通过FlinkSQL+数据湖存储实现同一套代码两种计算模式，同时保证计算口径一致性。同时也会有一些挑战，开发模式的改变，CDC（change data capture）延迟目前是分钟级延迟，如果调整为秒级，频繁提交，会生成很多小版本，对数据湖的吞吐量造成影响，总体来说，在部分应用场景下存在一定局限性，但分钟级延迟可以满足大多数的实时应用场景，对于研发成本和效率都会有较大提升，当然，目前也在不断的完成和探索。总体来说，目前在一些特殊场景下具有一定的局限性。
04问答环节
Q：分桶的应用效果？
A：总结成几个点就是：
从事后处理转变为事前监测。
不同周期、不同场景下动态计算倾斜阈值和分桶数量。
根据对列资源健康度动态扩展任务并发数量，实现资源利用最大化。
Q：Spark的应用在京东场景里最小的延迟是多少？
A：目前主要是基于小站点数据去做探索，数据处理量级比较小，目前延迟大概在分钟级左右，如提交的频率增大，对于io的性能会是一个很大的考验。
A：目前的版本可以支持行级更新，关于分区这部分主要还是结合业务特性，在设计分区时，尽量让变化的数据都集中到少部分文件上，降低文件更新范围。