(图摘自微博，侵删）
据艾瑞咨询的报道，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 来完成。
不是给做数据库的朋友故意制造焦虑，由上面的架构也看的出来，未来的数据应用更加偏向于场景定制化，哪种架构更适合用户应用场景，就会被构造出来，那种以数据库一招打遍天下模式的用法，已经一去不复返了！
精彩回顾：
