看亿级用户电商如何玩转SQL大数据

 

(图摘自微博，侵删）

据艾瑞咨询的报道，2017 年中国家电行业，苏宁是最大的市场占有者。线上线下的组合，占据整个行业的 20.0%. 是京东（12.3%）和国美电器（7.5%）之和，而天猫已被拉入了第三阶梯，比较起来毫无竞争力。

 

 

 

 

 

我认为家电行业要赶超前三位的占有者，首先就要看懂他们的数据，因此数据工程在整个行业分析上，都已经占据极其重要的战略地位。

 

苏宁首当其冲，它目前使用的数据工程，包括数据基建，数据应用都将是其他家电竞争者知识库中重要的战略武器。作为一名数据工作者，了解了苏宁集团的数据工程，对你的求职，事业的突破都将有重要的意义。

 

在《极客时间》上看到了苏宁 OLAP 引擎的分享，自是兴奋不已的要将它看个透，且分享出来让更多人知晓。

 

所有有些规模的家电零售类集团公司，在2019年这个时间档口，基本都完成了线上线下的铺设。从应用的大范围来讲，会包括两部分，一是离线的应用，二是在线的应用。反应到数据处理层面，则是异步批次处理与实时同步处理。

 

作为传统行业的数据仓库从业人员，我觉得下面的数仓结构对大家都应该不陌生：

 

 

 

 

从多个业务系统抓取数据，通过编制的 ETL 程序，将数据跑批进入数据仓库的数据模型中。前端通过报表工具，或自研或厂商提供，来展示各类关键指标数据，以便做进一步的决策。

 

自电子商务开展以来，尤其以淘宝的出现作为时间点（毕竟是中国首家规模化的电子商务应用），数据仓库的应用跨入了2.0的时代，除了要容纳离线门店的数据归档，还要实时的去处理在线应用的数据。苏宁正是这样的典型模式应用者。

 

一 、统一标准

 

在整个集团，如果将数据隔离成原先离线的应用和现有的在线应用，那么数据就会有“丢帧”出现。线上线下无法完成统一视图，资源就无法有效分配，比如部门沟通成本，基建重复建设以及数据口径变更不同步。因此集团的数据应用，目标就是要标准，要统一。

 

 

 

 

二、时序数据

 

在《极客时间》的《大规模数据处理实战》课程中，有一篇讲解到了批次处理与流式处理。作者从边界角度去观察数据，将没有边界的数据称为流式数据，将有边界的数据称为批次数据。我理解的边界角度，应该是时间边界。

 

在无限长的时间角度来看，数据会源源不断的流入到系统里面，比如用户日志，用户评论以及用户事件，无非是在频次上不固定，每个人不可能每天都一时间上网聊天，看新闻，发微博。放在他的一生时间维度上，他\她所产生的数据，都是在不停地流入到手机、平板等移动应用中。这个角度来观察数据，数据就是流式的。

 

但我们在观察人产生数据的时候，盖棺定论的做法恐怕是不够的。我们需要知道更细粒度的时间维度内，这个人发生了哪些变化。因此用批次处理，即每个特定时间去收集和分析他的数据，对于商业才是可行的。

 

所以，时序数据，在哪个商业应用中，都非常普遍。

 

时序数据，即时间序列数据。据《大规模数据处理实战》指出，时序数据会有两个状态：发生和处理。

 

一个现象或者事件发生了，给它盖一个时间戳，这就是发生时间；如果事件发生了，没有被捕获、感知，那也就不会被处理，即数据失帧，失去了意义。一旦数据被捕获、感知，我们就可以对其进行处理，此时我们给它盖上一个时间戳，叫做处理时间。

 

时序数据的这两个时间戳，成为我们处理数据的两个关键。

 

时序数据，根据其发生频次，继而可分为两类：规则和不规则时序数据

 

很多loT监控工具提供的便是规则时序数据，比如传感器，每个特定时间发送一个观测数据，这类数据因为发生频次固定，有强规则性，我们称之为规则数据；而例如支付宝app的个人支付数据，则是不规则的时序数据，个人不会每隔一分钟或者十分钟去用支付宝支付购买一个商品。

 

苏宁集团每天有着300G+的数据产生量，如此规模，为什么要选择Druid，而不是一般的RDBMS来存储呢？这个问题本质也是为什么要开发一个时序数据库的原因了。

 

 

 

 

计算广告厂商，Google 可以拿来做很好的例子。作为Google，他掌握着天然的广告入口渠道和出口投放渠道。

 

广告入口渠道，就是流量。每个网站的流量都在Google的数据库里存着，这个网站是否具有投放广告的必要，Google都可以计算的出来。一旦有必要，Google就会在其网站上投放广告，通过流量点击广告，记录点击次数，就可以跟广告主计算广告费用。处于计算的需要，Google在搜集点击量的时候，就会用到时序数据。

 

就像上图所示，Google监控了三个广告源的广告点击情况，在特定时间点上进行采集，形成了时序数据流。

 

 

 

 

单值，多值的时序数据，仅仅是格式不同而已，对于业务来说，并没有不同。

 

Google看上去是家高精尖的科技公司，但从盈利分布来分析，其实它是家不折不扣的广告公司

 

 

 

谷歌母公司Alphabet发布了2019年第二季度业绩。受益于移动搜索、YouTube和云计算业务的强劲增长，Alphabet第二季度总营收为389.44亿美元，比上年同期增长19%；第二季度净利润为99.47亿美元，同比增长211%，均超出市场预期。

 

谷歌仍不断从广告商那里获取大量营销资金。在Alphabet第二季度营收中，广告业务仍是谷歌收入最大的业务，占当季营收的83.7%。谷歌二季度广告收入为326.01亿美元，高于去年同期的280.87亿美元，同比增长16%；谷歌其他营收为61.81亿美元，高于去年同期的44.25亿美元。

http://tech.163.com/19/0726/14/EL143TFN00097U7R.html

 

326亿美金季度广告收入，换成年来算，那将是千亿级别收入，而且是纯现钞交易。

 

可想，并没有单一的一个网站可以产生如此之多的收益，必须是千万级，乃至是亿级共同的流量，才造就了如此强劲的广告收益。

 

这么多网站，同时要给Google去发送时序数据，仅靠 MySQL, Oracle 任何单一产品都将无法承受。应对如此频繁的增量实时数据，时序数据库应运而生。

 

先来考察下 MySQL/Hadoop 的生态：

 

MySQL: 存储成本：时序数据压缩不佳；维护成本：分库分表，人工复杂；写入吞吐低；查询性能差：聚合分析没有优势；

 

Hadoop:数据延迟高：离线批处理，数据从产生到可分析，耗时长；查询性能低：严重依赖MapReduce;

 

以下是几个常用的时序数据库，而苏宁采用的便是 Druid.

 

 

 

Druid 是典型的 Lambda 架构，能够将批次处理与实时处理有效隔离，在汇总层还能达到数据查询的一致性。非常适合搭建企业数据湖的项目。

 

 

 

 

那么 Kylin 在苏宁大数据架构中，扮演什么角色呢？

 

 

 

 

这就要说到非时序数据了。非时序数据在苏宁采用的存储主要是 PG (PostgreSQL, 一款开源数据库），通过对其改写，使其更好的与 Spark SQL 联合起来使用。在 PG 层，最终的结果是生成一系列依据维度建模创建的模型表。

 

 

 

 

这些模型表，对于细粒度查询是非常有用的，但聚合起来就费时了。因此使用 Kylin 做了预聚合，典型的使用空间换时间的做法。

 

 

 

 

做为一个完整的数据架构，必须由存储和计算组成。存储综上所述是分为时序与非时序两类，而计算更多采用的是 Spark SQL 来完成。

 

 

 

 

 

不是给做数据库的朋友故意制造焦虑，由上面的架构也看的出来，未来的数据应用更加偏向于场景定制化，哪种架构更适合用户应用场景，就会被构造出来，那种以数据库一招打遍天下模式的用法，已经一去不复返了！

 

 

 

 

 

精彩回顾：

 

禁用 SQL 游标，告诉你外面听不到的原因【内含福利】

SQL Join 不可不知的一点优化策略