干货 | Apache Doris在小米集团的运维实践

Posted 2022-03-19 小米技术

本期技术干货，我们邀请到了小米OLAP引擎研发工程师魏祚、小米存储计算引擎SRE工程师孟子楠，和大家从运维的角度分享Apache Doris在小米集团的应用实践。

一、背景

为了提高小米增长分析平台的查询性能以及降低平台的运维成本，2019年9月小米集团首次引入了Apache Doris系统。在过去两年多的时间里，Apache Doris在小米集团得到了广泛的应用，目前已经服务了增长分析、集团数据看板、天星金融、小米有品、用户画像、广告投放、AB实验平台、新零售等数十个业务，如图-1所示。在小米集团，质量就是生命线。随着业务持续增长，如何保障线上Doris集群的服务质量，对集群的运维人员来说是个不小的挑战。

图-1 Apache Doris在小米的业务分布

二、集群部署和升级

基于Apache Doris社区发布的稳定版本，小米也维护了内部的Doris分支，用于内部小版本的迭代。由于和社区编译Docker第三方库的硬件环境存在差异，基于社区Docker编译出的Doris二进制包运行在小米的线上环境会有问题，因此小米内部也维护了自己的Docker镜像，用于内部Doris分支的编译和发版。内部发版时，在Docker容器中会完成源码的编译和打包，并通过Minos将二进制包上传到Tank Server（小米内部的版本仓库），小米内部的Doris发版流程如图-2所示。

图-2 小米内部的Doris发版流程

Minos 是小米自研并开源的一款基于命令行的大数据基础组件部署和进程管理系统，支持Doris、HDFS、HBase、Zookeeper等服务的部署和管理。在小米内部，包上传、集群部署、集群下线、集群升级、进程重启、配置变更等操作都可以通过Minos完成，Minos对于服务的管理依赖于配置文件deployment-config，其中配置了服务版本信息、集群的节点信息、集群的配置参数等信息。部署集群时，Minos会根据deployment-config中配置的服务版本信息从Tank Server上拉取对应的二进制包，并根据deployment-config中配置的节点信息和集群参数部署集群。在集群部署之后，如果进程意外挂掉，Minos会自动拉起进程，恢复服务。

轻舟是小米自研的分布式服务生命周期管理平台，贯穿大数据分布式服务从需求评估开始到资源下线结束的生命周期互联互通管理，主要由发布中心、巡检中心、运营数仓、环境管理、故障管理、容量管理等组成，各模块之间逻辑互联、数据互通，如图-3所示。轻舟发布中心提供了可编排、低代码、可视化的服务发布和进程管理能力。轻舟发布中心底层依赖Minos，因此，可以基于轻舟对Doris服务实现平台化管理，包括集群部署、集群下线、集群升级、进程重启、配置变更等操作，如果Doris的FE或BE进程意外挂掉，轻舟会自动拉起进程，恢复服务。

图-3 轻舟管理平台

三、业务实践

Apache Doris在小米的典型业务实践如下：

（1）用户接入

数据工场是小米自研的、面向数据开发和数据分析人员的一站式数据开发平台，底层支持Doris、Hive、Kudu、Iceberg、ES、Talso、TiDB、mysql等数据源，同时支持Flink、Spark、Presto等计算能力。在小米内部，用户需要通过数据工场接入Doris服务。用户需要在数据工场进行注册，并完成建库审批，Doris运维同学会根据数据工场中用户提交的业务场景、数据使用预期等描述进行接入审批和指导，用户完成接入审批后即可使用Doris服务，在数据工场中进行可视化建表和数据导入等操作。

（2）数据导入

在小米的业务中，导入数据到Doris最常用的两种方式是Stream Load和Broker Load。用户数据会被划分为实时数据和离线数据，用户的实时和离线数据一般首先会写入到Talos中（Talos是小米自研的分布式、高吞吐的消息队列）。来自Talos的离线数据会被Sink到HDFS，然后通过数据工场导入到Doris，用户可以在数据工场直接提交Broker Load任务将HDFS上的大批量数据导入到Doris，也可以在数据工场执行SparkSQL从Hive中进行数据查询，并将SparkSQL查到的数据通过Spark-Doris-Connector导入到Doris，Spark-Doris-Connector底层对Stream Load进行了封装。来自Talos的实时数据一般会通过两种方式导入到Doris，一种是先经过Flink对数据进行ETL，然后每隔一定的时间间隔将小批量的数据通过Flink-Doris-Connector导入到Doris，Flink-Doris-Connector底层对Stream Load进行了封装；实时数据的另一种导入方式是，每隔一定的时间间隔通过Spark Streaming封装的Stream Load将小批量的数据导入到Doris。

