本文为字节跳动基于数据湖技术的近实时场景实践，主要包括以下几部分内容：数据湖技术的特性、近实时技术的架构、电商数仓实践、未来的挑战与规划。
首先介绍一下语雀的整体情况，语雀是蚂蚁集团推出的一款笔记与文档知识库的管理 & 协同工具，目前蚂蚁集团和阿里集团的员工大约有 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，有些业务的规模本身就非常大，也有些业务会遇到一些流量高峰，比如电商会遇到大促的情况。 而这时候大部分的流量实际上都是读请求，而且大部分数据也是没有那么多变化的，如热门商品信息、微博的内容等常见数据就是如此。此时，缓存就是我们应对此类场景的利器。
2021年《全球 DevSecOps 现状报告》显示，去年实行 DevOps 的企业数量持续飙升，已经从 2020年的 27%，迅速增长到35.9%。与此同时，信通院在去年发布的《中国 DevOps 现状调查报告》也显示，70%的受访者表示自己所在的团队使用了 DevOps 平台。 然而，我们却看到很多企业的DevOps转型，只发生在IT部门内部，有些还仅仅停留在技术和自动化的层面上，距离引领业务的发展相距甚远。究其原因，DevOps要求的是深层次的组织和文化变革，并非简单的将开发与运维部门合并，它是通过自动化的基础设施，合理的流程规范以及智能化的系统测试来加强开发过程中各部门的协作与沟通。这需要团队有观念上的转变，打趴各部门之间的“墙”，让所有人都参与进来，让组织文化朝DevOps方向上扭转。
高并发解决的核心问题是在同一时间上有大量的请求过来，然后我们的系统要怎么抗住这些请求带来的压力。比如在线直播服务，同时有上百万甚至上千万人观看。比如秒杀品，同时有大量用户涌入。 高并发是从业务角度去描述系统的能力，实现高并发的手段可以采用分布式，也可以采用缓存等，当然也包括多线程、协程，但远远不仅如此；高并发的基本表现为单位时间内系统能够同时处理的请求数，高并发的核心是对资源的有效压榨，有限的资源应对大量的请求。 现代互联网服务，基本上都要考虑高并发问题，因为一般的产品，用户的请求量都很大。
