网易考拉经过3年多的发展，已经成为中国领先的跨境电商平台。随着业务的飞速发展，如何支撑庞大的数据业务和需求，实现用户生命周期管理和个性化营销，已成为数据技术团队的关键问题。本次分享包含：1.考拉大数据架构的变迁升级历史;2.我们如何收集并计算全站数据，并进行高效的ETL开发和数据仓库建设。3.基于受众定向技术产生的海量算法规则标签，如何进行高性能的用户画像查询和探索;4基于个性化技术，如何实现海量个性化营销方案自动部署实施和AB效果追踪。
分享大纲：
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小时里。
数据仓库实时化改造完成之后，我们主要
