对于平台界面设计来说，不论是审美和功能都需要不断地进行更新迭代，满足业务需求同时在竞争激烈的互联网+时代站稳脚跟。本次2.0瑶台官网的迭代与以往不同的是，本次除了对平台框架进行了调整以外，品牌的设计语言也进行了重新定义。
随着 RTC 使用场景的不断复杂化，新特性不断增多，同时用户对清晰度提升的诉求也越来越强烈，这些都对客户端机器性能提出了越来越高的要求 (越来越高的分辨率，越来越复杂的编码器等)。但机器性能差异千差万别，同时用户的操作也不可预知，高级特性的使用和机器性能的矛盾客观存在。当用户机器负载过高时，我们需要适当降级视频特性来减轻系统复杂性，确保重要功能正常使用，提升用户体验。 视频性能降级能做什么？ 一是解决因设备性能不足、突发的性能消耗冲击（如杀毒软件）带来的用户音视频体验问题（如视频卡顿、延时高、设备卡死）等问题； 二是提升一些高级功能的渗透率，例如默认情况下开启视频超分，设备性能不足的情况下主动关闭； 三是降低部分场景的设备功耗，例如当电脑使用电池供电的时候，通过关闭视频超分、降低视频帧率等方式主动降低一些功耗。
本文为字节跳动基于数据湖技术的近实时场景实践，主要包括以下几部分内容：数据湖技术的特性、近实时技术的架构、电商数仓实践、未来的挑战与规划。
首先介绍一下语雀的整体情况，语雀是蚂蚁集团推出的一款笔记与文档知识库的管理 & 协同工具，目前蚂蚁集团和阿里集团的员工大约有 10 万多人日常也在使用这个工具，同时也在对外提供服务。 如下图所示为语雀基于 Electron 推出的 Mac 和 Windows 桌面端，还有应对移动端工作场景的小程序。另外，从去年开始我们着手开发了移动端 App，并于今年 2 月份顺利发布上线。图中右侧展示的是 Android/iOS的 App 截图。
供应链时效域历经近一年的发展，在预估时效方面沉淀出了一套理论和两把利器（预估模型和路由系统）。以现货为例，通过持续的技术方案升级，预估模型的准确率最高接近了90%，具备了透出给用户的条件。但在接入前台场景的过程中，前台对我们提出接口性能的要求。 以接入的商详浮层场景为例，接口调用链路经过商详、出价、交易，给到我们供应链只有15ms的时间，在15ms内完成所有的业务逻辑处理是一个不小的挑战。
负载均衡是分布式系统里最常用的能力，实现方式有很多，轮询、随机、加权轮询、一致性hash等文章很多，今天要讲的是遇到的一个真实的生产问题。 公司内部的ES访问架构一般是，Java应用--->SLB(域名)---->ES ingest node (no data) --> ES data node，其中ingest节点是对外暴露的，供Java应用访问，承担了一个纯client角色，不提供数据存储和倒排索引检索服务。这其中SLB是为了方便起到一个域名和负载均衡的功能，绑定后端的n个client节点，并且做到对业务透明，但是毕竟还是有开销的，多了一次网络rpc的转发(尽管很快)，同时也是多花了一份钱。所以在930的时候我们把SLB去掉了，并且进行了验证完全没有问题，这其中还要得益于es本身就支持ip配置列表，并且自身实现了负载均衡的功能。 更改之后的访问链路，Java应用--->ES ingest node -->ES data node。
在真实的业务场景中，我们的业务的数据——例如订单、会员、支付等——都是持久化到数据库中的，因为数据库能有很好的事务保证、持久化保证。但是，正因为数据库要能够满足这么多优秀的功能特性，使得数据库在设计上通常难以兼顾到性能，因此往往不能满足大型流量下的性能要求，像是 MySQL 数据库只能承担“千”这个级别的 QPS，否则很可能会不稳定，进而导致整个系统的故障。 但是客观上，我们的业务规模很可能要求着更高的 QPS，有些业务的规模本身就非常大，也有些业务会遇到一些流量高峰，比如电商会遇到大促的情况。 而这时候大部分的流量实际上都是读请求，而且大部分数据也是没有那么多变化的，如热门商品信息、微博的内容等常见数据就是如此。此时，缓存就是我们应对此类场景的利器。