（3）数据查询

小米的Doris用户一般通过数鲸平台对Doris进行分析查询和结果展示。数鲸是小米自研的通用BI分析工具，用户可以通过数鲸平台对Doris进行查询可视化，并实现用户行为分析（为满足业务的事件分析、留存分析、漏斗分析、路径分析等行为分析需求，我们为Doris添加了相应的UDF和UDAF）和用户画像分析。

Doris的数据导入和数据查询方式如图-4所示。

图-4 Doris的数据导入和数据查询方式

（4）Compaction调优

对Doris来说，每一次数据导入都会在存储层的相关数据分片（Tablet）下生成一个数据版本，Compaction机制会异步地对导入生成的较小的数据版本进行合并（Compaction机制的详细原理可以参考之前的文章《Doris Compaction机制解析》）。小米有较多高频、高并发、近实时导入的业务场景，在较短的时间内就会生成大量的小版本，Compaction对数据版本合并不及时的话，就会造成版本累积，一方面过多的小版本会增加元数据的压力，另一方面版本数太多会影响查询性能。小米的使用场景中，有较多的表采用了Unique和Aggregate数据模型，查询性能严重依赖于Compaction对数据版本合并是否及时，在我们的业务场景中曾经出现过因为版本合并不及时导致查询性能降低数十倍，进而影响线上服务的情况。但是，Compaction 任务本身又比较耗费机器的 CPU 、内存和磁盘IO资源，Compaction 放得太开会占用过多的机器资源，也会影响到查询性能，还可能会造成 OOM 。

针对Compaction存在的这一问题，我们一方面从业务侧着手，通过以下方面引导用户：

对表设置合理的分区和分桶，避免生成过多的数据分片。

规范用户的数据导入操作，尽量降低数据导入频率，增大单次导入的数据量，降低Compaction的压力。

避免过多地使用delete操作。delete操作会在存储层的相关数据分片下生成一个delete版本，Cumulative Compaction任务在遇到delete版本时会被截断，该次任务只能合并Cumulative Point之后到delete版本之前的数据版本，并将Cumulative Point移动到delete版本之后，把delete版本交给后续的Base Compaction任务来处理。如果过多地使用delete操作，在Tablet下会生成太多的delete版本，进而导致Cumulative Compaction任务对版本合并的进度缓慢。使用delete操作并没有真正从磁盘上删除数据，而是在delete版本中记录了删除条件，数据查询时会通过Merge-On-Read的方式过滤掉被删除的数据，只有delete版本被Base Compaction任务合并之后，delete操作要删除的数据才能作为过期数据随着Stale Rowset从磁盘上被清除。如果需要删除整个分区的数据，可以使用truncate分区操作，而避免使用delete操作。

另一方面，我们从运维侧对Compaction进行了调优：

根据业务场景的不同，针对不同集群配置了不同的 Compaction 参数（ Compaction 策略、线程数等）。

适当地降低了Base Compaction任务的优先级，增加了Cumulative Compaction任务的优先级，因为Base Compaction任务执行时间长，有严重的写放大问题，而Cumulative Compaction任务执行比较快，并且能快速合并大量的小版本。

版本积压报警，动态调整Compaction参数。Compaction Producer生产Compaction任务时，会更新相应的metric，其中记录了BE节点上最大的Compaction Score的值，可以通过Grafana查看该指标的趋势判断是否出现了版本积压，另外，我们还增加了版本积压的报警。为方便 Compaction 参数调整，我们从代码层面进行了优化，支持运行时动态调整 Compaction 策略和 Compaction 线程数，避免调整Compaction参数的时候需要重启进程。

支持手动触发指定Table、指定Partition下数据分片的Compaction任务，提高指定Table、指定Partition下数据分片的Compaction优先级

四、监控和报警管理

（1）监控系统

