IT瘾百度推荐

百度搜索中台新一代内容架构：FaaS化和智能化实战

Thu, 13 Jan 2022 03:28:31 CST

导读：百度搜索中台内容计算架构为在线提供了数十亿的异构且有丰富特征和信号的优质原材料。我们以 Serverless 理念为指引，通过FaaS化和智能化的系统性建设，构建了新一代内容数据计算系统，实现了业务研发效率、资源成本和架构稳定性维护性的显著提升。本文从搜索中台内容架构演进过程中遇到的问题入手, 分析系统设计思路，然后详细介绍具体实践方案。

全文10719字，预计阅读时间7分钟

一、背景

搜索中台内容计算架构支持了数十个业务线的上百个检索场景，每个场景的数据都有一定的差异性，之前这些差异性都是由业务同学通过自定义的脚本进行独立开发。这些脚本存在开发成本高、维护成本高的情况，我们引入了业务框架+服务平台，实现了业务可以独立开发、自动部署和上线，同时代码库可以复用，一定程度上解决了开发成本和维护成本的问题。伴随业务快速发展，自定义入场开发的场景和诉求越来越多，在此过程中出现了以下问题：

学习成本大: 业务框架做了抽象，业务要上手开发需要学习完整的接入规范、开发规范，有的场景可能只要较少的业务代码开发，但是学习时间却要一周甚至更久，在新场景接入、尤其是简单业务场景，越来越多的情况下，学习成本变成了个棘手问题
资源成本高: 很多的业务场景有潮汐式特征，即每天只有一小段时间有内容计算，假设它只有1小时有，那么之前的架构浪费了23/24的资源，即另外23小时没有任何计算确占着资源，导致巨大的资源浪费
维护成本高: 搜索自身的复杂性，导致出现问题的时候开发者排查异常困难，有时候强依赖某些有经验的同学，整个系统的维护成本越来越高

在业务接入越来越多、业务迭代也越来越高频、业务的数据量越来越大的情况下，如何通过技术手段，实现开发成本、资源成本和维护成本的显著提升？相信这个问题，也是一个业务系统经过一定发展后，大概率会遇到的一个问题。

二、思路与目标

业界对于Serverless的大规模实践主要是聚焦于Web端应用，中后台的实践相对少一些。我们面对的场景是搜索中台数据的实时计算，而搜索本身又是非常复杂的业务。但是通过对我们场景的抽象与分析，我们具备了在中后台复杂场景实践Serverless/FaaS的可行性：

一方面，虽然业务开发的功能需求千差万别，本质上仍然有很多通用共性的地方。对于业务特定化的处理逻辑都可以将逻辑转化成一个一个的函数。而共性的功能可以通过抽象成通用组件。通过函数的编排和组件的复用可以乐高式搭建出适合业务的搜索数据计算系统。同时业务完全聚焦于业务自身逻辑中去，高可用、高并发、高扩展这些用户都不需要关注, 极大的简化的业务接入成本。
另一方面，由于业务流量的波峰波谷异常明显，通过深入业务层的智能化调度的实现，不仅可以提升业务在流量峰值的扩展能力，而且通过调度可以实现资源的充分利用，节约大量的资源成本。同时，针对越来越复杂的的系统，必然导致问题的排查恢复的成本也越来越高，通过智能化控制系统的引入，实时发现分析处理异常问题，使得整个系统更稳定更有韧性。

结合业务痛点，总结起来主要是两方面的工作：

通过 FaaS化建设，业务从聚焦于服务研发转变为聚焦于函数开发，全面的提升业务的开发效率。这里的FaaS化改造不仅仅说的是技术底座的变革，更是全系统全流程整体的业务效率的提升。
通过 智能化建设，让架构系统根据服务的容量和状态进行动态调整，使得可以在追求更低资源成本的同时提供更高质量服务。智能化建设即包括从0到n极致化的智能伸缩调度，还包括根据系统的多维度实时状态信息进行智能分析自愈的智能控制系统。

三、FaaS化改造: 追求业务明显感知的卓越效能

FaaS的极简化的思维从直观的角度上来说本身就会给业务带来巨大的人效的提升，如下图所示：

如上图所示业务在过去的普通云化服务中需要关注内容较多：从应用程序本身、组件和数据，以及服务的运行时环境，到最后的服务容器等基础设施的管理都需要业务方去关注。
当业务转变到FaaS化的思维中，业务需要开发处理的只是业务的一段逻辑表达，这里是以Function的方式表示，其他部分(包括组件、数据、运行时环境和基础设施等一系列因素，业务甚至连原本应用程序本身)都不需要管理。

搜索中台内容计算在FaaS化方面主要进行两部分工作，其一是核心框架，其二是业务全流程系统建设，最终保证业务的开发效率与现在相比有根本性的转变。

3.1 核心框架: 业务抽象与能力复用

核心框架是我们整个系统改造的基石，对业务来说主要包含两部分:

极致抽象的业务框架：是核心框架基础中的基础，提供新的开发范式同时，为后续智能调度奠定良好基础
高度复用的基础服务：强大丰富的后端服务能力封装，支持业务低成本复用，降低开发成本同时提升稳定性。同时系统还提供强大的编排能力，低成本支持业务从简单到复杂的发展

极致抽象的业务框架

业务框架作为FaaS层和业务代码的载体，是整个业务逻辑的代码框架。框架本身维护数据流语义，面向有向无环图（DAG）的数据流，调用业务函数代码。业务框架是面向有向无环图的数据流实时计算，支持完备的流式计算语义：

业务端使用开发成本低的脚本语言进行开发（例如Python），基础服务框架使用C++实现，通过架构层面的优化策略来达到服务性能和开发成本的平衡。

基础框架的发展本身经历了两个阶段：

阶段1:基础框架引擎使用C++实现(原来业务框架阶段基于脚本语言实现)，架构代码与业务代码的充分解耦，直接调用业务函数代码，业务开发效率已经有了质的飞跃。
阶段2:为了规避脚本语言在进程中只能使用单核（如Python、Php、JS等）特点，让业务函数具备容器内使用多核的能力，为后续支持极速扩容奠定基础。

下面就来看下整体框架的构成方式，看上图右侧部分:

流式计算框架: 我这边是直接基于百度StreamCompute流式计算框架开发，该框架原生支持基础流式计算数据流语义、支持拓扑函数的编排描述，为整个FaaS提供坚实的基础底座。大家实际使用过程中可以选取合适的流式计算框架开发。
数据预处理: 这里包含的功能比较多，从大体上协议解析、性能优化和数据观测等三个方面的工作
协议解析: 这里主要说明的框架的基础通信协议的定义解析，为了各业务数据通用性定义为入参和出参均为原始字符串；
性能优化: 接入数据流框架本身，通过批量顺序读写、数据压缩的方式提高数据穿入过程中的服务吞吐；
数据观测: 进行基础指标汇报包括QPS、延时、内部队列等一系列信息，和异步的Trace信息(进入到Kafka中)。
进程管理&服务管理: 并不在数据的主通道上，主要是应对整个容器内部进程和服务的管理。
进程管理: 伴生服务，负责启动、维护、销毁整个子进程的生命周期。
服务管理: 伴生服务，负责初始化并且维护远端的rpc 的client，修改访问参数，如超时、重试、下游访问策略等。负责新进程的创建、回收，以及进程间交互信息的维护。
进程通信异步数据分发: 这里有三个关键点: 数据不丢 、 异常健全 和支持 下游竞争消费。调研了包括数据管道通信、共享内存、系统队列和RPC等操作方式，考虑到稳定性、扩展性和实现成本等因素选择基于Baidu-RPC框架实现进程异步数据分发；
单进程模式： 当进程个数为1的时候则_跳过进程通信_，直接在本进程内部进行方法调用；
多进程模式：每个进程完全独立启动,业务视角隔离，但是公用一套业务代码环境。子进程处理完成后将请求结果反馈给父进程。
业务逻辑处理: 主要包括校验解析&函数调用&本地优化加速几部分，如上图左边就是业务逻辑处理的展开图。
解析&校验&优化: 每个线程内会进行参数解析协议校验，为了方便老业务迁移，支持多用户协议解析，线程并发优化；
执行引擎: 函数接口是真正函数调用地方，支持不同语言的调用引擎。eg: 如果业务使用Python，使用pybind。
数据提交: 执行完成后会统一推送到本地输出队列，本地队列里面的信息会异步提交到远端的消息队列里面给后续算子消费。

高度复用的基础服务

业务依赖的后端服务，包括多媒体长留服务，数据存储服务，策略计算等十项服务能力，所有的服务架构的支持目标都是通过简单配置、少量代码的方式进行服务接入。

架构通用能力：包括索引算分(倒排、正排、向量索引)，数据审核(政治敏感数据/色情数据识别&过滤)，多路分发、数据建库等能力；
与业务联合研发的能力：数据的低质过滤能力(实现数据清洗/归一化/数据去重/类目拼接)，数据多元融合，数据质量打分计算(质量打分/作弊识别/物料打分)
基于公司强大基础能力: 多媒体处理服务(外链转内链/OCR/水印计算/重复图计算/主体识别/视频转储等)，自然语言处理服务,数据沉淀服务

支持的BaaS服务主要是两个特点: 简单稳定 & 充分集成公司内其他优质能力。用户通过 SDK调用、 算子复用和 数据流复用等方式直接进行能力复用，完全不需要进行服务的部署和管理，服务易用性、稳定性由搜索中台来处理。使用任何服务后端都可以收口在一个地方，避免业务频繁跟多个服务团队进行交流处理，极大降低业务使用成本。

业务最开始接入通常只需要简单的少数功能（例如，修改部分字段的信息)，多数业务直接用我们提供的平台化的开发模板即可完成开发。但是随着业务的逐步深耕,业务逐步使用，业务会向复杂逐步过渡，例如搜索中台某业务通过复用 超过8种能力的组合使用，建设出具有深度定制的数据系统。

3.2 全流程效能提升: 提供极简的用户使用体验

如3.1中提到的核心框架是FaaS化的基础但并不是全部。因为改造的底层逻辑是让业务聚焦于开发业务逻辑。这个过程不仅仅包括代码的开发阶段，而是包括从接入、开发、调试测试、上线维护的全流程阶段，因此我们需要对于系统进行全流程效能提升，才能最终保证业务的全面效率提升：

快速接入:权限申请到数据接入的全面简化。简化的建设主要是两方面思路：其一是流程上的简化（例如: 权限申请流程无需架构同学参与，组内同学就可以审批处理）；其二开发过程的简化，对于常见的流式数据系统(公司其他中台或者官方数据系统) & 通用存储(常用的公司数据存储 eg Mysql、Mongo、公司内部的表格存储甚至原生FTP本地文件) 支持配置化的批量导入。同时我们也提自定义(完美适配Docker)的任务系统提供做够的灵活性保证业务的低成本接入；
极速开发:平台完善函数内容。我们这边开发有两种模式，一种适合初学者的Air模式，一种是适合高端玩家的Pro模式；针对于Air模式本身，用户可以直接在平台完成代码的提交和调试功能，完全一键处理；
快速调试&测试:业务可以根据自己实际的需要可以通过平台化的方式调试通用的模板函数，也可以通过线下集成调试环境一体化的对整个系统进行调试。针对于测试提供了平台化的测试方案，业务可以默认0配置的情况下进行服务性能和执行数据结果的DIFF；
问题定位: 这部分对于业务问题解决尤为重要。主要包括监控报警和云日志两部分功能(具体架构设计在2.1可观测性建设中有详细的描述)：
监控报警：包含两部分信息通用部分和业务自定义两部分。其中通用部分提供包括算子总体堆积程度，每个算子的处理的信息，app 实例状态等等20多项常用数据指标，直接集成到管理平台内部，可以不需配置直接使用。而自定义部分提供了基础的SDK函数装饰器，可以极低成本给监控自定义代码段的成功率，延时等信息；
云日志：包含数据Trace(数据流向)、日志Trace以及相关的数据报表服务,业务都可以极低成本进行服务接入。

通过的FaaS化建设，业务接入、开发、迭代、维护等全流程阶段的效率都有了巨大的提升, 达到了 10倍人效提升。

四、智能化:追求更低成本、更高质量的服务

通过上一部分提到的FaaS化改造，业务的全流程服务效率问题得到巨大的改善。接下来通过智能化改造的工作在避免大量资源浪费、降低资源成本的同时，提高业务的服务质量。智能化的工作主要包括两部分：

通过智能化的资源调度方案，极大的节约用户的资源成本，真正做到按需使用，而且可以有效处理流量洪峰，提高系统稳定性。
通过智能化的控制架构，有效处理异常问题，做到问题主动感知、决策并且主动处理，提升系统韧性的同时降低大量的维护人力成本。

下面针对于这两部分系统设计进行详细阐述。

4.1 智能调度: 极致化弹性伸缩

过去，业务的app主要配置固定容量配置，我们多数的业务流量都有明显的潮汐式，大量业务天级别只有1个小时，甚至几分钟的流量，这样就造成了大量资源浪费。

智能调度的核心作用就是实现业务的资源的按需分配, 实现从0→n的资源满足，具体上来讲主要有如下功能：

自动伸缩：根据当前服务流量的波动情况自动分配出来对应可以满足整体实例消费情况的实例数进行消费,包含纵向本地扩容+容器横向伸缩的方式相结合 多阶段扩容；
服务资源回收&冷启动：保证长时间没流量的服务容器，资源完全被回收，不占用任何服务资源，当新流量资源到来的时候，服务接着过去资源的数据消费，保证数据生效稳定性的同时，使得业务完全做到按需使用；
异常实例迁移：主要通过热点实例迁移，长尾实例迁移保证服务全局的正常运行；
容器资源自适应：主要通过检测内存使用状态，对资源容器进行自适应的调整，保证容器资源在不浪费的同时，保证服务不会超限而造成服务的OOM。

其中自动伸缩是一个这个场景下最典型的调度场景，下面以自动伸缩为出发点从设计思路&核心架构两个方面来具体阐述。

设计思路：多阶段扩容的设计原因

扩缩容最初只有传统意义上的横向扩缩容，在我们的业务场景下可以达到分钟级的是时效性，多数业务可以满足需求。然而，针对于高时效业务，当流量高峰突然到来的时候(例如3倍过去高峰流量)，分钟级的扩容速度业务无法接受。为了解决这个问题一般只能给一定业务流量BUFFER(比如2倍流量)。如果资源BUFFER充足，业务方则有大规模的的资源浪费，如果资源BUFFER不足时效性依然没有完全解决。

其实业务的核心诉求是架构能否做到相对稳定的秒级伸缩。可以快速缓解业务流量洪峰的压力，提高系统稳定性扩展性的同时达到最佳的资源利用。通过分析横向扩缩容底层现状我们发现:

启动时间分析: _容器的调度时间+rumtime初始化时间_占据了整个启动时间的98%以上，一般需要5分钟，依赖于公司基础PaaS环境，优化成本非常高；
开发业务：业务都是通过脚本语言开发（通常是Python），受到解释器限制极限只能用满CPU单核, 有时甚至由于业务代码逻辑问题远远无法达到；
资源占用：容器规格很小(CPU规格极小、容器内存资源充足)，多数机器上的剩余quota足够。

因此我们就想到使用，增加纵向本地扩容阶段：1. 通过Quota Resize 解决容器资源扩容问题；2.通过框架的多进程并发解决大容器下的业务能力上限问题。

结合3.1核心框架中提到的多进程框架的实现，实际扩容包含两个阶段：

纵向本地扩容阶段：可以满足在高时效业务场景下突发流量到来的极速资源满足速度，通常可以瞬间满足5~10倍的资源。此外，扩容过程中是允许少数实例纵向扩容失败的，通过流量均匀分发的能力，将纵向失败的流量实例流量均摊到成功的实例上。
容器横向伸缩阶段：两种情况会进行横向扩容阶段：
其一，当高峰流量持续时间较长(一般超过10分钟)时，会进行横向扩容实让服务容器分裂(例如：2个实例_10进程 → 20个实例_1进程)；
其二，纵向扩容后仍然不能完全满足吞吐要求(例如100倍的服务吞吐需求)，则会在纵向扩容后瞬间触发横向扩容，不过此时业务完全满足效率退化成分钟级。

以上描述的是扩容过程，缩容过程类似，优先进行本地缩容。这样保证容器的均匀分布，随时都能有本地扩容的能力。

核心实现: 调度核心架构

如下图是我们智能调度简化架构图:

主要分成下面几个阶段:

采集层: 采集数据的基础信息，这里主要需要集中类型的信息，尤其是扩缩容其实主要关注两个队列信息:
数据流的队列信息
流式算子之间的队列信息
决策层: 根据历史调度信息和当前的实际状态信息进行决策，实现多阶段可变步长的扩容:
优先进行本地扩容，根据当前容器的资源使用量最多需要平均可以扩容5→20倍
长时间当本地扩容到(或者接近)极限，则会进行横向扩容，这个资源水平没有特殊限制
多阶段: 本地扩容(纵向) + 横向扩容
可变步长: 数据堆积都有多个阈值，每个阈值关系到不同的步长(默认每个APP至少两个步长)。eg: 政务业务的数据流堆积1000持续超过30s则触发扩容1倍，如果超过10000，则直接扩容到最大实例数
分析层: 在整体资源低于阈值(默认85%)的时候默认是跳过该阶段；在整体资源超过阈值后，为了保证高优先级的资源进行优先级调度使用的，必要的时候会对低优任务进行淘汰
执行层: 根据决策分析层提供的信息执行
本地扩容: 直接调整容器Quota信息的同时基础框架的进程管理启动服务的进程数来实现本地的极速扩容(比横向扩容快一个数量级)
横向扩容: 普通横向调整实例个数，由于涉及到资源调度，数据环境的初始化，需要的时间周期是分钟级
过滤: 扩容生效都有一个时间周期(本地扩容秒级，横向扩容分钟级)，每个决策后都有一个静默期(比如10分钟)从而避免重复决策执行
跳档: 过滤只针对于完全相同的操作拦截，针对于不同步长扩容不拦截，保证业务在流量洪峰下的感知执行速度
执行: 真正执行操作，例如扩缩容操作

关于本地计算扩容: 进程管理的时候每启动一个子进程，实际内存增加约60M，CPU极限增加1核心(10个实例资源只是600M内存，10个逻辑核心)，超过实例 90% 情况都可以实现本地极速扩容。

按需计费的实现考虑到不同业务有不同的调度逻辑和配置场景: 有的业务需要资源预留（保证最低实例数), 则这部分业务有最低资源占有成本；而多数业务没有特定的需求，一般冷启动延迟业务可以接受，则不需要保证最低实例数;有的业务需要时效性要求比较高，扩容敏感度高，缩容敏感度低，而对于普通扩容敏感度，甚至敏感度更低的业务，相同状况下扩容的资源数可能完善不一致;有的业务不需要容器自动适配，而多数业务需要在容器尤其是内存设置不合理的时候主动获取更大的容器。业务实际上的收费就是按照业务不同的调度策略进行计费，真正做到不多不漏，合理计费。

通过智能调度服务实现了核心生产环境多数场景支持秒级自动伸缩，支持0→n的极致扩容。按需计费，整体资源节约87%。

4.2 智能控制: 防止问题升级扩散，全自动实时处理

智能化调度实现了极致化的弹性伸缩，做到了资源的极大节省。我们的整个系统也随着系统云原生化的改造下变得越来越复杂，但是问题的排查成本却越来越高。因此问题的排查通常需要多个方向的同学通力合作(或者依赖个别专家同学的定位)才能处理解决。这不仅仅是对架构人力的巨大浪费，而且干预时间常常不可控，对于线上有很大风险。为了解决这个问题，搜索中台内容生效架构引入了智能控制系统, 快速、准确的发现问题、处理问题并且整个过程是完全自动化的：

快速: 处理速度快，主动发现与消息通知相结合的方式，全面进行问题排查
准确: 历史出现过的问题转化成系统规则，整个过程模拟专家进行处理解决。只要规则合理，没有误操作，没有非预期行为
自动: 处理过程完全无需人工干预，全程自动化处理

智能控制系统总体上是以可观测为基石，以健全的自愈能力为手段，通过智能分析引擎进行实时动态分析决策，决策的结果会影响到观测数据做下一轮的数据分析。它们的相互关系如下。

通过整体系统的执行自愈的连续迭代调整，最终让系统调整到一个健康的状态。

完善可观测系统(基础)

可观测系统并非此次叙述的核心，但是它仍然是智能控制的基础。没有完备的可观测系统建设，一切有效的控制系统都是空谈，如下图就是整体可观测系统的概览:

基础采集层: 为所有的观测系统的数据提供最原始的基础数据采集。从数据类型来分主要是三类:
流式数据: 需要记录每条数据的信息，主要借助于Kafka的数据队列收集
指标数据: 对外汇报每个实例的指标数据，对外exporter汇报数，或者直接原始公司公司内的监控系统进行采集
自定义数据: 这种一般使用脚本以特定化的方式采集，作为基础指标采集的补充
数据处理层: 该层主要是针对于流式原始数据的数据处理，从图中可以看到主要是两部分数据，很多基础数据信息不需要额外聚合
指标聚合层: 主要是提供于 拓扑分析系统，这里基于StatsD和Prometheus的转换接口，实现的 指标动态分桶机制,极少资源完成大量数据信息
数据聚合层: 主要提供于 实时成功率监控系统，这里是基于数据的动态Hash和流式计算完成的
存储层: 该层是可观测系统的 中间核心，这里我们用到的数据存储既有开源的系统(包括ES/Prometheus/Mongo等)，也有公司内的监控系统(以复用为主)。有两个大系统提供原始数据:
一方面，给上层应用系统提供数据展示的原始数据；
另一方面，给智能控制提供决策的原始数据。
展现层: 用户直接访问的前端接口，这里有我们自定义的平台，也有直接借助开源系统Grafana和Skywalking之上进行建设
应用层: 用户或者是架构所需的对外查看的系统，有 6大业务系统，包括:
Trace系统: 包括数据Trace 和日志Trace，确认任意单条数据信息
指标系统: 最关键的基础数据信息，所有架构层和业务层的核心指标都收录于此
健康刻画系统: 通过当前全局的报警信息（报警级别、时间、个数）刻画出整体当前系统的健康程度
拓扑分析系统: 分析业务侧面和架构侧数据流是否存在异常（数据流量变化，异常点分析）
效果监控系统: 从数据生效结果监控，从架构效果端反推业务问题，比如监控关键数据变更的时间戳反推架构系统问题
实时成功率监控: 查看数据流整体端到端的实时成功率信息

通过一整套监控系统建让架构掌握大量实时多维度的数据指标。所有的系统的问题都会反应到一个（或者几个）指标数据的变化中去。一方面，可以作为后续自动控制的数据原材料；另一方面，架构通过将这些指标的分级(高中低)分通路(电话、短信、通信软件消息)的方式保证系统的人工兜底。

健全的自愈能力建设(手段)

完善可观测性提供决策的数据源，它是智能控制的基础。而自愈能力的建设是自动化的控制的重要手段，否则依赖纯人工干预（例如”手动删除一个实例” 或者 “线上修改一个配置”）的操作是没办法实现自动化和快速止损的。自愈能力建设这里重点描述所覆盖的功能集合，不仅仅包含我们传统意义上的容器管理功能(例如：实例重启、迁移等)，还有深入到业务系统架构中的服务管理类和通路控制类的功能：

服务管理类: 主要是基于资源&服务的管理，包括通路切换（主备切换，优先级切换）、数据拦截、数据回灌和服务降级等
通路管理类: 主要是基于提供基础组件的管理功能，包括流量清理、查询拦截(异常查询&慢查询查杀)

自动化问题分析引擎(核心): 规则+Function

自动化问题分析引擎是整个智能控制系统的大脑。它上游接收观测提供的原始数据，进行自动的分析决策后，通过系统提供的自愈能力处理。自动化问题分析引擎的核心思路: 只要历史上出现过的问题，RD同学能找到问题和解决方案，就可以转化为系统规则和后置函数梳理。那当下一次遇到问题则无需人工干预。规则引擎的核心分析过程是2段式的:

阶段1: 传统配置化的规则引擎的配置（上图中右上角黄色部分），配置多个采集指标项的逻辑关系（与或交非），这里主要是针对问题的基础分析功能,判定规则是否触发。
阶段2: 基于这个基础分析的结果，进行后置Function的执行分析，这个主要是针对复杂问题的分析补充，最终执行引擎根据这个返回结果进行函数执行。

下面针对问题分析引擎的执行结果如下:

前提: 开发者需要配置好处理逻辑规则（以及规则依赖的数据项，必填） & 回调函数（选填）。
数据解析器: 数据解析器主要承担的数据的原始抽取的工作，一共分成如下3步；

配置解析: 逻辑执行根据开发者配置的数据信息解析；
数据抽取: 根据解析出来的配置通过数据接口进行获取，可以从统一接口根据配置的信息从不同的介质充抽取所需求的信息；
数据归一化: 将不同介质的原始数据归一化成为统一的数据格式供规则管理器使用。

规则管理器: 规则管理器主要承担核心的逻辑分析工作，一共分成如下几步:

规则解析: 根据开发者配置的规则逻辑，将原始配置信息，解释成原始的规则树；
执行计算: 根据数据解析器提供的数据结果和配置的函数规则分别执行计算。执行计算过程中最重要的就是基础分析器，整体提供了5大基础能力，数十种常见的逻辑计算来辅助规则配置。
规则逻辑运算: 根据上层解析出来的规则树和每个数据项执行完成的计算结果进行逻辑运算，并根据执行的结果确定是否进行高级数据分析器，如果判断结果为真则根据所配置的后置函数进行处理；

高级数据分析器: 如图所示有两种模式，对于简单基础分析可以判断结果的，直接给默认的处理函数进行数据拓传；对于简单逻辑规则无法准确表达的，开发者可以自定义后置分析函数，函数会将原始数据和基础计算的计算结果作为参数传出来，开发者只需要通过处理后的数据描述清楚分析逻辑即可；
动作执行器: 就是这个分析器的真正的执行引擎，根据规则运算的结果中包含的参数进行动态调整。

通过 智能控制系统的建设，月级别分析处理上万的异常问题，自动恢复的比例占总数的 96.72%，所有问题的恢复时间平均在 1.5分钟， 90分位小于 3分钟，核心故障同比减少 60% （由于预处理防止普通问题恶化成严重问题）。

五、总结

整体的工作思路以Serverless为指导思想，通过FaaS化和智能化两个维度的系统化建设，以技术手段系统性实现了降本、增效、提质：

通过 FaaS化的建设，提升基础服务性能的同时全流程服务效率的提高，具体来说包括两部分：
打造新一代的核心框架，提供强大的基础底座让业务核心关注点从原来的云化服务思维聚焦到逻辑实现，业务通过简单复用和编排实现复杂的功能，让业务开发更简单
提供一体化全流程系统建设，让业务从接入、开发、调试测试到最终系统维护全流程的流畅体验，助力业务更高效的交付
通过 智能化建设，在稳定性有巨大提升的同时大幅度降低资源成本和系统的维护成本，具体来说也包含两部分：
通过智能化调度, 实现业务的按需分配(0→n), 秒级应对突发流量, 节约大量的资源成本；
通过智能化控制，实现全系统绝大多数问题问题的自动感知、自动分析、自动处理，提升稳定性的同时降低了系统的维护成本。

在Serverless上线之后，同时FaaS化和智能化的建设，业务真切感受到降本增效的同时稳定性和架构维护成本也显著降低，让架构和业务同学都切实感受到了新研发范式下的技术红利。Serverless 带给我们的是一种新的研发范式，实现了业务创新能力的巨大提升，期待在越来越多的场景中，涌现更多的最佳实践。

