分享大纲：
1、考拉数据发展简介
2、数据仓库构建
3、数据营销业务实践
正文：
一、考拉数据发展简介
三年前，网易考拉开始构建数据仓库，虽然借助了部分网易集团技术实力，但整个过程还是面临着诸多挑战，大致分为以下四方面：一是业务复杂、变化快。与普通电商平台相比，跨境电商的产销流程和仓储供应链都相对复杂，且受到政策，比如税改方面的影响更大;二是数据时效性，近年电商平台的大小促销活动频繁，业务方对数据实时或准实时要求增多，整个数据仓库的构建也在慢慢向该方向发展;三是海量数据产生的大量计算，元数据管理问题;四是数据质量，包括埋点的管理等。
针对以上四大问题，网易考拉将数据仓库建设分为四部分：数据仓库层级重构、数据仓库实时化、数据元数据管理、数据监控质量管理。
二、数据仓库构建
上图为网易考拉数据仓库层级重构变迁，从上到下依次分为四个阶段：
第一部分是初创阶段，起初并不需要复杂的数据技术，我们用oracle的dw就可以同步业务数据，但随着业务发展，这种方式很快就无法满足需求;
第二部分：该阶段，业务系统内部表可以通过etl计算做冗余，加速整个计算过程。随着数据仓库开发团队人员增多，大量中间件出现指标冗余现象，部分表无法重用等问题不断出现。
第三部分：该阶段我们主要做了两部分工作，一是对架构进行梳理，在dw中分出ods、cdm和ads三层;将部分计算引擎迁移至hive。
第四部分：继续减轻oracle部分的计算负担，将大部分oracle的etl计算部分任务迁移至hive重新计算。优化内部etl计算流程。
网易考拉数据仓库层级重构比较核心的工作是cdm层，该层主要包括三个部分――dws汇总层、dwd细节层以及dim公共维表层。我们会对每一个业务线做切分，包括用户，流量、交易，仓储物流都会做垂直切分，垂直切分的好处在于可以把数据仓库工程师分配到复杂的业务线，每个数据域都会有比较好的迭代和上线版本。需要注意的问题是，域和域之间不是完全隔离，比如用户域会涉及流量或者订单，线上对某个域进行开发时，我们通常会邀请其他域的工程师做评审。
为了支撑这种开发模式，其实我们需要有比较好的etl平台，该平台主要做三件事情，一是元数据管理，需要梳理清楚数据血缘关系，提供数据源管理，包括任务依赖调度等;二是数据质量;三是etl框架。数据起初来自于业务数据库或客户端服务器上的用户行为日志，通过网易自研的datastream日志服务收集数据，将数据同步到kafka，之后定时归档到hdfs。
如果是业务数据库，可以利用sqoop吧数据增量或者全量同步到数据仓库进行etl计算，并写到hdfs。最后数据信息同步到impala，提供线上查询，或者直接写到oracle或redis。在实时流部分，我们会写一些程序进行实时计算，然后把处理后的数据写到redis。但是这一整套计算流，在实际的数据业务中，我们发现了sqoop同步的两大缺陷。
第一个缺陷：以网易考拉为例，大小促之前通常会有一段预热期，在此期间某些业务会呈爆发式增长。例如：优惠券，这部分数据量明显增大对数据运维工作造成很大挑战。sqoop凌晨同步的方式，很容易在一个时间点，产生较大的数据同步压力。
第二个缺陷：数据时序问题，搜索和推荐中有一个非常重要的指标叫线上商品转化率，它的数值取决于购买人数和商品uv的比值。订单交易任务表里用sqoop同步最快可以做到分钟级，但流式计算可能是秒级或者毫秒级延迟，所以会导致指标偏小，如果使用该数值就可能造成一定算法风险，基于此，我们内部也进行了一些尝试。
一个简单的解决方案是，在kafka里产生并消费一个订单消息队列。这种方法，虽然可以保证用户行为日志和订单消息时序一致，但很难在线上大规模推广，因为业务部分的日常版本发布，或者开发压力非常大，这类后端数据埋点很难在线上要求所有业务场景都把消息打出来，这是不可持续的。当然，2.0版本中sqoop已经可以连接到kafka，但网易内部用得比较少。
网易考拉目前的解决方案是自研ndc产品做数据同步消费，增量订阅。ndc实际上就是用binlog的方式把数据变更转化成流式消息传到kafka。当然，线上除了mysql或者redis，oracle本身也支持到线上kafka之类的消息同步。通过这种方式，我们可以在不影响线上业务的前提下，拿到线上业务数据变更记录。
网易考拉内部配合ndc一起使用的是kudu，因为需要线上olap做分析，所以kudu这种实时产品的表更新和事务查询就比较适合提供线上实时数据仓库表，同时也会用kudu做一些存储。对于实时和离线混合的查询，我们建议使用impala，它可以和kudu很好集成。通过改造，整个数据仓库的实时化就可以落地实现了。
上图为改造后的数据仓库架构图，业务数据库里的数据通过ndc无时差打到kafka上，原来的非结构化日志通过datastream也可以打到kafka。上层可以通过流式计算引擎，比如sparkstreaming或者jstorm来做实时化。如果是相对简单的系统，jstorm性能会比较好，如果是线上用户路径分析等微批处理任务，建议用sparkstream。当然jstorm目前也可以实现类似mini-batch的功能。实时报表、实时数仓流量表或交易量以及线上用户行为日志分析、异常分析等几大场景均可以支持。
对于离线部分，部分离线场景会使用上述模式替代，比如凌晨同步大量全量或增量日志，给数据库或集群造成巨大负担等场景，我们可以使用该方式将计算或者同步分担到全天24小时里。
数据仓库实时化改造完成之后，我们主要关注的两件事情是监控系统和数据地图。监控系统在网易内部有很多平台支撑，我可以举一个例子，比如一个典型的监控系统可能分为三部分，最底层是哨兵监控，也就是数据接口和数据产品监控，可以看到内存cpujvm的一些情况;中间一层是猛犸大数据平台监控，包括impala、集群部分整体调度以及数据产品本身的任务流运行监控;最上层是业务指标监控，可能涉及业务、系统、模块和指标的一些监控。
在数据地图部分，数据地图所做的工作就是到数据仓库或业务系统的数据库里同步元数据，经过处理清洗之后，写到es里面做索引。对于静态信息，我们可以解析静态azkaban配置文件，将依赖关系写到es之中。此外，我们还会对表依赖关系进行分析。
以上为数据地图的架构图，以下为数据地图的产品界面：
在数据地图中，如果具体到某一张表，我们可以看到非常丰富的元数据信息，包括表的负责人、数据量级以及表更新记录。至于表级别的依赖血缘关系查询，任何表在系统里都能把依赖关系进行查找放大并还原，这对整个etl数据建设非常有帮助。
在数据业务实践部分，大部分开发人员第一个上线的产品可能都是报表，做bi或者数据仓库方向的开发人员对报表的依赖程度非常大。所以，我们认为报表是非常重要的应用。我们将报表分为两类，一类是普通报表，比如没有交互作用的邮件数据报告，这类报表目前我们是在网易有数里面进行配置。只要准备好数据源，基本不需要经过太多数据技术，业务方可以直接在系统里选择数据源，然后根据业务要求选择维度，或者说根据某个指标就可配制出简单没有交互的报告，这部分目前基本能够覆盖我们所有报表需求，因此不需要报表类工程师;另一类是进化报表，相对来说技术门槛更高，下图为交易构成模块概况，以美容彩妆bu为例，销售额、流量等情况都可以在该报表中显示出来。
大部分业务方在看报表时，通常希望可以通过报表发现并解决问题。在网易考拉的系统中，业务方可以下钻bu上的每一个商品，通过某些条件筛选，可以发现一些商品问题，比如如果商品的毛利下降，我们可以通过单品查询细化毛利组成，看到底是采销成本下降了还是物流运营成本下降了。这种一站式分析诊断问题的方式对业务方而言很重要，毕竟他们最关注的就是数据问题的结论。该系统目前存在的问题也是数据仓库的后续发展中会碰到的问题，如何更彻底的把数据变现，变成生产资料。
在整个电商运营环境中，最能体现数据价值的方式，就是把数据化运营做到极致。在数据生产资料部分，网易考拉接下来的工作会集中在个性化推荐、个性化营销、用户画像服务、算法数据特征库、实时数据仓库、商品标签服务以及数据接口服务方面。其中数据营销业务是最符合数据化运营的业务场景。
三、数据营销业务实践
数据精准营销面临的问题在于如何找到目标人群、如何适配最优资源营销策略以及如何节约成本。对技术人员而言，营销广告的核心问题就是为多组用户与环境组合找到最合适的广告营销投放策略以优化整体广告活动利润。在最优化方面，如果用a代表整个营销收益最大，那么a等于1表示的是历次广告投放，如果用r代表广告收益，q表示广告成本，在这个关系中，q的值是比较好控制的，因为短信营销或者市场投放广告的成本是明确的。在成本固定的情况下，我们如何做广告投放呢
假设：
r函数内影响参数定义;
a表示本次投放的广告(例如:以商品，品牌，类目，活动生成的营销主题);u表示广告投放的用户群体;
c表示广告的环境，场景(包括上下文场景，资源位，弹窗，邮件edm等触达方式)
如要解决广告收益最优化问题，那么有四件事情可以做，一是定制化用户分群(受众定向)，也就是刻画网易考拉的用户画像。二是标签人群查询(查询引擎)，让营销人员或者非技术人员可以通过查询引擎到系统里探索人群;三是资源广告投放服务(投放引擎);四是营销效果反馈平台(a/b效果评估)。
以上为产品梳理出来的业务流程图。以前，网易考拉基于数据和用户画像进行投放，从提需求、拉取人群到找营销资源、沟通成本文案，一个方案在线上跑起来大概需要3到5天，大的方案可能需要一个礼拜，还不包括线下评估效果。现在，业务方只需要做三件事情――配方案、找用户、看效果。从去年至今，网易考拉已经有一万多方案，平均每天可跑30多个方案，这其中还不包括探索性配置标签方案。现在的瓶颈不在于我们可以投放多少方案，而在于业务方可以想出多少营销策略，只要他们想得出，我们就可以实现。
在受众定向―标签挖掘分层部分，主要分为四个层次。首先是模型层，该层数据来源于数据仓库层级重构架构图cdm部分的dwd细节层;其二是物料层，该层可以根据用户行为属性或者偏好在产品层面对标签进行分类，标签不需要用户主动填写，我们可以通过相应算法进行挖掘;其三是标签层，根据用户标签对其进行分类，系统会根据标签筛选出符合本次营销活动的用户;其四是应用层，在标签层完成工作的基础上，应用层可以通过各大资源位、搜索推荐位或者短信优惠召回等方式开展营销活动。
其中，用户标签挖掘涉及用户生命周期、用户属性、潜在购买以及用户价值等指标，后台每天会更新和计算一些指标，如果根据具体条件对用户进行筛选，比如购买天数，其实跨度还是很大的。我们在线上统计过人类可以选择并覆盖的标签数量最多为10个，超过这个上限，运营人员会很难理解。所以，算法标签，标签挖掘，智能化是必选项。
对于标签挖掘部分，我以身高体重为例具体讲解面临的问题。在用户没有主动上传身高体重参数的情况下，我们可以通过用户的历史购买情况进行计算，但这种方式的覆盖率不是很高，尤其是品类较少的运动户外类服装。此时，我们也会考虑用户的收藏加购情况，也就是计算有效点击情况。计算身高体重有两个问题。第一个问题，网易考拉现在可以开通黑卡服务，很多用户可能会以家庭为单位购买，这里就要解决一个账号对应多个用户的关系。第二个问题，如果其中有小孩子，那么随着年龄的成长，孩子的身高体重会发生很大变化，我们会选取某人最近购买往前三年的时间做一个成长曲线补偿。对于不同品牌之间的尺码偏差，我们会在底层进行身高体重合并等操作。
线上挖掘部分，我们也会做用户购买行为预测，判断未来某用户是否会发生购买行为，这部分涵盖全站类目级别。本质上，我们会抽取历史67天左右的特征，选择前60天的数据进行特征训练，选择剩下7天的数据进行模型打标。
整个过程涉及的特征类型众多，此处列举了一小部分供参考：
虽然决策树可以把每一个特征和路径记录下来，但是很多机器学习算法都是黑盒测试，即便转化率很高，也很难和业务方说清楚转化率高到底是什么原因�...