Prometheus会定时从Doris的FE和BE上拉取metrics指标，并展示在Grafana监控面板中。基于轻舟数仓的服务元数据（轻舟数仓是轻舟平台基于小米全量大数据服务基础运行数据建设的数据仓库，由2张基表和30+张维度表组成，覆盖了大数据组件运行时的资源、服务器cmdb、成本、进程状态等全流程数据）会自动注册到Zookeeper中，Prometheus会定时从Zookeeper中拉取最新的集群元数据信息，并在Grafana监控面板中动态展示。另外，我们在Grafana中还添加了针对Doris大查询列表、实时写入数据量、数据导入事务数等常见排障数据的统计和展示看板，能够联动报警让Doris运维同学在集群异常时以最短的时间定位集群的故障原因。

（2）Falcon报警

Falcon是小米内部广泛使用的监控和报警系统。因为Doris原生地提供了较为完善的metrics接口，可以基于Prometheus和Grafana方便地提供监控功能，所以我们在Doris服务中只使用了Falcon的报警功能。

针对Doris出现的不同级别故障，我们将报警定义为P0、P1和P2三个等级：

P2报警(报警等级为低)：单节点故障报警。单节点指标或进程状态发生异常一般作为P2等级发出报警，报警信息以小米办公（小米办公是字节跳动飞书在小米的私有化部署产品，功能和飞书类似）消息的形式发送到告警组成员。

P1报警(报警等级为较高)：集群短时间（3分钟以内）内查询延迟升高或写入异常等短暂异常状况将作为P1等级发出报警，报警信息以小米办公消息的形式发送到告警组成员，P1等级报警要求Oncall工程师进行响应和反馈。

P0报警(报警等级为高)：集群长时间（3分钟以上）查询延迟升高或写入异常等情况将作为P0等级发出报警，报警信息以小米办公消息+电话报警的形式发送，P0级别报警要求Oncall工程师1分钟内进行响应并协调资源进行故障恢复和复盘准备。

以上对报警类型和案例进行了简单举例，实际上为了维护Doris系统稳定，我们还会有形式多样、级别各异的报警和巡检。

（3）cloud-doris

cloud-doris是小米针对内部Doris服务开发的数据收集组件，其最主要的能力在于对Doris服务的可用性进行探测以及对内部关注的集群指标数据进行采集。

举例说明：cloud-doris会模拟用户对Doris系统进行读写来探测服务的可用性，如果集群出现可用性异常，则会通过Falcon进行报警；对用户的读写数据进行收集，进而生成用户账单；对表级别数据量、不健康副本、过大tablet等信息进行收集，将异常信息通过Falcon进行报警。

小米内部Doris服务的监控和报警系统结构如图-5所示。

图-5 Doris服务的监控和报警系统结构

（4）轻舟巡检

对于容量、用户增长、资源配比等慢性隐患，我们使用统一的轻舟大数据服务巡检平台来进行巡检和报告。巡检中一般包括两部分：服务特异性巡检和基础指标巡检，其中服务特异性巡检指各个大数据服务特有的不能通用的指标，对Doris来说，主要包括：Quota、分片副本数、单表列数、表分区数等；基础指标巡检主要指各服务间可以通用的巡检指标，主要包括：守护进程状态、进程状态、CPU/MEM/DISK、服务器故障及过保提示、资源利用率等。

通过增加巡检的方式，很好地覆盖了难以提前进行报警的慢性隐患，对重大节日无故障提供了支撑。

五、故障恢复

当线上集群发生故障时，应当以迅速恢复服务为第一原则。如果清楚故障发生的原因，则根据具体的原因进行处理并恢复服务，如果不清楚故障原因，则保留现场后第一时间应该尝试重启进程，以恢复服务。

（1）接入故障处理

Doris使用小米LVS作为接入层，与开源或公有云的LB服务类似，提供4层或7层的流量负载调度能力。用户通过VIP(域名)连接Doris集群。Doris绑定合理的探活端口后，一般来说，如果FE单节点发生异常会自动被踢除，能够在用户无感知情况下恢复服务，同时会针对异常节点发出报警。当然，对于预估短时间内无法处理完成的FE故障，我们会先调整故障节点的权重为0或者先从LVS删除异常节点，防止进程探活异常引发不可预估的问题。

（2）节点故障处理

对于FE节点故障，如果无法快速定位故障原因，一般需要保留线程快照和内存快照后重启进程。可以通过如下命令保存FE的线程快照：

通过以下命令保存FE的内存快照：