推荐阅读：

当技术重构遇上DDD，如何实现业务、技术双赢？

接口文档自动更改？百度程序员开发效率MAX的秘诀

技术揭秘！百度搜索中台低代码的探索与实践

百度智能云实战——静态文件CDN加速

化繁为简--百度智能小程序主数据架构实战总结

百度搜索中台海量数据管理的云原生和智能化实践

百度搜索中“鱼龙混杂”的加盟信息，如何靠AI 解决？

---------- END ----------

百度 Geek 说

百度官方技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎各位同学关注

试乘了三家自动驾驶后，对百度失望了

Fri, 31 Dec 2021 16:35:31 CST

$百度(BIDU)$

回内地的第一件事情就是在广州试乘了百度萝卜快跑（Apollo）、文远知行（Weride）、和小马智行（Pony）的Robotaxi服务。

先上结论，试乘下来的体验是：这三家公司的技术水平排序为 小马智行>文远知行>百度萝卜快跑，而商业运营能力则是反过来，百度萝卜快跑>文远知行>小马智行。

百度萝卜快跑Apollo

我的试乘是从黄埔科学城的站点之一：科珠路口站出发，用百度地图叫了一辆Robotaxi，。百度地图叫车的App体验很顺畅，大约不到2分钟就有车接单，然后过了大约4-5分钟Robotaxi开到了上车点。叫车的体验和用滴滴软件叫快车没有太大区别。

此次行程起点是科珠路口站，终点是萝岗和苑。路程大约7-8公里。乘车的体验有几点：

急刹车&顿挫感：好几次急刹车发生在红绿灯前。我在车里老远就看到了红灯，但汽车就是要开到红灯跟前来个急刹车。总有种顿挫的感觉，不是特别流畅自然。

算法保守：百度萝卜快跑遇到有其他车从旁边的入口汇入时，百度Robotaxi会停在那里等好一阵子。我这次是Robotaxi等人汇车等了2分钟左右，才绕到左边的车道继续前行。可以看得出百度阿波罗的算法偏保守。

人工干预频率较高：最不好的一点体验是，车辆到终点停车的时候，安全员人工干预了。给出的理由是：离停车点3-5米的地方有道路施工，高精地图没有及时反映这一块的路况变更，所以需要人工干预。这个解释显然不够好。高精地图的更新本来就有一个时间滞后的特性，这也就是为什么Robotaxi的感知硬件需要武装到牙齿。这部Robotaxi是搭载了禾赛激光雷达的，理论上可以扫描到200米以内的障碍物。如果只是因为高精度图没有覆盖就需要人工干预，那么这样的Robotaxi只能在封闭或者半封闭路段才能开吧。只要是开放路段，就肯定会碰到路边有施工的情况，而高精地图是没有办法解决这种困境的。

V2X和5G云代驾体现不多：从试乘的体验来看，基本上没有看到V2X相关的应用。5G云代驾的说法更加飘渺。我发现这一年多以来，百度发通稿发的很勤快，提出的概念也很多，但是都不太能落地。

我感觉百度的车顿挫感十足一部分原因是 算法的保守，另一部分原因可能是 线控改造不太成功。我这次试乘的都是红旗给百度打造的前装量产车型，其实条件已经比小马智行和文远知行的后装改造要优越很多，但是很遗憾，体验效果不尽如人意。

我在网络上搜索了一些其他人的试乘体验，在北京亦庄试乘林肯改装的阿波罗的乘客也有提出类似的顿挫感。而这篇亦庄的试乘体验报告已经是将近两年前写的。两年了，百度都没有在顿挫感方面提升，让人失望。

文远知行Weride

首先吐槽一下，文远知行的安全员是试乘的三家里面态度最不友好的。主驾驶和副驾驶都各坐了一名安全员，跟两尊门神一样。主驾驶的方向盘上方有一个红绿灯装置，我试图问安全员，那个红绿灯装置闪烁不同颜色的灯光是否意味着目前路况是否需要人手干预，对方冷冰冰地说：“任何问题请你联系我们客服，我只是一个安全员。 ”

第二，文远知行在黄埔科学城的车辆投放还是不够多，App的体验也一般。比如我在黄埔科学城外或者生物岛外的地方，App地图上不能显示在哪些地方可以试乘Robotaxi。但是百度和小马智行，打开App，哪怕是在试乘区域外，也会告知可以试乘Robotaxi服务的站点，这样我也好通过正常的交通工具找过去。就算是到了黄埔科学城，不知道是不是因为我的手机号是境外号码，文远知行的App里依然显示不了上车地点，还是最后换了我老公的手机才预约上附近的车。预约时间大概2-3分钟，但是车子开过来，花了约20-30分钟。

吐槽完了文远知行这些让人感觉很生硬的体验之外，再说一说文远让人惊喜的地方。试乘路线是从萝岗和苑出发，在黄埔科学城内，大约行驶了十公里。中间经过了前方路段施工、跟车超车大型货车、无保护左拐、行人突然冲出马路等情况，文远的处理都很平滑。行人冲出马路时汽车缓缓停下让路这一段，和人类开车的感觉差不多。再三和安全员确认，他说他没有人工干预。到达目的地的停车也非常顺滑。 从启动到停车，全程没有人工干预。

但是总的来说呢，这段路并没有经过类似城中村和老城区这样的路段，都是在走高架和宽敞的六车道，不是技术难度特别高的路段。

小马智行（Pony ai）

接下来，上小马智行！

之前听朋友说， 小马智行的Pre-IPO估值给到100亿美金以上，心中颇为不忿。毕竟当时我正在写威马那篇文章，想说威马好歹卖出了几万辆车了，估值才50亿美金上下。而文远知行的估值也只是30亿美金上下，小马何德何能，给到这么高的估值。

而且小马智行对外营销都很喜欢说在美国加州那边自动驾驶拿到了多少牌照什么的。但是美国的路况和中国路况复杂程度不可同日而语，对于这种宣传的话术，我也有些微辞。

然而事实证明， 没有试乘就没有发言权。小马智行的试乘体验成了一个大型真香现场。

首先还是先上吐槽，我选择了离市区最近的庆盛站出发。然后等我坐地铁到了庆盛站才发现，打到一辆小马智行的Robotaxi要花15-20分钟，而等我打到了这辆车，漫长的等待才刚刚开始，因为那辆车花了42-45分钟时间开过来。从开始打车到我最后坐上车，我花了一个多小时。加上我从家里坐地铁到庆盛站，妥妥俩个多小时花出去。

说完了吐槽，来说说真香的部分。整个试驾体验，非常平稳和顺滑。我的试乘路程的起点是庆盛站，终点是南沙客运港地铁站。中间路程20公里。

如果坐萝卜快跑的车有时候给我一种是一个不是很完善的机器人在开车，难免有生硬之感，那么小马给我的感觉就是，这是一个老司机在开车。20公里的路程，经过了高架、南沙老城区等，汽车平稳到我中间睡着了一小会儿。

几个亮点：

1 从庆盛站到南沙客运港，全程20公里，经过的路段有高架、宽阔的公路、以及南沙老城区狭窄拥挤的街道。在每一个测试场景下，汽车表现都非常好。在南沙老城区，路人红灯的时候也有行人一直在拖拖拉拉过马路。汽车不但很好的对行人和障碍物进行甄别，而且没有傻傻急停在那里等待，而是缓缓绕过后再正常速度通行。换了百度的萝卜快跑，估计就在那儿死机了，不死机也会完全停下。老城区也有很多外卖骑手骑着小电动车穿插在车流中行进，这些小马的处理也很好，不停车，但是又能缓缓避让。这一点和真人司机很像了！

2 在从庆盛站出来的一段公路行驶路段，汽车开着开着就打了转向灯变道到超车道，然后行驶了好几十秒又打转向灯回到主车道，和前车的顺序并没有发生变化。安全员解释说，这是汽车想要超车，但是超车又不成功，就打灯变回原来的车道。如果说Robotaxi是个在公路上驰骋的机器人，这机器人到了小马这儿，多了几分调皮和灵活。

试乘体验总结

试乘了三家的Robotaxi之后我百思不得其解，因为文远知行和小马智行都是原百度自动驾驶出来的人马搞的创业公司，研发经费、测试里程和百度都不是一个量级的，为什么试乘下来，感觉文远知行和小马智行的Robotaxi要比百度阿波罗顺溜很多呢？

问题到底出在哪儿？我只能来做一个推测。

感知硬件&高精地图：在感知层硬件和路线规划方面，这三家其实都类似，都采用了激光雷达+毫米波雷达+摄像头+高精地图的方式，在硬件上舍得下本钱。不过感知硬件多了，就遇到一个多传感器融合的问题。百度的Robotaxi在遇到道路施工的时候就要人工干预，给出的解释是高精地图没有覆盖到，这也从侧面证明，百度Apollo在决策层面的算法里，高精地图输入的信息权重是很高的，甚至高过激光雷达感知到的环境信息输入。

线控&底盘&软硬件耦合：这三家里面，文远和小马是分别改装了东风日产和雷克萨斯RX450h。只有百度阿波罗实现了Robotaxi的前装量产。目前在路上运营的是百度第四代无人车。红旗专门开辟了一条生产线来前装量产百度的Robotaxi。百度的是前装量产车本来应该在软硬件耦合调试和标准化方面做得是更加到位的。但是百度的顿挫感是最强的。我怀疑这种顿挫感除了算法上面的保守之外，线控和底盘没有设计好是一个原因，软硬件耦合没做好。都说Robotaxi是一个车+脑的组合。说白了，这种急刹车、顿挫感和动不动就死机停在马路上的情况，就是车身和车脑子没有搭配好。

算法：我一直都不觉得算法在这个AI满地走的时代是一个大的门槛。算法方面的优劣永远是动态的。我也不知道他们是什么样的算法，当然在算法这块就没啥发言权了。

后记

因为我在上文中萝卜快跑的试乘体验选的路程只有7公里，很多场景没有测试到，所以我前天又第二次试乘了阿波罗，选的路线是科珠路口站到启学路公交站，十几公里的路程。但这一次真的大失所望。

我一坐上来安全员就上手了，手握着方向盘把车开走！总共30分钟不到的路程，安全员操作了有20分钟！！！！！只有在人少车少的空旷大马路上是汽车自己在开。

我问安全员为什么老是干预，哥们儿解释说是因为路况复杂。但是这个路况在我看来，就是一个稍微有点难度的行车场景：六车道的大路，路中间有一小块施工地段，但是并不影响开车，因为施工路段并没有延伸到主要车道上。

整个试乘旅程，车子动不动就死机，停在那儿启动不了啦。我总结了一下这一次的糟糕体验

1 只要有旁边的车道上有车汇入，车就会停下来，急刹车那种

2 疑似前面或者后面有车要变道，车就会停下来，急刹车那种

3 遇到红灯都是急刹车

4 车间距拉得贼宽，这也导致会有很多车进来加塞。一加塞，那么参考第1点，车会急停

5 如果不幸，遇上拥堵路段，左右都有车来加塞，那么，阿波罗当场死机，让安全员接管

6 路权博弈极其谨慎，直行的阿波罗如果到了前方路口感知到路口的车辆在等待机会U Turn（掉头），那么直行的阿波罗就又不知道怎么办了，停在那里，等安全员介入。

这一路的急刹车搞的我差点晕车吐车上！

All In AI这么多年，号称一家科技公司，百度真的可以反省一下这么多时间和金钱砸下去，怎么还可以把Robotaxi做成这个样子。

为了公平起见，我又在黄埔科学城打了一个Weride。这一次Weride接驾很快。是从万科金色梦想到广州航新航空科技股份有限公司的路段。这个路段我自己觉得选的不错，有施工路段和拥挤路段。整个行程大约20公里不到，30分钟的样子。

不到两分钟就打到了车，然后我紧赶慢赶赶去上车点。到那儿定睛一看，我直呼“好家伙”。很拥堵的道路，路中间一大块区域在施工。Weride的车大摇大摆打着双闪停在路上，后面堵了一长龙的车。

我抱着歉意赶紧上车，然后问安全员没有等太久吧？然后安全员面无表情地说：“你好，有问题请联系客服，谢谢。” 我又讨了个没趣。

Weride这个车很有意思，还有一个打表器，窗户上还贴着每公里2.6元啥的。整个一个出租车即视感。我打这个车，App上还给我预估了一个车费，一次是10元，一次是50元。为啥同样的路程两个截然不同的路费，我也不敢说，我也不敢问。但其实吧，这个打表器和预估路费都是摆设。我坐了三次Weride，你问我付过车费没有，没付过！

不是我故意坐霸王车，是根本没地方付费。下车的时候问安全员怎么给钱，他摆摆手让我拿好东西下车就行。后来App上也找不到付费的地方。如果确实少了Weride的车费，欢迎Weride联系我，我把车费补上！

第二次试乘Weride的体验当然又一次完爆了百度阿波罗的萝卜快跑。不说别的，试乘Weride这一次选择的路线比一小时前坐阿波罗的路线更拥堵和困难。但是Weride至少全程是没有安全员干预的。

Weride的体验优点在于

1 预感到侧后方有大货车会靠车道另一边行驶，尽量跟大车之间保持距离

2 变道打灯还算顺畅

3 监测到前方有人或者两轮车或者有车汇入变道等，都会放慢速度。

但是也有一些我觉得可以改进的地方

1 和阿波罗有类似的问题，就是和前方车距保持得很宽，导致会不停有车进来加塞。而Weride只要是感知到旁边的车辆有加塞的苗头，基本上就是减速甚至停下来，等对方车加塞完再重新启动。但这个停车和百度萝卜快跑的停车不同。因为百度的车停下来基本上就要安全员介入了

2 前方有人停车下车，Weride也是停车，而没有像Pony那样往旁边挪一挪然后继续前进。

整个旅途，虽然全程无干预，但是由于是高峰期，加上Weride的车动不动就要礼让加塞的车和汇入的车，所以也是走走停停。

关于路权博弈：

我能理解现在Robotaxi都是测试阶段，安全第一。但路权博弈本来也是日常行驶中会碰见的情况，如果一直都是选择让出路权，对于加塞、汇入等都是选择减速甚至停车等待的话，那么行车的效率也会是一个问题。这个问题对于测试阶段没有什么影响，但是等到大规模商业应用的时候，肯定还是影响效率的。

小马智行就没有二测了，一来上次选择的测试路径无论从难度和长度来看，我都是满意的。二来，南沙真的太远了。等有机会去二测的话，我再来跟大家汇报。

结尾

这几次的试乘体验，有几个总结，

1 未来商业化铺开，路权博弈是一个需要考虑的问题。自动驾驶的汽车是否要把所有的路权都拱手让给其他汽车？但是如果对方的车辆也是一辆自动驾驶的汽车呢？怎么让？

2 技术层面上，由于360度的感知能力，自动驾驶其实可以做到比老司机更加安全。南沙的小马智行和黄埔科学城的文远知行都有这种潜力。而在南沙的老城区以及黄埔科学城的拥挤路段上，这两家自动驾驶公司也证明了自己的实力。

3 在一个舆论可以主导社会中大多数议题的今天，自动驾驶出租车并不是100%的安全，发生事故只是一个早晚的问题。一旦发生了导致人员伤亡的Robotaxi事故，舆论压力是否会让相关领域的立法显著放慢？

4 这三家Robotaxi都只能在固定站点上下车。之后大面积铺开，固定站点的安排会显得不够灵活。

写了五千字了，终于在2021年的最后一天把这几次的试乘体验写出来交作业啦。自动驾驶代表着未来，而未来已经到来。希望过去的2021年是未来十年中最差的一年，却又是开启了下一个恢弘时代（20年代）的开局之年！

都看到这儿了，点个关注呗～

图片上传中......

消息称，腾讯和字节的内容即将向搜索开放，百度或成最大赢家？

Tue, 19 Oct 2021 07:58:00 CST

据彭博社报道，工信部正在考虑要求腾讯和字节跳动等媒体公司开放搜索壁垒——即允许用户在本平台上搜索并访问其他平台的内容。

知情人士说，规章设计仍在讨论当中。工信部希望可以通过百度等搜索引擎，让用户直接可以获取到微信上的数亿篇文章。其中一位知情人士说，工信部还在考虑将抖音的短视频也向搜索引擎开放。他们表示，监管机构正在向公司征求反馈意见，目前尚不清楚这一政策是否会实际执行。

如果政策得以实施，这将标志着国家在打破互联网巨头垄断——尤其是在腾讯和阿里——上取得重大进展。监管机构已经警告科技公司开放他们所谓的搜索壁垒，允许与竞争对手服务的链接。这同样也为全球范围内的反垄断进程做出了良好表率。

迫使字节跳动或腾讯允许百度和其他竞争对手在互联网搜索中展示他们的社交媒体内容，这将对互联网巨头的广告板块产生阶段影响。它可以将广告收入从微信或抖音等服务，转移到百度等搜索引擎上。

应此消息，百度在港股股价一度上涨4.3%。腾讯发言人拒绝评论，而字节跳动和百度的发言人则完全没有回应彭博社的评论请求。工信部对此也没有回复。

雷锋网分析，随着打击力度的扩大，反垄断局已向互联网大公司所经营的封闭生态系统宣战。一些公司采用封锁和其他方法来保护各自的领域，这成为了反垄断机构的主要打击对象：比如腾讯微信之于社交媒体，阿里巴巴的淘宝和天猫之于电子商务，以及字节跳动的抖音和今日头条之于视频和新闻。

而以可见的速度，垄断壁垒正在消除。腾讯上个月允许微信用户通过一对一消息链接到抖音视频和淘宝商店等内容，而阿里巴巴在其部分应用程序中添加了微信支付系统。

在先前，国家的互联网治理已经取得了不小的成效。国家先后整治了阿里巴巴和美团的市场滥用，并开展净网行动，同时先前出台的未成年人网游防沉迷新规也同样体现了国家智力互联网领域的决心。

据称，目前的审议主要集中在微信的公众账号上，它允许个人和企业发布从娱乐到新闻等多个领域的的文章内容，而这个庞大的内容库现在屏蔽了百度和字节跳动等搜索引擎。微信上的文章现在只出现在微信的本地搜索功能或搜狗上。

为了与微信竞争，百度于 2016 年推出了自己的内容平台——百家号来填充百度平台上的内容，这也使得百度在BAT的内容竞争上可以不落人后。

限制搜索服务的并非只有腾讯。2008 年，淘宝就屏蔽了百度搜索。据称，此举旨在保护消费者利益。而事实上，这将商家牢牢地绑定在了淘宝上，这也使得阿里从当时开始就主导了网上购物领域。知情人士说，目前尚不清楚工信部是否还打算取消对淘宝列表或其他内容的屏蔽。

【封面图片来源：网站名和讯网，所有者：和讯网】

NervJS/taro: 开放式跨端跨框架解决方案，支持使用 React/Vue/Nerv 等框架来开发微信/京东/百度/支付宝/字节跳动/ QQ 小程序/H5/React Native 等应用。 https://taro.zone/

Sun, 13 Jun 2021 14:34:39 CST

Taro

简体中文| English

