本文旨在通过一个实际的例子，说明如何通过数据思维来解决研发工作中的一些棘手问题。通过此文，希望能够清楚地阐述我对下面几个问题的理解：

【What】什么是“数据思维”？

【Why】为什么要用“数据思维”去解决问题？

【Who】数据分析师、开发工程师、测试工程师、产品经理等各角色在这个领域内的定位？

【How】能否用一个清晰可复制的流程来描述“数据思维”的执行过程？

70%的实时数据场景已经接入，查询响应速度平均在200ms左右。

本文主要介绍去哪儿网DBA团队如何通过抓包、解析MySQL协议，获取数据库全量访问日志，解决了“谁动了我的数据”问题。

高并发、高可用场景下，提升系统稳定性的一次实战优化。

DAG计算、标签数据OLAP和OLTP查询一体化。

本文通过讲述一个数据不一致问题的定位原因和解决问题的过程，展示了MySQL改表工具ptosc在主从数据同步中的妙用。

作为 1971 诞生的电子邮件(email)，在当前的互联网环境依然发挥着无可替代的作用。虽然国内使用的相对较少，人们更倾向于使用即时通讯消息，甚至即使倒退十几年，我们对短信的偏好也远胜于邮件，但在国外依旧是主流的信息交互方式，也因此保留了时至今日依旧是主流营销渠道之一的 EDM(Email Direct Marketing，电子邮件营销)。而 EDM 也是甚少与前端有关的邮件术语之一，大概仅仅只是因为邮件含有 HTML 的缘故吧。

经常有这样的 case ，业务线开发同学需要 DBA 帮助其在不同的 PostgreSQL 数据库或集群之间同步数据。

数据量较小时，使用 pg_dump 工具或 copy 命令即可完成同步需求。但当数据量较大时，直接同步数据容易引发源 DB 或目标 DB 出现 slow query 或主从同步延迟等问题，容易对数据库的性能及稳定性造成不良影响。

而且无论数据量大小与否，有时候手工或写定时任务同步数据都很容易出错，且目标DB的数据如果恰好有人在使用极易与同步数据的任务相互阻塞。

是否存在其他数据同步方案避免上述问题呢？通过调研加实践，PostgreSQL中运用FDW与Materialized View可以较好的优化上述问题。

探讨高性能网关核心设计、实现与治理经验。

文章通过MySQL官方文档和MySQL源码两个方面，分析了MySQL主从复制延迟参数Seconds_Behind_Master是如何计算的。

近年来，人工智能逐渐在安防，教育，医疗和旅游等工业和生活场景中落地开花。在携程旅游业务上，AI技术同样广泛覆盖了多个旅游产品和旅游服务领域，携程度假AI研发根据旅游的特定场景和业务需求，将自然语言处理，机器翻译，计算机视觉，搜索排序等主流AI技术成功应用于旅游度假的多个业务线，例如自由行，跟团游，签证，玩乐和租车等。

从技术角度，为了适应不同的业务场景需求，涉及到多种AI技术，包括传统机器学习，卷积神经网络，Transformer等深度学习模型结构，以及知识图谱和图神经网络等技术领域。同时，为了充分挖掘AI技术的优势，模型设计复杂度日渐提升，包括模型深度，宽度以及结构复杂度等各个维度，计算量的增大使得AI推理性能瓶颈日益凸显，尤其是实时性的业务需求对推理速度要求更高。为了追求最佳推理性能，往往需要手动进行逐个优化，涉及的开发，部署和沟通成本都很高。主要问题集中在：

• 模型结构种类多，性能瓶颈差异较大，适用的优化方法各有不同，手动优化成本高；
• 优化方法众多，自上而下，涉及多种模型压缩方式，系统级，运行时优化等，手动优化门槛高；
• 逐个手动优化，可推广性差，技术覆盖面有限；
• 硬件平台的差异，需要针对性调优，导致优化的人力成本和部署成本都很高；
• 新模型的发布和迭代，需要应用优化方法，涉及较高的沟通和接入成本，同时带来了性能的不稳定性；
• 模型压缩技术对不同模型的优化效果有所差异，可能需要进行模型的再训练，训练和数据准备流程较长，效率低下；

因此，为了降低优化，部署和迭代成本，提高工作效率，并保证性能稳定，我们尝试搭建模型自动化优化平台，旨在为算法模型提供更全面易用，稳定性更好，使用和维护成本更低的优化解决方案。

用量化的思维解决慢查询。

聊聊大数据元数据管理重要的一环字段血缘。

最近组内同学遇到一个问题，说数据库被业务打死了，无响应，只好用 kill -9 pid 杀掉，然后重启，幸好此时的数据库角色是从库，影响不大。同学自述，在杀掉重启的时候，心里默念，千万别启不来啊，这个库的数据量有点大，快要达到 4T 了。做运维的人都知道，事情就不能念叨，一念叨，这事儿就准发生。这次也不例外，确实是出现了。现象是长时间启动不了，基本卡死状态。

一道 Sequence 的“开水白菜”，敬请“享用”。

随着携程海外酒店业务的发展，遍布全球的海外供应商与携程总部IDC之间的数据传输量快速增长。技术上，这种日益增长的数据量对跨境网络专线的带宽、延迟等提出了更高的要求；业务上，由于当前有限的跨境网络专线资源对业务处理效率及用户体验也造成了一定的影响；成本上，跨境网络专线作为一种昂贵的资源，通过单纯的专线扩容又会给IT成本造成巨大压力。所以我们开始思考是否可以通过公有云结合酒店直连的业务特性来解决日益增长的带宽压力和供应商接口延迟的问题。

酒店直连系统主要是使用自动化接口实现供应商或集团与携程之间的系统对接，实现静态信息、动态信息、订单功能等都通过系统的方式流转交互。目前携程大量海外酒店业务是通过酒店直连系统对接。

本文将主要从携程酒店直连服务迁移部署至AWS过程中所进行的应用架构调整及云原生改造，使用AWS后取得的技术和业务收益，在部署过程中对EKS（Amazon Elastic Kubernates Service）、DNS查询延时和跨AZ流量降低所做的成本优化等几方面进行详细介绍。