在版本升级或一些意外场景下，FE节点的image可能出现元数据异常，并且可能出现异常的元数据被同步到其它FE的情况，导致所有FE不可工作。一旦发现image出现故障，最快的恢复方案是使用recovery模式停止FE选举，并使用备份的image替换故障的image。当然，时刻备份image并不是容易的事情，鉴于该故障常见于集群升级，我们建议在集群升级的程序中，增加简单的本地image备份逻辑，保证每次升级拉起FE进程前会保留一份当前最新的image数据。

对于BE节点故障，如果是进程崩溃，会产生core文件，且minos会自动拉取进程；如果是任务卡住，则需要通过以下命令保留线程快照后重启进程：

六、结束语

自从2019年9月小米集团首次引入Apache Doris以来，在两年多的时间里，Apache Doris已经在小米内部得到了广泛地使用，目前已经服务了小米数十个业务，集群数量达几十个，节点规模达到数百个，并且已经在小米内部形成了一套以Apache Doris为核心的数据生态。为了提高运维效率，小米内部也围绕Doris研发了一整套的自动化管理和运维系统。随着服务的业务越来越多，当然Doris也暴露出了一些问题，比如没有比较好的资源隔离机制，业务之间会相互影响，另外，系统监控还有待继续完善。随着社区的快速发展，越来越多的小伙伴参与到了社区建设，向量化引擎已经基本改造完成，查询优化器的改造工作正在如火如荼地进行，Apache Doris正在逐渐走向成熟。

END

干货推荐：如何运维千台以上游戏云服务器——游族网络

干货推荐：如何运维千台以上游戏云服务器——游族网络

 

来自上海游族网络的运维总监李志勇，在3月4日云栖社区中带来的分享“如何运维千台以上游戏云服务器”。本次分享重点是云时代的运维，包括游戏上云部署整体方案、游戏服务器批量运维管理，并对企业选择RDS还是自建MySQL数据库给出了自己建议。

 

关于分享者：

李志勇，2010年加入游族网络，目前担任游族网络运维总监，全面负责游族网络运维业务。他具有十年运维工作经验，八年游戏行业从业经验，专注于游戏虚拟化技术和网络优化。

 

分享正文：

 

游戏产品架构进化史

 

 

图一：游戏产品架构进化史

 

经过近七年的高速发展，公司游戏服务器从100台增长到10000+台，游族整体游戏架构也经过了三个阶段的演变：

• 公司早期广泛使用的第一代架构，当时主流的产品都是以DB+计算+前端这样的3个角色开发设计并部署，服务器以物理机为主，一个游戏区组需要2~4台服务器，不同的机器承担不同的角色。这种架构方案效率低，基本上不可能实现一天开100个区组（100个区组大概需要400台服务器）；
• 随着业务量的增长和虚拟化技术广泛使用，游族整体游戏架构更新为第二代架构，全面采用虚拟化技术，把一台高配的物理机器虚拟化成多台符合游戏需求的虚拟机来使用，并实现了ALL IN ONE的系统架构。该架构方案运维效率高，适合规模开展游戏运营，但不具备业务高可用特性，一天开100个区组成为常态；
• 为了迎合大区大服、全球同服，游族融合了前两代架构的特点，推出了第三代架构，按角色分拆并形成服务集群模式。集群架构结合了物理机与虚拟化的优势，实现弹性扩容，游戏逻辑以服务进程或集群配置项的形式提供服务。该架构方案运维效率更高，可实现秒级开服同时具备业务高可用特性。

 

基于第二代架构，游族基于OpenStack自己的私有云，最初目标是为了提高服务器利用率、降低成本和实现分钟级开服。运维团队以OpenStack G版为蓝本进行调优并修改；整个网络采用的是VLAN模式，保证最大限度与现有网络架构保持兼容；存储方面使用本地磁盘作为存储。

 

通过底层优化后，游族私有云基本上可以满足业务的需求，目前90%游戏业务运行在上面，虚机规模持续保持在10000台以上，游族私有云平台没有提供WEB管理界面，日常所有的操作都是通过命令行和脚本的形式进行操作，但对于虚拟机的增删查改，重新封装了一层简洁的API接口实现与游族运维平台的对接。经过评估测验，在高峰时期，整个私有云资源利用率可达到83%。

 

运维方式的转变

 

与三代架构相互对应是游族运维的三个阶段：

 