👽Taro['tɑ:roʊ]，泰罗·奥特曼，宇宙警备队总教官，实力最强的奥特曼。

简介

Taro是一个开放式跨端跨框架解决方案，支持使用 React/Vue/Nerv 等框架来开发微信/京东/百度/支付宝/字节跳动/ QQ 小程序/H5 等应用。现如今市面上端的形态多种多样，Web、React Native、微信小程序等各种端大行其道，当业务要求同时在不同的端都要求有所表现的时候，针对不同的端去编写多套代码的成本显然非常高，这时候只编写一套代码就能够适配到多端的能力就显得极为需要。

版本说明

当前 Taro 已进入 3.x 时代，相较于 Taro 1/2 采用了重运行时的架构，让开发者可以获得完整的 React/Vue 等框架的开发体验，具体请参考《小程序跨框架开发的探索与实践》。

如果你想使用 Taro 1/2，可以访问文档版本获得帮助。

学习资源

5 分钟上手 Taro 开发

awesome-taro

掘金小册： Taro 多端开发实现原理与实战

社区共享

Taro 交流社区——让每一次交流都被沉淀

Taro 物料市场——让每一个轮子产生价值

使用案例

Taro 已经投入了我们的生产环境中使用，业界也在广泛地使用 Taro 开发多端应用。

征集更多优秀案例

Taro 特性

框架支持

React/Nerv 支持

在 Taro 3 中可以使用完整的 React/Nerv 开发体验，具体请参考基础教程——React

代码示例

importReact,{Component}from'react'import{View,Text}from'@tarojs/components'exportdefaultclassIndexextendsComponent{state={msg:'Hello World！ '}componentWillUnmount(){}componentDidShow(){}componentDidHide(){}render(){return(<ViewclassName='index'><Text>{this.state.msg}</Text></View>)}}

Vue 支持

在 Taro 3 中可以使用完整的 Vue 开发体验，具体请参考基础教程——Vue

代码示例

<template>
  <viewclass="index">
    <text>{{msg}}</text>
  </view>
</template><script>exportdefault{data() {return{msg:'Hello World!'}},created() {},onShow() {},onHide() {}}</script>

多端转换支持

Taro 方案的初心就是为了打造一个多端开发的解决方案。

目前 Taro 3 可以支持转换到 微信/京东/百度/支付宝/字节跳动/QQ 小程序以及 H5 端。

抖音 360 百度等应用被指过多收集用户信息

Fri, 21 May 2021 16:35:24 CST

网信办公布了《关于抖音等105款App违法违规收集使用个人信息情况的通报》，称在调查之后发现这些应用收集了与其服务无关的个人信息或未经用户同意收集使用个人信息。被列入名单中的应用包括抖音、快手、360 浏览器、搜狗浏览器、百度浏览器、360 搜索、欧朋浏览器（Opera）、UC、傲游、领英、猎聘、前程无忧、智联、以及百度等等。网信办要求相关运营者在 15 个工作日内完成整改，逾期未完成整改将面临惩罚。

电信行业三户模型_百度百科

Tue, 06 Apr 2021 17:25:42 CST

三户模型即客户、用户和帐户，来源于etom的模型。三户模型在电信行业成为建设运营支撑系统普遍运用的模型，三户模型也是根据营销模型转向“以客户为中心”理念而产生的结果，客户的需求成为支撑系统信息模型不断趋于完善的主要驱动力。与客户这个实体概念关联最为紧密的概念就是用户和帐户，这三者之间的关系应该是一个相互关联但又是独立的三个实体，这种关联只是一个归属和映射的关系，而三个实体本身是相互独立的，分别是体现完全不同的几个域的信息，客户是体现了社会域的信息，用户体现了业务域的信息，帐户体现的是资金域的信息。

中文名三户模型

设计

编辑

三户模型是贯穿于整个业务运营支撑系统中的核心模型之一。

从前台的营业、到后台的计费帐务、决策分析以及客户关系管理和客户服务等子系统都要贯彻三户模型。在实施应用的过程中，保持客户、账户和用户三个信息实体的清晰边界与关系是信息系统建设的关键点，但在许多系统的建设中，这三者之间的界定往往不是十分清晰，为了实现某些未透彻分析的客户需求，模糊了三户的概念，从而导致整个业务运营支撑系统中的信息关系与数据关系的混乱，从而导致了信息数据无法进行高效合理的统计、分析，无法提取需要的和有价值的信息，甚至造成业务的混乱。

客户

编辑

客户是一个社会化的概念，一个自然人或一个法人（任何社团、组织、机构等，具有社会关系比较紧密，并且有相似消费特征的团体）就称之为一个客户，法人客户既可以是一个企业，也可以是与这个企业、集团相关的自然人客户，可以称之为一个集团客户组（群），因此，实体的属性应该是包含该实体所有的社会属性的描述。自然人应可包括，姓名、性别、年龄、职业、联系地址、联系电话、证件类型、证件号码、电子邮件地址、工作单位、工作性质、职位等等社会属性。法人客户的概念同样成立，此实体应该包含了法人客户的社会属性的描述。如法人机构名称、证件类型、证件号码、联系人、联系地址、联系电话、法人机构性质等。

由于人在参与社会活动的过程中，针对具体的社会活动会产生一些附加的社会信息，同样业务运营商也为客户赋予一定的附加属性，例如客户的忠诚度、信用度、客户级别（客户等级）、客户的状态、客户帐单等，其中有些附加属性本应该也是属于社会属性，但在具体的国情下成为业务经营方赋予客户的附加属性了。例如在中国由于社会的信用体制不健全的情况下，只能在企业根据客户的行为分析而赋予客户信用度；客户应当在该客户的第一个用户产生的时候随之生成，在最后一个用户离开时而离网；客户帐单为客户提供统一的全业务消费视图，这主要是实现法人客户和个人客户的模型统一而产生的，客户帐单是依据用户帐单的简单算数加和而得到的。

客户的模型建立必须考虑中国的国情，在实际的应用过程中会遇到这样的问题，注册开户的客户与实际使用的客户并非同一个人，我们建立客户资料的目的是为了更好地为使用业务的客户服务，并不是开户人；从企业运营风险的角度来看，在当前信用制度不健全的情况下，企业必须考虑到运营风险，为了规避风险需要很完善、真实的客户资料，但我们重视了注册开户客户的资料而忽略了使用客户的资料信息，对我们的服务造成了很大的麻烦。处理这个矛盾我认为，主要是市场理念的问题。首先，为了让使用客户享受到服务，我们的客户资料应该以使用客户的资料为主；其次为了规避运营风险，应该登记担保人的信息，这个资料信息即就是注册客户的资料信息。这样使用客户的资料中对身份证的验证不像现在那样重要了，而注册客户的的身份证验证才是重点，因为他是担保人，这在金融界也是使用的一个方法来规避金融风险的。实际上在我们市场在做一些市场活动中，已经完善了一个模型，在客户资料模型中，已经加入了担保人的信息，但在市场运营的过程中并没有这样贯彻。这样客户资料模型就应该改变为使用客户的资料，而不是注册开户客户的资料。

帐户

编辑

帐户的概念起源于金融业，只是一个客户在运营商存放资金的实体，目的是为选择的产品付费。该实体应该包含帐户的归属人，可以归属一个个人，也可以归属于一个团体。帐户应该还包含了资金余额、联系人、联系电话、开户日期、帐户的状态、催费金额、催费次数等等。一个客户可以拥有一个帐户也可以拥有多个帐户，帐户上的资金可以为客户本人的用户付费，也可以为其他客户的用户付费，这种付费关系需要一个付费规则进行关联。

既然账户关系到付费规则，必然会引出帐单的概念，帐单是计费帐务模块产生的。一般来说就一个产品（用户）而言，应该有产品的消费价格，我们在生成帐单也应该是按照这种价格生成，从而可以得出，我们首先要生成用户账单，帐单应该归属于用户。帐单应该分为两级，客户帐单和用户帐单；客户帐单是根据用户帐单按照客户的订制规则进行简单的算术加和得到的；用户账单可以进一步细分为帐单项，账单项是为客户打印账单提供清晰明了的消费明细；而帐单项由一个或者几个帐目项组成，帐目是对该产品某项子服务的消费金额，也是计费过程中的最小累帐单元，按照客户的账单订制规则将帐目合成容易理解的账单项。帐单应当归属于用户，为客户提供的帐单应当以产品为单元来生成帐单，一般的消费习惯都是以产品为单元来付费；但同时也应该生成客户帐单，如果一个客户选择了运营商的多个产品，那么客户如果需要一个所有产品的账单，运营商应当提供，同时集团客户需要一个集团所有客户的消费明细，也需要有一个集团客户帐单。

用户和帐户的映射关系，主要就是销账规则，该规则指明了帐户为某个或者某几个账单，或者其中某一个账单中几个账单项的付费关系。账户可以细分为科目，科目应当对应帐单中的帐目，表示了该资金的用途和来源，可以一个科目对应一个账单中的帐目，也可以一个科目对应一个账单中的几个帐目。一个用户在开户时，必须要指定一个账户为其付费，如果没有已有帐户为其付费，则必须新建立一个帐户，在指定帐户的时候，如果是一个帐单需要几个账户付费，则要按照帐目指定帐户。如果存在一个帐户为多个用户付费的情况，则客户必须制定这种付费关系的优先级。

销账流程中处理模型应当也是按照用户的账单来销账，而不是按照客户帐单，用户与账户对应了一种付费映射关系，所以这种付费关系不在映射到客户，简化付费模型的复杂度，客户的账单应当只是用户帐单的简单算术运算的得到的账单，只提供打印，客户可以选择按照客户帐单打印也可以选择按照用户帐单打印。运营商都是提供销账后的账单，所以如果有一个用户账单没有销账的情况下，不能提供客户帐单，只有将所有的用户帐单都销账以后才能提供客户帐单。销账模型的设计上应当考虑半冲销，这主要存在于预交款用户上，如果帐户上的资金余额不能够冲销一个用户的账单，那么称之为部分冲销，由于帐户的账目是最小的单位，则只能将账目可以拆分成两个部分。如一个账单的所有账目都被销帐后，才能算该用户的帐单完全销账。只有将所有用户的账单完全销账后，才能算该客户的账单完全销账。

客户和帐户应当有一个归属的对应规则，该规则应当是一种归属关系，个人账户应该归属于个人客户，集团账户应当归属于集团客户。但这只是一种归属关系，而没有付费关系，账户可以跨客户为几个用户付费，也可以为单个用户帐单的某个帐目付费，

客户和用户应当存在一个归属对应规则，一个用户开户应当归属一个客户，就和一个产品必须有使用人一样。当一个集团客户的帐户从集团分离出来的时候，必须重新建立客户资料。但一个客户加入一个集团的时候，就可以需要将其并入到集团客户的资料中。这种设计思想是服务的对象的改变，我们服务的是人，而不是产品（用户），体现出“以人为本”的服务理念，所以针对个人客户我们的服务对象是客户本身，针对集团客户服务的服务是集团，而不是单个人用户。

产品在市场提供时难免会遇到，产品的某项子功能的交叉优惠，比如在发布移动产品的同时想附加赠送一个数据业务功能，从而能够使客户能够体验一下数据业务，这是一种促销的策略。我认为这个赠送的数据业务功能，应当打包成为一个产品。在商业活动中，一个产品售出时赠送另外一个产品，这是很常见的事情，所以这种赠送的新业务也应当成为一个产品来赠送。在具体的系统模型中的体现就是增加一个用户，并赋予一定的资费，同时指定一个账户来为其销账，就统一了整个模型。

用户

编辑

用户是客户使用运营商开发的一个产品以及基于该产品之上的增值业务时，产生的一个实体。如果说一个客户使用了多个产品，那么一个客户就会对应好几个用户（即产品）。从这个角度上来看，用户的属性应当包含产品的属性和特征，产品的属性就包括了，产品提供的业务功能、产品的价格、产品的服务。就拿移动电话为例，包括了电话号码、SIM卡号、资费、用户的终端设备型号和机身串号、以及开通的功能（省内长途、国际长途、国内长途、省内漫游、国内漫游、国际漫游等等）和特服（来电显示、三方通话、呼叫转移等等）、开通渠道、开通时间、用户状态、最后一次状态改变时间以及增值业务的开通情况以及增值业务的资费情况等等。还有就是运营商附加给用户的属性，例如用户的级别（在所有此类用户的等级）、用户的帐单等等。

产品，从客户的角度来看，应该是客户利用一种终端设备可以使用的一个业务功能包；从运营商的角度来看，是通过一套网络平台或者设备为客户提供基于该平台下的一个服务集合。就其含义来分可以分为基本业务和增值业务；

基本服务就是提供的基本产品服务，基于运营商提供的硬件平台独立为客户提供的服务，例如：基本的通话、短信、来电显示、三方通话、会议电话等等，这些服务都是运营商可以借助自己的网络平台独立为客户提供的服务，除了基本通话服务外我们称之为特服。

增值服务提供商通过对服务提供商所提供的产品进行扩展，为客户提供了服务提供商原来所没有提供的额外的功能或对性能进行提升等，一般来说，增值业务的服务需要借助另外一个设备平台共同来实现，增值业务提供商提供辅助设备，借助运营商的网络平台共同实现的业务。通过为服务提供商的产品增加一些新功能，从而提升了产品的价值，但是，这些新增的功能对于产品本身而言并非本质性的、基本的东西，而是居于从属地位的。例如，附加服务提供商对于一个移动电话服务的服务提供商而言，可以是一个专家级的内容提供商角色。附加服务提供商与服务提供商之间是合作伙伴关系，通过应用它自己的产品，它可以增强服务提供商提供给客户的产品，从而使得服务提供商对于客户变得更具有吸引力，同时客户在使用服务提供商的产品时也更方便了。附加服务提供商与客户间可能也会存在商业关系，这依赖于所提供产品的特点，同时，也可能依赖于周边的商业文化氛围。通常，一个附加服务提供商所提供的产品是要与服务提供商的产品一起推广的。

产品是一个市场范畴的概念，作为一个产品，首先应该是对产品提供的各种子服务进行子业务关联性定义（子服务相互之间是有关联性的，例如国际漫游开放的同时国际长途也应该开放，不然就无法国际漫游）；其次是为产品定价，定价的原则应该细化到各种子业务的价格，面向客户应该是清晰明了的；另外应该给用户提供给与该产品的基础之上可以使用的哪类增值业务，增值业务的定价应该给用户一个清晰的说明（例如利用短信通知）；最后是产品的服务，是指在客户在选择该产品后能够获得服务。如果一个客户选择了该项产品，那就形成了一个用户。

百度中标今年国内智能交通领域的最大招标订单

Fri, 28 Aug 2020 12:42:37 CST

PingWest品玩8月28日讯，据财联社报道，今日，百度Apollo旗下子公司阿波罗智行科技（广州）有限公司中标“广州市黄埔区广州开发区面向自动驾驶与车路协同的智慧交通‘新基建’项目”，采购人为科学城（广州）投资集团有限公司，项目金额接近4.6亿元，这成为今年国内智能交通领域的最大招标项目订单，订单包括车路协同路网基础设施、智能路口、车联网等相关应用系统的建设，这有望加速推动广州开发区以及粤港澳大湾区智能网联示范高地建设。

百度APP-Android H5首屏优化实践

Sat, 17 Aug 2019 14:10:06 CST

一、背景

百度App自2016年上半年尝试Feed流业务形态，至2017年下半年，历经10个版本的迭代，基本完成了产品形态的初步探索。在整个Feed流形态的闭环中，新闻详情页（文中称为落地页）作为重要的组成部分，如果打开页面后，loading时间过长，会严重影响用户体验。因此我们针对落地页这种H5的首屏展现速度进行了长期优化，本文会详细阐述整个优化思路和技术细节

二、方法论

通过分析用户反馈，发现当时的落地页从点击到首屏展现平均需要3s的时间，每次用户兴致勃勃的想要浏览感兴趣的文章时，却因为过长的loading时间，而不耐烦的选择了back。为了提升用户体验，我们进行了以下工作：

通过用户反馈、QA测试等多种渠道，发现落地页首屏加载慢问题
定义首屏性能指标（首屏含图，以图片加载为准；首屏无图，以文字渲染结束为准）
NA、内核、H5三方针对自己加载H5的流程进行划分并埋点上报
统计侧根据三端上报的数据产出平均值、80分位值的性能报表
分析性能报表，找到不合理的耗时点，并进行优化
以AB实验方式，对比优化前后的性能报表数据，产出优化效果，同时评估用户体验等相关指标
按照长期优化的方式，不断分析定位性能瓶颈点并优化，以AB实验方式评估效果，最终达到我们的落地页秒开目标

三、Hybrid方案简述及性能瓶颈

（一）方案简述
优化之前，我们与业内大多数的App一样，在落地页的技术选型中，为了满足跨平台和动态性的要求，采用了Hybrid这种比较成熟的方案。Hybrid，顾名思义，即混合开发，也就是半原生半Web的方式。页面中的复杂交互功能采用端能力的方式，调用原生API来实现。成本低，灵活性较好，适合偏信息展示类的H5场景。
下面用一张图来表示百度App中Hybrid的实现机制和加载流程

（二）性能瓶颈
为了分析Hybrid方案首屏展现较慢的原因，找到具体的性能瓶颈，客户端和前端分别针对各自加载过程中的关键节点进行埋点统计，并借由性能监控平台日志进行展示，下图是截取的某一天全网用户的落地页首屏展现速度80分位数据

各阶段性能点可以按Hybrid加载流程进行划分，可以看到，从点击到首屏展现，大致需要2600ms，其中初始化NA组件需要350ms，Hybrid初始化需要170ms，前端H5执行JS获取正文并渲染需要1400ms，完成图片加载和渲染需要700ms的时间
我们具体分析下四个阶段的性能损耗主要发生在哪些地方：
1) 初始化NA组件
从点击到落地页框架初始化完成，主要工作为初始化WebView，尤其是第一次进入（WebView首次创建耗时均值为500ms）
2) Hybrid初始化
这个阶段的工作主要包含两部分，一个是根据调起协议中传入的相关参数，校验解压下发到本地的Hybrid模板，大致需要100ms的时间；此外，WebView.loadUrl执行后，会触发对Hybrid模板头部和Body的解析
3) 正文加载&渲染
执行到这个阶段，内核已经完成了对Hybrid模板头部和body的解析，此时需要加载解析页面所需的JS文件，并通过JS调用端能力发起对正文数据的请求，客户端从Server拿到数据后，用JsCallback的方式回传给前端，前端需要对客户端传来的JSON格式的正文数据进行解析，并构造DOM结构，进而触发内核的渲染流程；此过程中，涉及到对JS的请求，加载、解析、执行等一系列步骤，并且存在端能力调用、JSON解析、构造DOM等操作，较为耗时
4) 图片加载
第（3）步中，前端获取到的正文数据包含落地页的图片地址集，在完成正文的渲染后，需要前端再次执行图片请求的端能力，客户端这边接收到图片地址集后按顺序请求服务器，完成下载后，客户端会调用一次IO将文件写入缓存，同时将对应图片的本地地址回传给前端，最终通过内核再发起一次IO操作获取到图片数据流，进行渲染；总体来看，图片渲染的时间依赖前端的解析效率、端能力执行效率、下载速度、IO速度等因素
通过分析，延伸出对Hybrid方案的一些思考：

渲染为什么这么慢
图片请求能否提前
串行逻辑是否可以改为并行
WebView初始化时间是否还可以优化

四、百度App落地页优化方案

（一）CloudHybrid
基于之前对Hybrid性能的分析，我们内部孵化了一个叫做CloudHybrid的项目，用来解决落地页首屏展现慢的痛点；一句话来形容CloudHybrid方案，就是采用后端直出+预取+拦截的方式，简化页面渲染流程，提前化&并行化网络请求逻辑，进而提升H5首屏速度

1.后端直出-快速渲染首屏
a. 页面静态直出
对于Hybrid方案来说，端上预置和加载的html文件只是一个模板文件，内部包含一些简单的JS和CSS文件，端上加载HTML后，需要执行JS通过端能力从Server异步请求正文数据，得到数据后，还需要解析JSON，构造DOM，应用CSS样式等一系列耗时的步骤，最终才能由内核进行渲染上屏；为了提升首屏展示速度，可以利用后端渲染技术(smarty)对正文数据和前端代码进行整合，直出首屏内容，直出后的html文件包含首屏展现所需的内容和样式，内核可以直接渲染；首屏外的内容（包括相关推荐、广告等）可以在内核渲染完首屏后，执行JS，并利用preact进行异步渲染

百度APP直出方案：

对于客户端来说，从CDN中拉取到的html都是已经在server渲染好首屏的，这样的内容无需二次加工，展现速度可以大大提升，仅直出一点，手百Feed落地页的首屏性能数据就从2600ms优化到2000ms以内
b. 动态信息回填
为了保证首屏渲染结果的准确性，除了在server侧对正文内容和前端代码进行整合外，还需要一些影响页面渲染的客户端状态信息，例如首图地址、字体大小、夜间模式等
这里我们采用动态回填的方式，前端会在直出的html中定义一系列特殊字符，用来占位；客户端在loadUrl之前，会利用正则匹配的方式，查找这些占位字符，并按照协议映射成端信息；经过客户端回填处理后的html内容，已经具备了展现首屏的所有条件
c. 动画间渲染
先看下优化前后效果（上图：优化前；下图：优化后）：

正常来说，直出后的页面展现速度已经很快了；但在实际开发中，你可能会遇到即使自己的数据加载速度再快，仍然会出现Activity切换过程中无法渲染H5页面的问题（可以通过开发者模式放慢动画时间来验证），产生视觉上的白屏现象（如上面上图）
我们通过研究源码发现，系统处理view绘制的时候，有一个属性setDrawDuringWindowsAnimating，从命名可以看出来，这个属性是用来控制window做动画的过程中是否可以正常绘制，而恰好在Android 4.2到Android N之间，系统为了组件切换的流程性考虑，该字段为false，我们可以利用反射的方式去手动修改这个属性，改进后的效果见上面下图

  
/**
     * 让 activity transition 动画过程中可以正常渲染页面
     */
    private void setDrawDuringWindowsAnimating(View view) {
        if (Build.VERSION.SDK_INT > Build.VERSION_CODES.M
                || Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
            // 1 android n以上  & android 4.1以下不存在此问题，无须处理
            return;
        }
        // 4.2不存在setDrawDuringWindowsAnimating，需要特殊处理
        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
            handleDispatchDoneAnimating(view);
            return;
        }
        try {
            // 4.3及以上，反射setDrawDuringWindowsAnimating来实现动画过程中渲染
            ViewParent rootParent = view.getRootView().getParent();
            Method method = rootParent.getClass()
                    .getDeclaredMethod("setDrawDuringWindowsAnimating", boolean.class);
            method.setAccessible(true);
            method.invoke(rootParent, true);
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    /**
     * android4.2可以反射handleDispatchDoneAnimating来解决
     */
    private void handleDispatchDoneAnimating(View paramView) {
        try {
            ViewParent localViewParent = paramView.getRootView().getParent();
            Class localClass = localViewParent.getClass();
            Method localMethod = localClass.getDeclaredMethod("handleDispatchDoneAnimating");
            localMethod.setAccessible(true);
            localMethod.invoke(localViewParent);
        } catch (Exception localException) {
            localException.printStackTrace();
        }
    }

2.智能预取-提前化网络请求
经过直出的改造之后，为了更快的渲染首屏，减少过程中涉及到的网络请求耗时，我们可以按照一定的策略和时机，提前从CDN中请求部分落地页html，缓存到本地，这样当用户点击查看新闻时，只需从缓存中加载即可

手百预取服务架构图

目前手百预取服务支撑着图文、图集、视频、广告等多个业务方，根据业务场景的不同，触发时机可以自定义，也可以遵循我们默认的刷新、滑停、点击等时机，此外，我们会对预取内容进行优先级排序（根据资源类型、触发时机），会动态的根据当前手机状态信息进行并发控制和流量控制，在一些降级场景中，server还可以通过云控的方式来控制是否预取以及预取的数量
3.通用拦截-缓存共享、请求并行
在落地页中，除了文本外，图片也是重要的组成部分。直出解决了文字展现的速度问题，但图片的加载渲染速度仍不理想，尤其是首屏中带有图片的文章，其首图的渲染速度才是真正的首屏时间点
传统Hybrid方案，前端页面通过端能力调用NA图片下载能力来缓存和渲染图片，虽然实现了客户端和前端图片缓存的共享，但由于JS执行时机较晚，且多次端能力调用存在效率问题，导致图片渲染延后

初步改进方案：为了提升图片加载速度，减少JS调用耗时，改为纯H5请求图片，速度虽然有所提升，但是客户端和前端缓存无法共享，当点击图片调起NA图片查看器时，无法做到沉浸式效果，且仍需重复下载一次图片，造成流量浪费
终极方案：借由内核的shouldInterceptRequest回调，拦截落地页图片请求，由客户端调用NA图片下载框架进行下载，并以管道方式填充到内核的WebResourceResponse中

此方案在满足图片渲染速度的同时，解耦了客户端和前端代码，客户端充当server角色，对图片进行请求和缓存控制，保证前端和客户端可以共用图片缓存，改造后的方案，非首图展现流程，页面不卡顿，首屏80分位值缩短80ms~150ms
效果如下（上图：优化前Hybrid方案；下图：优化后通用拦截方案）：

4.整体方案流程

（二）新的优化尝试
1.WebView预创建
为了节省WebView的性能损耗，我们可以在合适时机提前创建好WebView，并存入缓存池，当页面需要显示内容时，直接从缓存池获取创建好的WebView，根据性能数据显示，WebView预创建可以提升首屏渲染时间200ms+

具体以Feed落地页为例，当用户进入手百并触发Feed吸顶操作后，我们会创建第一个WebView，当用户进入落地页后，会从缓存池中取出来渲染H5页面，为了不影响页面的加载速度，同时保证下次进入落地页缓存池中仍然有可用的WebView组件，我们会在每次页面加载完成（pageFinish）或者back退出落地页的时机，去触发预创建WebView的逻辑
由于WebView的初始化需要和context进行绑定，若想实现预创建的逻辑，需要保证context的一致性，常规做法我们考虑可以用fragment来实现承载H5页面的容器，这样context可以用外层的activity实例，但Fragment本身的切换流畅度存在一定问题，并且这样做限定了WebView预创建适用的场景。为此，我们找到了一种更加完美的替代方案，即MutableContextWrapper

Special version of ContextWrapper that allows the base context to be modified after it is initially set. Change the base context for this ContextWrapper. All calls will then be delegated to the base context. Unlike ContextWrapper, the base context can be changed even after one is already set.
简单来说，就是一种新的context包装类，允许外部修改它的baseContext，并且所有ContextWrapper调用的方法都会代理到baseContext来执行

下面是截取的一段预创建WebView的代码

  /**
     * 创建WebView实例
     * 用了applicationContext
     */
    @DebugTrace
    public void prepareNewWebView() {
        if (mCachedWebViewStack.size() < CACHED_WEBVIEW_MAX_NUM) {
            mCachedWebViewStack.push(new WebView(new MutableContextWrapper(getAppContext())));
        }
    }
    /**
     * 从缓存池中获取合适的WebView
     * 
     * @param context activity context
     * @return WebView
     */
    private WebView acquireWebViewInternal(Context context) {
        // 为空，直接返回新实例
        if (mCachedWebViewStack == null || mCachedWebViewStack.isEmpty()) {
            return new WebView(context);
        }
        WebView webView = mCachedWebViewStack.pop();
        // webView不为空，则开始使用预创建的WebView,并且替换Context
        MutableContextWrapper contextWrapper = (MutableContextWrapper) webView.getContext();
        contextWrapper.setBaseContext(context);
        return webView;
    }

2.NA组件懒加载
a. WebView初始化完成，立刻loadUrl，无需等待框架onCreate或者OnResume结束
b. WebView初始完成后到页面首屏绘制完成之间，尽量减少UI线程的其他操作，繁忙的UI线程会拖慢WebView.loadUrl的速度

具体到Feed落地页场景，由于我们的落地页包含两部分，WebView+NA评论组件，正常流程会在WebView初始化结束后，开始评论组件的初始化及评论数据的获取。由于此时评论的初始化仍处在onCreate的UI消息处理中，会严重延迟内核加载主文档的逻辑。考虑到用户进入落地页的时候，评论组件对用户来说并不可见，所以将评论组件的初始化延迟到页面的pageFinish时机或者firstScreenPaintFinished； 80分位性能提升60ms~100ms

3.内核优化
a. 内核渲染优化：
内核中主要分为三个线程（IOThread、MainThread、ParserThread），首先IOThread会从网络端或者本地获取html数据，并把数据交给MainThread（渲染线程，十分繁忙，用于JS执行，页面布局等），为了保证MainThread不被阻塞，需要额外起一个后台线程（ParserThread）用来做html的解析工作。ParserThread每解析到落地页html中带有特殊class标记的一个div标签或者P标签（图中的first、second）时，就会触发一次MainThread的layout工作，并把layout后得到的高度与屏幕高度进行对比，如果当前layout高度已经大于屏幕高度，我们认为首屏内容已经完成布局，可以触发渲染上屏逻辑，不必等到整篇html全部解析完成再上屏，提前了首屏的渲染时间； 80分位下，内核的渲染优化可以提升首屏速度100ms~200ms

b. 预加载JS：
预创建好WebView后，通过预加载JS（与内核约定好的JS内容，内核侧执行该JS时，只做初始化操作），触发WebView初始化逻辑，缩短后续加载url耗时； 80分位性能提升80ms左右

五、新的问题-流量和速度的平衡

频繁预取会带来流量的浪费：预取的命中率虽然达到了90%以上，但有效率仅有15%
解决思路：
&nbsp&nbsp1.压缩预取的包大小，减少下行流量
&nbsp&nbsp2.少预取或者不预取
（一）精简预取数据：
图文：优化直出html中内联的css、icon等数据，数据大小减少约40%
（二）后端智能预取：
1) 图文：通过对图文资源进行评分，来决定4G是否需要预取，多组AB试验最优效果劣化9.5ms
2)视频：为了平衡性能和流量，在性能劣化可接受的范围内（视频起播时间劣化100ms），针对视频部分采用流量高峰期不预取的策略，减少视频总流量约7%，整体带宽峰值下降3%
（三）AI智能预取
通用用户操作行为，对Feed预取进行AI预测，减少无效预取的数量。

六、总结&展望

（一）优化总结
在总结之前，先来看下整体优化的前后效果对比（上图：优化前；下图：优化后）：

可以看到，经过一系列的优化手段，落地页已经实现了秒开效果。回顾所做的事情，从分析用户反馈到定位性能瓶颈，再到各种优化尝试，发现所有类似的性能优化手段都可以从以下几点入手：

提前做：包括预创建WebView和预取数据
并行做：包括图片直出&拦截加载，框架初始化阶段开启异步线程准备数据等
轻量化：对于前端来说，要尽量减少页面大小，删减不必要的JS和CSS，不仅可以缩短网络请求时间，还能提升内核解析时间
简单化：对于简单的信息展示页面，对内容动态性要求不高的场景，可以考虑使用直出替代hybrid，展示内容直接可渲染，无需JS异步加载

（二）TODO

页面的更新机制，目前方案仅适用于偏静态页面，对于动态性要求较高的业务，需要提供页面更新机制，保证每次显示的正确性
开源之路：后续计划将我们总结下来的这套方案打包开源，前行之路必定坎坷，希望大家多多支持

百度最难捱的一夜：五名高管闪电辞职内幕

Thu, 30 May 2019 22:46:14 CST

五位高管离职、销售侧管理层空缺、老板和老板娘亲自上前线督战——百度正处在迎接字节跳动搜索大战的最前夜

文 |《财经》记者张珺

编辑|宋玮

2019年5月17日凌晨4点，百度（BIDU）的财报发布团队已经忙碌到最后关头，在困倦和疲惫中匆匆睡去。他们此时完全不知道，百度高级副总裁、搜索公司总裁向海龙的离职消息将在1小时后由公司最高层面宣布。紧接着，内外将引发轩然大波。

这位扎根14年，在百度内部犹如“磐石”一样的人，去年底悄悄购买了行李箱，开始有计划地从北京办公室和居所往上海家中搬东西，到离职当天办公室已经收拾一空。一位近距离接触向海龙人士将此称为“蚂蚁搬家”。

此前，向海龙一直在北京租房，2019年春节刚过，他没有对身边任何人说明缘由，把租住多年的房子退了，自己住进酒店。

密切跟随他的助理一直到官方消息发布的一刻才恍然大悟：“哦，海龙撤了。”

向海龙的离职消息和百度2019年Q1财报同期发布，该季度创造了这家公司自2005年上市以来亏损先例，净亏损3.27亿元人民币。双重利空叠加，百度市值一夜蒸发89亿美金，从538亿跌落至449亿美元。这一跌幅直逼去年5月明星经理人陆奇（原百度集团总裁、COO）辞职当日挥发的93亿美金，但彼时其市值高达886亿美元。整整一年，百度市价已然腰斩。

向海龙辞职只是这次风暴正中央，漩涡中，还有另外4位高管离开。《财经》独家获悉，就在近三个月，百度副总裁吴海峰、顾国栋、赵承，以及执行总监孙雯玉均辞职。其中，赵承和孙雯玉的Last Day在4月，吴海峰和顾国栋在5月，向海龙最迟，在6月。百度副总裁的职级为M4-A，执行总监为M4，后者被认为是“见习期的副总裁”。

其中多位都是在百度10年以上老将——向海龙14年，吴海峰13年，孙雯玉12年，赵承13年左右。除了赵承主管政府关系外，向海龙、顾国栋、吴海峰和孙雯玉都为百度搜索公司管理层。

《财经》独家了解到，向海龙离职后，其“接班人”、高级副总裁沈抖未直接接手搜索公司销售体系。销售是向海龙传统强项，由顾国栋直接管理，二人辞任后还没找到新接替者。如今，百度采用了一个权宜之计——成立“销售管理委员会”来过渡，成员包括崔珊珊（人力资源副总裁）和沈抖。

五位高管离职、销售侧管理层空缺、老板和老板娘亲自上前线督战——百度正处在迎接字节跳动搜索大战的最前夜。兵临城下，这家19岁的公司重新“排兵布阵”。这是在战争号角吹响前一个难眠而不安的夜晚。

地震当日

“陆奇要走内部有风声传出来，这次好神奇，没有人知道，真是一点都不知道。”一位百度搜索公司中层人士对《财经》记者形容这起风波，“事发前没有任何异动，事发后就不是异动了，是地震。”

向海龙虽然职位为集团高级副总裁，但他手握实权最大，在“走马灯”般的百度高管轮换中，在位时间最长（百度成立19年，他在百度14年）。百度原副总裁李明远“倒台”后，2016年4月百度成立搜索公司，向海龙出任该公司首位总裁。

这是一场突如其来的离职。就在1天前，有团队刚去向海龙办公室做了汇报；3天前，向海龙如期参加了搜索公司周会；7天前，向海龙在成都出席一年一度的百度联盟生态合作伙伴大会，并发表演讲。

很快百度下了封口令。一位百度技术体系员工回复《财经》记者消息说：“有要求，不讨论，不评论，不转发，不接受采访。”

辞职当天，董事长兼CEO李彦宏临时召集搜索公司连开两场内部会，上午是总监级，下午是经理级。出席高层包括李彦宏、马东敏，以及Estaff成员。（Estaff是代表百度最高决策的虚拟组织）

“What’s the problem? ”李彦宏在会上问道。接着，他给出三个回答——第一，宏观经济有压力；第二，广告主预算有压力；第三，内部广告业务有问题。一位在场人士认为，第三方面的归因是暗指去年医疗广告业务整改未达集团预期。

“我会带领大家继续往前走。”上述人士转述向海龙继任者沈抖在现场的表态，“我们肯定是有问题的，但是造就问题的是我们每一个人。”沈抖当天升任高级副总裁，他正努力在内部稳定军心。

