在网约车行业中，有很多场景中都有着因果推断的相关应用，不仅仅是算法同学等在因果建模时运用到相关知识，很多业务同学在做相关决策时也经常用到。因此采用日常生活中常见的例子以及行业中的常见问题，对因果推断方向进行科普。

在营销增长领域，我们一直在思考工程技术侧可以做什么来赋能业务，尤其在完成0-1的基础设施建设之后，技术的发力点在哪里；我们不想去做陷入细节的、不确定的平台优化，这会带来不确定的业务收益，不明显的ROI，尤其在业务的爆发式增长期，在资源相对有限的情况下我们认为瞄准业务痛点，技术驱动的“快速赋能”是首当其冲的事情。我们基于纯工程手段实现了bandit中的Epsilon-Greedy算法，并让Epsilon-Greedy和我们的投放系统深度融合。

在我们 Hummer 跨端技术框架 的研发过程中，不可避免会对 JavaScript 引擎有所探索和研究。只有深入了解了 JavaScript 的工作原理，才能在跨端研发的诸多细节上避免踩坑，并且做出更好地调优工作。对于很多前端同学来说，JavaScript 引擎就像一个难以触及的黑盒，既熟悉又陌生，因为它被内置在了浏览器内核中。即使在平时开发过程中天天和 JavaScript 引擎打交道，但大多也只是知道 JavaScript 引擎可以解释执行 JavaScript 代码，对于其内部实现原理并不是特别了解。所以我们接下来会专门花几个专题，来深入剖析一下 JavaScript 引擎的世界，逐步揭开它的神秘面纱。这一期我们主要讲一下 JavaScript 引擎中的 “JSValue 的内部实现”。

为了满足不同用户在价格、体验等方面的差异化诉求，滴滴提供了越来越丰富的品类，这些品类大体流程是类似的，在一些细节体验上有差异，一套架构如何兼顾隔离和复用，同时支持这些品类，且看滴滴服务端技术的湾流平台怎么做。

近年来，因果推断逐渐成为了机器学习中的热点话题。增益模型（Uplift Model）作为工业界因果推断与机器学习结合最成熟的算法之一，在智能营销中有着广泛的应用。目前大多数增益模型仅讨论了二元处理变量情况下的处理效应估计，然而在网约车市场中存在大量多维、连续的处理变量。针对这一困境，我们构造了连续因果森林模型，并成功地应用在了网约车交易市场策略上。

基于网约车司机的职业特性，帮助与指引司机在各类复杂的场景下更安全、便捷地完成工作，并尽可能疏导与减轻他们因长时间处于封闭环境下的心理压力，一直是滴滴发力的一个方向。但现有的一些途径，如规则展示、人工客服等，可能存在着司机被动接收信息成本较高、因客服处理速率引发其他情况等弊端。因此，我们在将AI能力与车主端功能结合的过程中做了各类尝试，最终创造了一个可以完善解决这些问题的司机助手：小滴。

滴滴作为一家网约车交易平台，乘客和司机的体验和安全是其核心壁垒之一。在体验和安全优化过程中，缺少准确而大量的标注样本，是制约模型效果、进而影响业务优化的重要技术难题。在滴滴，我们使用few shot的方法，在治理和安全场景做了大量的探索，形成了一套系统的解决方案。

DRouter是滴滴乘客端自研的一套Android路由框架，基于平台化解耦的思想，为组件间通信服务。该项目以功能全面、易用为原则，支持各种路由场景，在页面路由、服务获取和过滤、跨进程及跨应用、VirtualApk插件支持等方面都能提供多样化的服务。目前已在滴滴乘客端、顺风车、单车、国际化、滴滴定制车等十多个滴滴的app内使用，得到各种场景的验证。

在19年下半年，为了将微信钱包/支付宝九宫格入口的滴滴出行迁移为小程序，团队对小程序进行了大量的功能升级与补全。在整个过程中也遇到并克服了一系列问题和挑战，其中包体积问题尤为突出。接下来全面介绍一下滴滴出行小程序在体积控制方面做的努力与沉淀。

LogicFlow 脱胎于滴滴技术团队在客服业务下的实践，是由滴滴智能中台体验平台研发的一款流程可视化的前端框架，提供了一系列流程图交互、编辑所必需的功能和灵活的节点自定义、插件等拓展能力，方便我们快速在业务系统内满足类流程图编辑器的需求。目前，LogicFlow 已经在公司内外不同用户的流程配置需求中得到了验证。

滴滴NodeX是由滴滴普惠、金融、车服三个泛前端团队合力共建，致力于打造滴滴集团级的专业、高效、稳定的Node研发生态。帮助开发者降低服务搭建门槛，提升壁垒和快速闭环赋能业务，目前生态已覆盖滴滴大部分业务。

实现自动驾驶是一个复杂的系统工程，需要精准感知环境，理解交通参与者的意图并能够在广泛丰富的场景下，实现稳定安全的无人驾驶。需要面对真实路况中的大量 “不确定性”。这种不确定性是贯穿上下游的，并且感知局限性、行为预测偶然性、规控交互性共同交织的挑战。在不确定性挑战中的规控相应需要满足稳定性和可扩展性的双重特性，但这两个特性存在冲突，且基于单一特性发展的系统会存在技术弊端。本文将探讨规控模块如何去攻克和突破：通过收集海量的数据信息，并使用数据驱动的方法论来驱动技术的迭代。重点从数据驱动的问题分析，算法开发迭代、系统性验证这三个层面切入探讨。

在滴滴SQL任务从Hive迁移到Spark后，Spark SQL任务占比提升至85%，任务运行时间节省40%，运行任务需要的计算资源节省21%，内存资源节省49%。在迁移过程中我们沉淀出一套迁移流程， 并且发现并解决了两个引擎在语法，UDF，性能和功能方面的差异。

HDFS中默认的3副本方案在存储空间和其他资源（例如网络带宽）上有200％的开销。对于冷数据，使用纠删码（ErasureCoding，EC）存储代替副本存储是一种非常不错的替代方案。EC存储在保证容错能力不低于副本存储的同时，有着更低的存储空间消耗。HDFS EC在滴滴内部稳定落地已超过半年，为公司节约了大量的存储成本。本文将介绍EC在滴滴内部的实践情况。

LogI-KafkaManager脱胎于滴滴内部多年的Kafka运营实践经验，是面向Kafka用户、Kafka运维人员打造的共享多租户Kafka云平台。专注于Kafka运维管控、监控告警、资源治理等核心场景，经历过大规模集群、海量大数据的考验。内部满意度高达90%的同时，还与多家知名企业达成商业化合作。

有个印象很深的细节,优享司机在出发前都会说一句话，“座椅空间需要调整的麻烦告诉下我。请系好安全带，我们出发了”。在每个优享司机讲这句话背后，滴滴在运营上做了什么?以及这里面的管理成本有多大？