1. 在第一代架构上，运维基本是手工运维，技术含量并不高，纯粹是采用人与时间堆积进行，运维同学需要登录每一台服务器，顺序执行相关的命令和脚本。独立的版控服务器，通过主动推送的形式进行版本更新；
2. 在第二代架构上，通过自动化工具进行批量运维，团队推出了使用expect写的auto批量脚本，所有操作只需登录一台集控服务器执行批量并发操作的脚本，独立的版控服务器，通过并行的主动推送；
3. 在第三代架构上，可以实现系统化运维，多个运维系统相互协调配合实现，例如：CMDB、业务树、作业平台等。游戏区组搭建的时间基本上可以忽略（可按需求实现按条件触发或手动触发搭建操作），所有的更新操作在WEB管理平台就可完成。

 

游族作业平台UJOBS

 

图二：UJOBS架构及其游戏更新流程

 

系统化运维过程中使用的作业平台（UJOBS）是属于C/S的架构，其核心部分由任务调度器和agent组成，通过调用API接口完成多种形式的指令下发。UJOBS简单的来说是为服务器管理提供了执行命令的通道，将所有的执行命令和脚本在目标服务器横向执行完，把输出结果记录日志里面，同时可通过WEB界面实时查看分析。任务调度器是用来全局策略控制，进行并发量控制。任务列表里面保存任务的完整信息。指令仓库保存常用的命令个脚本和上下文关联的命令组合。

在UJOBS平台上，游戏版本更新流程如下：

1. 版本库的版本变更自动触发构建；
2. 从版本库拉取变更后的版本文件；
3. 通过构建操作后，推送目标程序到分布式的全局版控服务器集群；
4. 在作业平台下发更新操作后，UJOBS的agent取得该次更新的版控服务器地址、变更清单以及版本信息；
5. 从版控服务器拉取更新文件到本地执行预定的更新脚本；

同时在UJOBS执行的过程中可实时查看输出的日志。当游戏版本更新出现异常，有两种回滚方式：第一种，游戏服务器上保留历史版本，异常时回退到历史版本；第二种，覆盖回滚，将老版本再次发布进行回滚。

 

数据库备份与恢复

  

相对于游戏版本更新备份而言，数据库备份更为重要。ALL IN ONE模式或者非集群模式的游戏业务场景下，会存在多达好几千个MySQL实例，若是要按常规的MySQL备份方案来实施，管理难度和成本都要翻好倍。因此游族网络采用Xtrabackup在主库上直接备份数据文件方式，备份文件暂存本地；本地备份完成后在备份系统选举一台远程服务器进行异地备份；备份策略每小时一次备份，半小时本地备份半小时远程备份。该备份方法在单主库业务场景下可能是最靠谱的数据备份方案，但备份过程对主库会有影响、（限制IO操作），最坏情况下可能出现1小时的数据丢失（业务接受少量的数据丢失）。

 

在数据恢复方面，通过一键恢复工具，只需要提供恢复的IP、时间段和业务信息（如库名）即可实现数据恢复；24小时内的数据通过本地的数据恢复（结合二进制日志），超过24小时的数据通过异地数据恢复。

 

云上迁移历程

  

现在游族已经将几款老游戏迁移到阿里云上。在将ALL IN ONE架构平滑迁移到云上的过程中，首先要求就是迁移过程不能长时间停服，只能接受正常的版本更新的停服时间。整个迁移过程分为以下几步：

第一步提前准备资源，在阿里云提前申请好资源，初始化环境并把VPC与自有机房的网络打通，实现内网互通为数据同步做好准备；

第二步提前同步数据，使用Xtrabackup备份在线把MySQL配置成主从同步模式，将数据同步到阿里云ECS，在一段时间后完成数据迁移。

第三步正式迁移，正常的游戏停服维护时间（0.5~2小时）就可完成业务上阿里云的迁移。目前已经平滑完成3款游戏产品的迁移，每款产品准备时间3~5天，正式迁移用时1~2小时，在阿里云平台使用的虚机超过1000台。

 

图三：新游戏上阿里云部署方案

 

上图为ALL IN ONE架构迁移在阿里云后的游戏部署：游戏逻辑运行在ECS上，业务中使用VPC网络，通过自建的ULB对外提供服务。游族网络下一步计划将集群模式部署在阿里云平台上，游戏逻辑将在ECS集群运行，后端数据存储在RDS集群中，前端通过SLB和负载均衡保证业务高可用，同时会接入LOG和大数据计算服务MaxComputer确保大数据业务。

 