Q1财报和向海龙辞职消息都于凌晨5点发布，百度官方当即给出定调。在李彦宏发的内部信中，他用“具有战略视野，敢打硬仗、能打胜仗”形容沈抖，而仅用寥寥数语宣布向海龙辞职：“我们感谢海龙过去14年的陪伴和贡献，并祝他未来一切顺利。”

负责对外沟通的公关部提前2小时，在凌晨3点才紧急接获通知，他们迅速拟定口径。一位公关人士斩钉截铁对《财经》表示，向海龙对近期负责的核心业绩不达标，用户体验没有改善，要负不小责任。向海龙辞职、沈抖上任，是百度自我革新、优胜劣汰、能者居之。“也破除了外界对海龙动不了的说法。”

“搜索公司挺慌的。”上述中层认为，现在只是震荡的开端。“看到新闻觉得我肯定要失业了。”内部甚至已经有些人开始找工作。不过，他们没人能说得清向海龙去职真相，谣言在公司散播——其中一个传闻是，“向海龙是两周内被高层干掉的”。

一位向海龙的同事告诉《财经》记者，向海龙在2018年初有过一段迷茫期，那时候陆奇任COO，向海龙向他汇报，再由陆奇汇报给李彦宏。“他很迷茫，自己的角色和定位到底是什么。”不过那时候仅仅是徘徊，真正下定决心辞职是在去年中陆奇离开之后。陆的离职本质上加速了向做决定，“因为他成了所有矛盾的出口”。

据这位同事回忆，他曾私底下对向海龙推断局势：“陆奇离开了，集团层面是不是应该给你升一个总裁或者COO？”向海龙那时很肯定地回答，他不想当百度的二号人物。

上述近距离接触向海龙人士称，向海龙此次系主动辞职，这天他没有在公司出现，下午已乘坐高铁离开北京这片是非之地，返回上海的家。

《财经》了解到，百度搜索公司已改组为“移动生态事业群”，英文名Mobile Ecology Group，简称MEG 。三年时间，向海龙是搜索公司第一任总裁，也是最后一任，他的辞职标志百度搜索公司时代的落幕。

风暴的酝酿

风暴不是一蹴而就，而是一步步酝酿到今日的。

向海龙即将离职的消息甚嚣尘上始于2017年。彼时，在百度12年之久的搜索公司HRBP（人力资源业务合作伙伴）负责人顾佩玲突然辞职赴美读书。HR是最能灵敏感知内部变化的部门，有两位接受《财经》采访的人士都把顾的离职看做是“地震”来临前先兆。

对于百度来说，2017年是让外界看到希望的一年。“魏则西事件”曾在2016年将这家公司推上舆论风头浪尖，2017年初伴随“硅谷最有权势华人”陆奇的强势入驻和马东敏的回归，所有人认为百度迎来巨变。马东敏出任CEO特别助理，负责战投部。但后来，集团层面发生了一件事，一度引起员工们的警觉。

《财经》了解到，马东敏回公司后，牵头组建百度“人事委员会”，负责公司中管干部任命和提拔。该委员会成员包括李彦宏、马东敏、崔珊珊和刘辉（人力资源高级副总裁，今年5月退休）。崔珊珊是“百度创始七剑客之一”，和马东敏一样，她也是17年在百度元老任旭阳举荐下重回百度的，出任“文化委员会秘书长”，目前接替刘辉担任人力资源副总裁。

一位接近百度人士认为，从“人事委员会”成立起，搜索公司进一步把“人权”交到集团手中，中管干部从向搜索公司晋升委员会述职答辩转向集团。

该委员会首次在搜索公司发挥作用，是在决定百度联盟总经理一职的任命上。联盟总经理有三年任期限制，2017年底，向海龙提议，让搜索公司原运营规划部负责人郭浪波来担任，但“人事委员会”拍板，答案是否认的。（郭浪波已离职）

崔芳和李忠军分别是HRBP和联盟的接任者，崔芳本是支持包括战投在内非业务的HRBP，李忠军是原CEO助理。他们二人在内部看来更接近李彦宏和马东敏，而非向海龙体系内的原部下。这样是为了保证管理层彼此权力监督和透明。

但上述人士称，有时从集团最高层派驻的手下可能会干扰业务正常运行。一个案例是，搜索公司曾在贴吧尝试过一个小视频的信息流产品（有些类似今天的抖音），而战投部在2017年下派了一名年轻的经理王涵宇来贴吧，他认为抖音这种产品只是昙花一现，应该在贴吧内发展“介于熟人和陌生人的社交”，最终推翻既定方向。不久，百度贴吧总经理胡玥离职。

除了对人事任命权缺乏把控力，作为搜索公司总裁，向海龙自始至终没有财权在内部是一个公开的秘密。搜索公司财务都需要经过集团CFO，而CFO向CEO汇报。原集团CFO李昕晢（JenniferLi）和向海龙是相互掣肘的关系，上述中层回忆起一次矛盾爆发。

CFO的观点是，应该保证公司利润率，哪怕收缩业务规模，只“吃”利润最丰厚的部分。一次会议上，向海龙当着老板的面质问：“搜索公司到底是保利润还是利润率？”一位搜索公司管理者有些讽刺地插话：“手机贴膜利润率很高，你去贴吗？”

一位知情人士对《财经》记者解释，搜索公司只是组织架构的虚拟公司，并未单独成立公司实体，本质就是一个“事业群”。百度从来都是集团化管理（由集团高层而非事业部负责人做关键决策）。包括陆奇在内，没有任何一名高级管理人员手握过人事和财务大权。

2017年10月，关于向海龙离职的传闻一度达到鼎沸。在位于中关村的皇冠假日酒店会议室，搜索公司管理层在这里开战略研讨会。约20人的内部会上，向海龙坐中间，他开口第一句话就说：“我先跟大家宣布一个事，我不会走。”

此后半年流言更加汹涌，一直到2018年5月18日陆奇卸任百度总裁和COO职务，4天后向海龙带着搜索公司高管出席联盟生态大会，这一传言终于平息。然而，一年后，在外界最平静的时刻，他离开了。

“所有的预兆都是从去年下半年开始密集出现的。”上述中层分析。他能明显感觉到，集团高层开始加强管控——“评定总监的时候，Robin（李彦宏）和Melissa（马东敏）也要看，以前是没有的。”

陆奇离任后，百度面临的内外压力更为凸现。《财经》了解到，2018下半年，百度启动对医疗广告的整改。此前医疗广告营收占比较高（约20%-25%），但医疗广告经常存在虚假成分。内部发起了一个叫“落地页托管”的整改计划，强制客户将推广页托管到百度，进行监测以便打击假冒，要求在去年底100%完成。该计划主要针对“四品一械”（即药品、保健品、化妆品、医疗用品、医疗器械）。一位接近财务信息人士对《财经》记者透露，这次整改从去年四季度开始影响营收，单季度大概影响十几亿人民币左右。

在内部整顿的同时，外部势力正在迅猛崛起——字节跳动旗下抖音今年1月宣布日活突破2.5亿。在宏观经济环境变化、广告主预算收紧的情况下，传统搜索对广告主吸引力下降，新兴媒体对百度的抽血作用逐渐暴露。“去年8-9月份有点感觉出来，但我们对困难的估计准备严重不足。”上述人士认为，去年医疗整改掩盖了营收下滑的本质原因，“躺在了功劳簿上，对外部环境缺少敬畏”。

在风暴爆发前最后三个月，隐约征兆是有迹可循的。据上述人士回忆，今年3月，在李彦宏和马东敏都参加的月度会上，二人一起指责搜索公司销售主管，营收这么差为什么不早说；4月，百度Q1财报原本定在20日发，结果延迟到5月中旬；5月，马东敏亲自出马了，就在财报发布前一周，她专门派其战投部手下计算了搜索公司2019年剩下三季度的收支。

《财经》独家获悉，百度曾给几位核心高管签过一项对赌，记者目前了解到的不完全对赌条件包括：2019年底实现1，股价达约300美元（相当于千亿美金市值）；2，营收约达1200亿人民币。如若完成这些条件，高管们将会有一大笔变现。

权臣向海 龙

很多人不知道，向海龙是百度最高决策组织Estaff中最年轻的高管。他于1977年出生在重庆，今年42岁。

就读于华东师范大学计算机系，向海龙大三就开始创业，是当年同学里第一个花一万块买“大哥大”的人。毕业后向注册成立公司——上海企浪网络科技有限公司，这家公司与百度都是2000年成立，日后成为百度、谷歌、新浪等的代理商。上海企浪的出资人是一名温州企业家，他的妹妹后来成为了向的妻子。

得益于李彦宏赏识，百度在2005年上市前启动了对上海企浪的收购案，这起收购的操刀人是今天高瓴资本创始人兼CEO张磊。由此，28岁的向海龙加入百度，开启了他长达14年的职业生涯。

在百度，向海龙的权力一路扩大。他得到的第一个身份是上海分公司总经理。一年后，当收购对赌到期时，李彦宏让他兼管北京分公司，三个月扭转业绩。他本来想从北京回上海，李彦宏为了挽留，在2007年直接把他晋升为销售副总裁和Estaff成员。这时向海龙还不到30岁，比曾经有“太子”和“最年轻副总裁”之称的李明远担当重任时年龄更小——李明远是31岁升任百度副总裁。

随后向海龙先后“取代”了百度副总裁史有才、王湛和李明远等众多高管的位置。伴随这些人离开，李彦宏把他们留下的业务都划给了向——百度全公司3万多人，向海龙管理约2万；搜索公司充当百度“现金牛”，贡献超7成营收。至此，搜索公司收归了百度很大部分核心业务，而搜索公司的权力顶端就是向海龙。辞职前，他还兼任百度的PC（产品设计委员会）主席，而TC（技术委员会）主席是公司总裁张亚勤。

作为一名在百度颇有权势的高管，很多人对他的印象是——隐忍、知进退、有城府。向海龙开会很少直接坐到李彦宏或马东敏身边。一般的情景是，李彦宏坐在PPT一侧，马东敏坐在大会议桌对面，而向海龙不远不近坐二人中间，保持相对安全的距离。当李彦宏对业务细节出现疑问时，向会走到他跟前趴在桌上给他演示。

“大多数时候，他都会先往后退。”一位搜索公司员工告诉《财经》记者，李彦宏经常会亲自过问项目，向海龙通常做法都是——退到一边。每当遇到决策时，向海龙都会对手下说“你去请教Robin”，而等过一段时间李彦宏退居幕后，他又重新出来做指挥。“有时候Robin会冲得靠前，海龙都是缩的，他们两个永远都是你进我退的关系。”

在任期间，向海龙一直非常低调，尤其不喜欢抛头露面，但他却是身负流言蜚语最多的高层。“他一直低调地躲，但是躲不开，毕竟深陷漩涡里面，是洗不清自己的。”上述向海龙同事说。

虽然性格内敛，但向在商业上展现出生猛的一面。接近向海龙人士说，他特别喜欢看《动物世界》，曾对手下讲，除了人类，世界上绝大多数动物都是饿死的。一只大象可能脚崴了就丢失生命。他因此警告下属——“不能犯一次错误”。

成立搜索公司后，2016年中向海龙提出手百和信息流战略。此战略下，时任负责人报了24个亿的预算。集团批准后，向海龙单独对他说：“我把钱给你了，如果这事做砸了，千刀万剐，提头来见。”

《财经》获悉，2019年百度春晚红包活动斥资10亿人民币，包括4亿央视投标和6亿红包，这是百度历史上第一次花费大额资金打品牌广告。当时高层不少人反对，李彦宏也犹豫了一段时间，向海龙“提着脑袋”签了字。投标时，百度面对的最大竞争对手是字节跳动。据知情人士称，投标时一个是红包活动，一个是视频活动，前者4亿起投，后者2.5亿起投。最后在向的主导下百度以4亿底价拿下红包活动，而字节跳动花了5亿人民币做视频活动。春晚战役的千人团队在百度获得了“重大突破奖”。

李彦宏曾对内表达，高管应当“武将死战，文臣死谏”。

多年以来，向海龙的形象更像是李彦宏和众多百度高管的“反面”。“他是里面最接地气的一个。”前述中层告诉《财经》记者，向海龙给人的感觉不似李彦宏那样文质彬彬，而是“精明、利落、干练”。他重视收集信息，有时凌晨还在向下属询问，他会在群里@所有人，交叉验证。开会风格是针对业务偏强势的探讨，时不时直截了当打断对方说：“你这个不对啊，我听XX说不是这样的。”和李彦宏用人追求完美主义不同，向海龙的观点是“有烂砖没烂墙”。

向海龙格外注重成本控制，投资风格相对保守。在得知一名下属买了辆40万的车，向叫着他的名字认真地说：“你开的是豪车。”此外，他热衷买房，而且很少买别墅，大多选择120平米左右户型，方便转手。

《财经》了解到，百度有两项资本动作变更和向海龙有关。其一是百度外卖的出清，向海龙曾是内部最反对O2O战略的高管之一，当百度放弃O2O向人工智能赛道转变时，高层希望向将百度外卖和糯米都收归搜索公司，向海龙拒绝收百度外卖，这一定程度促使了百度外卖的分拆；其二是，百度曾准备战略投资共享单车品牌ofo，向海龙多次开会向马东敏反对，力劝她放弃这笔投资。其观点是外卖和单车是AT支付战争时期的武器。

上述向的同事说，如果把用户产品和商业产品看做组成飞机的两个发动机，从2009年俞军辞职（原百度产品副总裁，与向海龙同年升任VP，有“百度贴吧之父”之称）起，相当于百度的一个发动机熄火了。“这十年如果没有海龙的话，这个飞机飞不到今天。”——Q1财报显示，百度如今现金和短期金融资产为1578亿人民币，这其中很多归功于向海龙的商业变现。

一位互联网从业者说，如果一定要说向海龙之过，那就是他销售能力过强，令百度变现轻而易举，没能居安思危而错失机遇。

重置棋盘

在近期某位高管离职前，马东敏和崔珊珊与他有过一次对谈。据转述，他们在谈话中抛出一个疑问——百度今天这种状况，市值没有突破，大家的责任是什么？Robin本身就是在承担责任，其他人应该承担什么责任？——这次谈话被认为是集团最高层开始向下追责，起因是抖音赛道错失被抬上桌面。

过去一年，字节跳动在抖音和国际化上突飞猛进，今年初他们悄然上线搜索引擎，正式发起针对百度搜索的进攻。百度不得不整合信息流和搜索防止敌人突围。 2月，搜索公司启动了一轮以迎敌为主要目的的轮岗，但却意料之外触发了更多高管离开。

在原搜索公司架构下，向海龙共有四名副总裁级别“战将”，分别是——负责手百和Feed的沈抖、负责搜索的吴海峰、负责商业产品的郑子斌和负责销售的顾国栋。其中，沈抖是向海龙招到百度，也是很早就选定的“接班人”。综合多位人士评价，和向海龙内向不同，沈抖性格更外放；他情商很高，注重细节，为人温文尔雅、从善如流。

这次轮岗的本意是让沈抖一人统管信息流和搜索，提高内部效率抗击敌人。所以组织调整将吴海峰负责的搜索直接合并给沈抖，沈抖全面接管用户产品（手百+Feed+搜索）；吴海峰转而接手郑子斌的商业产品（凤巢）；而郑子斌调去负责以CRM为基础的创新业务。

在搜索公司，沈抖和吴海峰一直被视为竞争关系。沈抖在2012年加入百度，比吴海峰晚6年，两人原本都是搜索业务总监，中途沈抖转到百度金融，吴海峰继续在搜索，期间二人升至执行总监。之后沈抖调回搜索公司，两个人又都于17年被擢升为副总裁。去年，沈团队推出“百家号”，吴团队推出“熊掌号”，PK中“百家号”取胜。

这次轮岗伤害了吴海峰的利益。“吴海峰不同意轮岗，但公司已经公告了。”上述接近百度人士说。他接到对商业产品的指令是“大力整顿”。不过，消息一出，最先提出辞职的是孙雯玉。孙雯玉是吴海峰新晋提拔的执行总监，执行总监在百度意味着是“见习期副总裁”，她负责核心搜索业务。吴海峰被调岗后，孙雯玉上升通道受阻，最先辞职，而后是吴海峰。再之后，顾国栋因销售业绩不达预期，高层追责而其本人不认同，也递交辞呈。

百度现阶段面临一个有些尴尬的处境——移动生态事业群内，除了沈抖是高级副总裁外，只剩下一位创新业务副总裁。而沈抖过往经历主要集中在用户侧，商业和销售根基不深。据《财经》了解，辞职风波后，商业和销售副总裁处于空窗。同时，沈抖没有直接接手销售。为了权力平稳过渡，马东敏、崔珊珊和沈抖临时成立三人委员会，共同管理。

李彦宏也一直深度参与搜索公司业务。从2017年11月起，李彦宏亲自领兵信息流，他每天早晨8点准时出现在百度科技园5号楼，和沈抖与他的总监们一起开早会。2018年中信息流走上正轨，李彦宏稍稍休息了一段时间。下半年，他又接着和搜索公司开周会，开会时间是周一全天，上午和用户侧开，下午和商业侧开。

而集团层面也发生着一系列变化。《财经》曾在2018年4月发表文章《陆奇举刀，百度第三次重组内阁》，其中详细梳理了2000-2018年百度高层变动名录，将人事变动划分成三轮，如今这个名单又有了更新。

百度在今年推出高层退休计划，两位重量级高管张亚勤（公司总裁，将于7月退休）和刘辉（人力高级副总裁，于5月退休）进入该计划。他们都是Estaff成员。

很早百度就着手拆分张亚勤管辖的新兴业务事业群组（EBG）。去年12月，智能云事业部升级为独立事业群组（ACG）；基础技术体系（TG）划至高级副总裁王海峰旗下；今年3月，百度又把文库、阅读并给搜索公司（现改名移动生态事业群）；5月，教育2B方向分拆并进智能云事业群。

在人力资源上，崔珊珊从刘辉手中接棒，有观点认为组建“人事委员会”目的之一，是李彦宏、马东敏帮崔珊珊交接人力资源。自她回归，百度高管已从招揽光鲜背景的空降职业经理人，转向召回老百度。《财经》获悉，过去一年，以张东晨（原总裁助理）回百度出任业务发展副总裁为标志，引发回归潮；而百度从外引进的高管是原贝恩中国副总裁及全球合伙人陆原和原网易市场部总经理袁佛玉，担任百度战略副总裁和市场副总裁。

为促进内部交流，陆奇曾在百度推行“新风会”，他离职后这一形态得以保留，崔珊珊将其改名“内部沟通会”。

据《财经》独家了解，此次辞职风波后，百度正在寻找各个岗位的继任者。其中，政府关系副总裁将是一位“老百度”；他们还接触了美图COO程昱，希望他接商业化副总裁之位，但谈判似乎不成功。此外，两位接近百度集团的人士透露，百度有可能将启动一轮裁员。“感觉暴风雨要来了。”一位员工说。

辞职、退休、重组，意味着百度正在战争前夜“重置棋盘”。对于这是这家即将弱冠之年的公司来说，一场伟大的战役是挑战，也是机遇。新人们从前人手中接过火炬，肩负着更加艰巨的使命。

战事全面爆发前的夜晚比平时更加黑暗。兵临城下，黑压压一片中，有士兵在两军中间来回游走。敌军开出具诱惑的薪水挖百度能人强将，有人欣然答应，有人毅然镇守，还有人摇摇头远离这场炮火。

这是一场不能言败之战。一位在百度超10年的管理层对《财经》记者说：“如果百度此战失利，中国互联网还是BAT的，只是BAT要重生，这个B会从Baidu换成Bytedance（字节跳动）。”

曾有同事问他，你会不会加入字节跳动？上述人士生气地答复说：“那我就是站在了自己过去10年的对立面。”

申明： 本文系腾讯新闻TOP计划独家首发稿件，未经授权，请勿转载。

百度广告陷入危机，但出问题的不只是百度也不只是广告业

Tue, 21 May 2019 15:52:29 CST

两个交易日下来，百度股价下跌 23.5%，市值蒸发 126 亿美元、已低于京东、美团。名不副实多年的“BAT”彻底成为一个过去式。

一切从上周四晚上百度发布 2005 年上市后首季亏损财报开始。跳崖一般的股价说明，投资者对于百度的溃败措不及防。去年一季度，百度有 66.94 亿元的净利润，李彦宏将此归于百度应用里新开辟的“信息流”广告，但今年这个时候，整个公司已经变成亏损 3.27 亿。

在百度发布亏损财报的前几周，另一个长期被认为夺走百度互联网话语权的腾讯也发了财报。微信依然有着超过 11 亿人的惊人体量，但腾讯的广告业务也开始明显放缓。

而百度一直以来试图模仿的对象，利润依然惊人的 Google 也在 4 月底遭遇了七年来最严重的一次下跌，一度跌掉千亿美元市值，也是因为增长放缓的广告销售。

是什么出了问题？

数字广告从 PC 向手机的转型在全球完成，这是百度最主要的危机

百度的亏损是它在广告收入增长放缓到 3.2% 的同时，营销成本持续高涨。

自 2018 年以来，百度广告收入增速减缓，但是成本却持续上升，其营销和流量获取费用增速自 2018 年第二季度开始就持续上升，从 33% 一路涨到本季度的 71%。

对此百度 CEO 李彦宏在上周的营收电话会议上给了三个理由：

数字广告竞争加剧
特定行业遭遇的广告监管
宏观经济变化

第一条是百度作为曾经的行业领导者所特有的危机。

百度面临的竞争已经被说了很久，我们在 2015 年年底选择百度作为年度被颠覆公司。它的问题在于，绝大部分广告收入来自搜索，而搜索不重要了。

2015 年 7 月接受美国商业媒体 Re/Code 采访时，李彦宏说：“我们意识到很多公司开始做自己的应用——它们不再允许我们索引它们的内容，而且它们在为消费者提供很好的服务。如果移动时代的用户花大量的时间在搜索以外，我们就有问题了。如果用户直接去应用获得服务，他们就不再需要搜索，因为搜索提供的只是信息。”

互联网初期，上网看个新闻、用个服务都需要输入网址。没多少人有记网址的习惯，在搜索引擎的输入框里敲几个字才是最方便的，反正键盘永远在你手边。搜索完之后，屏幕上出现了一些网页链接，但多数时候当中过半都是广告，这些就是百度的收入。

公平地说，相对其它中国竞争对手，百度搜索一直做得不错。2010 年 Google 被迫出走没能成就搜狗、360 们。今天中国搜索市场依然是百度一家公司控制八成以上，其它对手各自守着个位数的份额。在可预见的未来，还没有公司可以在中国的搜索市场颠覆百度。

但随着人们每天打开手机而不是 PC，百度不再决定大多数人看什么、用什么。点一下屏幕就能打开的应用取代搜索引擎和网页，成为每天进入各种互联网服务的入口。

当微信、今日头条、支付宝、抖音、淘宝成为各个领域的入口，用户在地铁上刷朋友圈、看抖音和头条打发时间，而不是搜索看网页，广告自然发生了转移。

今日头条是最常拿出来说的例子，2018 年，今日头条和抖音的广告收入加在一起近 500 亿元，接近百度的一半。

短视频和信息流这是百度也重点培养的新收入来源，但是差距已然拉开：李彦宏在财报分析会议上称百度应用每天有 1.74 亿人打开，好看视频日活跃用户达到 2200 万。作为对比，今年 2 月的发布会上，抖音就已经宣布日活跃用户超过 2.5 亿。而微博每日有超过 2 亿、微信早已超过 10 亿。同样做信息流广告，用户少、使用时间短的服务能卖的广告位就是更少的。

在北京、上海、深圳，大大小小讨论抖音、快手流量操盘的大会小会每周都有好几场，那是新兴的流量聚集地，创业者和经纪公司、服务商相互交流着如何在短视频、信息流快速增长的时代抓住机会。

十年前搜索起步的时候，也有过同样的热闹。

这不只是百度一家公司的问题，Google 在过去一年里也看到了 PC 广告的崩溃。

根据第三方检测机构 Merkle 得到的数据，2018 年 Google 的手机广告依然有 46% 增长，高于去年同期。但 PC 和平板都只有 2%。

图表来自 Merkle

2019 年第一季度，放缓的广告业务营收增速拖累了 Google 整体营收增速，造成三年来最低的营收增幅。Google 广告收入增速变缓，意味着 Google 的流量增速不足以弥补广告价格的下滑。

除了 PC 以外，Google CFO Porat 还在营收会议上指出 YouTube 近期的一些调整导致广告点击量增长放缓。上一季度，Google 广告点击量增长 39%，比去年同期低了 20 个百分点。同时单个点击的价格也大幅减少 19%——YouTube 广告往往单价高于搜索广告。但 Porat 没有给出具体 YouTube 广告数据，Google 财报也不公布具体移动、视频等分类的数据。

在本月中旬的 Google Marketing 大会上，Google 推出了一系列新的移动端广告产品，开始重视起了信息流广告。

在 Google 艰难的这一季，Facebook 的广告收入较上一年同期增长了 26% 至 149 亿美元。其中，移动广告收入较去年同期增长 30% 至 139 亿美元，Instagram 成为其主要广告收入增长来源。

从中我们也能看到，全球广告的趋势都是如此，数字超过传统，而移动又超过桌面。

百度自 2017 年启动信息流项目，让人在里面看新闻。但作为广告载体，百度已经不太适合与头条相比。李彦宏称一季度每天有 1.78 亿人打开百度应用、2200 万人打开手机短视频。作为对比，头条 1.06 亿、抖音 2.5 亿。甚至，每天打开微博的人都有 2 亿人，高过百度。

用户量，以及这些用户每天看到、点开的广告数量决定着平台的广告收入。到了手机时代，百度远不再是中国最重要的广告渠道。

同时监管无处不在，医疗、游戏、金融广告都受影响

多年来，百度广告收入主要来自零售电商、医疗健康、特许经营服务、金融服务等行业。

医疗以及当中的医疗电商是中国目前为数不多的依然蓬勃发展的行业。2018 年天猫医药馆成交总额达到 595 亿元，外加医美、体检、疫苗、口腔等消费医疗品类，增长超过 140%，平安好医生的健康商城 2018 年成交总额增速也近 80%。

百度长期受医院青睐，因为它依然是求医问药的主要渠道。山东开创集团是百度第二大广告代理商，也是代理商里不多的上市公司，它每年披露的大广告客户基本都是民营医院，一家医院就能通过它在百度投放上千万人民币的广告。

李彦宏在财报会议中称，百度在监管以及自身医疗规范的要求下，将医疗类广告的页面放到了百度自己的平台上。他的 CFO 余正鈞在营收会议上说影响将在下个季度变得更严峻。

“我们在一季度末切换了大部分医疗广告商，”余正鈞说“当你换（广告）网页的时候，用户往往需要一些时间适应它们，转换率需要一些时间才能恢复。”

为了避开审核，大多数医药、保健品广告多年都会采用“二跳”形式，也就是在首页瀑布流中出现的首个广告页面内容合规，二次跳转后页面内容则是过去医药广告里常见的“临床医学专家”、“患者现身说法”——能有效劝人购买，但不合规。

去年 3 月和 12 月，今日头条被北京市工商行政管理局海淀分局两次处罚，也都是因为违法医疗广告。

换句话说，百度在遵循更严格的医疗广告要求之后，无法吸引用户点击广告、购买医疗产品和服务。当分析师追问三季度医疗广告能否恢复的时候，余正鈞称无法给出准确预测。

监管问题不只有医疗，影响的也不只是百度。陌陌总裁王力在今年 3 月的财报会议上称，由于游戏版号停发，陌陌的相关业务也受到直接影响。同样的下滑也体现腾讯、网易的财报中，由于无法推出足够多的游戏，两家公司都缩减了游戏的营销费用。

