创新的数字化！企业想赚更多钱，是怎么和大数据平台扯上关系的？
你有没有经历过以下的场景：今天刚刚说到想买一个东西，然后点开某个应用，搜索一个名字，再次打开就会发现它又给你推荐了，没错，这是靠技术实现的。
应该来讲，无论是传统企业还是互联网公司，都是针对目标用户，将产品通过合适的渠道（媒体网站、实体渠道、语音、短信等）进行推荐，从而刺激用户的购买，这是两者可以比较的基础。
今天就和大家来讲讲这个。
一、功能架构
不同公司实现的是有差别的，但万变不离其宗，其包括引擎、分布式计算平台，流计算平台等核心模块，如下图所示。
1、投放引擎
系统中必不可少的部分是一个实时响应请求、并决策的投放引擎。
2、分布式计算平台（离线数据处理）
最具挑战的算法问题大多集中在离线数据处理部分，离线处理有两个输出目标：
一是统计日志得到报表等，供决策人进行决策时作为参考。
二是利用数据挖掘、机器学习技术进行受众定向、点击率预估、分配策略规划等，为在线机器决策提供支持。
离线数据处理主要有很多模块，其中就包括BI系统：
（此处已添加小程序，请到今日头条客户端查看）
3、流计算平台（在线数据处理）
在线数据处理基本上可以认为是离线数据处理的镜像功能，它是为了满足系统对实时数据反馈的要求，解决那些离线分布式计算平台无法快速响应的计算问题，在线数据处理主要包括以下模块：
（1）在线反作弊: 实时判断流量来源中是否有作弊流量
（2）计费：这部分同样是关键的业务功能之一，对于预算耗尽的，必须马上通知索引系统将其下线。
（3）在线行为反馈：包括实时受众定向和实时点击反馈等部分，这部分是将短时间内发生的用户行为和日志及时加工成为实时用户标签以及实时的点击率模型特征，这部分对于在线效果提升的意义重大，在很多情况下，把系统信息反馈调整做得更快比把模型预测做得更准确效果更显著。
（4）实时索引：索引由于涉及预算调整等商业环节，因此必须在投放管理者调整以后实时的在线上索引中生效。
二、技术架构
技术架构很多是借鉴Google的，决定了其开源的性质，用开源技术可以解决基本所有的问题，以下是一张技术架构图：
1、WEB服务器
由于有高并发，低延迟的性能高要求，Nginx很多时候是首选的web服务器解决方案，但传统企业其实没有那么高的并发量，因此用weblogic等产品也是可以的。
2、全文检索引擎
实现一个功能全面、效率较高的倒排索引并不是一个简单的事，由于与核心业务逻辑关系不大，可以用开源工具Lucene。
3、数据高速公路
个性化系统并发高，日志量大，在这类系统中，应该避免对数据做单点的集中式读写，而是尽量应该让数据的处理形成环形的流动，即由数据高速公路将线上日志准实时地送至离线或在线处理平台，再将处理结果存放在缓存中供线上使用。
在这样的架构中，一个分布式，高吞吐量的数据传送通道至关重要。在这类工具中，Flume是比较常用的开源解决方案之一，笔者所在企业的营销系统原始信令数据等的采集即是通过Flume+kafka实现的。
3、分布式离线数据处理平台
Hadoop估计是当前业界的标配了，包括分布式文件系统HDFS，计算框架MapReduce，分布式配置和集群管理工具ZooKeeper等等。
4、特征在线缓存
无论是离线计算的受众定向还是点击率模型参数或特征，由于规模较大，一般都无法直接存在在广告投放机的内存中，而是要用独立的缓存服务，在线用的特征缓存有两个显著的特点，首先往往只需要存储简单的键值对，其次是大多时候需要支持高并发的随机读，Redis这种NoSQL数据库是一种解决方案。
5、流计算平台
Hadoop能够处理的数据规模相当可观，但处理的响应速度也难以保证，因此在线处理部分，需要一种新型的、能够以数据流的方式对线上日志准实时处理的平台作为基础设施，Storm，Flink等等都是可以考虑的。
6、跨语言通信接口
前面架构图中各个模块之间要广泛地进行数据交互，由于模块需求不同，有时我们会选用不同的开发语言来分别实现它们，为了方便在不同语言的模块之间实现调用接口，避免应用开发者过多将精力放在底层通信，开源社区也提供了Thrift此类产品来支撑。
三、传统企业精确营销系统的典型架构
下面示例了某传统企业的精确营销系统的一种典型架构，可以看到，其各个功能模块有事实上的映射关系。
1、标签平台
标签库以标签形式统一客户群数据的封装规范和操作风格，实现便捷的定向客户群计算和推送，支持各渠道精确营销的执行。
2、营销策略中心
提供营销策划功能，实现客户群、产品、渠道等营销策略的制定、管理和处理。
3、营销执行中心
基于规则实现与外围系统的互动，实现客户群的渠道投放。
4、营销评估中心
收集营销结果信息并对执行的效果进行评估。
5、大数据基础平台
为标签平台提供基础数据支撑，通过流处理的方式支撑营销执行中心的实时客群投放。
四、差距分析
来说说我认为最重要的两个差距吧。
1、线上的差距
现在所有大佬都在提企业的数字化转型，最关键的其实就是所有的数据都应该能采集到，而且要确保这些采集到的数据进行自由的流转。
而大量企业的数字化转型才开始，即使正在推进的企业在数据归集上也是困难重重。
就拿你到处能看到的企业摆摊为例吧，企业摆摊人员在为你受理业务的时候，有多少是有数字化设备支撑的？他们今天咨询、受理的所有信息是否都实时的回传到自己企业的数据中心，这些企业的数据中心能否实时的给出分析和服务的建议？
评估一个企业的数字化能力，其实不用去看它的数据中心，看看它一线人员所使用的设备和系统就可以了。
数据有去无回是很多企业的通病，而数据回不来就就没有评估的可能，更谈不上优化。企业渠道管理的复杂性，大量的线下操作导致了这种现象。
即使你从线下好不容易拿回来了数据，但你的优化迭代速度显然跟线上直接回来差了一个量级。
最近我们在做模型的线上自动迭代，以前优化一个模型1个月，现在只要1天，我们也许并不是做不好模型，而是迭代的次数太少了，这个又是受限于线上的能力。
2、实时的差距
在技术层面，传统的精确营销系统，最大的差距就是实时的能力。前面的在线系统的拥有的实时能力是一般企业精确营销系统难以项背的。
比如实时的点击率模型、实时的全局收益最优模型、实时的用户标签、实时的反作弊及实时的上下文等等，而传统企业的精确营销系统，基本都是以离线分析和建模为核心的。
对于传统的精确营销系统来说，推荐数据的更新往往还停留在以天甚至月为周期的阶段。比如产品推荐大多依赖于T-1的数据进行，你上午刚办了个业务，有可能下午它还会给你推荐同样的业务，比如营销人员今天配置了策略，明天才能生效，这就是受限于实时的能力。
当然企业做营销不能为了实时而实时，但有一点要明确，大数据的4V特征中，实时是一个关键特征，因为时间意味着信息量的差异，而信息量决定了价值，能从实时中挖掘出多少价值取决于企业对于业务和场景的理解。
实时化的趋势是不可能改变的，只要你的企业希望能更好的理解用户，希望能为户提供更好的服务，你的企业就要具备实时感知用户的能力。
现在实时数据中台崛起是一种很好的趋势，实时数据中台是用来改变企业营销基本面的，而不是做个实时应用了事。
当然实时的技术有很多类型，适用不同的场景，采集类的如flume、kafka，处理类的如flink，storm，查询类的如redis、hbase、分析类的如kylin、ES等等。
可以看到，虽然企业的精确营销系统和在线系统有很大的相似性，但受限于企业的客观条件，还是需要结合自己的实际一步步来演进。
里面有很多值得借鉴的东西，特别是技术层面，说它是顶尖的不为过。
立即沟通