在迁移到云的过程中，阿里云的技术支持起到了关键作用，线上线下及时沟通，以及特定技术的定制，保证了整个迁移过程的顺利进行。

 

如何去选择合适的数据库？

 

在游戏迁移过程中，遇到了很多困难，其中一点是选择自建MySQL还是RDS。根据游戏迁移经验，解决该问题，他认为应从以下三个因素进行考虑：

1.实例数量：实例数量多且业务规模小（无需进行针对性的优化）适合自建MySQL服务；实例数量不多业务相对会比较集中，数据库负载较高需要针对性的进行优化适合使用RDS服务；

2.数据大小：数据量的大小会直接影响到数据库性能和数据备份的机制，数据量越大越需要对数据库进行精细化管理，数据的备份难度也越大，这种情况下建议使用RDS服务，反之可自建；

3.成本核算：从实例规格来看RDS会比ECS自建MySQL要贵，但若是必须用到RDS的某些特性（如：数据安全和稳定性）时成本也就不会放在首要位置了。

 

与此同时，大数据量的自建MySQL可以采用延时同步的方法，此方法已在游族网络的女神联盟（手游）的集群架构方案中在使用。游族运维团队独创的数据备份系统、UJOBS、业务网关等独具特色解决方案确保了其业务量在行业内处于领先地位。

 

QA环节：

1、游族目前的运维人员数量是多少？

 

答：游族网络最初运维团队在二十人以上，经过技术优化后，目前团队人数在十人左右。从原来的十几款产品到现在的三十几款产品，运维业务量增长一倍，整个运维团队人员缩减一半。团队不断将技术转化为生产力，这是一个持续推进的过程。

 

2、从运维小白到总监的成长过程？

 

答：首先，我对运维这个行业保持很高的兴趣。从游戏对战平台接触运维开始，就愿意持续花时间投入游戏运维，曾耗费两天三夜的时间来处理运维中遇到的故障。当然最初也是从底层的运维人员做起，团队管理是被逼出来的，是一个慢慢成长的过程。在团队中，学习应居于首位，每个运维人员需要不断地学习，提升自己的能力。

 

3、DB除了MySQL还有其他类型吗？比如NoSQL这类数据库是如何管理和部署的？

 

答：游族网络的产品绝大多数都是使用的MySQL，有少数产品使用了Mongodb，因为量少暂时还是通过手工管理；缓存业务有使用Redis但不存储关键数据，Redis的数据备份使用数据备份系统进行集中管理，所有的软件部署都是通过标准化的业务模板进行管理的。

 

4、在新方案中，大数据计算服务MaxComputer的应用场景是什么？

 

答：在游族之前的架构中，游戏日志是分开存储，易丢失。在新的架构中，通过Log服务将游戏日志搜集到大数据计算服务MaxComputer，对后续的游戏和运维数据分析提供便利支持。

 

5、数据库的部分是单DB多实例吗？有没有启用分布式DB的架构呢？

 

答：ALL IN ONE架构下，在一个MySQL实例中只运行一个业务；在集群架构下，在单DB实例下，会运行多个业务，分布式DB架构也相应是必备的。

 

6、游族私有云是用的OpenStack，本身组件很多，后续和公有云之间如何衔接的？

 

答：目前游族使用OpenStack仅限于机房，短时间内不会与社区版本同步，机房内修改和使用都很简单，整个OpenStack定制和修改不多，更多着重于框架的使用。

 

7、国际节点和国内节点的高可靠链路如何建立？

 

答：该链路使用的基本资源是遍布全球的阿里巴巴骨干网，阿里云是将自己的资源分享出来给使用VPC的客户，实现国内外高可靠链路的建立。

视频回放地址：

http://click.aliyun.com/m/4092/

幻灯下载地址：https://oss.aliyuncs.com/yqfiles/a4fa09bc8a0a2a559df4b93839437a88.pdf

 

**************************************************************************************

来自行业CTO的深度实践分享， 第3期在线培训直播报名开始！

主题：《基于混合云的OTA比价系统、精准运营和大数据用户推荐》

分享者：驴妈妈副CTO邵汉成

分享内容：主要包括采用混合云，进行产品比价跟价；进一步提升精准运营并提升产品竞争力；并结合大数据分析，根据用户喜好和个性数据，推荐性价比高的产品。

直播时间：2016年3月11日上午10:00-11:00 (含问答环节)

报名地址：https://yq.aliyun.com/webinar/join/3