金融服务方面，保监会关门、资管去杠杆、P2P 暴雷，带来的也是一整个行业的广告消失。

整个中国广告市场迎来 11 年来最大降幅，问题已经超出渠道转移和具体行业监管

广告是企业花钱促进业务增长的重要手段。当企业经营状况不好之后，如果无法开源创造新收入，就只能节流缩减成本，裁员、减少广告投放都是常用手段。

这也是目前中国广告市场所面对的问题，不只是电视、印刷等传统广告介质受影响，全部广告介质的增长都在下滑，只有电梯海报广告维持两位数的增长。

CTR 媒介智讯数据显示，2019 年第一季度的广告市场下降 11.2%，这是中国广告市场过去 11 年最大降幅，也是第一次第一季度的跌幅达到两位数。

CTR 的广告主调查研究则显示，只有 33% 的广告主计划在今年增加预算，这一数字是过去 10 年最低水平。计划保持、减少预算的广告主占比都属于 10 年内第二高的水平。

在财报会议上，李彦宏提到了宏观经济的影响，称春节后的广告投放并没有像往年一样反弹。他说“尽管中国政府推出多项经济政策刺激经济，但考虑到目前的宏观环境，政府更严格的内容监管、风投收缩等原因，我们认为短期内广告业务将面临更艰难的环境。”

马化腾持同样的观点，并给出了具体的行业。在腾讯财报会议上，他说：“广告收入受到了宏观经济的影响，特别在汽车、地产和互联网服务领域。互联网公司往往有很大规模，但没有盈利，大量 O2O 公司和很多互联网创业公司都在此时选择了调整支出。”

不管在中国还是美国，投广告的主要行业差得都不太多。

美国的前五行业是零售、汽车、金融、电信和消费品。

央视市场研究（CTR）的数据则显示，2018 年全媒体广告花费 TOP5 的行业分别是邮电通讯、饮料、药品、食品和商业及服务性行业。大部分都在下滑，为数不多还在增长的是饮料、食品和商业服务性行业。今年第一季度，除了食品增长 11.8%之外，另外四个行业的广告投放花销跌幅都超过 20%。

因为主要行业基本都在下滑。

2018 年，中国汽车销售 30 年来首次下滑。全国乘用车市场信息联合会称 2018 年中国汽车销量按年减少 5.8%。2019 年前三个月这一数字扩大到 -10.5%。

这自然也反映到了车企的广告预算上，全国排名前十的大车企，没有一个销售投入增速是在上涨的。

地产公司也是一样，自 2016 年销售额冲到一年 3000 亿、2017 年冲到一年 5000 亿之后，中国三大房企碧桂园、恒大、万科的销售额 2018 年都陷入停滞。

而地产公司在中国都是高负债经营，销售放缓就意味着现金流危机，各家也都在放慢销售开支以节省成本。2018 年，碧桂园和万科的销售费用增速都有所放缓。三家房企中增长最少的恒大，销售费用只增长了 7.68%。

今年第一季度，恒大为加快公司现金回款速度打折卖房，碧桂园被曝大规模人员调整计划，万科董事会主席郁亮在 2 月25 日的一份内部发言稿再次提到 “活下去”。情况看上去只是更差了。

互联网公司在过去几年逐渐成为大广告主，它们也开始削减投入

CTR 第一季度广告市场回顾报告显示，以网站和手机产品为主的所谓“邮电通讯行业”（这是一个别致的行业划分方法）在 2019 年第一季度的全媒体广告花费下滑了 24.3%。

其中一部分是因为游戏公司开始削减成本，直接体现为腾讯在一季度砍掉 42 亿销售费用，超过 20%。

减少 42 亿支出之后，腾讯的利润有所增长，但这对广告业是坏事——腾讯没有实体业务，它砍销售费用基本就是砍广告费。

另外一方面，如马化腾所说，能大量烧钱投广告的创业公司也少了。

移动广告繁荣的那几年，也是一批又一批创业公司烧钱换增长的时候，从 2013、14 年的 O2O 到 2016、17 年的共享单车热，不管这些创业公司能活多久，总要在广告上烧一烧。楼宇电梯的分众电视屏幕，长期播放着拼多多、瑞幸的广告视频。

现在，随着一些行业消失、大批公司倒下、还有一批公司上市公开财务数据，可以继续不计成本将钱烧在广告上的公司也少了。

最近一季度，食品行业在广告投放花费中是唯一上涨的，与此同时电商平台的广告收入仍然保持着高增长。

最后能指望的还是只有消费，以及刺激消费的力量。但消费的潜力究竟有多少呢？

制图 / 冯秀霞龚方毅

题图来自题图来自： ROBIN WORRALL on Unsplash

我们做了一个壁纸应用，给你的手机加点好奇心。去 App 商店搜好奇怪下载吧。

百度财报出现首次亏损，向海龙退场，李彦宏求变

Fri, 17 May 2019 11:16:00 CST

雷锋网消息，5 月 17 日，百度公司 CEO 李彦宏宣布，向海龙即日起辞去百度高级副总裁、搜索公司总裁职务；同时，百度搜索公司战略转型为移动生态事业群组，沈抖晋升为高级副总裁，全面负责移动生态事业群组。

对于百度，这可以说是一个重大的人事变动。

百度财报首次亏损，向海龙匆匆离开

向海龙是一位在百度工作了 14 年的百度老员工。

据了解，向海龙 2000 年毕业于上海华东师范大学计算机系，同年创建上海企浪网络科技有限公司并担任总经理；2005 年 2 月，百度收购上海企浪网络科技有限公司，向海龙正式加入百度。此后，向海龙一路高升，最终担任百度高级副总裁和搜索公司总裁，掌控了百度最核心的现金流业务，甚至被一度认为是百度的二号人物。

向海龙作为百度高级副总裁、百度搜索公司总裁的最后一次公开亮相，就在一周前的 5月10日。当天，他在 2019 百度联盟生态合作伙伴大会上做了主题演讲，他表示，技术变革使得互联网不再是一个个毫不相关的交互行为的叠加，而是关联、联系、关心所有用户的“户”联网，并意气风发地展望了未来——为了真正做好用户运营和服务，百度将构建开源生态，打通信息壁垒，将百度联盟从流量联盟升级为用户联盟。

如今，一切仿佛毫无征兆，向海龙匆匆离开。

与向海龙的离开相伴随的，是百度在凌晨发布的截止 2019 年 3 月 31 日的 2019 财年第一季度的财报。

这份财报显示，百度第一季度总营收为人民币 241 亿元（约合 35.9 亿美元），同比增长 15%。若不计入此前宣布的资产剥离交易的影响，则百度第一季度营收同比增长 21%。百度第一季度净亏损为人民币 3.27 亿元（约合 4900 万美元），相比之下去年同期的净利润为人民币 67 亿元。百度第一季度每股美国存托凭证摊薄亏损为人民币 1 元（约合 0.15 美元）。

按照彭博社的说法，这是百度 2005 年上市以来录得的首个季度亏损。

由于一季报盈利和营收、二季度营收指引均不如市场预期，罕见录得运营亏损和净亏损；于此同时，搜索业务总裁向海龙已递交辞呈，百度虽宣布了 10 亿美元的股票回购计划，股价盘后仍大跌近10%。

显然，在这种情况下，百度的日子并不好过。李彦宏在内部信中表示，产业价值链不断受到冲击，新旧动能面临转换，外部环境的不确定、竞争的加剧，导致整个科技行业都进入震荡期，百度公司也不例外。同时，李彦宏也承认，百度依然面临着严峻的局面，必须保持战略定力，提高精细化运营能力和创新力，热爱用户，尊重用户。

沈抖高升，百度继续求变

面对的这样的困境，百度也在积极求变。

李彦宏表示，百度将更加坚定地投入组织能力建设，坚定地推动干部年轻化进程，让优秀的人才脱颖而出——某种程度上，这也是沈抖晋升为高级副总裁的原因，也是有着 14 年百度经历的老人向海龙离开的原因。

雷锋网了解到，沈抖于 2012 年加入百度，在 2012 年到 2016 年期间，曾担任百度公司联盟研发部总监、网页搜索部高级总监、金融服务事业群组 (FSG) 执行总监。沈抖于 2017 年晋升为百度公司副总裁，全面负责百度 APP、信息流、好看视频、百家号、百度新闻、百度浏览器、 hao123 等移动相关业务，2019 年他开始全面负责搜索公司用户产品，带领团队充分发挥“搜索和信息流”双引擎的优势，打造“一超多强”的移动产品矩阵，建设健康、繁荣的百度内容生态。

值得一提的是，2 月 26 日，百度曾发布内部邮件，宣布对三位副总裁沈抖、吴海锋、郑子斌进行干部轮岗调整，三位副总裁继续向搜索公司总裁向海龙汇报。当时有媒体解读称向海龙已经成为百度二号人物；如今来看，这倒可能与沈抖的晋升存在前后铺垫关系。

而如今，伴随着沈抖的新角色，百度搜索公司已经战略转型为移动生态事业群组。李彦宏在公开信中表示，在移动业务上，百度表示会继续强化、放大百度已经形成的一超多强的产品矩阵优势，在搜索、信息流双引擎驱动的基础上进一步升级为生态思维，通过社区化运营、垂类内容深耕、新交互形式提升用户时长和黏性。

另外，李彦宏也强调了 AI 业务，表示百度要深入理解各行业的发展模式，精耕细作，抓住产业智能化的机遇，进一步拓宽自身的业务领域和商业模式，加快业务发展。

另外，李彦宏在公开信的一些措辞，似乎也指向一些具体的问题。

比如说，李彦宏表示，作为领军人物，说“我们尽力了”没有用，要确保在必须赢的战场上取得胜利;每一位员工，在工作中要倾尽全力，确保每一件事情执行到位；同时“不能等、不能靠、不能怕，要敢于说真话、敢于试错、敢于创新”，“不是给失败寻找借口”。

可见，李彦宏对百度的问题也是颇有所感知的。

雷锋网总结

从人事来说，百度这两年可以说是变动频繁。先是打算“带领百度驶向人工智能大航海时代”的陆奇在 2018 年 5 月离开，接着张亚勤也已经宣布了退休的消息。而老将向海龙的离开，则意味着百度另一次具备节点意义的人事震荡；尤其是他的离开正值在百度亏损之时，不免让人浮想联翩。

对于向海龙的离开，李彦宏在公开信中表示，感谢向海龙过去 14 年的陪伴和贡献，并祝他未来一切顺利。不过，也有媒体报道称，向海龙是被辞退了。对此，向海龙则也通过媒体渠道进行了回应，称自己是正常离职，未来将会创业。

那么问题来了：与向海龙就此挥手而别、分道扬镳之后，百度的前路将会如何？

以下是李彦宏的公开信内容：

中国首个！百度云宣布边缘计算开源，发布智能边缘开源版本平台OpenEdge

Mon, 10 Dec 2018 16:40:57 CST

刚刚12月6日，百度云在2018ABC InspireSUMMIT企业智能大会上宣布，正式发布百度智能边缘（Baidu IntelliEdge，BIE）开源版本OpenneEdge，在中国第一个宣布边缘计算开源。

12月6日，百度副总裁、百度云总经理尹世明现场发布中国首个开源边缘计算平台

这是百度云继今年5月31日国内第一个发布国内首款智能边缘产品BIE后，在边缘计算领域的又一次重大发布又第一个宣布开源。

百度云希望通过开源，将BIE的核心功能全面开放，同时并推出国内首个开源边缘计算平台—OpenEdge，旨在打造一个轻量、安全、可靠、可扩展性强的边缘计算社区。

借助开源的OpenEdge，开发人员可以更灵活地开发控制自己的边缘解决方案和应用。百度云期待利用社区的力量为国内边缘计算技术营造良好生态，促进边缘计算在中国快速发展，加速更多行业人工智能应用落地。

边缘计算正在成为人工智能的下一个热点

据Gartner报告中所述，边缘位列2019年十大技术趋势中。作为一种计算拓扑，边缘计算将信息处理、内容收集和传递的场所更靠近需求端。试图保持流量和处理更接近‘本地化’，从而减少流量损耗和延迟。

Gartner认为，未来五年，专业的人工智能芯片以及更强大的处理能力、存储及其他高级功能将被添加至更广泛的边缘设备。同时伴随5G的成熟，其提供更低的延迟、更高的带宽，将使得每平方公里节点（边缘端点）的数量急剧增加。此外，边缘计算也将在实现数字业务和IT解决方案等层面应用广泛。

百度云依托ABC能力，持续保持技术领先

智能边缘BIE是百度云发布的国内首个边缘计算产品，发布伊始即推行“端云一体”解决方案，它由智能边缘本地运行包、智能边缘云端管理套件组成；在云端进行智能边缘核心设备的建立、身份制定、策略规则制定、函数编写、AI建模，然后生成配置文件和执行文件通过端云协同的方式下发至本地运行包，在近设备端的本地运行包里完成数据采集、消息分发、函数计算和AI推断等功能，通过一键发布和无感部署的方式，极大提高智能迭代的速度，使之整体达到“训练、管理、配置在云端，采集、转发、计算、推断在本地”的效果。

在架构设计上，智能边缘推行容器化，基于智能边缘BIE提供的DockerFile文件可以在Docker支持的各类操作系统上进行“一键式部署”，依托Docker的跨平台支持特性，确保智能边缘在各系统、各平台的环境一致性标准化；此外，智能边缘BIE还针对Docker容器化进行容器资源隔离与限制，精确分配各运行实例的CPU、内存等资源，提升资源利用效率。

在降低各功能间耦合度方面，智能边缘推行模块化，每一项功能都是一个独立的模块，各项子功能模块运行互不依赖、互不影响，推行模块化的设计模式，可以充分满足用户“按需使用、按需部署”的切实要求。

智能边缘BIE旨在依托容器化、模块化的设计模式，通过降低各模块间的耦合度及强制性的证书认证模式，打造一个轻量、安全、可靠、可扩展性强的边缘计算环境，为国内边缘计算技术的发展营造一个良好的生态环境。

作为百度云天工的重点输出产品，智能边缘BIE可以与天工各云端平台服务无缝对接，如IoT Hub、TSDB、IoT Visualization、IoT EasyInsight等；换句话说，部署了智能边缘BIE的设备和边缘计算节点，既可以与百度云天工进行无缝数据交换，对敏感数据进行过滤计算，也可以在无网或者网络不稳定的情况下，缓存数据、独立计算，实现实时的反馈控制。

目前，智能边缘BIE已经能够支持基于PaddlePaddle、TensorFlow、Intel Openvino等主流AI框架训练的算法模型，并与百度云推出的云端函数计算服务（CFC）、云端大数据服务（Jarvis）、云端视觉模型工厂服务完全兼容，能够独立运行在10多种主流系统和硬件架构上，让每一台联网的终端设备都“轻装上阵”，实时进行计算。

从边缘视频接分析到边缘机器视觉

无论是人脸识别、工业质检还是城市管理、公共安全，在云端完成训练的机器视觉模型已经应用到各行各业。智能边缘BIE提供将这些视觉模型轻松的部署到本地设备上的能力，一方面提供快速的识别响应，另一方面降低视频/图片的传输带宽成本。

从边缘物联网数据分析到边缘数字孪生

面对复杂的数据采集环境、多样的数据通讯协议、海量的原始数据以及不同的数据流向需求，智能边缘BIE可以通过功能模块组合，轻松的搭建集数据采集、协议解析、数据分析、数据转发为一体的边缘计算应用，满足工业生产、城市监控的大多数物联网场景的通用需求；同时，数据分析可以通过AI、大数据等手段进一步升级为数字孪生模型，智能边缘BIE提供将数字孪生模型轻松的部署到本地设备上的能力，面向每一台独立的设备以及它所处的独特环境，提供针对性的数字孪生服务。

目前，一些科技公司已经将边缘计算应用在实际生活中。比如在精准农业病虫害防治，矿井探放水行为分析，渣土车抛洒污染识别，新能源充电质量监测等场景下，基于百度云边缘计算能力，更加有效地保障了作业安全，降低了成本，更精细更智能的解决了实际应用问题。

边缘计算开源是人工智能加速走向应用的重要一步。随着ABC、IoT技术的快速发展，数据增长越来越快，计算需求越来越多。面临多样的硬件形态和应用场景，BIE提供了从云端生产环境、管理环境到本地运行环境的全套工具，将百度云 ABC 的能力从云上拓展到边缘，进而拓展至各行各业。

百度云期待通过开源方式，携手更多的ABC合作伙伴，促进行业智能化变革。

毫秒级从百亿大表任意维度筛选数据是怎么做到的？

Wed, 28 Nov 2018 00:00:00 CST

业务背景

随着闲鱼业务的发展，用户规模达到数亿级，用户维度的数据指标，达到上百个之多。如何从亿级别的数据中，快速筛选出符合期望的用户人群，进行精细化人群运营，是技术需要解决的问题。业界的很多方案往往需要分钟级甚至小时级才能生成查询结果。本文提供了一种解决大数据场景下的高效数据筛选、统计和分析方法，从亿级别数据中，任意组合查询条件，筛选需要的数据，做到毫秒级返回。

技术选型分析

从技术角度分析，我们这个业务场景有如下特点：

需要支持任意维度的组合(and/or)嵌套查询，且要求低延迟；
数据规模大，至少亿级别，且需要支持不断扩展；
单条数据指标维度多，至少上百，且需要支持不断增加；综合分析，这是一个典型的OLAP场景。

OLTP与OLAP

下面简单对比下OLTP和OLAP：

数据量瓶颈：mysql比较适合的数据量级是百万级，再多的话，查询和写入性能会明显下降。因此，一般会采用分库分表的方式，把数据规模控制在百万级。
查询效率瓶颈：mysql对于常用的条件查询，需要单独建立索引或组合索引。非索引字段的查询需要扫描全表，性能下降明显。

综上分析，我们的应用场景，并不适合采用行存储数据库，因此我们重点考虑列存数据库。

行式存储与列式存储

下面简单对比一下行式存储与列式存储的特点：

HybridDB for MySQL计算规格介绍

HybridDB for MySQL计算规格对我们的这个场景而言，核心能力主要有：

任意维度智能组合索引(使用方无需单独自建索引)
百亿大表查询毫秒级响应
MySql BI生态兼容，完备SQL支持
空间检索、全文检索、复杂数据类型(多值列、JSON)支持

那么，HybridDB for MySQL计算规格是如何做到大数据场景下的任意维度组合查询的毫秒级响应的呢？

首先是HybridDB的高性能列式存储引擎，内置于存储的谓词计算能力，可以利用各种统计信息快速跳过数据块实现快速筛选；
第二是HybridDB的智能索引技术，在大宽表上一键自动全索引并根据列索引智能组合出各种谓词条件进行过滤；
第三是高性能MPP+DAG的融合计算引擎，兼顾高并发和高吞吐两种模式实现了基于pipeline的高性能向量计算，并且计算引擎和存储紧密配合，让计算更快；
第四是HybridDB支持各种数据建模技术例如星型模型、雪花模型、聚集排序等，业务适度数据建模可以实现更好的性能指标。

综合来说，HybridDB for MySQL计算规格是以SQL为中心的多功能在线实时仓库系统，很适合我们的业务场景，因此我们在此之上构建了我们的人群圈选底层引擎。

业务落地

在搭建了人群圈选引擎之后，我们重点改造了我们的消息推送系统，作为人群精细化运营的一个重要落地点。

闲鱼消息推送简介

消息推送(PUSH)是信息触达用户最快捷的手段。闲鱼比较常用的PUSH方式，是先离线计算好PUSH人群、准备好对应PUSH文案，然后在第二天指定的时间推送。一般都是周期性的PUSH任务。但是临时性的、需要立刻发送、紧急的PUSH任务，就需要BI同学介入，每个PUSH任务平均约需要占用BI同学半天的开发时间，且操作上也比较麻烦。本次我们把人群圈选系统与原有的PUSH系统打通，极大地改善了此类PUSH的准备数据以及发送的效率，解放了开发资源。

系统架构

离线数据层：用户维度数据，分散在各个业务系统的离线表中。我们通过离线T+1定时任务，把数据汇总导入到实时计算层的用户大宽表中。

实时计算层：根据人群的筛选条件，从用户大宽表中，查询符合的用户数量和用户ID列表，为应用系统提供服务。

人群圈选前台系统：提供可视化的操作界面。运营同学选择筛选条件，保存为人群，用于分析或者发送PUSH。每一个人群，对应一个SQL存储。类似于： select count(*) from userbigtable where column1> 1 and column2 in ('a','b') and ( column31=1 or column32=2) 同时，SQL可以支持任意字段的多层and/or嵌套组合。用SQL保存人群的方式，当用户表中的数据变更时，可以随时执行SQL，获取最新的人群用户，来更新人群。

闲鱼PUSH系统：从人群圈选前台系统中获取人群对应的where条件，再从实时计算层，分页获取用户列表，给用户发送PUSH。在实现过程中，我们重点解决了分页查询的性能问题。

分页查询性能优化方案：在分页时，当人群的规模很大(千万级别)时，页码越往后，查询的性能会有明显下降。因此，我们采用把人群数据增加行号、导出到MySql的方式，来提升性能。表结构如下：

批次号：人群每导出一次，就新加一个批次号，批次号为时间戳，递增。
行号：从1开始递增，每一个批次号对应的行号都是从1到N。

我们为"人群ID"+"批次号"+"行号"建组合索引，分页查询时，用索引查询的方式替换分页的方式，从而保证大页码时的查询效率。

另外，为此额外付出的导出数据的开销，得益于HybridDB强大的数据导出能力，数据量在万级别至百万级别，耗时在秒级至几十秒级别。综合权衡之后，采用了本方案。

PUSH系统改造收益

人群圈选系统为闲鱼精细化用户运营提供了强有力的底层能力支撑。同时，圈选人群，也可以应用到其他的业务场景，比如首页焦点图定投等需要分层用户运营的场景，为闲鱼业务提供了很大的优化空间。

本文实现了海量多维度数据中组合查询的秒级返回结果，是一种OLAP场景下的通用技术实现方案。同时介绍了用该技术方案改造原有业务系统的一个应用案例，取得了很好的业务结果，可供类似需求或场景的参考。

后续计划

人群圈选引擎中的用户数据，我们目前是T+1导入的。这是考虑到人群相关的指标，变化频率不是很快，且很多指标(比如用户标签)都是离线T+1计算的，因此T+1的数据更新频度是可以接受的。后续我们又基于HybridDB构建了更为强大的商品圈选引擎。闲鱼商品数据相比用户数据，变化更快。一方面用户随时会更新自己的商品，另一方面，由于闲鱼商品单库存(售出即下架)的特性，以及其他原因，商品状态会随时变更。因此我们的选品引擎，应该尽快感知到这些数据的变化，并在投放层面做出实时调整。我们基于HybridDB(存储)和实时计算引擎，构建了更为强大的“马赫”实时选品系统。已推出“ 马赫”的系列文章，有兴趣的同学可以关注。另外如果对本文中的具体技术实现(细节)有任何问题，请联系我们。谢谢。

参考资料： HybridDB for MySQL介绍： https://www.aliyun.com/product/petadata

▼往期精彩回顾▼ Qcon2018·Flutter&Dart三端一体化开发

GDD2018·TensorFlow应用“UI 2 Code"

千人千面线上问题回放技术揭秘

2018双11·尖货优品实时选——“马赫”

关注二维码，前瞻技术尽在掌握

都在谈城市治理，后起的百度能成为那个率先破局者吗？

Tue, 20 Nov 2018 17:27:00 CST

随着城市化规模的进一步上升，摆在市长们眼前的城市治理摊子也越来越棘手。一方面，公共资源的增加速度远远无法解决人口增长带来的复杂问题，另一方面，普通老百姓也在日复一日的拥堵、有些不太齐整的市容市貌、偶尔捉襟见肘的能源供应（例如：高温停电）这些身边的问题面前颇有怨言。

这时候，解决问题的智能化方案成为科技公司，尤其是云服务平台热衷进入的领域，或也成为市长们缓解焦虑的有效路径。

诸如百度、腾讯、阿里以及亚马逊、微软、谷歌等企业纷纷入局，众多巨头们看准了市长们每年在城市治理的智能化上的巨额投入，在ABC（人工智能、大数据、云计算）等方面各出“新招”。而谁能解决市长的焦虑，谁或能首先实现市场突破。

对城市治理的“智能化”理解，过去也许跑偏了

新技术应用到传统领域，其在应用过程中也不免存在着对概念的误读以及对应用的曲解。

1 政府不能唱“独角戏”

许多人认为城市治理的智能化应该由政府全权负责。然而事实并非如此，拿共享单车来说，之前政府做的公共自行车无一例外都没有成功，而企业方同样是做共享单车，用的却是极其市场化的方式，把站点建设和用户对服务到家需求兼顾，从而跑出了新天地。

所以，新技术应用到建设也需要充分发挥市场的主动权。技术的应用本身也不仅仅是要求政府管理水平需要大幅提高，更加重要的是让市民懂得如何通过市场化手段满足自身需求，企业清楚如何在适当的时机采取各种方法达成目标。

也就是说，技术应用落地从来都不是政府一个人的游戏，其建设是一条市场主导、政府引导的路子，要求的是政府和企业一起通过市场化服务、社会化服务来推动公共服务，最终实现社会效益和市场收益最优。

2 技术全面落地不只是“拼图游戏”

最终，智能化的城市应该长什么样子？这个问题不亚于回答“什么是好人？”

随着城市综合治理理念的不断成熟，人们开始意识到目前个别企业标榜的“智慧应用”仅仅只是耍小聪明式的玩法，与真正的全局智能化还相差甚远，尽管量级（即拥有多项“智慧应用”）上已经接近，但依然是支离破碎的。

如今城市治理智能化建设需要面临最大的难题，就是需要跨界整合不同的技术和应用，并形成统一的系统，从而在生活的各个方面实现落地。

许多企业都力图把自己说成是所谓“智慧城市”的代表，而它们只是在做“碎片化”的智慧。对于入局的玩家来说，智能化城市治理需要充分利用每个业务线的“优势拼图”，才能真正拼出不一样的“智慧城市”，从全局动态运营层面让市长放心，而不是头痛医头脚痛医脚，新问题层出不穷。

解决安防、环保、交通三大难，或是缓解市长焦虑的开始

随着“互联网+”和城镇化浪潮的风起云涌，智能化被寄望了广阔前景和无限潜力。其中，最让市长们头痛的安防、环保、交通三个城市建设难题，也一度被当做核心发展领域。而这三个部分在城建财政支出上一般都占有很大比例，从现实角度讲，谁能缓解市长焦虑，谁可能就算有了技术落地+商业化成功的开始。

不过，城市治理智能化构建并不能一蹴而就，它至少需要分为“三步走”。

第一步：应用AI数据感知，从终端层面获取数据并转化成有价值数据。感知数据是智能化的奠基工作，比如，百度云为各领域数据提供了丰富的感知方式。包括，百度云与银川交通合作，应用路网硬件数据采集及交通工具数据采集；其又与首都机场签署战略合作协议，实现机场闸机人脸识别收集用户信息以及与苏州公安合作，实现安防快速取证；与宁波智慧城管项目合作，利用“百度大脑”的数据感知、收集、加工以及人工智能分析基础平台，构建最完整的AI技术开放生态，为宁波创造了一个完整的“智慧城管”全过程。

