数据平台的4个阶段:从数据库到数仓再到中台,超详细的架构全解( 二 )


最终 , 随着客户、订单和外部流量的逐步上升 , 数据量从GB发展成TB级别 , 数据库通过普通查询存在较大的压力 , 只能做升级改造 , 于是就有了数据仓库的诞生 。
2、数据仓库阶段
随着业务指数级的增长 , 数据量增长的同时公司的组织架构慢慢变得庞大、复杂 , 面临的问题也越来越多 , 越来越深入 。公司上层关心的问题 , 从最初简单的想知道“昨天、今天的GMV”、“上周的PV、UV是多少”、“某品类商品的环比、同比的增长比例是多少” , 慢慢演化到希望通过数据进行精细化运营和用户的价值模型分析 。
希望通过数据统计/分析/挖掘 , 分析出用户在某种特定的使用场景中 , 比如“18~25岁女性用户在过去三个月对服装类商品的购买行为与节假日促销活动之间的关系” 。
当公司运营和高层 , 提出此类非常具体的case , 希望通过数据统计/分析/挖掘对公司运营决策起到关键性作用的问题 , 其实是很难从业务数据库从直接调取出来 。
原因是由于数据库是面向事务的设计 , 数据仓库是面向主题设计的 。数据库一般存储在线交易数据 , 为捕获数据而设计 , 在设计上数据库是尽量避免冗余 , 一般采用符合范式的规则来设计 。
比如 , 业务数据库中的数据结构是为了完成商品交易而设计的 , 不是为了查询和分析的便利设计的 。数据仓库存储的一般是历史数据 , 为分析数据而设计 , 在设计上是有意引入冗余 , 采用反范式的方式来设计 。
数据库和数据仓库两个基本的元素都有维表和事实表 。(维表是看问题的角度 , 比如时间 , 部门、人 , 维表放的就是这些东西的定义 , 事实表里放着要查询的数据 , 同时有维表的ID) 。
因此 , 数据仓库的出现 , 并不是要取代数据库 , 而是为了更好的做数据分析和报表需求分析 , 主要处理OLAP(联机分析处理)需求 。
但是 , 随着客户、订单和外部流量的逐步上升 , 数据量从TB发展成PB级别 , 原来的技术架构越来越不能支持海量数据处理 , 这时候又有了数据平台的诞生 。
3、数据平台阶段
第一、企业业务系统过多 , 彼此数据没有打通 。涉及分析数据的过程当中 , 需要先从各个系统寻找到相应的数据 , 然后提取数据进行整合打通 , 才能做数据分析 。在这个过程中人为进行整合出错率高 , 分析效果不及时 , 导致整体的效率低下 , 数据迁移、数据同步的滞后与错误;
第二、业务系统压力大 , 架构相对笨重 , 做数据分析计算消耗资源很大 。需要通过将数据抽取出来 , 经过独立服务器来处理数据查询、分析任务 , 来释放业务系统的压力;
第三、性能问题 , 公司业务越来越复杂 , 数据量越来越大 。历史数据的积累严重 , 数据没有得到使用 。原始数据系统不能承受更大数据量的处理时 , 数据处理效率严重下降 。
于是 , 通过整合Hadoop/Spark/Storm/Flink等分布式的离线与实时计算框架 , 建立计算集群 , 并在上面运行各种计算任务 , 搭建大数据平台 , 使得平台具有数据互联互通、支持多数据集实时同步、支持数据资源管理 , 实现多源异构数据的整合管控能力;
可以提供完善的大数据分析基础运行环境 , 提供统一二次开发接口等能力的 , 用这些能力来解决大数据存储与计算问题 , 提升数据分析效率以及用户画像系统/推荐/搜索系统的运用落地 。
(此处已添加小程序 , 请到今日头条客户端查看)4、数据中台阶段
数据量的指数级增长 , 从PB发展成EB级别 , 为了更好的赋能业务 , 企业启动中台战略 , 打通各个业务线的数据 , 整合汇集数据 , 在底层通过技术手段解决数据统一存储和统一计算问题 。
在数据服务层通过数据服务化的Data API的方式 , 打通数据平台和前台的业务层对接 , 结合算法 , 把前台业务的分析需求和交易需求直接对接到中台来 , 通过数据中台处理和逻辑运算 , 然后在反向赋能业务 , 真正做到意义上的『一切业务数据化 , 一切数据业务化』 。


推荐阅读