第二步：大数据分析。从终端AI数据感知，到通过对有价值数据综合分析得出有价值决策信息，每一步都是智能化构建的重要组成部分。比如在智能楼宇领域，百度云自曝AI黑科技，通过百度在能源管理、物联网、人脸识别等方面能力，可实现系统节能20%以上，可为企业年节省电费100万元。同时，百度云与首都机场、美兰机场合作，综合运营数据，共通推进智慧机场建设。阿里则通过蚂蚁金服宣布上线“城市服务”，通过支付宝这个强粘性的产品，充分了解并分析用户需求，并为参与到智能化城市治理建设中来的机构开放更多的移动与数据能力。

第三步：落地多元化的行业服务。智能化落地场景除了城市/机构公共服务，并利用AI数据感知和大数据分析最终的行业应用落地。比如腾讯与西安市政府合作，将其第一款产品“腾讯觅影”落地西安智慧医疗领域，并发布的智慧医院3.0解决方案，提升了患者的就医体验。百度云则在各领域多点开花，其先后与山西市政府、美兰机场、宁波市政府等多方面合作，打造了一个涉及银行、保险行业、车联网、智能家居、钢铁、煤炭等多个领域的应用链条，保障了百度在智能化城市治理构建中各环节的完整性，更进一步推出天工平台，聚焦工业物联网，对多个领域进行产能升级和应用赋能。

当然这三步并没有绝对的先后顺序，具体还需要看每个企业自己的优势和执行进度。回过头来看，百度云之所以能够以后起姿态获得一定的案例领先优势，也正是因为通过三步走，在着重解决市长的焦虑：

安防方面：宁波智慧城管项目解决城市治理无法实时监控的难题，通过终端图像数据收集、云端分析处理更好地治理市容市貌、预控隐形风险；苏州人脸识别卡口系统大大提升安防数据的来源和准确性，为预防犯罪、提升城市治安水平和市民安全感提供了保障。

环保方面：在工用、民用能源日益紧张的今天，节约而又不伤及正常使用成了重要课题，百度的智能楼宇不仅仅是个体节约电费支出的问题，更重要的是能够帮助市长们避免面对处处告急的能源负荷境况，只不过这种方案可能还需要从百度单一项目向所有楼宇推广。

交通方面：经济的快速发展导致城市日益拥堵，与百度云合作的银川市在2018年Q1出其不意成为了全中国最堵的城市，百度云推出的静态智慧交通系统刚好卡在了交通形势最为严峻的点上，通过上文所说的多端数据采集来试图缓解处处停车场的交通状况，智能化城市治理案例布局到了关键点上。

点对点落地，最终都要解决这两个问题

想要更好落地智能化应用，尤其是像百度云这样从全局安排但是又点对点破局安防、环保、交通智能化问题的平台，面临两个亟需解决的问题。

1 解决信息孤岛问题

如今世面上，城市治理智能化的项目越来越多，但在推进过程中，面临包括“千城一面”、“重建设、轻应用”、标准规范缺失等问题，尤其是政府数据资源的不够开放和共享，“信息孤岛”等现象，已经逐步成为制约各地新型城市治理的突出问题。

智能相对论认为，正如中国科学院院士、北京理工大学副校长梅宏所说，未来智能化的城市，应是一个软件定义的城市，在万物互联的基础之上，所有的信息基础设施、各种传感器、数据资源、能源、交通及其构成的网络和新型应用等，都需要基于数字化、虚拟化来构建。因此打破信息孤岛，实现数据的开放共享极为重要。

但这其中，还需清楚的是，“信息孤岛”只是目前第一阶段需要克服的难题，在打破信息闭塞实现开放共享之后，下一阶段就是运用数据做决策，而不论交通、养老、教育、安全、出行哪个方面，信息永远都是第一位的。

目前看，几个玩得溜的大企业在信息整合方面已有了自己的方案，比如百度云将自身信息整合归纳为两个方面。一方面为“小整合”，如百度云银川静态交通管理系统，路网端与交通工具端数据整合，以单个项目、单类信息进行整合、处理；另一方面为“大整合”，如百度云阳泉市城市大脑综合方案，政务、产业全整合，这则是针对整个行业和城市的宏观信息处理。不过具体执行效果如何，还需等待时间验证。

2 将智慧生态系统作为行业“破局之道”

城市治理，本来就是一个智能且能够自我成长的生态系统。只有形成一个元素间相互影响相互促进的生态体系，城市治理才能拥有很强的良性循环能力。

在构建“生态系统”方面，国内各企业也不断盘算着自己的“一出好戏”。比如，华为提出了解决方案的整体架构，即“一云二网三平台”，并发布以“智慧城市”定义的生态圈行动计划，构建一个具有领先性、成熟型、安全性的生态圈。

除了华为、腾讯等企业外，百度云也动作频频。比如百度云与苏州市公安局合作，打造“AI+安防”模式，通过百度云自研深度学习的生物特征提取技术、视频图像技术、大数据检索以及处理等核心技术实现了快速在视频中查找目标人物并协助处理案件。百度云ABC已经赋能智能化城市治理进入3.0时代，融合了信息采集、大数据应用及人工智能能力，通过物联网技术将其和现实世界进行交互。

目前来看，国内巨头们也开始意识到完整的“生态系统”对于智能化城市治理的重要性，随着人工智能技术及城市认知的不断深化，更加完备的生态系统也将开始逐渐浮出水面。

技术推动城市治理变革，还是一场“无限运动”

当下，许多城市在城市治理方面的智能化只是尝试之举，与许多有明确结果和目标的建设相比，正处于不断摸索和“进化”之中。从技术演进的本身而言，技术革新必然会是一场“无限运动”。

虽然许多技术应用有突破性的进展，但是，城市治理只有更优没有最优，在这场技术革新的“无限运动”中，真正的优胜者还需要时间和市场来检验。

未来，城市管理当中人类参与管理与决策将越来越少，最终达到城市自主智能化管理的效果，从而实现高效、安全、节能、可持续发展的城市发展目标。

同样，城市治理的智能化始终要有开放的心态，能够形成开放运转而不是封闭自己玩的体系。例如，百度云之所以能够成为后起的“破局者”，其布局智能化城市治理的顶层构架，正是构建了一个具有统一核心又能够自由组装的模块化玩法。这种玩法，或具备了无限延展的能力，符合“无限运动”的特征。

这也给了这个赛道更多发展不确定性，没有谁能够最终一手遮天，技术与治理总会不断演化而有新的需求。解决市长焦虑后，鹿死谁手尚未可知。

百度开源 FAQ 问答系统—AnyQ

Fri, 24 Aug 2018 15:34:46 CST

前言

近年来，随着人工智能技术的发展，人机对话技术得到越来越多的关注，人机对话产品也不断涌现。其中，智能客服作为人机对话的一个典型场景表现出极大的商业潜力和很强的研究价值，各企业也争先恐后的推出自己的智能客服产品。

FAQ 问答技术作为智能客服系统最核心技术之一，在智能客服系统中发挥重要作用。通过该技术，可实现在知识库中快速找到与用户问题相匹配的问答，为用户提供满意的答案，从而极大提升客服人员效率，改善客服人员服务化水平，降低企业客服成本。

百度在今年 7 月的 AI 开发者大会上开源了首个工业级基于语义计算的 FAQ 问答系统——AnyQ，旨在赋能开发者，为人工智能技术及应用蓬勃发展贡献力量。

FAQ 问答技术难题与现状

FAQ 问答主要有以下技术难题：

用户问题较为口语化，包含大量省略、指代等现象；
用户问题复杂多样，基于字面信息很难精准匹配语义相同问题；
实际产品应用中，对系统鲁棒性、整体性能要求较高；

学术界研究的 FAQ 问答技术主要集中在问题匹配单点技术上，对整体 FAQ 问答系统研究较少。而工业界使用的 FAQ 系统对外则极少披露细节。

AnyQ 系统框架

开源 AnyQ(Answer Your Questions) (https://github.com/baidu/AnyQ) 系统采用配置化、插件化框架设计，搭载由百度自主研发、业界领先的 SimNet 语义匹配技术，针对 FAQ 问答的种种技术难题给出了高效的解决方案。

AnyQ 系统主要由 Question Analysis、Retrieval、Matching、Re-ranking 等核心部件构成。系统框架如图示：

AnyQ 系统特色

特色 1——框架设计灵活，插件功能丰富

AnyQ 系统的配置化和插件化设计，使得开发者可以自主配置选择系统的功能，当前支持 20 多个插件。同时，开发者也可根据需要便捷地将定制化的功能以插件的方式加入系统。

• 配置化

AnyQ 系统集成了检索和匹配的丰富插件，通过配置的方式生效；以相似度计算为例，包括字面匹配相似度 Cosine、Jaccard、BM25 等，同时包含了语义匹配相似度。

• 插件化

AnyQ 的所有功能都是通过插件形式加入，用户自定义插件，只需实现对应的接口即可，如 Question 分析方法、检索方式、匹配相似度、排序方式等。

特色 2——极速语义检索

传统倒排索引只考虑了输入问题和索引问题间的字面重合度，这种技术在智能客服场景中存在很大问题，FAQ 集合通常是专业人员整理，其问题形式比较书面和正式，而用户问题更加口语化，两者之间即使语义一致，但表述上差别迥异。与基于倒排索引的 FAQ 问答系统相比，AnyQ 在检索方面采用了业界前沿的语义检索技术。

语义检索技术将用户问题和 FAQ 集合的相似问题通过深度神经网络映射到语义表示空间的临近位置，检索时，通过高速向量索引技术对相似问题进行检索。语义检索原理如下图：

特色 3——业界领先语义匹配技术 SimNet

问题相似度计算是 FAQ 问答系统的核心，其算法效果好坏决定了整个系统的效果。

AnyQ 使用 SimNet 语义匹配模型构建文本语义相似度，克服了传统基于字面匹配方法的局限。

SimNet 是百度 NLP 于 2013 年自主研发的语义匹配框架，在百度搜索、百度信息流、百度地图等产品广泛应用，主要包括 BOW、CNN、RNN、MM-DNN 等神经网络模型。此外，我们基于 SimNet 框架集成了学术界主流模型：Match-Pyramid、MV-LSTM、K-NRM 等。SimNet 支持 PaddlePaddle 和 Tensorflow 两种平台训练。基于 SimNet 语义匹配框架，开发者可以快速训练已有的语义匹配网络模型。

使用 SimNet 训练出的模型可以便捷的加入 AnyQ 系统中，增强 AnyQ 系统的语义检索和语义匹配能力。

本次开源包含一个基于百度海量搜索数据训练的 SimNet-BOW 模型，在一些真实的 FAQ 问答数据集上，该模型效果相比基于字面的相似度方法 AUC 提升 5% 以上，有效解决特定领域由于标注数据少无法训练出准确语义匹配模型的问题。

总结

AnyQ 系统配置化、插件化的框架设计有助于开发者快速构建、快速定制适用于特定业务场景的 FAQ 系统。AnyQ 包含了百度积累多年的 SimNet 语义匹配框架，开发者可根据自身产品需求训练自己的语义模型，提升产品效果。此外，针对无任何训练数据的开发者，AnyQ 还包含了基于百度海量数据训练的语义匹配模型，开发者可零成本直接使用。

信息流广告三国杀百度上位腾讯平稳头条下挫

Tue, 21 Aug 2018 21:12:26 CST

　　在各互联网巨头的商业版图中，广告收入始终是一个重要阵地。随着今日头条的加入，信息流广告在这片阵地上迅速崛起。数据显示，信息流广告的市场占有率在2012年只有1%，到2017年已经达到14.3%，是互联网广告各门类中增长最快的板块。

　　今日头条虽然是信息流广告的先行者，但随着各大平台的先后入局，信息流广告市场的争夺日渐焦灼，尤其是百度、腾讯的加入，为信息流战场输送了当量更高的重型武器，让竞争更加激烈。

　　在这片战场上，三家尚在排兵布阵，但各家比拼的不仅是拿到战场上的装备，还有持续供给的能力：对于头条来说，信息流是广告展示平台，也几乎是其唯一的数据来源;对于百度和腾讯来说，其背后有着庞大而丰富的数据矩阵，可谓厚积而薄发。

　　 三家角力信息流市场

　　今年06月，信息流广告的使用率达到38.8%，首次超过长横幅大尺寸广告，成为所有网络广告形式中，广告主使用最多的一种。

　　根据艾瑞咨询的判断，信息流广告仍处于快速发展阶段，未来两年内仍将保持50%以上速率增长。

　　信息流可以帮助平台主动触及客户，随着对客户识别能力的增强，其呈现出来的广告价值也会越来越大，已经成为互联网巨头们的兵家必争之地。

　　和今日头条不同，各巨头们入局信息流都各自带有鲜明的特征：阿里的电商属性，百度有搜索优势，腾讯有社交数据。

　　尽管作为先行者的头条仍占据领先地位，但百度、腾讯凭借雄厚的数据能力和领先的AI技术，厚积薄发，已经与头条共同站在第一梯队，形成了“三国杀”的竞争局面。

　　2016年百度开启信息流业务，到2017年底，信息流业务每日分发量环比增加20%以上，百度App用户总使用时长同比增长约30%。

　　百度刚刚披露的二季度财报显示，搜索之外，也就是“AI+信息流”的收入已经接近百度总收入的20%，同比增长超过150%。

　　后来者增长迅猛，头条的领先优势不断缩窄，竞争手段只能愈发向下。据财新网报道，为了拓展一个日均消费不足千元的个体开锁商户，今日头条的销售曾威胁将用恶意点击的方式清空商户的其他账户余额。

　　对于头条而言，信息流几乎是其全部，是不得不守住的阵地。对于百度和腾讯而言，信息流的作用也绝不仅仅是锦上添花：获得信息流优势，是百度和腾讯发挥整合营销和精准营销的前提，是重要的战役。

　　 BT夹击头条显颓势

　　在这片战场上，平台之间在三个层面进行比拼：用户的规模和粘性，变现路径以及整合营销能力。

　　其中，用户的规模和粘性是互联网广告变现的基础。从这个角度看，腾讯拥有月活过10亿的超级APP，用户的规模最大，百度系居中，而头条系核心产品月独立用户数低于2.5亿，排在最末。

　　不仅如此，头条系产品的日活数据增速从今年1月份开始一路下滑，已经显露出增长的疲态。

　　其次，变现路径决定着变现效率的高低。简单来说，广告促使客户达成交易的路径越短，变现的效率就越高。

　　在信息流领域里，变现路径体现在精准和用户时长两个方面。广告越是可以精准地满足用户当下的需求，变现效率就越高。举例来说，某汽车品牌需要针对新款车型进行信息流投放，如果广告可以精准地找到有购车意图，并且TA对车辆的需求与推送的广告内容高度重合，那么变现效率就会很高。

　　在这方面，头条的精准依赖于其打造的“兴趣营销”模式，所谓“你关心的就是头条”，百度和腾讯分别坐拥搜索、社交两大数据源，主打“意图营销”和“社交营销”。

　　相比之下，头条系产品的依据只有兴趣，但用户感兴趣的，未必就是TA会购买的，腾讯的社交网络对用户的理解相对深入，但朋友喜欢的未必是我喜欢的，而百度依靠搜索平台，通过对用户的主动搜索数据进行分析，可以洞察到用户的“意图”，这是其他两家所不具备的优势。

　　最后，整合营销能力的比拼是信息流广告的加分项，用户个性化数据的丰富度是整合营销的基础。从这个角度来看，腾讯和百度分别从不同维度拥有庞大的用户数据，都具备明显的后发优势，头条的领先地位岌岌可危。

　　信息流市场的比拼已近半场，三家尚未分出伯仲，而下半场的竞争更需要深厚的内功和精细作战能力，这场三国杀的最终结局已见端倪。

百度李彦宏：中国人对隐私问题没那么敏感

Mon, 26 Mar 2018 17:14:16 CST

近期， Facebook备受隐私问题困扰，甚至不少名人大咖主动带头掀起了“DeleteFacebook”运动，在国内都引发了不小的关注。国内消费者对于隐私问题的重视程度远不及美国用户，百度CEO李彦宏在近期的活动上也发表了类似的看法：中国人对隐私问题没那么敏感。

2018年3月26日，中国高层发展论坛在北京举行，会上邀请了众多国内外的科技公司大佬参加，包括百度CEO李彦宏、苹果CEO 蒂姆·库克。而李彦宏的在活动中的一些言论瞬间让网友们炸开了锅。

在谈及近期热议的数据泄露和隐私问题时，李彦宏表示：

中国人更加开放，或者说对于隐私问题没有那么敏感，如果说他们愿意用隐私来交换便捷性或者效率，很多情况下他们是愿意这么做的。

但同时，李彦宏也强调，百度当下也更加注重隐私问题，而且中国相关的法律也在不断完善，百度同样也会遵循一系列原则。笔者了解到，在今年的两会上，个人信息泄漏泛滥成为网络安全领域焦点话题之一，包括周鸿祎在内的一些两会代表建议通过立法来解决这个问题，建立完善的用户隐私信息保护机制。

在国内人工智能和大数据应用方面，百度算是走在前列。李彦宏在现场也表达了对待用户数据的态度：

如果用这个数据会让所有者收益，而且他也愿意让你使用这个数据，我们会使用的，我想这是我们的基本做法。

其实就李彦宏所表达的观点来看，并没有什么太大问题。国内消费者的隐私意识虽然不断在加强，但整体来看并没有像美国用户那么敏感。此番言论一出，显然很多用户并不买账。在各大媒体、社交平台，大量负面抨击的评论瞬间炸开锅。但同样也有一部分网友赞同李彦宏所阐述的现状，也透露出一种无奈。

还是那句话“当你接入互联网的那一刻,也许你的隐私就失控了”，曾经有数据显示，国内平均每个人信息泄漏次数至少8条，现在应该远不止这个数。除了传统的网页端，安卓手机的权限管制问题也是造成个人信息泄漏的原因之一。但或许，我们还没有遭受过一次如Facebook那样的事故，没有那种深刻的反思。当然，不得不说，国内在个人信息保护方面的法律法规不够完善，也成为造成消费者这种无奈的原因之一。

有一点笔者觉得大多数人还是无法反驳的，“如果能够用隐私交换便捷性或者效率，很多情况下他们还是愿意的”，最普遍的就是以各种实名认证为基础电子支付、外卖服务、共享单车、网约车等等，你会发现因为互联网而方便的一切事物似乎都代表着你同意将自己的隐私交给某个平台。

从媒体报道出来到现在不过几个小时的时间，百度以及李彦宏又成了网友口诛笔伐的对象，一是百度近几年几次重大负面事件造成的影响，另一种或许是对个人信息泄漏泛滥以及隐私保护无奈感的一种宣泄吧。

*本文作者：Andy，转载请注明来自FreeBuf.COM

百度网盘下载限速如何破解？ - 知乎

Wed, 21 Feb 2018 21:12:18 CST

我们都知道百度云是我们经常使用的软件之一，但是现在使用它，下载速度确实很感人，就算是你买了会员，速度也并不是很快，所以今天教大家几个方法，不管你是手机还是电脑，都可以轻松下载百度云。

Android：ES 文件管理器 + ADM Pro

ADM Pro

打开ADM，【设置】-->【下载】-->【找下面的选项】

【User-Agent】 -->选择【Custom】
【Custom User-Agent】
填写：netdisk;5.2.7;PC;PC-Windows;6.2.9200;WindowsBaiduYunGuanJia

ES 文件管理器

打开ES文件浏览器，登录百度云盘，侧滑点击【网络】--> 【网盘】，点击啊【+】，登录百度云

下载

把要下载的文件选中，打开为【视频】，选择【ADM下载】，开始

PS：下载的时候，ADM和ES文件浏览器不要关闭，等下载完成就好了。

方法二：油猴脚本 + 百度网盘下载助手脚本

百度网盘直接下载助手

http://dwz.cn/dupanzhushou

" width="640">

因为这个要安装油猴脚本，所以可以参考这个来安装下载： http://mp.weixin.qq.com/s/3EkJcdhlxLLyIMw86E0ARw。

或者在百度云下载：链接: https://pan.baidu.com/s/1jIDqnT8密码: ksrb。

这个插件，你可以使用它可以直接获取文件原始链接，这样你就可以使用第三方（IDM，Folx）下载了，再也不用使用百度云客户端的龟速了。

还可以多个文件选择，批量下载。

解决百度云大文件下载限制： http://dwz.cn/3EiCAf

推荐第三方下载工具

下面推荐很多，不同平台的都有，大家对号入座啊，这样就可以轻松高速下载百度云啦。通过上面脚本获取到链接，使用下面下载工具就可以下载了。原始链接也不会限制下载。

IDM：Windows

Folx 2：Mac

Aria2：Mac / Win

ADM：Android

迅雷：全平台

Village 山寨云

" width="1920">

Village 是一款第三方百度云客户端。

尤其是现在百度云没个会员就下载不了东西的情况下，这样一个工具的出现真是太及时了。

它支持网盘搜索功能，支持查看，分享，下载功能，主要是速度还不错。

但愿能活的更久一点。

只有Android 版本。

" width="1178">

上面提到的软件和App ，关注公众号： 高效率工具搜罗（gongju006），回复： 百度云，即可打包下载。

PS：收藏都快破千了，点赞还是寥寥数几，大家还是点个赞再走。

3个方法解决百度网盘限速 (2018-02-16) | 奔跑中的奶酪

Wed, 21 Feb 2018 21:11:56 CST

最早是网友“有一份田”制作的脚本百度下载助手，可以显示直链，绕过大文件云盘下载，还可以调用迅雷或者 IDM加速下载。

使用方法：
1、浏览器安装拓展 Tampermonkey
2、安装下载脚本： https://greasyfork.org/zh-CN/scripts/37515
3、用迅雷或IDM下载时，需要点击“显示直链”，然后将链接复制到迅雷或IDM中去下载，支持在网盘管理页面和文件分享页面生效。
4、如果需要快速调用下载可以安装Firefox下的拓展“xthunder”来调用下载软件。

另附：
迅雷极速版下载： http://www.pc6.com/softview/softview_108931.html
IDM绿色版下载： https://pan.baidu.com/share/init?shareid=3457730696&uk=1767948507#3edk密码 3edk

注意：
1、IDM绿色版需要点击运行文件 "!绿化卸载.bat" 才会自动关联下载。
2、如果你不太会怎么操作，你可以尝试一下已经集成好脚本的Firefox浏览器： http://www.runningcheese.com/firefox-v8
（下载后需要在右上角的那个“火箭”图标里选择“系统工具”，然后再选择“设置IDM”，这样就会自动调用IDM下载了。）
3、如果下载速度被限制在100KB左右，说明你的帐号被百度网盘拉黑了，需要退出登录才能恢复正常下载。
4、如果下载速度在200-700KB左右，可以在“设置-->连接”中，将最达连接数设置为16或者32.
5、在文件分享页面，直接选择文件夹会无法下载，可以同时勾选下载任意一个文件，让文件夹与文件同时下载，这时即可下载。

百度、支付宝、今日头条被工信部约谈！原因与你有关

Sat, 13 Jan 2018 08:35:08 CST

针对近期媒体报道相关手机应用软件存在侵犯用户个人隐私问题，11日，工信部信息通信管理局约谈了北京百度网讯科技有限公司、蚂蚁金服集团公司（支付宝）、北京字节跳动科技有限公司（今日头条）。

违规行为将被严查不得过度收集信息

信息通信管理局指出，对照《网络安全法》《全国人民代表大会常务委员会关于加强网络信息保护的决定》《电信和互联网用户个人信息保护规定》有关规定，三家企业均存在用户个人信息收集使用规则、使用目的告知不充分的情况， 要求三家企业本着充分保障用户知情权和选择权的原则立即进行整改。

信息通信管理局已组织技术部门 对相关手机应用软件是否存在侵犯用户个人隐私行为进行持续监测，并将加强对互联网服务信息收集使用规则告知、账号注销等环节的监督检查。一经 发现违法违规行为，将严肃查处并向社会曝光。

信息通信管理局要求各互联网企业严格遵守相关法律法规，遵循合法、正当、必要的原则收集使用个人信息， 不得收集服务所必需以外的用户个人信息，不得将信息用于提供服务之外的目的，不得非法向他人出售或提供个人信息，同时进一步优化服务协议、用户隐私政策和手机权限调用说明，切实保障用户知情权和选择权，维护用户合法权益。

过度获取公民信息事件时有发生

就在支付宝被工信部约谈的前一天，支付宝已经被网信办约谈。1月3日，在支付宝推出2017年度支付宝账单的当晚，一篇名为《紧急！查看支付宝年度账单前，请先看看这个》的微博广泛传播，并引发了公众对获取个人信息的关注。1月4日凌晨，支付宝旗下的蚂蚁金服发布声明，反思此次行为。同时，对于“默认勾选”，也做出了及时调整。

事实上，因过度获取公民个人信息而遭到质疑的互联网公司，不止支付宝一家。

2017年12月11日，江苏省消费者权益保护委员会，就百度公司涉嫌违法获取消费者个人信息等相关问题，提起消费民事公益诉讼。今年1月2日，南京市中级法院已正式立案。

2017年12月11日，网上出现一篇名为《一位92年女生致周鸿祎：别再盯着我们看了》的文章，公开质疑360“水滴直播”侵犯公众隐私的行为。12月20日，360宣布，关闭水滴直播。

众多APP也被曝违规读取用户信息

在刚刚过去的2017年，国家工信部公布了前三季度的手机app抽检结果，每一季度的抽检，都有软件涉及违规收集使用用户个人信息、恶意“吸费”等问题。“尽可能收集用户信息”已成为不少APP开发商的运营理念。

“凤凰新闻”手机app，下载后会出现“需要使用电话权限，您是否允许”，“需要使用存储权限，您是否允许”等字样，尽管给用户提供了选择，但让人费解的是，对于一个新闻客户端来说，“拨打电话等权限”是否真的需要？

“腾讯新闻”手机app，下载后也会显示出“为了您的正常使用，腾讯新闻需要获取以下权限”，其中就包括位置信息，存储空间以及电话权限。

除下载时的权限获取要求，一些手机app在使用过程中，也会对个人信息数据进行进一步的获取。打开 “网易云音乐”，只要手机里储存了对方手机号，无需任何门槛，就可以查看到对方最近收听过的所有歌曲。在默认的消息和隐私设置中，有“其他人可以在附近页看到我”、“其他人可以通过手机通讯录找到我”等选项，如果不主动关闭，在下载此APP时，这些选项全部是默认开通。

安全专家裴智勇：

获取用户信息，应该和功能实现之间有必要的关系。比如说一个社交软件，它可能需要读取你的通讯录，通过通讯录加更多的好友，权限是合理的。但比如说一画图软件，要读取通讯录，短信记录，通话记录，和功能实现之间就没有必要的关系。

实际上，《网络安全法》早在半年前就已经出台，几大互联网巨头也都在去年9月联合签署了《个人信息保护倡议》，然而并未阻止支付宝账单事件的发生。在信息保护倡议的支持和公民对个人信息保护意识的“觉醒”下，还应有更多的强制性约束手段出台，遏制互联网公司为牟利超越底线的冲动，才能杜绝个人隐私在互联网世界里“裸奔”。

更多新闻

监制/唐怡主编/张天宇

编辑/李嘉欢

©央视新 闻

严查侵犯用户隐私！

（附完整视频）Apollo 2.0 CES 发布前，我们试乘了百度最新的L3、L4级别自动驾驶汽车

Sun, 07 Jan 2018 01:20:00 CST

去年 4 月，在陆奇的带领下，百度宣布对外开放自家的自动驾驶能力，“阿波罗平台”（Apollo）就此诞生。不过那时，没有人知道 Apollo 平台是何走向。

3 个月后，在百度 AI 开发者大会上，陆奇再次站台，对外公布了 Apollo 1.0 的具体细节，1.0 主要发布的是完整的封闭场地循迹自动驾驶。具体开放能力集中在数据平台 1.0、3D 障碍物标注数据、Road Hackers 数据、高精地图数据等方面。

循着“每周更新，两个月左右进行一次新版本和总体能力的提升”的节奏，去年 9 月，Apollo 1.5 对外发布，据当时雷锋网新智驾的报道，整个系统新增了 65000 行代码，重点开放了 5 种能力：障碍物感知、决策规划、云端仿真、高精地图服务、端到端的深度学习，其中前四种能力均为首次开放。而且，1.5 支持昼夜定车道自动驾驶，可实现夜间环境下的障碍物识别，以及非典型交通场景下的异性障碍物识别。

距离 Apollo 1.5 发布，3 个多月的时间过去了，Apollo 计划也即将迎来 2.0 的更新。这一次，百度将重大发布放到了 CES 2018 上。在此之前，百度将国内诸多媒体请到其硅谷的新研发中心，举行了一场规模庞大的展前自动驾驶汽车体验活动。

该研发中心位于硅谷桑尼韦尔（Sunnyvale），旁边就是旧金山湾。去年 10 月正式揭幕，未来主要用于自动驾驶和互联网安全领域的相关研发工作。加上百度此前在硅谷库比蒂诺（Cupertino）以及西雅图开设的研发中心或办公室，如今，百度在美国已经形成了三地联动。

据了解，百度美国研究院拥有超过 200 名员工，主要集中在人工智能、安全和硬件、自动驾驶三个领域进行先进技术的研究。

此次自动驾驶体验活动上，百度还邀请了 Apollo 平台的诸多合作伙伴到场，其中包括 GPU 巨头英伟达、自动驾驶汽车改装企业 AutonomouStuff、汽车零部件供应商采埃孚（ZF）以及汽车分时租赁企业盼达用车。

这些企业之间形成的合作，你中有我、我中有你，构成了百度所期待的“生态圈”。

去年 1 月，采埃孚成为第一家宣布采用英伟达 Drive PX2 计算平台的汽车供应商，双方要打造自动驾驶控制平台 ZF ProAI；
去年 7 月，百度与英伟达宣布联合开发自动驾驶技术，二者结成联盟；百度目前基于林肯 MKZ 改装的自动驾驶汽车便是与 AutonomouStuff 合作完成；几乎同一时间，AutonomouStuff 宣布为英伟达旗下的自动驾驶平台——Drive PX 以及传感器提供相关套件；
去年 9 月，采埃孚与百度共同宣布，双方正式达成新的战略合作，将在自动驾驶、车联网以及移动出行服务领域展开合作，为中国市场开发完备的自动驾驶解决方案；
去年 11 月，百度与盼达用车展开合作，百度将其 Apollo 平台的自动驾驶技术集成到盼达的共享运营车辆上，后者将率先在重庆两江新区开展自动驾驶共享汽车的试运营，可以达到 L3 级别，支持自主泊车以及 App 叫车。而百度与盼达合作的自动驾驶车辆便采用了采埃孚 ProAI 控制平台。

当然，这并不是百度 Apollo 自动驾驶生态的全部。今年 CES，趁着 Apollo 2.0 的更新，百度的更多伙伴将齐聚“Baidu World”大会。

（预告一下：2018 年 1 月 16 日，雷锋网新智驾将在湾区举办 GAIR 硅谷智能驾驶峰会，我们邀请了数十家中美两地顶尖的自动驾驶团队在峰会现场演讲分享，这将是 2018 年最值得参与的智能驾驶峰会之一。目前特惠票依然开放预订中，点击： https://gair.leiphone.com/gair/gairsv2018 直达峰会报名地址，获得与行业顶尖大脑们进行思维碰撞的通行证。）

不过，在此之前，所有风头都是属于自动驾驶车辆试乘。这一次，百度把与采埃孚、盼达（包括力帆）合作的 L3 级别自动驾驶分时租赁车型以及搭载了 Apollo 2.0 最新技术的 L4 级别自动驾驶车型都展示了出来并且提供试乘。

Apollo 2.0 + Drive PX2 = L4 自动驾驶

这就是搭载了百度 Apollo 2.0 系统，具备 L4 级别能力的自动驾驶原型车。

这款自动驾驶汽车是由百度和 AutonomouStuff 联手基于林肯 MKZ 车型改造而成，车顶搭载了 Velodyne 的一枚 64 线激光雷达和两枚 16 线激光雷达，同时还配有 GPS 定位传感器。在激光雷达的左右两侧，各自安装了一枚前视摄像头，可通过视觉途径识别目标物，比如红绿灯。在车辆前脸部位，其搭载的是一款来自大陆的毫米波雷达，安装位置经过了精确的调校。

当然，这样的一套传感器配置是可以灵活应变的，这其中起关键作用的是传感器融合的技术。只要针对传感器的数据修改相应的算法，便可以实现传感器配置的变化，都是可以定制的。

在车辆的后备箱内，是对于自动驾驶最为关键的车载电脑，是整个系统的计算单元。

百度的这辆自动驾驶汽车配备了两台车载电脑：一台是基于 Apollo 2.0 所需要的工控机（使用的是 Neousys Nuvo-6108GC，这是一款性能强大的 X86 解构工业控制计算机）；旁边则是英伟达用于自动驾驶的 Drive PX2。据百度方面的技术负责人介绍，这两台电脑虽然服务的是两套不同的系统，但 Apollo 系统会对这两套系统都进行支持。

实际上，任何一台电脑工作都可以实现车辆的自动驾驶，而百度之所以这样配置，是为了免去测试过程中来回拆机器的过程。问及两台电脑之间的性能区别，该技术负责人向雷锋网新智驾表示，英伟达的 Drive PX2 在图像处理的性能上更加优异，因为其有自带的 GPU 以及进行图像处理的软件；而针对另一台普通的工控机，百度在其中添加了英伟达的 GPU，用于处理图像数据以及激光雷达扫描产生的点云数据，工控机的运算能力相比 Drive PX2 则要强一些。

百度方面称，现阶段，这款车支持在简单的城市道路、高速上行驶。这次试乘，也是百度 Apollo 2.0 首次在加州的公路上进行路测。

百度搭载了 Apollo 2.0 的 L4 级别自动驾驶车辆试乘是在百度美研办公楼周围的一段公共道路上进行的。整个行驶区域的道路相关信息已经进行过采集，百度专门为这段路制作了高精地图来辅佐自动驾驶车辆。

在试乘的整个过程中，会碰到红绿灯、交叉路口、其他机动车以及自行车等，车辆需要自己进行刹车、启动、变道、加速等操作。加之当日是阴雨天，也给自动驾驶汽车带来了一些难度。

整体体验来看，因为是简单的城市道路，这个过程完成得还是比较顺利的，最高时速达到 56 公里/时，车辆刹车、变道的平稳度还是可圈可点的。但是在加速操作时，这辆车还显得有些不够沉稳。

*雷锋网新智驾体验百度搭载了 Apollo 2.0 系统的 L4 级别自动驾驶汽车

百度相关技术负责人告诉雷锋网新智驾，目前，Apollo 2.0 的相关更新代码已经上传至 Github，包括相关的软硬件指导。而 Apollo 2.0 的最终发布要在几天后到来的 CES 2018 上进行。

Apollo 2.0 + ProAI + 盼达 = L3 自动驾驶落地

除了 L4 级别的自动驾驶汽车外，作为百度 Apollo 平台的合作伙伴，总部位于重庆的新能源汽车分时租赁企业盼达用车将双方合作的成果空运到了硅谷百度美研。

其实称双方并不准确，这款车其实是五方合作的成果，包括百度、采埃孚、博世、力帆以及盼达。其中采埃孚提供的技术非常特别，是其与英伟达合作研发的自动驾驶控制平台 ZF ProAI，这个平台刚刚量产不久，就得到了盼达方面的采用。从几方宣布合作，到自动驾驶汽车落地，整个过程据称只花了一个多月的时间。

在传感器方面，这款车算是非常简约，只有前后两个摄像头以及周身的 12 枚超声波雷达，这样的传感器配置已让其具备了 L3 级别的自动驾驶能力，而且，还支持自动找车位和自主泊车的操作。

实际上，低速、简约的传感器配置以及自动找车位和自主泊车的能力某种程度上让这款车非常适合于分时租赁或者其他共享服务。

盼达用车 CEO 高钰告诉雷锋网新智驾，目前盼达已经在重庆两江新区启动了自动驾驶分时租赁车辆的试点运营，先期将投放数十辆车进行尝试。这到底是不是一门好生意，现在谁也不知道。

从真实体验来看，这款车因为目前还不能开上公共道路，所以行驶的速度很慢；在刹车、转向时，整体体验不如此前 L4 自动驾驶汽车那样顺畅。

*雷锋网新智驾体验百度盼达合作的 L3 级别自动驾驶汽车

无论是 L3 还是 L4，看完完整视频的你对于百度自动驾驶的能力应该有所拿捏。Apollo 2.0，CES 2018 上再见。

一个完整推荐系统的设计实现-以百度关键词搜索推荐为例

Wed, 17 Sep 2014 22:42:45 CST

在之前一篇博文中，有同学在评论中问了个问题：如何解决因式分解带来的推荐冷门，热门关键词的问题。在回答这个问题的时候，想到了近几年在做搜索推荐系统的过程中，学术界和工业界的一些区别。正好最近正在做技术规划，于是写偏文章说下工业界完整推荐系统的设计。 结论是：没有某种算法能够完全解决问题，多重算法+交互设计，才能解决特定场景的需求。下文也对之前的一些博文进行梳理，构成一个完整工业界推荐系统所具有的方方面面（主要以百度关键词搜索推荐系统为例）

完整的推荐系统肯定不会只用一种推荐算法

在学术界，一般说到推荐引擎，我们都是围绕着某一种单独的算法的效果优化进行的，例如按内容推荐，协同过滤（包括item-based, user-based, SVD分解等），上下文推荐，Constraint-based推荐，图关系挖掘等。很多比较牛的单个算法，就能在某个指标上取得较好效果，例如MAE，RMSE。。。不过有自己的优点，每种算法也有自己的缺点，例如按内容推荐主要推荐和用户历史结果相似的item，一般的item-based容易推荐热门item（被更多人投票过）。。。。所以在工业界，例如各互联网公司，都会使用多种算法进行互相配合，取长补短，配合产品提升效果。而且 在完整的推荐系统中，不仅有传统的Rating推荐，还需要辅以非常多的挖掘， Ranking来达到预期效果。

推荐系统3大件：User Profile、基础挖掘推荐、Ranking

在实践中，一个完整的推荐系统会主要由3部分组成：

User Profile
基础推荐挖掘算法
Ranking

此处之所以将Ranking单独列出来，是因为其在推荐任务中过于重要，直接决定了推荐的效果。

以下为整个推荐的数据流：

User Profile

A user profile is a representation of information about an individual user that is essential for the (intelligent) application we are considering user profile主要是用户（注册）信息，以及对用户反馈的信息进行处理，聚合，用于描述用户的特征；是后续推荐和排序的基石。一般情况下，user profile会包含以下具体内容：

用户兴趣数据
用户的基础注册信息，背景信息：例如用户出生地，年龄，性别，星座，职业等。这些信息一般从用户注册信息中获取；例如高德，百度地图注册用户，淘宝注册用户等
用户行为反馈：包括显示的反馈(explicit)和隐藏(implicit)的反馈，显示的反馈包括用户的评分，点赞等操作，百度关键词搜索推荐工具上的点赞（正向显示反馈）和垃圾桶（负向显示反馈），淘宝上的评分；隐式反馈包括用户的浏览行为，例如在百度关键词搜索推荐上搜过那些词，淘宝上点击了那些页面，在高德上点击了那些POI等
用户交互偏好：例如用户喜欢使用哪些入口，喜欢哪些操作，以及从这些操作中分析出来的偏好，比如在高德地图上根据用户行为反馈分析出来的用户对美食的偏好：更喜欢火锅，粤菜，还是快餐
用户上下文信息：这些信息有些是分析出来的，例如在LBS中分析出来的用户的家在哪儿，公司在哪儿，经常活动的商圈，经常使用的路线等

user profile经常是一份维护好的数据，在使用的时候，会直接使用该数据，或是将该数据存储在KV系统中，供Online系统实时使用。在搜索或是推荐的场景下，每次请求一般只会涉及到一次user profile的KV请求，所以online使用的时候，主要的实现困难是存储，以及快速KV的快速响应。

基础挖掘推荐算法

基础挖掘推荐算法，主要使用传统推荐算法，结合分析的item profile和user profile，建立user和item的关系，此时并不会过多考虑其他因素，例如是否冷门/热门，最主要的就是建立user和item的关系。在各种论文中狭义的推荐，主要就是指该部分内容。主要围绕着Rating，以及Top N进行该处的Top N（更像是直接Rating值最高的Top N）传统的推荐算法研究主要围着这块工作进行，现在已经有很多比较成熟的算法，这些算法相关的研究可参见博文：《推荐系统经典论文文献及资料》；其中也能找到业界较多成功推荐系统的实践分享主要包含以下几类：

Content Based推荐：按内容推荐，主要的工作是user profile, item profile的提取和维护，然后研究各种相似度度量方法（具体相似度度量参见博文：《推荐系统中的相似度度量》）
协同过滤：相当于应用了用户的行为进行推荐（区别于Content based算法），比较经典的算法包括传统的item-based/user-based算法（参见博文：《协同过滤中item-based与user-based选择依据》，《 collaborative-filtering根据近邻推荐时需要考虑的3要素》），SVD，SVD++(具体原理及源码参见博文：《 SVD因式分解实现协同过滤-及源码实现》)
上下文相关推荐：和传统推荐相比，考虑更多上下文因素，LBS，移动场景下使用比较多（具体参见博文：《 context-aware-recommendation》）
基于图的关系挖掘推荐：主要是利用图论原理，根据item,user之间的数据，反馈关联关系，挖掘更深层次的关系进行推荐，该类方法一般效果都不错，当然资源要求也较高。具体参见博文：《级联二步图关系挖掘关键词推荐系统》，《频繁二项集合的hadoop实现》《 itemrankrandom-walk-based-scoring-algorithm-for-recommener-system》
Constrainted-based推荐：根据限制性条件进行演绎推荐

在实际应用时，我们经常使用按内容推荐，item-based寻找从感知的角度比较靠谱的结果，使用SVD,SVD++，图关系寻找更深层次的联系结果。同时在推荐时，会结合很多因素来进行综合排序，例如关键词，或是LBS中POI的热度等。具体可参见下文ranking部分。

算法效果衡量

以上这些算法，我们在离线的时候，使用Cross-Validation方式，就可以分析出其效果，而且离线分析的时候，代价比较小，比较容易操作。当然，对于不同的问题会使用对应的指标进行衡量。对于预测Rating准确性主要是用RMSE，或是MAE；具体可参见博文：《关键词搜索推荐系统中的推荐准确性度量》如果是排序，则更多使用NDCG，MAP, MRR等指标；具体可参见博文：《使用ndcg评估关键词推荐系统的相关性》在具体应用场景中，对于特定推荐问题，会涉及到选用哪种算法的问题。推荐不像CTR预估这样的问题，目标比较单一，经常我们需要考虑多个指标，而且这些指标可能此消彼长，需要做权衡，例如需要考虑算法的准确性(accuracy)，同时也需要考虑算法的覆盖(coverage)，置信度（confidence）,新鲜度(novelty)和惊喜度(Serendipity)，同时还需要考虑推荐为系统带来的收益和效用(utility)。这些指标经常需要权衡，而且经常提升某一个的时候会导致其它下降，所以有时候存在一定的主观性：我们到底看中哪一个指标？而且这个问题可能随着系统，平台所处的阶段而不同。例如在建立口碑的时候，我们可能不太关注coverage，而更关注accuracy，因为要让用户建立一种：该系统很准的认知；如果在系统已经比较成熟了，此时可能需要考虑novelty, serendipity的同时，还需要考虑utility：该推荐能为系统带来什么收益，例如对百度的变现有多大收益？对淘宝的销售有多少收益等具体这些指标的选择可参见博文：《选择推荐算法时需要考虑得因素》

Ranking，此部分是成熟的搜索，推荐系统具有的核心逻辑

比较简单的实现方法，是直接对各种特征拍阈值进行线性加权，比较成熟的系统一般会使用机器学习的方式和综合个维特征，学习出模型后进行排序，例如使用Learning to rank技术。该部分需要考虑的因素较多较为复杂。和传统的推荐相比，此处单独将Ranking拿出来。基础推荐挖掘，和传统的推荐部分比较类似，主要结合user profile，挖掘哪些item适合推给哪些user。但仅根据这些挖掘就直接进行推荐是不够的。真实online推荐场景中，需要考虑更多其他因素，例如：相关性，推荐的上下文，CTR预估，以及商业业务规则。

相关性： item与用户的相关性，这是大多数搜索和推荐任务的基石，例如在搜索中判定一个query和一个document的相关性，或是一个query 和另一个query的相关性，或是在特征比较多的情况下，一个user 和一个item 记录的相关性；实现方式可以很简单，例如传统的相似度度量方式（参见博文：《推荐系统中的相似度度量》），对于文本，业界使用简单的TF*IDF，或是BM25；不过很多时候我们需要增加更多维度特征，包括推荐item本身的重要性，例如IDF，Pagerank(具体参见博文：《 pagerank的经济学效用解释》)，同时使用模型来提升相关性判断的准确性。使用模型的方式会更加复杂，但效果提升也非常明显。具体可参见博文：《集成树类模型及其在搜索推荐系统中的应用》，《分类模型在关键词推荐系统中的应用》，《 adaboost》
推荐的上下文：例如推荐产品的入口，交互方式，不同的入口，甚至同一入口的不同交互方式，推荐的结果有可能都需要不一样；在LBS生活服务中，请求发生的时间，地点也是推荐需要重点考虑的上下文因素，例如饭点对餐饮item的提权；异地情况下对酒店等结果的加权等
CTR预估：成熟的商业系统都会使用模型来完成CTR预估，或是转化预估
以及商业业务规则：例如黑白名单，或者强制调权。例如在百度关键词搜索推荐中，某些有比较高变现潜力的词，就应该加权往前排；比如在高德LBS服务中，有些海底捞的店点评评分较低，但我们也应该往前排；或是在搜索引擎中，搜国家领导人的名字，有些最相关的结果可能因为法律因素是需要屏蔽的

算法评估

很直接，离线调研的时候看就看算法的评估指标，参见博文：《关键词搜索推荐系统中的推荐准确性度量》，《使用ndcg评估关键词推荐系统的相关性》上线的时候，进行圈用户（圈定某两个user集合作为实验/对照用户组）实验，或者圈请求实验（例如随机圈定5%流量进行实验），之后根据系统效果监控中的指标值判断实验效果。以下为一个典型的效果监控截图：实验如果证明成功，达到预期效果，一般之后推广到全流量；反之，如果实验未达到预期效果，则需要分析什么地方有问题，如何改进，之后继续调整算法继续实验。当实验较多时，还会涉及较多工程问题，例如分层实验框架等。

系统效果监控

对于整个系统，需要建立晚上的效果监控平台进行效果的实时监控，以便发现用户的行为模型，系统的不足，分析后续的发力点等。一般这样的监控平台会使用Dashboard来完成，基本的框架是前段UI + 后端数据库。很多时候，离线统计策略在hadoop上处理统计日志计算指标，并将计算出来的指标存入数据库，前端UI访问数据库，拉出指定时间段内某些指标的值，并进行简单分析。具体的监控指标，及指标体系的建立，可参见博文：《搜索引擎变现策略指标体系》

交互设计

完整的产品包括便捷的交互和背后牛叉的算法。很多时候，要提升推荐的效果，需要算法和交互配合，才能达到理想的效果：交互需要有健壮的算法产出结果；而算法也需要有配套的交互，才能达到预期效果，否则再牛叉的算法，对结果的影响也可能没那么明显。

一些交互的例子参见博文：

《关键词推荐工具中的用户引导机制之一：总述》

《关键词推荐工具中的用户引导机制之二：suggestion架构》

《关键词推荐工具中的用户引导机制之三：相关搜索query技术》

《关键词推荐工具中的用户引导机制之四：种子query推荐》

说了那么多，中心就是想说明，一个完整的推荐系统，远远不止是一两个rating算法能够覆盖的，而且此处还未涉及工程部分。

更多内容，也可直接访问： http://semocean.com

百度开源项目推荐

Wed, 06 Sep 2017 16:41:42 CST

JavaScript 图表库 ECharts

ECharts是一款由百度前端技术部开发的，基于Javascript的数据可视化图表库，提供直观，生动，可交互，可个性化定制的数据可视化图表。

提供大量常用的数据可视化图表，底层基于ZRender（一个全新的轻量级canvas类库），创建了坐标系，图例，提示，工具箱等基础组件，并在此上构建出折线图（区域图）、柱状图（条状图）、散点图（气泡图）、饼图（环形图）、K线图、地图、力导向布局图以及和弦图，同时支持任意维度的堆积和多图表混合展现。

开源自动驾驶平台 ApolloAuto

Apollo (阿波罗)是一个开放的、完整的、安全的平台，将帮助汽车行业及自动驾驶领域的合作伙伴结合车辆和硬件系统，快速搭建一套属于自己的自动驾驶系统。

Apollo 是百度重点打造的 AI 开放平台之一，计划主要包含 4 个技术模块：定位/感知模块、车辆规划与运营（AI+大数据，精准控制车辆，适合不同路况）、软件运营框架（支持英特尔、英伟达等多种芯片）。

百度文件系统 BFS-Baidu

百度的核心数据库Tera将数据持久化在分布式文件系统上，分布式文件系统的性能、可用性和扩展性对整个上层搜索业务的稳定性与效果有着至关重要的影响。现有的分布式文件系统（如HDFS等）无法满足低延迟、高可用、跨地域扩展等方面的需求，所以我们从百度搜索的业务特点出发，开发了自己的分布式文件系统BFS。

系统主要由NameServer、MetaServer、ChunkServer、SDK、bfs_mount和bfs_client等几个模块构成。
其中NameServer是中心控制模块，采用集群化部署，负责目录树的管理；ChunkServer是数据节点负责提供文件块的读写服务；SDK以静态库的形式提供了用户使用的API；bfs_mount通过libfuse，将bfs挂载到本地，作为本地文件系统访问；bfs_client是一个二进制的管理工具。

在线脑图编辑器 Kity Minder

KityMinder 是百度FEX团队的f-cube小组（原UEditor小组）的又一力作。作为一款在线的脑图编辑工具，它有着很多Native编辑工具的交互体验。KM与UE有着一样的宗旨，就是注重最终用户的使用体验。同时，它充分发挥了Web云存储的优势，可以直接将编辑中的脑图同步到云端。此外，借由独创的 “云盘分享”功能，用户可以一键将当前编辑的脑图直接生成在线链接共享给其他用户，实现无缝沟通。

分布式配置管理平台 Disconf

专注于各种分布式系统配置管理的通用组件/通用平台, 提供统一的配置管理服务。包括百度、滴滴打车、银联、网易、拉勾网等知名互联网公司正在使用!

分布式表格系统 Tera

Tera 是一个高性能、可伸缩的数据库系统，被设计用来管理搜索引擎万亿量级的超链与网页信息。为实现数据的实时分析与高效访问，我们使用按行键、列名和时间戳全局排序的三维数据模型组织数据，使用多级Cache系统，充分利用新一代服务器硬件大内存、SSD盘和万兆网卡的性能优势，做到模型灵活的同时，实现了高吞吐与水平扩展。

Android自动化测试框架 Cafe

Cafe 测试框架是一款来自百度QA部门的具有开创性意义的Android平台的自动化测试框架，框架覆盖了Android自动化测试的各种需求。框架致力于实现跨进程测试、快速测试、深度测试，解决了Android自动化测试中的诸多难题，比如业界一直没有解决的跨进程测试问题。

富文本编辑器 Ueditor

UEditor是由百度web前端研发部开发所见即所得富文本web编辑器，具有轻量，可定制，注重用户体验等特点。

地图可视化工具库 Mapv

Mapv 是一款基于百度地图的大数据可视化开源库，可以用来展示大量的点、线、面的数据，每种数据也有不同的展示类型，如直接打点、热力图、网格、聚合等方式展示数据。

全新 3D 可视化库 ECharts-X

ECharts-X是 ECharts 团队推出的全新 3D 可视化库，它是基于 ECharts 的扩展，底层深度整合了 WebGL 库QTEK和 Canvas2D 库ZRender。

百度音乐播放内核 MuPlayer

MuPlayer 是一款跨平台、轻量级的音频播放解决方案，是百度@音乐前端团队开发维护的浏览端音频播放内核，它基于HTML5 Audio及Flash音频技术，已在百度音乐多个线上产品线中应用，具备很强的灵活性和稳定性。

文件上传组件 WebUploader

WebUploader 是由Baidu WebFE(FEX)团队开发的一个简单的以HTML5为主，FLASH为辅的现代文件上传组件。在现代的浏览器里面能充分发挥HTML5的优势，同时又不摒弃主流IE浏览器，延用原来的FLASH运行时，兼容IE6+，Andorid 4+，IOS 6+。两套运行时，同样的调用方式，可供用户任意选用。

感谢 jihong10102006 投递这篇资讯

资讯来源： oschina

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

百度坐标系下经纬度距离的计算

Mon, 14 Aug 2017 17:26:39 CST

最近的一个项目中有用到经纬度距离的计算，数据库中存储的是百度的经纬度。由于先前学习过一些地图经纬度坐标系的知识，所以心中产生了困惑：使用随机偏移过的经纬度地址计算出来的距离是否是正确的？重新梳理了一些基本知识：

地球坐标 (WGS84)

国际标准，从 GPS 设备中取出的数据的坐标系
国际地图提供商使用的坐标系

火星坐标 (GCJ-02)也叫国测局坐标系

中国标准，从国行移动设备中定位获取的坐标数据使用这个坐标系
国家规定：国内出版的各种地图系统（包括电子形式），必须至少采用GCJ-02对地理位置进行首次加密。

百度坐标 (BD-09)

百度标准，百度 SDK，百度地图，Geocoding 使用(本来就乱了，百度又在火星坐标上来个二次加密)

从设备获取经纬度（GPS）坐标

如果使用的是百度sdk那么可以获得百度坐标（bd09）或者火星坐标（GCJ02),默认是bd09
如果使用的是ios的原生定位库，那么获得的坐标是WGS84
如果使用的是高德sdk,那么获取的坐标是GCJ02

更多参考信息：

最准确的距离计算应当采用WGS84的坐标，采用火星坐标系和百度坐标从原理上就可能存在偏差。但是是否可以对经纬度直接进行计算呢，考虑到百度地图有测量距离的功能，于是拔了他的代码用来研究：

代码来源： http://api.map.baidu.com/getscript?v=2.0

var j = void 0,
        p = null,
H.prototype.nb = function(a) {
        return a && this.lat == a.lat && this.lng == a.lng
};

getDistance: function(a, b) {
            if (a && b) {
                if (a.nb(b)) return 0;
                var c = 0,
                    c = R.To(a, b);
                if (c === p || c === j) c = 0;
                return c
            }
        },

nb: function(a) {
            return !(a instanceof eb) || this.xj() ? q : this.se().nb(a.se()) && this.of().nb(a.of())
        },

function R() {}
    R.prototype = new gc;
    x.extend(R, {
        To: function(a, b) {
            if (!a || !b) return 0;
            a.lng = this.ND(a.lng, -180, 180);
            a.lat = this.RD(a.lat, -74, 74);
            b.lng = this.ND(b.lng, -180, 180);
            b.lat = this.RD(b.lat, -74, 74);
            return this.Re(this.Sk(a.lng), this.Sk(b.lng), this.Sk(a.lat), this.Sk(b.lat))
        },
Re: function(a, b, c, d) {
            return this.jP * Math.acos(Math.sin(c) * Math.sin(d) + Math.cos(c) * Math.cos(d) * Math.cos(b - a))
        },
		jP: 6370996.81,

		RD: function(a, b, c) {
            b != p && (a = Math.max(a, b));
            c != p && (a = Math.min(a, c));
            return a
        },
        ND: function(a, b, c) {
            for (; a > c;) a -= c - b;
            for (; a < b;) a += c - b;
            return a
        }
		Sk: function(a) {
            return Math.PI * a / 180
        },        
});

使用Python对上述代码进行了重写：

def get_distance_bd09(point_a, point_b):
    """
    算法来源：http://developer.baidu.com/map/jsdemo.htm#a6_1
    :param pointA: {lat:29.490295, lng:106.486654}
    :param pointB: {lat:29.615467, lng:106.581515}
    :return:米
    """
    Radius = 6370996.81 #球半径

    if (point_a and point_b):
        if point_a["lat"] == point_b["lat"] and point_a["lng"] == point_b["lng"]:
            distance = 0
        else:
            a_lat = point_a["lat"] * math.pi / 180
            a_lng = point_a["lng"] * math.pi / 180
            b_lat = point_b["lat"] * math.pi / 180
            b_lng = point_b["lng"] * math.pi / 180
            # print(a_lng,b_lng,a_lat,b_lat)
            distance = Radius * math.acos(math.sin(a_lat) * math.sin(b_lat) + math.cos(a_lat) * math.cos(b_lat) * math.cos(b_lng - a_lng))
        print(distance)

发现此计算方法与wgs84的算法完全一致。

def get_distance_wgs84(point_a, point_b):
    """
    算法来源：https://stackoverflow.com/questions/27928/calculate-distance-between-two-latitude-longitude-points-haversine-formula
    :param pointA: {lat:29.490295, lng:106.486654}
    :param pointB: {lat:29.615467, lng:106.581515}
    :return:米
    """
    Radius = 6370996.81 #球半径

    d_lat = math.radians(point_b["lat"] - point_a["lat"])
    d_lng = math.radians(point_b["lng"] - point_a["lng"])

    a = math.sin(d_lat/2) * math.sin(d_lat/2) + \
        math.cos(math.radians(point_a["lat"])) * math.cos(math.radians(point_b["lat"])) * \
        math.sin(d_lng/2) * math.sin(d_lng/2)
    c = 2 * math.atan2(math.sqrt(a), math.sqrt(1-a))
    d = Radius * c
    return d

也就是说百度忽略了经纬度的偏移，可能原因是经纬度距离越是距离的近，算出的距离偏差越小，越是距离远，算出的偏差才会远。

补充知识

地理空间距离计算方法较多，可以分为两类：

球面模型，这种模型将地球看成一个标准球体，球面上两点之间的最短距离即大圆弧长，这种方法使用较广
椭球模型，该模型最贴近真实地球，精度也最高，但计算较为复杂

基于球面模型的地理空间距离计算公式，将地球看成圆球，假设地球上有A(ja,wa)，B(jb,wb)两点（注：ja和jb分别是A和B的经度，wa和wb分别是A和B的纬度），A和B两点的球面距离就是AB的弧长，AB弧长=R*角AOB（注：角AOB是A跟B的夹角，O是地球的球心，R是地球半径，约为6367000米）。如何求出角AOB呢？可以先求AOB的最大边AB的长度，再根据余弦定律可以求夹角。

如果业务场景仅仅是在一个城市范围内进行距离计算，也就是说两个点之间的距离一般不会超过200多千米。由于范围小，可以认为经线和纬线是垂直的，如图所示，要求A（116.8，39,78）和B（116.9，39.68）两点的距离，我们可以先求出南北方向距离AM，然后求出东西方向距离BM，最后求矩形对角线距离，即sqrt(AMAM + BMBM)。

public static double distanceSimplify(double lat1, double lng1, double lat2, double lng2, double[] a) {
     double dx = lng1 - lng2; // 经度差值
     double dy = lat1 - lat2; // 纬度差值
     double b = (lat1 + lat2) / 2.0; // 平均纬度
     double Lx = toRadians(dx) * 6367000.0* Math.cos(toRadians(b)); // 东西距离
     double Ly = 6367000.0 * toRadians(dy); // 南北距离
     return Math.sqrt(Lx * Lx + Ly * Ly);  // 用平面的矩形对角距离公式计算总距离
    }
}

参考内容：

百度宣布开源自主驾驶软件

Thu, 06 Jul 2017 17:25:51 CST

百度宣布其自驾车软件可供任何想下载的人使用，而且免费，此举旨在把用户吸引到百度的开源人工智能平台，并收集数据。百度新的 “阿波罗（Apollo）” 平台向任何公司（包括其竞争对手）免费提供自主驾驶软件，这些软件随后可被量身定制，开发他们自己的自主驾驶车辆。百度声称该软件 “开箱即用”。它在林肯 MKZ 混合动力车上可以立即使用，无需任何修改，在其他几种车型上仅需少量修改。百度创始人李彦宏搭乘一辆采用 “阿波罗” 自动驾驶软件的汽车抵达周三会议的会场。此举正受到北京交警部门的调查。在搜索广告营收受到医疗丑闻的打击后，百度正押注于人工智能成为其未来增长来源。该公司正努力成为人工智能的 Android，为所有来者提供一个开源平台。在此过程中，它把自己置身于用户的数据流中心；目前中国的高科技公司正在激烈争夺消费者数据。百度的人工智能框架 Paddle Paddle 正在与 Google 的 TensorFlow 和 Facebook 的 Caffe2 展开竞争。百度还将与开发者分享其主要来自数十亿日常搜索引擎和地图查询的数据。

Python批量挖掘百度下拉框关键词

Fri, 23 Jun 2017 18:00:00 CST

百度下拉框的关键词，一直是SEO关键词拓展的利器，只要在搜索框中输入一个关键词，就可以得到一批相关词。
我有个小技巧， 可瞬间提升上百倍的挖掘效率。并且 通过Python实现后，完全可用于 大规模关键词的批量挖掘。
思路其实很简单，有些朋友也有了解。记得当时跟夜息分享的时候，他一直说666 :)

First Blood

首先，在Chrome的Network中，可以获取到百度下拉框提示的API地址：
https://sp0.baidu.com/5a1Fazu8AA54nxGko9WTAnF6hhy/su?wd=黄&sugmode=2&json=1&p=3&sid=1427_21091_21673_22581&req=2&pbs=%E5%BF%AB%E6%89%8B&csor=2&pwd=%E5%BF%AB%E6%89%8B&cb=jQuery11020924966752020363_1498055470768&_=1498055470781

这里的 黄山，就是我输入的关键词，可替换为其他任意关键词。
输出的结果，通过简单处理，就是json格式。

具体代码实现如下：

def get_sug(word):
    url = 'https://sp0.baidu.com/5a1Fazu8AA54nxGko9WTAnF6hhy/su?wd=%s&sugmode=2&json=1&p=3&sid=1427_21091_21673_22581&req=2&pbs=%%E5%%BF%%AB%%E6%%89%%8B&csor=2&pwd=%%E5%%BF%%AB%%E6%%89%%8B&cb=jQuery11020924966752020363_1498055470768&_=1498055470781' % word
    r = requests.get(url, verify=False)  # 请求API接口，取消了HTTPS验证
    cont = r.content  # 获取返回的内容
    res = cont[41: -2].decode('gbk')  # 只取返回结果中json格式一段，并且解码为unicode
    res_json = json.loads(res)  # json格式转换
    return res_json['s']  # 返回关键词列表


print '\n'.join(get_sug('黄山'))

输出为：

  黄山天气
黄鳝
黄山旅游自助攻略
黄山旅游
黄鳝门
黄山毛峰
黄鳝女主播
黄山山顶住宿攻略
黄山市民网
黄山旅游攻略

Double Kill

这里有个小技巧，就是在关键词后面输入 w，会出现跟拼音以 w开头的一系列关键词，比如“黄山w”，会出现“黄山温泉”，”黄山玩几天“，“黄山五绝”等关键词（见上截图）。因此，当我们把a~z遍历一遍，会出现更多关键词。

升级后，代码实现如下：

def get_more_sug(word):
    all_words = []

    for i in 'abcdefghijklmnopqrstuvwxyz':  
        all_words += get_sug(word+i)  # 遍历字母表 | 利用了上一个函数

    return list(set(all_words))  # 去重

print '\n'.join(get_more_sug('黄山'))

输入结果为：

  黄山红方印多少钱一包
黄山区政府网
黄山山顶住宿攻略
黄山开放时间
黄山西海大峡谷
黄山ie修复专家
黄山免费2017
黄山图片
黄山到宏村
黄山怪石
黄山农家乐
黄山哪里上山
黄山论坛
黄山旅游
黄山毛峰品牌
黄山游记
...

Triple Kill

将上面的思路延展一下，如果 在关键词后输入两个单词，就会出现以这2个字母为拼音开头的一系列关键词，比如“黄山tp”，会出现“黄山天气”，“黄山太平湖”（见截图2）。因此，我们又做了升级。

def get_most_sug(word):
    all_words = []

    for i in 'abcdefghijklmnopqrstuvwxyz': 
        for j in 'abcdefghijklmnopqrstuvwxyz': 
            all_words += get_sug(word+i+j)

    return list(set(all_words))  # 去重

然后就出现了更多关键词：

  黄山云谷索道在哪
黄山开锁
黄山城市风情
黄山评价
黄山能带狗吗
黄山露营
黄山办理港澳通行证
黄山旅游攻略
黄山到广东的高铁
黄山野生猴谷
黄山动车站怎么去黄山脚下
黄山古镇
黄山酒店
黄山太平索道
黄山舰
黄山自驾游
黄山天气预报一周
黄山led显示屏报价
黄山入口
黄山旅游集散中心
黄山阿拉自助游
黄山木雕
黄山北到汤口镇
黄山ppt
黄山特点是啥
黄山半源
黄山屯溪机场到黄山风景区
黄山累不累
黄山到千岛湖怎么坐车
黄山百步云梯
黄山人才网
黄山旅游要多少
黄山敏学教育
黄山银钩
黄山北站
黄山杭徽大酒店
黄山各县市区别墅
黄山卧虎高尔夫
黄山毛峰价格
黄山火车站到黄山屏山
黄山旺季
黄山天都峰
黄山茶庄
黄山宣传片
黄山红方印价格
黄山三日游最佳路线
黄山的诗句
黄山慈光阁索道
黄山一般玩几天
黄山矿泉水
黄山考试网
黄山香烟
黄山别墅
黄山市委党校
...

Legendary

这里还有一些技巧和思路拓展：

如果用作批量跑词，还需要 简单包装下，比如关键词循环，数据保存等。
实际应用中， 字母单循环的性价比更高（也就是Double Kill），速度和词数都比较可观。字母双循环，速度慢，词量也并没有那么高。
百度移动端是另外一个API， 搜狗，360，Google也有不同的API，可以作为扩展方式，脚本需自行完成。

Shut Down

最近在玩王者荣耀，所以小标题用了里面的提示，欢迎大神带我～
最近打算给公众号设置一些结构，比如大的品类分为文章、服务；其中文章里是SEO、Python等栏目，服务里有招聘，工具。这样整体结构更清晰一点。
题图是森林，也是一个小生态。最近正在思考互联网的生态和SEO的影响，之后可能会写一篇相关的文章。

百度网盘助手-获取网盘文件的下载地址，破解限速

Fri, 09 Jun 2017 13:26:36 CST

本文由 @91yun发布

众所周知，百度网盘的文件已经对非会员进行了各种限速。不过由于国内其他网盘基本都残废了，百度网盘作为仅存的少数几个，需求还是很大的，经常会碰到别人分享的百度网盘文件夹。

今天介绍的这种方法就是通过 chrome 的插件 网盘助手 来获得文件的下载地址，然后大家可以自由选择 aria2 ， idm 或者迅雷进行下载。

这种方法通用性强，无论是在 windows 还是 mac 下都可以这样获得下载地址后用下载工具下载

安装 chrome 的百度网盘助手插件

第一步：下载插件

由于很早以前百度的干涉，现在这款插件已经在扩展程序商城找不到了，我们要把他源码下下来，然后通过开发者模式加上去。

插件的 GitHub 地址： https://github.com/acgotaku/BaiduExporter

按照图片所指示的，下载代码的 zip 包

第二步：解压

第三步：加载扩展程序

勾选 开发者模式
选择 加载已解压的扩展程序
选择你刚才解压出来的扩展程序目录

这样你就可以在 chrome 上看到这个扩展程序的图标了。

导出百度网盘的文件下载地址

如果安装成功，那么在百度网盘的下载界面，你就会看到“导出下载”的按钮：

选择 导出下载 后就可以看到下载地址了：

这时候我一般会选择 拷贝下载地址 ，然后用迅雷下载，当然你看也可以直接用 aria2 或者 idm 或者其他工具下载：

百度网盘助手-获取网盘文件的下载地址，破解限速，首发于 91云(91yun.org)。

5天内，Google和百度各自发表AI计划，AI时代真的要来了

Thu, 25 May 2017 17:19:20 CST

当$谷歌(GOOG)$ 去年提出要从“Mobile First”转向“AI First”，我就在想这会不会影响今年Google I/O的走向。果然，上周的Google I/O 2017开发者大会上，“劈柴哥”就强调了这一点，然后全程围绕AI展开。虽说如此，但其实Google只拿出了Google Lens这一个新玩意，其他基本上都是把Assistant、Home、Photos等前几年I/O的亮点产品拿出来冷饭热炒。

Google Lens实质上也算不上是一个产品。按Google的说法，Google Lens是一组基于视觉的计算能力，它能理解你正在看什么，并通过这些信息采取行动。为了帮助观众们理解这个有点抽象的概念，Google通过相机做了三个场景演示。第一个场景是识别了一朵香殊兰百合，第二个场景是扫条形码完成了wifi连接，第三个场景是扫过街景的同时显示了对应店铺信息。

Lens的出场算是整场Google I/O的高潮，尤其是展示连接wifi的场景时，底下吃瓜开发者们响起一片“wow~”的声音。我第一次看视频的时候没想明白，为什么开发者们对Lens的欢呼是在扫码进wifi的场景，而不是在识别出那朵花或者街景的时候呢？后来磕了几颗瓜子之后才想明白这个问题，其中的关键点在于第一个场景扫描之后将花识别出来时，开发者对Lens的初步理解是“图像识别后连接到知识图谱”，但是当Lens连上wifi之后，大家瞬间反应过来Lens可以在不同场景下触发不同的操作，也就是Google所说的“understand”。当然，由于实现wifi连接所产生的屏幕跳转从视觉上更具有冲击性也是其中一个原因。

Lens的出现算是给这场Google I/O提振了士气，不然现场观众可能已经在怀疑他们正在参加一场只有男性参加的、微妙的家庭派对。不过，也有人对Lens的表现不以为意的，比如前“Google Brain”创立者，同时也是前百度首席科学家的吴恩达，就在twitter上发推“Um...Baidu search has had this for years...”（切，百度已经有这个东西好多年了），而且吴恩达发一条还不过瘾，又补了一张带截图的twit来强调下“赏花这件事吧，百度才是专业的”。

实话说，连我都知道“赏花”只不过是Lens一个单一的演示场景，keypoint不在这里，吴教授作为专家中的专家岂会不知。但他却在推特上恶作剧似得拿“赏花”这事嘲讽谷歌，可以看出作为当年“Google Brain”的创立者，他显然对今天Google在AI领域的成绩相当地不置可否。

就在一年一度的“Google I/O开发者大会”召开的5天后，吴恩达的另一个前东家$百度(BIDU)$ 也召开了“2017百度联盟峰会”。就像Google I/O以开发者大会的名义公布未来战略一样，李彦宏每年都会参加的“百度联盟峰会”也承担了同样的功能。而今年的百度联盟峰会用了和google一样的大主题——AI。

与Google相比，我认为百度在这次峰会上所传递出来的feeling可以说是“说得更虚，做地更实”。也就是李彦宏的演讲主题相比“劈柴哥”更为抽象，但百度将AI落地的应用准备更为实际。

李厂长在演讲一开始，把百度这一年落地的AI相关项目都简单过了一遍，其中包括DuerOS、人脸识别寻人、刷脸生活、阿波罗计划等。其中DuerOS和阿波罗计划两个项目偏重开放平台，而人脸识别寻人和刷脸生活的则是更实际的图像识别应用场景。同样是在去年提出以AI为首的战略，对比Google Lens这一孤立，看起来百度在AI领域的布局更迅速也更坚决。

而在简单撸完几个产品之后，李厂长开始正式切入主题，探讨“AI时代的思维方式”。大概意思可以理解为移动互联网已经过了，要把更多精力放在思考AI上，具体来说要将软硬件结合起来考虑，既要重视数据也要重视算法，而当你能做到这些，就能用这种方式干掉现有的互联网公司。

姑且不说李厂长这次演讲能不能称得上一套具有通用性的AI思维方式，但我们可以从百度至今的所为看出李厂长的一些思维方式。2016年9月，百度开放了百度大脑开放平台、百度深度学习平台。11月又发布了百度云的人工智能开放平台——天智。2017年3月，百度发布了DuerOS芯片并同步推出DuerOS开放平台，彻底打开语音交互的大门。随后4月的车展上，百度又放出Apollo计划，共享自动驾驶技术。

尚在百度时的吴恩达说过，人工智能将是新的“电能”，可以想见开放基础数据和基础算法、搭建整个AI开放生态，这将是未来几年百度人工智能的最大主题，这也是李厂长真正的AI思维。

从目前的情况看，其实我们很难判断Google和百度，谁在AI领域跑的更快。但是从双方共同的离职专家吴恩达的言论来判断，至少可以认为百度在AI方面并不落后于Google，甚至在不少方面可能还略微领先。但对整个市场来说，要开启AI时代需要有个像07年的iphone一样的超级消费品，然而不管是百度还是Google都缺乏这样一个能开启整个AI时代的产品。不过目前人工智能的基础技术已经基本完备，在这段时间Google和百度的“携手”轰炸下，越来越多的开发者和企业会进入AI领域，或许再有1~2年，我们就能打开AI时代的门缝。

----------------------------------------

声明：本文作者是人见人爱的营销人兼创业狗黑焰十字，Base上海，欢迎相约交流（日本料理优先）。微信公众号：黑焰十字（darkflame10）。

本话题在雪球有0条讨论，点击查看。
雪球是一个投资者的社交网络，聪明的投资者都在这里。
点击下载雪球手机客户端 http://xueqiu.com/xz

实用的开源百度云分享爬虫项目yunshare - 安装篇

Thu, 24 Nov 2016 11:59:53 CST

今天开源了一个百度云网盘爬虫项目，地址是 https://github.com/callmelanmao/yunshare。

百度云分享爬虫项目

github上有好几个这样的开源项目，但是都只提供了爬虫部分，这个项目在爬虫的基础上还增加了保存数据，建立elasticsearch索引的模块，可以用在实际生产环境中，不过web模块还是需要自己开发

安装

安装node.js和pm2，node用来运行爬虫程序和索引程序，pm2用来管理node任务

安装mysql和mongodb，mysql用来保存爬虫数据，mongodb用来保存最终的百度云分享数据，这些数据是json格式的，用mongodb保存更方便。

git clone https://github.com/callmelanmao/yunshare cnpm i

推荐使用cnpm命令安装npm依赖，最简单的安装方式

$ npm install -g cnpm --registry=https://registry.npm.taobao.org

更多安装cnpm的命令可以去 npm.taobao.org上面找。

初始化

爬虫数据（主要是url列表）都是保存在mysql数据库的，yunshare使用sequelizejs做orm映射，源文件在 src/models/index.js，默认的mysql用户名和密码都是root，数据看是yun，你需要手动创建yun数据库

create database yun default charset utf8

密码根据自己需要进行修改，完成mysql配置之后就可以运行下面的命令

gulp babel node dist/script/init.js

注意必须先运行 gulp babel把es6代码编译成es5，然后运行初始化脚本导入初始数据，数据文件在 data/hot.json，里面，是从页面 http://yun.baidu.com/pcloud/fr ... b%3D1 保存下来的。

启动项目

yunshare使用pm2进行nodejs进程管理，运行 pm2 start process.json启动所有的后台任务，检查任务是否正常运行可以用命令 pm2 list，正常运行的应该有4个任务。

启动elasticsearch索引

elasticsearch索引程序也已经写好了，mapping文件在 data/mapping.json，请确保你已经安装elasticsearch 5.0的版本之后才运行索引程序，命令 pm2 start dist/elastic.js。

默认的elasticsearch地址是 http://localhost:9200，如果你需要修改这个地址，可以在 src/ElasticWorker.js里面修改，修改任何js源码之后记得运行 gulp babel，在重启pm2任务，不然修改是不会生效的。

在完成elasticsearch配置之后，你也可以在process.json里面添加一项elastic任务，这样就不需要单独启动索引程序了。

DEMO

哔哩搜索

下一篇接着介绍整个项目的整体设计思路和开发过程中遇到的问题。

已有 0 人发表留言，猛击->> 这里<<-参与讨论

ITeye推荐

—软件人才免语言低担保赴美带薪读研！—

百度文件系统BFS v0.5.0 发布

Fri, 30 Dec 2016 08:00:00 CST

The Baidu File System

The Baidu File System (BFS) is a distributed file system designed to support real-time applications. Like many other distributed file systems, BFS is highly fault-tolerant. But different from others, BFS provides low read/write latency while maintaining high throughput rates. Together with Galaxyand Tera, BFS supports many real-time products in Baidu, including Baidu webpage database, Baidu incremental indexing system, Baidu user behavior analysis system, etc.

Features

Continuous availability
- Nameserver is implemented as a raft group, no single point failure.
High throughput
- High performance data engine to maximize IO utils.
Low latency
- Global load balance and slow node detection.
Linear scalability
- Support multi data center deployment and up to 10,000 data nodes.

Architecture

Quick Start

Build

  ./build.sh

Standalone BFS

  cd sandbox
./deploy.sh
./start_bfs.sh

How to Contribute

Please read the RoadMapor source code.
Find something you are interested in and start working on it.
Test your code by simply running make testand make check.
Make a pull request.
Once your code has passed the code-review and merged, it will be run on thousands of servers :)

Contact us

opensearch@baidu.com

百度文件系统

百度的核心业务和数据库系统都依赖分布式文件系统作为底层存储，文件系统的可用性和性能对上层搜索业务的稳定性与效果有着至关重要的影响。现有的分布式文件系统（如HDFS等）是为离线批处理设计的，无法在保证高吞吐的情况下做到低延迟和持续可用，所以我们从搜索的业务特点出发，设计了百度文件系统。

核心特点

持续可用
- 数据多机房、多地域冗余，元数据通过Raft维护一致性，单个机房宕机，不影响整体可用性。
高吞吐
- 通过高性能的单机引擎，最大化存储介质IO吞吐；
低延时
- 全局负载均衡、慢节点自动规避
水平扩展
- 设计支持两地三机房，1万+台机器管理。

架构

快速试用

构建

  ./build.sh

单机版BFS

  cd sandbox
./deploy.sh
./start_bfs.sh

如何参与开发

阅读 RoadMap文件或者源代码，了解我们当前的开发方向
找到自己感兴趣开发的的功能或模块
进行开发，开发完成后自测功能是否正确，并运行make test及make check检查是否可以通过已有的测试case
发起pull request
在code-review通过后，你的代码便有机会运行在百度的数万台服务器上~

联系我们

邮件： opensearch@baidu.com
QQ群：188471131

IT瘾百度推荐

百度搜索中台新一代内容架构：FaaS化和智能化实战

一、背景

二、思路与目标

三、FaaS化改造: 追求业务明显感知的卓越效能

3.1 核心框架: 业务抽象与能力复用

极致抽象的业务框架

高度复用的基础服务

3.2 全流程效能提升: 提供极简的用户使用体验

四、智能化:追求更低成本、更高质量的服务

4.1 智能调度: 极致化弹性伸缩

设计思路：多阶段扩容的设计原因

核心实现: 调度核心架构

4.2 智能控制: 防止问题升级扩散，全自动实时处理

健全的自愈能力建设(手段)

自动化问题分析引擎(核心): 规则+Function

五、总结

试乘了三家自动驾驶后，对百度失望了

百度萝卜快跑Apollo

文远知行Weride

小马智行（Pony ai）

试乘体验总结

后记

结尾

消息称，腾讯和字节的内容即将向搜索开放，百度或成最大赢家？

NervJS/taro: 开放式跨端跨框架解决方案，支持使用 React/Vue/Nerv 等框架来开发微信/京东/百度/支付宝/字节跳动/ QQ 小程序/H5/React Native 等应用。 https://taro.zone/

Taro

简介

版本说明

学习资源

社区共享

使用案例

Taro 特性

框架支持

React/Nerv 支持

Vue 支持

多端转换支持

抖音 360 百度等应用被指过多收集用户信息

电信行业三户模型_百度百科

目录

设计

客户

帐户

用户

百度中标今年国内智能交通领域的最大招标订单

百度APP-Android H5首屏优化实践

一、背景

二、方法论

三、Hybrid方案简述及性能瓶颈

四、百度App落地页优化方案

五、新的问题-流量和速度的平衡

六、总结&展望

百度最难捱的一夜：五名高管闪电辞职内幕

百度广告陷入危机，但出问题的不只是百度也不只是广告业

数字广告从 PC 向手机的转型在全球完成，这是百度最主要的危机

同时监管无处不在，医疗、游戏、金融广告都受影响

整个中国广告市场迎来 11 年来最大降幅，问题已经超出渠道转移和具体行业监管

互联网公司在过去几年逐渐成为大广告主，它们也开始削减投入

百度财报出现首次亏损，向海龙退场，李彦宏求变

百度财报首次亏损，向海龙匆匆离开

沈抖高升，百度继续求变

中国首个！百度云宣布边缘计算开源，发布智能边缘开源版本平台OpenEdge

毫秒级从百亿大表任意维度筛选数据是怎么做到的？

都在谈城市治理，后起的百度能成为那个率先破局者吗？

对城市治理的“智能化”理解，过去也许跑偏了

解决安防、环保、交通三大难，或是缓解市长焦虑的开始

点对点落地，最终都要解决这两个问题

技术推动城市治理变革，还是一场“无限运动”

百度开源 FAQ 问答系统—AnyQ

信息流广告三国杀 百度上位 腾讯平稳 头条下挫

百度李彦宏：中国人对隐私问题没那么敏感

百度网盘下载限速如何破解？ - 知乎

3个方法解决百度网盘限速 (2018-02-16) | 奔跑中的奶酪

百度、支付宝、今日头条被工信部约谈！原因与你有关

（附完整视频）Apollo 2.0 CES 发布前，我们试乘了百度最新的L3、L4级别自动驾驶汽车

Apollo 2.0 + Drive PX2 = L4 自动驾驶

Apollo 2.0 + ProAI + 盼达 = L3 自动驾驶落地

一个完整推荐系统的设计实现-以百度关键词搜索推荐为例

百度开源项目推荐

百度坐标系下经纬度距离的计算

信息流广告三国杀百度上位腾讯平稳头条下挫