{"data":{"allStrapiInsights":{"edges":[{"node":{"id":"Insights_17","customUrl":" ","type":"link","body":"https://cn.pingcap.com/events/pingcap-user-summit-2023/","image":{"alt":"用户峰会 2023","media":{"url":"https://img1.www.pingcap.com/prod/2023_KV_3cc432c503.png"}},"lable":"行业洞见","title":"创新涌动于先 | PingCAP 用户峰会 2023","description":"PingCAP 中国用户峰会是一个汇聚前沿数据科技与商业洞见的年度盛会，旨在探讨前沿数据技术的发展趋势与行业应用成果，分享行业领袖和专家智囊的实战经验与思想碰撞，构建多元的解决方案与生态合作。"}},{"node":{"id":"Insights_16","customUrl":" ","type":"link","body":"https://cn.pingcap.com/events/devcon2022/sh/index/?trackingCode=PingCAPCN","image":{"alt":"DevCon 2022-配图","media":{"url":"https://img1.www.pingcap.com/prod/Dev_Con2022_c001c5efa8.png"}},"lable":"行业洞见","title":"PingCAP DevCon 2022","description":"本次大会以“去发现 去挑战”为主题，特邀多位行业意见领袖、专家学者和技术大咖，共同探讨云原生、HTAP、Serverless、DB 微服务化等前沿数据技术趋势与发展方向，分享行业最佳实践，探索各行业云上业务和出海业务的多元化解决方案。"}},{"node":{"id":"Insights_15","customUrl":" ","type":"link","body":"https://cn.pingcap.com/events/pingcap-user-summit-2022/","image":{"alt":"PingCAP 用户峰会","media":{"url":"https://img1.www.pingcap.com/prod/_a12671ea01.png"}},"lable":"行业洞见","title":"现在决定未来丨PingCAP 用户峰会","description":"PingCAP 用户峰会是汇聚前沿数据科技与商业洞见的年度用户大会，致力于探讨前沿数据科技的发展趋势与行业应用成果，分享行业领袖、专家智囊的实战经验与思想碰撞，构建多元的解决方案与生态合作。"}},{"node":{"id":"Insights_12","customUrl":"new-economy-dtc-transformation","type":"detail","body":"新冠疫情促使新经济企业纷纷引入 DTC 战略（Direct to Customer，即“直接面向消费者”），把业务重心转到线上，建设面向最终消费者的大前台，例如自营电商、微信小程序、超级 APP 等，呈现出“线上服务与线下体验深度融合，业务前端 服务海量最终消费者”的特点。\n\n新产品迭代不断提速，营销手段推陈出新，海量实时在线的数据、不确定的高峰、广泛的连接成为常态。新经济企业正在探索以“一栈式数据服务平台”为驱动引擎，赋能数据价值的实时变现，打造极致的数字化用户体验。  \n\nPingCAP《新经济 DTC 用户场景白皮书》从“趋势洞察”、“场景方案解析”、“最佳实践”三个章节展开，一次讲透新经济五大场景下的数据挑战和数据架构设计，解析餐饮、新零售、地产、高科技制造、旅游酒店等头部企业的最佳实践。白皮书中的应用场景和实践都是来自近百家 TiDB 头部新经济用户的访谈和调研，旨在提炼新经济企业在面向海量消费者场景下数据挑战和数据服务架构的共性，以此抛砖引玉，引发更多探索。\n\n以下为部分内容预览，想要了解更多详细的内容，请下载 [PDF 版白皮书](https://app.ma.scrmtech.com/resources/ResourcePc/ResourcePcInfo?pf_uid=19697_1864&id=30372&source=1&pf_type=3&channel_id=9034&channel_name=%E7%BD%91%E7%AB%99-PingCAP&tag_id=3139bdcef9046473)。\n\n![新经济DTC-1.png](https://img1.www.pingcap.com/prod/DTC_1_7b22f74644.png)\n\n![新经济白皮书-2.png](https://img1.www.pingcap.com/prod/2_e6772ff428.png)\n\n![新经济白皮书-3.png](https://img1.www.pingcap.com/prod/3_8bb37102d4.png)\n\n![新经济白皮书-4.png](https://img1.www.pingcap.com/prod/4_4ece54298f.png)\n\n![新经济白皮书-5.png](https://img1.www.pingcap.com/prod/5_41077f8a2d.png)\n\n![新经济白皮书-6.png](https://img1.www.pingcap.com/prod/6_bda3cb9cc2.png)\n\n![新经济 DTC-7.png](https://img1.www.pingcap.com/prod/DTC_7_fd5994b66c.png)\n\n查看更多内容，请下载 [PDF 版白皮书](https://app.ma.scrmtech.com/resources/ResourcePc/ResourcePcInfo?pf_uid=19697_1864&id=30372&source=1&pf_type=3&channel_id=9034&channel_name=%E7%BD%91%E7%AB%99-PingCAP&tag_id=3139bdcef9046473)\n\n\n\n","image":{"alt":"新经济 DTC","media":{"url":"https://img1.www.pingcap.com/prod/DTC_cover_53dd8cf1ca.jpg"}},"lable":"场景实践","title":"新经济 DTC 用户场景白皮书","description":"一次讲透新经济五大场景下的数据挑战和数据架构设计，解析新餐饮、新零售、商业地产、高科技制造、旅游酒店等头部企业的最佳实践。"}},{"node":{"id":"Insights_13","customUrl":" ","type":"link","body":"https://pingcap.com/zh/events/database-behind-new-economy-digital-transformation/","image":{"alt":"新经济 DTC","media":{"url":"https://img1.www.pingcap.com/prod/DTC_Insight_2c4e65d917.jpg"}},"lable":"场景实践","title":"新经济 DTC 转型背后的数据库","description":"新经济企业纷纷引入 DTC（Direct to Customer，即“直接面向消费者”）战略，建设和运营线上线下一体化的服务平台，保持了业务经营强健的稳定性，本专题将带您探索这些企业 DTC 转型背后的数据库应用实践。"}},{"node":{"id":"Insights_10","customUrl":"real-time-htap-practice-in-financial-industry","type":"detail","body":"HTAP 用一套数据库架构来同时支持事务 (OLTP) 和分析 (OLAP) 两种需求，已经成为数据处理领域炙手可热的技术风向标。\n\nHTAP 对于金融行业来讲是一次重大的数据架构革新，结合 TiDB 在 HTAP 领域的技术优势和众多头部金融行业用户的真实反馈，PingCAP 重磅发布白皮书《实时数据服务平台——金融行业实时 HTAP 场景实践》。\n\n本白皮书从数字化趋势、 HTAP 技术架构、差异化优势等角度系统化解读 HTAP 在金融行业的应用趋势和场景实践，为企业数据服务架构的建设与转型升级提供参考借鉴。  \n\n以下为部分内容预览，想要了解更多详细的内容，请下载 [PDF 版白皮书](https://app.ma.scrmtech.com/resources/ResourcePc/ResourcePcInfo?pf_uid=19697_1864&id=26897&pf_type=3)。\n\n![金融 HTAP-1.png](https://img1.www.pingcap.com/prod/HTAP_1_17718fec7e.png)\n\n![金融 HTAP-2.png](https://img1.www.pingcap.com/prod/HTAP_2_4822b27476.png)\n\n![金融 HTAP-3.png](https://img1.www.pingcap.com/prod/HTAP_3_df720788bd.png)\n\n![金融 HTAP-4.png](https://img1.www.pingcap.com/prod/HTAP_4_0cb2138d2c.png)\n\n![金融 HTAP-5.png](https://img1.www.pingcap.com/prod/HTAP_5_4b8478c648.png)\n\n![金融 HTAP-6.png](https://img1.www.pingcap.com/prod/HTAP_6_57a46e7de4.png)\n\n![金融 HATP-7.png](https://img1.www.pingcap.com/prod/HATP_7_09592dc78f.png)\n\n![金融 HTAP-8.png](https://img1.www.pingcap.com/prod/HTAP_8_e153b4f836.png)\n\n查看更多内容，请下载 [PDF 版白皮书](https://app.ma.scrmtech.com/resources/ResourcePc/ResourcePcInfo?pf_uid=19697_1864&id=26897&pf_type=3)。\n\n\n\n\n\n\n","image":{"alt":"金融 HTAP 白皮书","media":{"url":"https://img1.www.pingcap.com/prod/_0479d7aa28.svg"}},"lable":"场景实践","title":"《实时数据服务平台——金融行业实时 HTAP 场景实践》白皮书","description":"本白皮书从数字化趋势、 HTAP 技术架构、差异化优势等角度系统化解读 HTAP 在金融行业的应用趋势和场景实践，为企业数据服务架构的建设与转型升级提供参考借鉴。"}},{"node":{"id":"Insights_11","customUrl":" ","type":"link","body":"https://pingcap.com/zh/events/database-behind-big-sales-promotion/","image":{"alt":"大促背后的数据库专题","media":{"url":"https://img1.www.pingcap.com/prod/_2c7083ca6a.jpg"}},"lable":"场景实践","title":"大促背后的数据库","description":"本专题中 ，PingCAP 与汽车之家、易车网、京东、中通等用户展开了一系列深入探讨，为大家揭秘逐年飙升的销量背后隐藏着什么技术难题？用什么技术架构才能平稳地扛住流量洪峰？"}},{"node":{"id":"Insights_9","customUrl":"open-source-community-maturity","type":"detail","body":"随着数字化场景大爆发，开源技术体系和云基础设施逐渐成为支撑数字化进程的两大支柱。开源带来了三个层次的价值，分别是“社会价值、商业价值、创新价值”。开源软件通过激发工程师个体在社群中的创造力，使得个人用户和中小企业可以无门槛使用质量优良的软件产品，带来巨大的社会价值；开源软件公司通过商业模式的创新，形成社区产品和商业化产品的良性互动，提升了软件的商业价值；开源的协同方式逐步成为开放创新的引领者，带来创新价值。在这个三大价值方面，开源社区都是基石般的存在，开源社区的成熟度，直接构成社会价值的基础，通过与商业模式融合带来潜在商业价值，随着开源社区的成熟度越来越高，开源社区也成为重要创新引擎。\n\n开源社区是一个由共同身份和集体目标联合起来的群体。由于开源社区出现的标志性特征是外部参与者开始参与生产与发展，一个健康的开源社区有助于开源项目扩大影响力，吸引更多的外部参与者，扩大社区规模，通过“网络效应”营造完整的开源生态。同时开源社区有着自身的生命周期曲线，如果社区成熟度落后于发展趋势，会导致社区出现“断层”，从而产生大量风险。所以维护者需要度量开源社区所处阶段与成熟度，以保证社区健康可持续性发展。\n\n本白皮书聚焦开源社区成熟度，阐述开源社区成熟度模型、探讨社区构建和度量体系，展望开源社区的发展趋势。\n\n以下为部分内容预览，想要了解更多详细的内容，请下载 [PDF 版白皮书](https://app.ma.scrmtech.com/resources/ResourcePc/ResourcePcInfo?pf_uid=19697_1864&id=23034&pf_type=3)。\n\n![社区白皮书-1.png](https://img1.www.pingcap.com/prod/1_45fcb3c834.png)\n\n![社区白皮书-2.png](https://img1.www.pingcap.com/prod/2_6a90b9d086.png)\n\n![社区白皮书-3.png](https://img1.www.pingcap.com/prod/3_6c2df3799b.png)\n\n![社区白皮书-4.png](https://img1.www.pingcap.com/prod/4_3b4eda88cc.png)\n\n![社区白皮书-5.png](https://img1.www.pingcap.com/prod/5_1d6c5a6bd4.png)\n\n![社区白皮书-7.png](https://img1.www.pingcap.com/prod/7_5ddbde1665.png)\n\n![社区白皮书-8.png](https://img1.www.pingcap.com/prod/8_647e40f056.png)\n\n![社区白皮书-9.png](https://img1.www.pingcap.com/prod/9_a1d1be580e.png)\n\n查看更多内容，请下载 [PDF 版白皮书](https://app.ma.scrmtech.com/resources/ResourcePc/ResourcePcInfo?pf_uid=19697_1864&id=23034&pf_type=3)。\n","image":{"alt":"开源社区成熟度白皮书","media":{"url":"https://img1.www.pingcap.com/prod/open_source_8819a6628e.jpg"}},"lable":"行业洞见","title":"开源社区成熟度白皮书","description":"本白皮书聚焦开源社区成熟度，阐述开源社区成熟度模型、探讨社区构建和度量体系，展望开源社区的发展趋势。"}},{"node":{"id":"Insights_14","customUrl":" ","type":"link","body":"https://pingcap.com/zh/events/devcon2021","image":{"alt":"DevCon 2021-配图","media":{"url":"https://img1.www.pingcap.com/prod/2_45aa1e97a7.jpg"}},"lable":"行业洞见","title":"PingCAP DevCon 2021","description":"本次大会旨在探讨前沿科技与数字化趋势的融合，解读行业领袖观点，分享技术大咖实战经验，展示用户场景的多元化创新，并展现多元化数据技术生态。"}},{"node":{"id":"Insights_8","customUrl":"tidb-htap-accelerate-financial-digital-transformation","type":"detail","body":"\n## 金融行业数字化转型不断深化\n\n正如工业革命推进了社会大发展，数字化转型将是当今世界经济发展的大趋势。2019 年 8 月，中国人民银行发布实施了《金融科技（ FinTech ）发展规划（ 2019-2021 年）》，明确我国金融科技发展的指导思想、基本原则、发展目标、重点任务和保障措施，标志着金融行业的数字化转型进入了新的历史发展阶段。\n\n目前，⾦融⾏业积极拥抱变化，其信息系统架构朝着数字化方向演进发展，金融服务也因科技⽽变得⽆时不在、⽆处不在。提供基于实时场景的嵌⼊式金融服务，提供基于数据智能营销的优质客户体验，推⾏数据分享和开放，构建基于数字化转型的组织架构，成为数字时代金融科技的鲜明特征。\n\n## 金融行业数字化转型剖析\n\n**场景服务创新**\n\n随着金融行业数字化进程加快，金融服务也逐渐向嵌入式的“场景化”方向转型。面向社交、电商、大宗商品交易、餐饮、出行、供应链等 B 端和 C 端市场，“场景+金融”的转型理念需更加深入理解用户心理，更加敏锐地识别、感知、引导、创新和满足客户需求。提供无处不在的金融服务，提升用户体验，场景服务敏捷创新成为金融数字化转型的核心。金融机构需要通过获取用户各类行为、金融交易、征信、风险偏好等数据精准识别出其风险特征和投资偏好，进而推荐合适的金融产品，并对营销线索的转化周期实时跟踪监测，根据用户需求的变化实时调整，提升转化效率；通过场景服务的不断迭代创新，下沉到与之相匹配的高频场景，在高频场景中植入金融场景，触达更多用户。\n\n**数据价值创新**\n\n场景服务的创新离不开数据价值的获取，数据价值创新旨在通过大数据基础设施建设、数据管理与数据建模，通过加工提炼形成数据资产并以数据服务的形态发布，实现数字化运营和精准营销。常⻅的解决⽅案通过⼤数据、机器学习、⼈脸识别、声纹识别等技术对海量数据进⾏采集、计算、加⼯、存储、学习，实现结构化及⾮结构化全域数据采集与引⼊、标准化的数据开发⼯⼚和数据模型、连接与深度萃取数据价值，最终形成数据资产以统⼀数据 API 形式提供智能化数据应⽤能⼒。通过数据价值创新，金融行业可以借此实现可弹性伸缩扩展的数据基础架构、实现业务数据复⽤与共享，数据模型的抽象与建立，消除数据孤岛，快速响应业务需求，最终形成以客户为核⼼，以数据为驱动，以科技为引领，科技赋能业务，构建数字金融体系，更好的匹配数字化经济的特征，完成数字化转型。\n\n**当前系统建设痛点**\n\n面对场景服务和数据价值的创新需求，目前金融行业大数据技术的建设基础主要是以 Hadoop 技术生态和分析型数据为主的离线分析技术，这些技术及平台提供的分析能力往往基于传统数仓 ETL 的建设，是以日终批量的形式将各个业务系统的源数据通过 ETL 抽取到 Hadoop 集群，这类平台的数据更新往往借助分区或全量使用当天数据覆盖，因此无法进行实时数据采集，存在无法利用最新鲜数据萃取加工形成数据资产的痛点，以下是金融行业传统大数据体系架构：\n![洞见1.png](https://img1.www.pingcap.com/prod/1_9a83247fb1.png)\n\n从上面的图中发现，目前金融行业数据价值的获取严重依赖于 Hadoop 生态的技术架构，例如每日日终通过 ETL 工具或数据开发工厂提供的数据同步服务将历史数据导入到数据湖系统，通过离线数仓模型和数据分析形成需要的数据资产，对于一些基于大数据实时数据分析的场景，数据生产方将源数据生成并投递到消息队列服务，数仓系统消费消息队列的数据，完成后续的数据加工并输出到 HBase 等列存数据库，整个方案链路复杂且存在数据延迟，并且传统的 NoSQL 数据库技术也不能支持高并发的查询，难以满足未来数字金融海量实时数据分析、深度萃取数据价值的业务发展需求。\n\n通过调研我们发现未来金融数字化转型的发展需要实时汇集多个系统多个数据库的海量数据，对数据进行统一过滤清洗，选择适合的数据模型进行计算分析加工，快速形成数据资产，典型的场景包括金融业务实时风险监测分析、智能投顾、金融实时风控、用户行为分析等实时数据分析场景。此类金融场景数据量庞大，通常需要在线同时处理 TB 级别的数据，传统的 Hadoop 生态技术栈存在技术复杂、维护成本高、SQL 执行慢等问题，离线数据分析的能力也无法支撑金融行业实时风控、智能营销、智能投顾、实时产品分析报表等数字化转型场景需求。\n\n\n## TiDB HTAP 助力金融行业数字化转型\n\nTiDB HTAP 架构作为新一代行列混合存储引擎分布式数据库，不但可以执行一些轻量级的数据分析类业务，还可以与传统大数据生态技术栈例如 Flink、Kafka 等技术相结合，不论作为单独的实时数据分析处理引擎，还是与传统大数据技术栈结合，都可以显著提升数据价值获取的能力，帮助金融机构搭建自有的场景金融、实时风控、智能营销体系，做好风险把控，将核心的业务及数据能力下沉到场景，展现金融生态的多样化，助力金融行业数字化转型。下⾯我们就结合具体的场景案例，分析 TiDB HTAP 数据库在具体金融数字化转型场景下的解决方案。\n\n\n**场景1：金融实时数据风控**\n\n金融实时数据风控以金融风控数据变量为中心，通过整合决策引擎、征信服务、额度系统、反欺诈等业务系统提供的服务能力进行编排，提供企业级的统一风控入口。随着数字金融的发展，业务场景对实时风控的场景能力进一步提升，网络贷款、支付、券商投资等核心业务要求在秒级完成整个风控流程，同时要求关键业务数据持久化且具备实时数据分析能力，对交易流水结果、征信、反欺诈、决策分析等数据实时或批量进行处理，按照业务定义维度、计算指标生成面向风控场景的数据集市，同时在大屏按照产品、渠道、地区等维度对实时数据进行统计分析和展现，是典型的 OLTP + OLAP 场景。 \n![洞见2.png](https://img1.www.pingcap.com/prod/2_e5ce3fabea.png)\n\n利用传统大数据的解决方案，需要对风控系统的源表进行 ETL 抽取，然后通过离线数仓的解决方案进行处理，这类方案的实时性及复杂度均不能很好的支撑业务需求。通过 TiDB HTAP 架构能力，利用：\n- 基于行存的 OLTP 架构，可以快速高效的将风控业务源数据进行持久化，并支持高并发的访问；\n- 基于列存的 OLAP 架构提供的高性能 MPP 框架以及可更新的列存引擎，可以在线通过分析任务按照业务维度对源数据进行分析加工形成数据资产保存至列存引擎中，以数据 API 的形式发布，提供给业务系统高频实时调用；\n- 基于优化器自动决策，无论是走行存索引选择，还是列存或 MPP 计算模式，都可以由优化器根据 SQL 执行语句统计信息自动做出选择，大大简化系统开发架构的复杂度。\n通过实时风控的场景，选择 “TiKV + TiFlash” 的 TiDB HTAP 架构，其中 TiKV 用于快速沉淀风控交易、决策过程、征信结果等风控业务数据并保障高可用，TiFlash 基于扩展 Raft 共识算法快速同步 TiKV 的数据，基于列存引擎对源数据进行分析查询加工，生成可用于金融风控业务的集市数据或可视化展现 BI 数据，极大提升了业务运行效率。\n\n**场景2：业务实时监测分析**\n\n金融业务实时监测分析系统通过实时汇聚支付、风险、贷款、账务核心、柜面与互联网运营等金融行业核心高频海量数据，通过数据模型对关键系统交易指标进行实时监测分析，关键业务处理逻辑如下：\n- 建立流式大数据实时处理通道；\n- 业务实时监测结果展现，例如业务成功交易量、成功失败率、支付通道成功率、平均耗时、失败率及失败原因汇总，进行多维度可视化报表展现；\n- 对特定交易设置预警阀值以及配置预警规则，出现问题及时输出详细信息。\n![洞见3.png](https://img1.www.pingcap.com/prod/3_715fab6c5e.png)\n\n基于 TiDB HTAP 实时数据处理技术架构的能力构建针对金融行业业务实时监测分析系统的解决方案，其中：\n1. TiCDC 是 TiDB 的增量数据同步工具，可以将多源数据例如支付、核心运营系统源数据库的变更日志输出 binlog 到 kafka 集群，建立大数据实时处理通道，实现多源数据快速接入；\n2. Flink 消费 Kafka 日志对源数据进行过滤清洗加工，根据各类业务指标，通过数据模型加工成模型宽表；\n3. Flink 将加工而成的宽表数据写入到 TiFlash 中，用于数据分析服务处理；\n4. 数据服务层将业务逻辑封装成标准的数据服务 API，直接查询 TiDB HTAP 数据用于各类消费系统进行消费；\n5. 对于中间态交易，日终批量对各类指标基于历史数据进行矫正；\n6. 监控报表等系统可直接利用 TiFlash 引擎进行高效查询分析，对交易成功失败率、交易耗时、失败原因汇总等信息进行多维度多视图展现。\n通过 TiDB HTAP 架构实现的业务实时监测分析系统，可以根据实时在线交易数据动态分析各类业务指标，根据日终批量对部分历史数据进行校对，极大提升日常核心业务的风险监测效率，满足了智能化管理的需求。 \n\n\n**场景3：智能投顾**\n\n智能投顾作为证券公司为客户提供的财富管理解决方案，可根据投资者的风险偏好、收益预期等信息，采用资本资产定价模型、现代化投资组合理论等核心算法模型，为用户提供匹配的投资组合优化建议，完成资产的配置和动态调整，是财富管理转型的重要实践。常用的算法模型使用 T-1 或更早的数据，对于投资市场的分析能力存在滞后性。\n![洞见4.png](https://img1.www.pingcap.com/prod/4_70db046d3f.png)\n\n采用 TiDB HTAP 方案，通过 CDC 或 kafka + Flink 等流式数据采集技术，实时感知外部数据源变化并汇聚数据至 TiDB，使得智能投顾系统可及时获取、分析并感知客户行为和市场波动信息，在系统内部完成客户财富资产方案管理，对资产配置再平衡提供建议。同时，使用 TiCDC + kafka + Flink 工具，实时采集 TiDB 的变化数据，可为下游应用提供实时、 高吞吐、稳定的数据订阅服务，将智能投顾方案建议更及时的触达客户终端，联动交易、CRM 等系统，完成客户服务完整链路触达，也可与多种异构生态对接，满足各类相关等数据应用与分析需求。提升智能投顾实时数据处理能力，能够加强客户在投前、投中阶段提供更加及时的资产配置服务，提升客户体验。在投前阶段，从客户认知和跟踪服务的角度，智能投顾可以体系且持续性的纳入、分析行为数据、交易数据等用户信息，并通过 TiFlash 加速用户信息等归纳、整理并更新算法，做到更加准确及时的 KYC（ Know your customer，即充分了解你的客户）。在投中阶段，针对持有产品的市场解读，在市场波动时，做出适当的交易建议提醒，稳定投资者情绪，降低交易频率，避免用户追涨杀跌、实现合理的长期持有。\n\n\n## 总结\nTiDB 作为一款实时 HTAP 数据库，针对金融数字化转型场景和数据创新的需求，面对传统大数据系统建设痛点，可以加速金融行业数字化转型。它不但能良好支持海量实时数据落地存储，并且可以提供一体化的分析能力，而行列混合的引擎设计也使得金融场景或数据服务能够支撑大规模的交互式查询。金融行业不但可以单独使用 TiDB HTAP 数据库构建轻量级的数据中台实时分析业务，也可以结合大数据传统生态技术一起构建离线 + 实时的全新大数据处理架构。","image":{"alt":null,"media":{"url":"https://img1.www.pingcap.com/prod/img_insight_4_bee413c312.jpg"}},"lable":"行业洞见","title":"TiDB HTAP 加速金融行业数字化转型","description":"数字化转型是当今世界经济发展的大趋势，金融服务也因科技⽽变得⽆时不在、⽆处不在。TiDB 作为一款实时 HTAP 数据库，面对金融行业场景服务和数据价值的创新需求，可很好解决传统大数据系统的建设痛点，加速金融行业数字化转型。"}},{"node":{"id":"Insights_1","customUrl":"in-community-we-trust","type":"detail","body":"前些天在与友人喝咖啡的时候，正好聊到关于 PingCAP 和 TiDB 的一些历史以及对于开源软件公司核心竞争力的理解，**回顾这几年的创业生涯和 TiDB 社区的生长壮大，就像是一场巨大且正在进行中的社会学实验，原本零散的一些想法随着一条主线变得逐渐清晰，就想着写成文章总结一下关于社区对于开源软件以及开源公司到底意味着什么**。\n\n## 无处不在的网络效应\n**两种网络效应**\n\n很多人听说过网络效应（梅特卡夫效应：网络的价值与联网用户的平方数成正比），许多伟大的产品和公司通过网络效应构建起了强大的护城河。提到网络效应，经典例子在通信领域，例如手机，每多一个用户，对于所有用户的价值就越大，虽然大家也无意为他人创造价值，但是一旦开始使用，该行为就会帮助这个网络创造价值。很多我们熟知的 to C公司，尤其是社交网络和IM（即时通信软件） ，通过这个效应构建了极高的壁垒。NfX Venture 在他们的一篇博客(https://www.nfx.com/post/network-effects-manual/ ） 中详细描述了很多种网络效应，在介绍社区之前，我想着重介绍下其中和开源软件相关的两种网络效应。\n\n1.**基于从众心理的网络效应**\n\n这类网络效应通常是从一些意见领袖开始，可能是行业大咖，可能是社交潮人，常常出现在一个新产品要去进攻一个老产品的市场时。尽管这个新产品相比市场的统治者来说不一定成熟，但它通常会带着一些鲜明的特色或者更加前沿的理念，吸引那些对「主流」不满或者希望突显自身前沿视野的意见领袖的支持，造成一种「很酷的人都在用，你不用你就要被淘汰了」的感觉。\n\n这种感觉会在新用户纷纷加入时，形成从众心理的网络效应，但是**这类网络效应的持续时间不会太长**。细想一下就能知道：如果早期意见领袖只是因为突显「不同」而加入，那么在这个社区成为主流后，这些意见领袖就没有理由留下，追随这些人的粉丝可能会随之而去。另外，对于这个新产品来说，完善程度通常不如老产品，美誉和差评会在早期同时到来。此时，如果不快速通过网络效应打磨产品，获得更好的迭代速度，那么，这个网络效应是根基不牢的。**一个好处在于，该效应在早期是事半功倍的**。\n\n回想 TiDB 早期的社区建设，也是因为几个创始人在 Codis 的工作以及在国内基础软件圈中积累的名声，和一些互联网技术圈中朋友的支持，形成最早的背书。\n\n2.**基于信仰的网络效应**\n\n**所谓「信仰」，就是基于对一个理念的认可而加入，从而形成网络效应**。这点在软件领域也不少见，自由软件运动和开源运动都是很好的例子。人嘛，总是要相信点什么。这类网络效应的护城河是极深的，而且对于产品缺陷的容忍度极高。因为信念是一个长期的念想，对于 TiDB 来说，这个念想形如：相信分布式是未来，相信云时代的业务需要像 TiDB 这样的数据库。但是这个目标又是足够有挑战的，值得长期为之努力。\n\n基于信仰的网络效应可能在最早期和从众心理网络效应有点类似，其中的关键是社区核心人群对于产品背后的理念是否有坚定信仰。反之，如果只是简单地秀优越感，是不会长久的，随着兴趣衰减，网络效应也会崩塌。\n\n\n\n**网络效应对于基础软件的意义**\n\n对于基础软件来说，我一直坚持两个观点：\n\n- 基础软件是被“用”出来的，不是“写”出来的。\n- 迭代和进化速度是这类软件的核心竞争力。\n\n这两点恰恰是网络效应能带来的，虽然价值链条不像IM那样明显，但是，网络效应存在的基础是新用户给老用户带来的额外价值。而基础软件的价值，体现为以下几点：\n\n- 可控的风险（稳定性）\n- 更多的场景适应性（发现新的适用场景和持续提升性能）\n- 良好的易用性\n\n对于风险控制来说，越多人用意味着风险被越多人均摊，其中的一个假设是：我不特别，我遇到的问题别人应该也遇到过，一定有人能比我早发现并修复它。这个假设在一个成熟且活跃的基础软件社区是成立的，因为基础软件的场景边界相对清晰，在适用范围内的路径大致相同，同一条路径走多了，坑自然就少了。只要有一个人踩到坑，反馈回社区，不管最后是谁修好的，这个行为对于其他用户都是受益的。\n\n同样的逻辑，对于场景适应性来说也成立。个体的认知总是带有局限性，即使是项目的创始团队，也不见得对于某个具体的应用场景有深刻理解。社区用户的创造力是无穷的，一些设计外的使用路径可能会出奇地好用，从而发展出新的优势场景。同样地，**只要有一个成功案例，那么对于其他具有相似场景的用户来说，软件的价值就增加了， TiDB 和 Flink 组合成的实时 HTAP 数据处理方案，就是一个很好的例子**。\n\n对于易用性改进的逻辑和稳定性类似，我就不赘述了。利用网络效应带来的飞轮效应改进软件，这个思路我在《大教堂终将倒下，但集市永存》一文中也提到过。\n\n## 社区的成熟度曲线和必经阶段\n**社区的诞生**\n\n在 GitHub 上开放你的源代码，甚至使用公开的 Git 工作流，都不是社区诞生的时刻。一个社区真正诞生，是在你和你的代码之外，开始有第三者介入并产生连接的时刻，可能是收到第一个外部 PR，可能是收到第一个外部 issue，这些才是社区的开端。社区始于连接，也成就于连接。开放源代码并不等同于开源，很多团队和项目在开放源代码方面花费了很多时间，却忽略了代码及背后团队的社区化，这是很可惜的。\n\n**死亡鸿沟和希望之坡**\n\n就像《跨越鸿沟》这本书中提到的，开源软件也有自己的生命周期曲线，这是和社区息息相关的。\n![洞见1.png](https://img1.www.pingcap.com/prod/1_6359c01571.png)\n图中断层出现的原因是产品成熟度迟迟没有跟上，用户过来以后发现都是坑，随之而来的各种差评会让早期支持者和创始人疲于奔命甚至而失去兴趣。\n![洞见2.jpeg](https://img1.www.pingcap.com/prod/2_c308184493.jpeg)\n\n\n**对于一个开源软件，断层的体现可能是经历早期快速增长后，来到长达 1~2 年的静默期，增长几乎停滞**。对于社区来说，几乎所有的精力都用在给早期用户填坑，期间会有用户自然增长但流失率也非常高。这个阶段对于资源的消耗非常大，社区的核心贡献者也会非常累，如果熬不过去就死了，所以说是“死亡鸿沟”。\n\n好消息是，**这个阶段终将会过去**，bug 这种东西嘛，改掉一个就少一个，产品也会在这个阶段逐渐摸索到自己的定位和最佳实践，而在最佳实践这个路径上，产品会变得越来越稳定和聚焦。如果定位是市场刚需，**那么就会迎来一个高速增长阶段（成熟期），而社区的生态也会随着产品的普及开始加速度发展**。这个从上图的 Kubernetes 和 TiDB 的搜索指数里面能看到这个鸿沟的一个侧写。\n\n\n**社区的终局**\n\n一个好的开源软件社区的终局会是什么样子？对于这个问题，其实我们有很多能参考的例子，例如 GNU Linux、Hadoop、Spark、MySQL 等等。我认为，不管一个开源软件及社区是由商业公司发起还是其他方式发起、壮大，到最后一定会出现独立于某公司之外的中立组织来接管这个社区，这也是最自然合理的方式。\n\n尤其是公司主导的开源项目，在后期会面临中立性的问题。因为对于公司而言，最重要的是客户成功，对商业化的诉求一定会影响开源软件功能设置和开发优先级。而且优先级往往是会变的（可能更紧急且更具体），变化也许会和社区的开发节奏冲突，但我不认为这两者的矛盾不可调和，我会在下文展开来讲。\n\n**中后期的开源软件已经支撑着太多用户的场景成功和商业利益，由一个中立的委员会来平衡各方的利益及监督各方的责任是目前看来比较成功的实践**，而且开始有这样的组织，也从侧面说明这个项目已经成熟，已经有良好的生态。还没有到达这个阶段的开源软件大多是由项目背后的公司主导社区，在项目成熟阶段，重点是不断地通过优化客户和场景的成功让整个飞轮转动起来，当主导公司之外有越来越多的成员在思考和实践 governance rule，这就是一个积极的信号。\n\n## 社区和商业化如何共存\n**种地和做菜 & 河与岸上的人**\n\n前文留下一个问题，就是开源与商业化的矛盾，不管我如何解释，本质上开源和传统的软件售卖模式一定是冲突的。\n\n我举一个比较好理解的例子：如果将开源比作种菜，开源软件源代码相当于种子，业务成功相当于长出来的菜，传统的软件商业模式类似于卖种子，但是种地施肥（hosting）都是客户自己的工作。开源软件的种子是免费的，地是客户的，种地的人也是客户的人，所以开源厂商大概只能提供种地指导服务，尤其在一些种子不是太好种的情况下，指导服务是有意义的。但仔细想想，随着种子不断改良（性能、稳定性、易用性等），随便撒到地里就能开花结果，那么专业的种菜服务就没什么必要性了。于是厂商只好卖一些额外的价值，比如保险服务，万一种子生长遇到极端天气，至少有专家团在背后帮忙解决。但是这种商业模式仍然比较别扭，因为价值链条大部分都在客户自己这边。所以，如果厂商看待社区只停留在潜在客户视角，很难做出好产品，因为没有内在动力去持续优化软件。\n\n一个更好的视角是往后退一步，我再举个好理解的例子：将社区当成一条河流，不属于任何人，大家共同保持河水的清澈和流动性，谁都不要过度捞鱼，不同的组织和个人都可以在河流周边构建自己的生态，至于岸上的人靠什么挣钱，那是另外一个问题，后文再讲。\n\n**客户成功和用户体验：内在的一致性**\n\n虽然开源软件商业公司的第一目标是客户成功，但这和做好社区并不矛盾。**一个常见的误区是在开源软件公司内部，这两个团队形成对立关系。**商业团队认为社区就是给商业化养鱼的，养肥了就要收割，极端点就动不动要闭源；社区团队认为商业化会减慢生态传播的速度，使用门槛上升，极端做法是产生反商业化的倾向。如果都只在自己的位置上思考问题，当然双方都没错，那到底是哪里有问题呢？\n\n问题出在了“阶段”和“客户选择”，社区用户和商业用户使用开源软件的生命周期可能完全不同，一般的开源软件公司会有两个漏斗，我称之为社区漏斗和商业漏斗。有些说法认为社区漏斗是商业漏斗的上层，我之前也深以为然，但经过几年的实践，我渐渐发现其实并不是那样。这两者是独立的，如果只是简单地作为一个漏斗，那么就会有很多问题，比如经典问题：不会流到商业漏斗的社区用户，其价值到底是什么？所以，肯定不是一个漏斗，而是有很深的内部联系。\n\n什么联系？为方便理解，还是用种菜举例说明。开源社区孵化出来的东西，例如用户成功案例、社区贡献对产品的打磨、探索出来的适用场景等，就像一个个生的菜和食材，而客户想要一盘鱼香肉丝，并不关心盘子中的肉和菜是怎么来的，所以看到关键点了吗？商业化团队的角色就像是厨师，社区运营团队就像农民，二者的关注点并不一样，厨师关注点是如何做好菜，农民的关注点是如何种好地，产生更好的食材。从食材到一道菜，还要经历很长的过程，但没有好食材，能力再强的厨师也难做出一盘好菜。\n\n**对于开源软件公司来说，社区和商业这两个团队的内部一致性是：好产品和制胜场景**。根据我们的实践经验，比较好的做法是，社区团队聚焦于两个关键点：\n- 社区用户对于产品的打磨（在制胜场景下）；\n- 发现更多的制胜场景。\n\n这两个关键点会形成闭环，社区团队持续产生食材（制胜场景以及持续进化的产品），商业团队聚焦于制胜场景的进一步加工和客户旅程优化，两个团队互相配合拉动整个公司和项目的大循环。例如TiDB商业用户的场景和解决方案，大多是从社区用户中诞生并打磨成熟，尽管可能两个用户群体完全不一样，但是通过 TiDB 形成了一个大的生态——商业化的循环，而PingCAP 就是中间的桥梁。另外，社区和商业化团队会有一个共同的北极星指标：用户体验。\n\n**可规模化变现的唯一出路：云**\n\n一个好的生意应该是可以规模化的，传统开源软件公司的商业模式，问题在于规模化中需要人的介入，销售/售前/售后交付等等，而基于人的生意是没法规模化的。在云诞生前这个问题是无解的，所以开源软件公司需要寻找一个和开源无关的软件商业模式（听起来有点别扭，但是仔细想想确实如此），而云本质上是一个资源租赁生意。\n\n还是以种菜的例子来说，过去传统的商业模式中，因为土地和种菜人都是客户自己的，所以开源软件公司的位置就比较尴尬，但是在云上，基础软件商业模式本质上是一个hosting服务，让原来价值链条中最重要的一部分“土地”（ hosting资源和基础设施）掌握在了厂商手上，这对于用户来说也是好的，毕竟管理“土地”也是一件费心费力的事情，而且很难做到按需购买。问题在于用户想要的只是一道好菜而已，注意这和开源（种菜）并没有什么关系，因为不管开不开源，用户支付的都是管理和租赁费用，相当于即使种子和食材免费，顾客去饭店吃饭，也需要为菜品买单，因为顾客购买的是好菜和服务体验。\n\n另外，**很多人认为开源社区是竞争壁垒，其实并不是，真正的壁垒是生态，而开源社区是构建生态的一种高效方式，如果一个产品不用开源也构建起了生态，那么效果是一样的**。一个很好的例子就是 Snowflake，尽管 Snowflake 没有开源，但是2012年诞生伊始，它在云数据仓库这个市场内几乎没有任何竞争对手，留给 Snowflake 足够的时间通过差异化定位和极佳的用户体验构建自己的生态，依托云的崛起和规模化效应取得了巨大成功。\n\n## 如何做好社区\n上文形而上地讨论了很多关于哲学的内容，接下来聊聊落地实践。想要做好开源社区其实是有方法论的，但前提是有正确的思考方式和思考角度，否则在实践环节你就会发现有无数事情可以做，却不知道哪件或哪些事情是更重要的，更难受的是你发现没法衡量对与错。以下是我的一些思考角度以及思考时考虑的重点指标，可作为社区运营者的参考。\n\n**你是谁？你解决了什么问题？为什么是你？**\n\n好社区的根基一定是好产品，要回答“你是谁”这个问题，一定是通过回答“你解决了什么问题”而得出的，这点和 to C 产品的运营很不一样。一些社区运营者会将注意力转移到各种活动或者宣传拉新，同时夸大产品能力，导致与现实不符，这是最常见的误区。\n\n很多做社区运营的朋友经常来找我：我也做了很多活动，写了很多文章，为什么看起来没有效果？通常这个时候我会问他：你能一句话说明白你的产品是做什么的吗？到底解决了什么问题？这个问题是普遍问题吗？非你这个产品不可吗？这个时候他就明白：完美的产品是不存在的，好的产品一定是跟随它的优势场景出现的，比如 Redis 显然不能用来做核心金融交易场景，但谁都不会否认Redis在缓存场景下是当之无愧的事实标准。同样的例子还有很多，例如 Spark、ClickHouse 等等。所以对于运营团队，在做任何动作之前要想清楚上面的四个问题。\n\n**好用决定了漏斗的转化率**\n\n找到制胜场景就够了吗？当然不是，如果把整个用户旅程当成一个漏斗，找到制胜场景充其量是找到正确的入口而已，进入漏斗以后，重要的事情就变成了提升各阶段的转化率，**决定转化率的一个关键指标是产品的易用性**，这点和做 to C 产品很像，很多做 to B 的团队会下意识忽略这一点，通常可能是两种原因：\n- 不太重视社区用户 Self-service ，项目官方甚至鼓励用户联系官方团队，因为早期知道有人在用这个信息是很重要的，而商业客户基本服务和支持都是官方的，客户无感，对公司而言没有动力优化。\n- 很多产品在诞生初期是救命型的产品，用户没有别的选择。例如早期的 TiDB ，在 MySQL 扩展需求迫在眉睫的时候，用户更关心如何立即把问题解决掉，内核能力更重要，其他的可以先缓缓，忍着就好。\n\n这两种原因导致的结果就是，对易用性和用户体验关注不足，这个错误在市场竞争初期是很隐蔽的。一方面因为流进漏斗的 leads 数量不够大，人肉支持尚可，且市场的竞争还不激烈，用户没有其他选择。试想一下，当这个市场终有一天变得成熟，大量客户被充分教育后流入漏斗，团队的支持带宽肯定是不足的；另一方面，因为市场已经被教育成熟，一定会有竞争对手能做类似的事情，这时，当你不是市场中唯一的救命选择，用户一定会选择用着顺手且省心的一方，这不难理解。这就是为什么在开源软件竞争的中后期，易用性和用户体验要放在至高位置的原因。对于“用着省心”，假设已经通过成熟的生态和案例背书解决了，而在“用着顺手”这一点上，中国诞生的开源软件团队相比世界先进水平而言，差距很大，毕竟海外的开源软件竞争比国内更加激烈，因为国外开源市场诞生时间长，而且业务场景对于基础软件的需求也没有国内极端，通常好几个产品都能搞定同一个场景，那么这时当然就要比拼易用性（省心）和生态（放心）。\n\n有几个问题，作为开源项目的产品负责人可以问问自己，在你的产品领域里，如何定义好用？最佳实践是什么？世界上最好用的同类水平是怎么样的？我相信思考这些问题对产品发展会有帮助。**一个反映易用性的好视角是：用户能够 Self-servicing 的程度，其指标体系较多**：比如在云上自助完整整个产品生命周期的比例，在开源社区从接触到使用过程中不用提问的比例，开源社区活跃贡献者数量等等。\n\n**二次传播是达成网络效应的关键**\n\n上文提到过，网络效应产生的前提是，任何一个新用户的使用对于老用户是有价值加成的，所以试想：如果一个社区用户默默地使用了软件，默默地看了文档和最佳实践文章，甚至出了 bug 自己默默地修好（不贡献回来），这对这个社区和产品是有价值的吗？\n\n我认为是没有的。\n\n尽管我知道一定会有这样的用户存在，就像沉默的大多数人一样。对于社区运营者来说，**最关键的任务不是让沉默者更多或更深度地使用，而是让他们和网络中的其他用户建立更多的连接**，例如分享经验（写案例文章）、培养贡献者、积极向社区反馈使用中的问题等等，而且一定要将这些内容传递到网络的其他节点，确保产生价值。例如：一个用户的使用场景帮到了另一个用户选型，一个用户反馈帮助产品发现了一个 bug 并修复，这些都是产生价值的例子。切忌让用户变成一个个孤岛，社区运营者如果看不清这个关键点，可能会陷入为了数字（使用量）而追求数字的情况，做了很多工作，但从全局看不到进步。\n\n**网络效应的转移**\n\n社区运营的最高境界是将网络效应从使用者的网络效应转移到基于信仰的网络效应，将社区中心从开源公司内部转移到外部以获得更大的势能。这两者都不容易，对于前者可能更多的是抽象和总结提炼理念以及持续保持长远而正确的 insight（洞察），加之寻找合适的布道者群体，这点并不容易。对于后者来说，只要在以公司为中心的阶段积累足够多的成功案例和优势场景，并且投入资源教育市场，剩下的交给时间就好，这个阶段关注的指标是品牌力。开源软件社区运营是一个指数曲线的游戏，要抱着长期主义的心态去耕耘。\n\n最后作为结尾，我想谈谈，一个伟大的开源基础软件产品应该是什么样的？\n\n**我眼中一个伟大的基础软件产品不仅仅是解决眼下的具体问题，而是开启一片新的天地，一个新的视角，创造新的可能性。就像智能手机的发明，它作为平台催生出了微信这样的伟大应用，开启了一个全新的世界。就像云、S3 和 EBS 的发明，给开发者提供了新的设计方式，催生出了Snowflake这类的新物种，彻底改变了人们使用分析数据的方式。而开源社区正是这类伟大基础软件诞生的最合适的土壤，就像鱼和水一样**。\n\n我不知道社区会带来什么，我也不敢高估自己能力，毕竟在群体智慧面前，个人的力量永远是渺小的。\n","image":{"alt":"In Community We Trust","media":{"url":"https://img1.www.pingcap.com/prod/image_5_23308cc26c.png"}},"lable":"技术趋势","title":"In Community We Trust","description":"我眼中一个伟大的基础软件产品不仅仅是解决眼下的具体问题，而是开启一片新的天地，一个新的视角，创造新的可能性。而开源社区正是这类伟大基础软件诞生的最合适的土壤，就像鱼和水一样。"}},{"node":{"id":"Insights_2","customUrl":"new-ideas-of-cloud-native-database-design","type":"detail","body":"在讲新的思路之前，先为过去没有关注过数据库技术的朋友们做一个简单的历史回顾，接下来会谈谈未来的数据库领域，在云原生数据库设计方面的新趋势和前沿思考。首先来看看一些主流数据库的设计模式。\n\n## 常见的分布式数据库流派\n分布式数据库的发展历程，我按照年代进行了分类，到目前为止分成了四代。第一代是基于简单的分库分表或者中间件来做 Data Sharding 和 水平扩展。第二代系统是以 Cassandra、HBase 或者 MongoDB 为代表的 NoSQL 数据库，一般多为互联网公司在使用，拥有很好的水平扩展能力。\n\n第三代系统我个人认为是以 Google Spanner 和 AWS Aurora 为代表的新一代云数据库，他们的特点是融合了 SQL 和 NoSQL 的扩展能力，对业务层暴露了 SQL 的接口，在使用上可以做到水平的扩展。\n\n第四代系统是以现在 TiDB 的设计为例，开始进入到混合业务负载的时代，一套系统拥有既能做交易也能处理高并发事务的特性，同时又能结合一些数据仓库或者分析型数据库的能力，所以叫 HTAP，就是融合型的数据库产品。\n\n未来是什么样子，后面的分享我会介绍关于未来的一些展望。从整个时间线看，从 1970 年代发展到现在，database 也算是个古老的行业了，具体每个阶段的发展情况，我就不过多展开。\n![洞见3.png](https://img1.www.pingcap.com/prod/3_d1b18e2723.png)\n\n\n## 数据库中间件\n对于数据库中间件来说，第一代系统是中间件的系统，基本上整个主流模式有两种，一种是在业务层做手动的分库分表，比如数据库的使用者在业务层里告诉你；北京的数据放在一个数据库里，而上海的数据放在另一个数据库或者写到不同的表上，这种就是业务层手动的最简单的分库分表，相信大家操作过数据库的朋友都很熟悉。\n\n第二种通过一个数据库中间件指定 Sharding 的规则。比如像用户的城市、用户的 ID、时间来做为分片的规则，通过中间件来自动的分配，就不用业务层去做。\n\n这种方式的优点就是简单。如果业务在特别简单的情况下，比如说写入或者读取基本能退化成在一个分片上完成，在应用层做充分适配以后，延迟还是比较低的，而整体上，如果 workload 是随机的，业务的 TPS 也能做到线性扩展。\n\n但是缺点也比较明显。对于一些比较复杂的业务，特别是一些跨分片的操作，比如说查询或者写入要保持跨分片之间的数据强一致性的时候就比较麻烦。另外一个比较明显的缺点是它对于大型集群的运维是比较困难的，特别是去做一些类似的表结构变更之类的操作。想象一下如果有一百个分片，要去加一列或者删一列，相当于要在一百台机器上都执行操作，其实很麻烦。\n\n## NoSQL - Not Only SQL\n在 2010 年前后，好多互联网公司都发现了这个大的痛点，仔细思考了业务后，他们发现业务很简单，也不需要 SQL 特别复杂的功能，于是就发展出了一个流派就是 NoSQL 数据库。NoSQL 的特点就是放弃到了高级的 SQL 能力，但是有得必有失，或者说放弃掉了东西总能换来一些东西，NoSQL 换来的是一个对业务透明的、强的水平扩展能力，但反过来就意味着你的业务原来是基于 SQL 去写的话，可能会带来比较大的改造成本，代表的系统有刚才我说到的 MongoDB、Cassandra、HBase 等。\n\n最有名的系统就是 MongoDB，MongoDB 虽然也是分布式，但仍然还是像分库分表的方案一样，要选择分片的 key，他的优点大家都比较熟悉，就是没有表结构信息，想写什么就写什么，对于文档型的数据比较友好，但缺点也比较明显，既然选择了 Sharding Key，可能是按照一个固定的规则在做分片，所以当有一些跨分片的聚合需求的时候会比较麻烦，第二是在跨分片的 ACID 事务上没有很好的支持。\n![洞见4.png](https://img1.www.pingcap.com/prod/4_039bdf1fb0.png)\n\n\nHBase 是 Hadoop 生态下的比较有名的分布式 NoSQL 数据库，它是构建在 HDFS 之上的一个 NoSQL 数据库。Cassandra 是一个分布式的 KV 数据库，其特点是在 KV 操作上提供多种一致性模型，缺点与很多 NoSQL 的问题一样，包括运维的复杂性， KV 的接口对于原有业务改造的要求等。\n\n## 第三代分布式数据库 NewSQL\n刚才说过 Sharding 或者分库分表，NoSQL 也好，都面临着一个业务的侵入性问题，如果你的业务是重度依赖 SQL，那么用这两种方案都是很不舒适的。于是一些技术比较前沿的公司就在思考，能不能结合传统数据库的优点，比如 SQL 表达力，事务一致性等特性，但是又跟 NoSQL 时代好的特性，比如扩展性能够相结合发展出一种新的、可扩展的，但是用起来又像单机数据库一样方便的系统。在这个思路下就诞生出了两个流派，一个是 Spanner，一个是 Aurora，两个都是顶级的互联网公司在面临到这种问题时做出的一个选择。\n\n### Shared Nothing 流派\nShared Nothing 这个流派是以 Google Spanner 为代表，好处是在于可以做到几乎无限的水平扩展，整个系统没有端点，不管是 1 个 T、10 个 T 或者 100 个 T，业务层基本上不用担心扩展能力。第二个好处是他的设计目标是提供强 SQL 的支持，不需要指定分片规则、分片策略，系统会自动的帮你做扩展。第三是支持像单机数据库一样的强一致的事务，可以用来支持金融级别的业务。\n![洞见5.png](https://img1.www.pingcap.com/prod/5_6dc3bb4f8d.png)\n\n\n代表产品就是 Spanner 与 TiDB，这类系统也有一些缺点，从本质上来说一个纯分布式数据库，很多行为没有办法跟单机行为一模一样。举个例子，比如说延迟，单机数据库在做交易事务的时候，可能在单机上就完成了，但是在分布式数据库上，如果要去实现同样的一个语义，这个事务需要操作的行可能分布在不同的机器上，需要涉及到多次网络的通信和交互，响应速度和性能肯定不如在单机上一次操作完成，所以在一些兼容性和行为上与单机数据库还是有一些区别的。即使是这样，对于很多业务来说，与分库分表相比，分布式数据库还是具备很多优势，比如在易用性方面还是比分库分表的侵入性小很多。\n\n### Shared Everything 流派\n第二种流派就是 Shared Everything 流派，代表有 AWS Aurora、阿里云的 PolarDB，很多数据库都定义自己是 Cloud-Native Database，但我觉得这里的 Cloud-Native 更多是在于通常这些方案都是由公有云服务商来提供的，至于本身的技术是不是云原生，并没有一个统一的标准。从纯技术的角度来去说一个核心的要点，这类系统的计算与存储是彻底分离的，计算节点与存储节点跑在不同机器上，存储相当于把一个 MySQL 跑在云盘上的感觉，我个人认为类似 Aurora 或者 PolarDB 的这种架构并不是一个纯粹的分布式架构。\n![洞见6.png](https://img1.www.pingcap.com/prod/6_5a62a64e4e.png)\n\n\n原来 MySQL 的主从复制都走 Binlog，Aurora 作为一种在云上 Share Everything Database 的代表，Aurora 的设计思路是把整个 IO 的 flow 只通过 redo log 的形式来做复制，而不是通过整个 IO 链路打到最后 Binlog，再发到另外一台机器上，然后再 apply 这个 Binlog，所以 Aurora 的 IO 链路减少很多，这是一个很大的创新。\n\n日志复制的单位变小，意味着我发过去的只有 Physical log，不是 Binlog，也不是直接发语句过去，直接发物理的日志能代表着更小的 IO 的路径以及更小的网络包，所以整个数据库系统的吞吐效率会比传统的 MySQL 的部署方案好很多。\n![洞见7.png](https://img1.www.pingcap.com/prod/7_5018b70bd4.png)\n\nAurora 的优势是 100% 兼容 MySQL，业务兼容性好，业务基本上不用改就可以用，而且对于一些互联网的场景，对一致性要求不高的话，数据库的读也可以做到水平扩展，不管是 Aurora 也好，PolarDB 也好，读性能是有上限的。\n\nAurora 的短板大家也能看得出来，本质上这还是一个单机数据库，因为所有数据量都是存储在一起的，Aurora 的计算层其实就是一个 MySQL 实例，不关心底下这些数据的分布，如果有大的写入量或者有大的跨分片查询的需求，如果要支持大数据量，还是需要分库分表，所以 Aurora 是一款更好的云上单机数据库。\n\n### 第四代系统：分布式 HTAP 数据库\n第四代系统就是新形态的 HTAP 数据库，英文名称是 Hybrid Transactional and Analytical Processing，通过名字也很好理解，既可以做事务，又可以在同一套系统里面做实时分析。HTAP 数据库的优势是可以像 NoSQL 一样具备无限水平扩展能力，像 NewSQL 一样能够去做 SQL 的查询与事务的支持，更重要的是在混合业务等复杂的场景下，OLAP 不会影响到 OLTP 业务，同时省去了在同一个系统里面把数据搬来搬去的烦恼。目前，我看到在工业界基本只有 TiDB 4.0 加上 TiFlash 这个架构能够符合上述要求。\n\n### 分布式 HTAP 数据库：TiDB (with TiFlash)\n为什么 TiDB 能够实现 OLAP 和 OLTP 的彻底隔离，互不影响？因为 TiDB 是计算和存储分离的架构，底层的存储是多副本机制，可以把其中一些副本转换成列式存储的副本。OLAP 的请求可以直接打到列式的副本上，也就是 TiFlash 的副本来提供高性能列式的分析服务，做到了同一份数据既可以做实时的交易又做实时的分析，这是 TiDB 在架构层面的巨大创新和突破。\n![洞见8.png](https://img1.www.pingcap.com/prod/8_0e3d5dd08a.png)\n\n\n下图是 TiDB 的测试结果，与 MemSQL 进行了对比，根据用户场景构造了一种 workload，横轴是并发数，纵轴是 OLTP 的性能，蓝色、黄色、绿色这些是 OLAP 的并发数。这个实验的目的就是在一套系统上既跑 OLTP 又跑 OLAP，同时不断提升 OLTP 和 OLAP 的并发压力，从而查看这两种 workload 是否会互相影响。可以看到在 TiDB 这边，同时加大 OLTP 和 OLAP 的并发压力，这两种 workload 的性能表现没有什么明显变化，几乎是差不多的。但是，同样的实验发生在 MemSQL 上，大家可以看到 MemSQL 的性能大幅衰减，随着 OLAP 的并发数变大，OLTP 的性能下降比较明显。\n![洞见15.png](https://img1.www.pingcap.com/prod/15_3cb41aaa3f.png)\n\n\n接下来是 TiDB 在一个用户实际业务场景的例子，在进行 OLAP 业务的查询的时候，OLTP 业务仍然可以实现平滑的写入操作，延迟一直维持在较低的水平。\n![洞见10.png](https://img1.www.pingcap.com/prod/10_9f1dc95953.png)\n\n\n## 未来在哪里\n### Snowflake\nSnowflake 是一个 100% 构建在云上的数据仓库系统，底层的存储依赖 S3，基本上每个公有云都会提供类似 S3 这样的对象存储服务，Snowflake 也是一个纯粹的计算与存储分离的架构，在系统里面定义的计算节点叫 Virtual Warehouse，可以认为就是一个个 EC2 单元，本地的缓存有日志盘，Snowflake 的主要数据存在 S3 上，本地的计算节点是在公有云的虚机上。\n![洞见11.png](https://img1.www.pingcap.com/prod/11_b41570ea20.png)\n\n\n这是 Snowflake 在 S3 里面存储的数据格式的特点，每一个 S3 的对象是 10 兆一个文件，只追加，每一个文件里面包含源信息，通过列式的存储落到磁盘上。\n![洞见12.png](https://img1.www.pingcap.com/prod/12_c3b901aa86.png)\n\n\nSnowflake 这个系统最重要的一个闪光点就是对于同一份数据可以分配不同的计算资源进行计算，比如某个 query 可能只需要两台机器，另外一个 query 需要更多的计算资源，但是没关系，实际上这些数据都在 S3 上面，简单来说两台机器可以挂载同一块磁盘分别去处理不同的工作负载，这就是一个计算与存储解耦的重要例子。\n\n### Google BigQuery\n第二个系统是 BigQuery，BigQuery 是 Google Cloud 上提供的大数据分析服务，架构设计上跟 Snowflake 有点类似。BigQuery 的数据存储在谷歌内部的分布式文件系统 Colossus 上面，Jupiter 是内部的一个高性能网络，上面这个是谷歌的计算节点。\n![洞见13.png](https://img1.www.pingcap.com/prod/13_1552fe4979.png)\n\n\nBigQuery 的处理性能比较出色，每秒在数据中心内的一个双向的带宽可以达到 1 PB，如果使用 2000 个专属的计算节点单元，大概一个月的费用是四万美金。BigQuery 是一个按需付费的模式，一个 query 可能就用两个 slot，就收取这两个 slot 的费用，BigQuery 的存储成本相对较低，1 TB 的存储大概 20 美金一个月。\n\n### RockSet\n第三个系统是 RockSet，大家知道 RocksDB 是一个比较有名的单机 KV 数据库，其存储引擎的数据结构叫 LSM-Tree，LSM-Tree 的核心思想进行分层设计，更冷的数据会在越下层。RockSet 把后面的层放在了 S3 的存储上面，上面的层其实是用 local disk 或者本地的内存来做引擎，天然是一个分层的结构，你的应用感知不到下面是一个云盘还是本地磁盘，通过很好的本地缓存让你感知不到下面云存储的存在。\n\n所以刚才看了这三个系统，我觉得有几个特点，一个是首先都是天然分布式的，第二个是构建在云的标准服务上面的，尤其是 S3 和 EBS，第三是 pay as you go，在架构里面充分利用了云的弹性能力。我觉得这三点最重要的一点是存储，存储系统决定了云上数据库的设计方向。\n\n### 为什么 S3 是关键？\n在存储里边我觉得更关键的可能是 S3。EBS 其实我们也有研究过，TiDB 第一阶段其实已经正在跟 EBS 块存储做融合，但从更长远的角度来看，我觉得更有意思的方向是在 S3 这边。\n\n首先第一点 S3 非常划算，价格远低于 EBS，第二 S3 提供了 9 个 9 很高的可靠性，第三是具备线性扩展的吞吐能力，第四是天然跨云，每一个云上都有 S3 API 的对象存储服务。但是 S3 的问题就是随机写入的延迟非常高，但是吞吐性能不错，所以我们要去利用这个吞吐性能不错的这个特点，规避延迟高的风险。这是 S3 benchmark 的一个测试，可以看到随着机型的提升，吞吐能力也是持续的提升。\n![洞见14.png](https://img1.www.pingcap.com/prod/14_925a02e6ab.png)\n\n\n### 如何解决 Latency 的问题？\n如果要解决 S3 的 Latency 问题，这里提供一些思路，比如像 RockSet 那样用 SSD 或者本地磁盘来做 cache，或者通过 kinesis 写入日志，来降低整个写入的延迟。还有数据的复制或者你要去做一些并发处理等，其实可以去做 Zero-copy data cloning，也是降低延迟的一些方式。\n\n上述例子有一些共同点都是数据仓库，不知道大家有没有发现，为什么都是数据仓库？数据仓库对于吞吐的要求其实是更高的，对于延迟并不是那么在意，一个 query 可能跑五秒出结果就行了，不用要求五毫秒之内给出结果，特别是对于一些 Point Lookup 这种场景来说，Shared Nothing 的 database 可能只需要从客户端的一次 rpc，但是对于计算与存储分离的架构，中间无论如何要走两次网络，这是一个核心的问题。\n![洞见15.png](https://img1.www.pingcap.com/prod/15_3cb41aaa3f.png)\n\n\n你可能会说没有关系，反正计算和存储已经分离了，大力出奇迹，可以加计算节点。但是我觉得新思路没必要这么极端，Aurora 是一个计算存储分离架构，但它是一个单机数据库，Spanner 是一个纯分布式的数据库，纯 Shared Nothing 的架构并没有利用到云基础设施提供的一些优势。\n\n比如说未来我们的数据库可以做这样的设计，在计算层其实带着一点点状态，因为每台 EC2 都会带一个本地磁盘，现在主流的 EC2 都是 SSD，比较热的数据可以在这一层做 Shared Nothing，在这一层去做高可用，在这一层去做随机的读取与写入。热数据一旦 cache miss，才会落到 S3 上面，可以在 S3 只做后面几层的数据存储，这种做法可能会带来问题，一旦穿透了本地 cache，Latency 会有一些抖动。\n![洞见16.png](https://img1.www.pingcap.com/prod/16_480a6223d1.png)\n\n这种架构设计的好处：首先，拥有对实时业务的数据计算亲和力，在 local disk 上会有很多数据，在这点上很多传统数据库的一些性能优化技巧可以用起来；第二，数据迁移其实会变得很简单，实际上底下的存储是共享的，都在 S3 上面，比如说 A 机器到 B 机器的数据迁移其实不用真的做迁移，只要在 B 机器上读取数据就行了。\n\n这个架构的缺点是：第一，缓存穿透了以后，Latency 会变高；第二，计算节点现在有了状态，如果计算节点挂掉了以后，Failover 要去处理日志回放的问题，这可能会增加一点实现的复杂度。\n![洞见17.png](https://img1.www.pingcap.com/prod/17_6794d03a16.png)\n\n\n## 还有很多值得研究的课题\n上面的架构只是一个设想，TiDB 其实还不是这样的架构，但未来可能会在这方向去做一些尝试或者研究，在这个领域里面其实还有很多 open question 我们还没有答案，包括云厂商、包括我们，包括学术界都没有答案。\n\n现在有一些研究的课题，第一，如果我们要利用本地磁盘，应该缓存多少数据，LRU 的策略是什么样子，跟 performance 到底有什么关系，跟 workload 有什么关系。第二，对于网络，刚才我们看到 S3 的网络吞吐做的很好，什么样的性能要配上什么样的吞吐，要配多少个计算节点，特别是对于一些比较复杂查询的 Reshuffle；第三，计算复杂度和计算节点、机型的关系是什么？这些问题其实都是比较复杂的问题，特别是怎么用数学来表达，因为需要自动化地去做这些事情。\n\n即使这些问题都解决了，我觉得也只是云上数据库时代的一个开始。未来在 Serverless，包括 AI-Driven 几大方向上，怎么设计出更好的 database，这是我们努力的方向。最后引用屈原的一句话，就是路漫漫其修远兮，我们还有很多事情需要去做，谢谢大家。","image":{"alt":"云原生数据库设计新思路","media":{"url":"https://img1.www.pingcap.com/prod/image_3_6320d69e39.png"}},"lable":"技术趋势","title":"云原生数据库设计新思路","description":"本文\b将先为过去没有关注过数据库技术的朋友们做一个简单的历史回顾，然后谈谈未来的数据库领域，在云原生数据库设计方面的新趋势和自己的一些思考。"}},{"node":{"id":"Insights_4","customUrl":"the-cathedral-and-the-fair","type":"detail","body":"作为一个在中国的数据库软件从业者，最近被不少朋友在微信上询问业内某厂商「团队整合」的新闻，我其实并不想对这个事情发表什么评论。我始终坚信：基础软件，未来只有开源一条路。如果不开源，或者说内核不开源的话，产品的生命力是有限的。所以，在这里想分享一些我个人有关开源与闭源的看法，希望大家看完这篇文章后能够有些自己的思考 :）\n\n顺便提一下，看到这个标题，熟悉开源运动的朋友肯定会心一笑，没错，作为 ESR 的门徒，我从不掩饰对于《大教堂与集市》这篇著作的喜爱。另外作为从事开源的创业者，这几年的实践让我们对于 ESR 的这本书的理解更加的深入，我会试着在这篇文章总结一些我们经常被问到的问题，最后一部分我斗胆给 ESR 的理论在当今云时代的背景下做一些修订，另外我们讨论的软件范围仅限于基础软件（数据库，编译器，操作系统等）。\n\n## 一、代码是核心竞争力吗？\n我和一些闭源软件项目的作者聊过，大多数选择闭源的原因不外乎以下几种：\n\n1. 觉得自己的核心算法非常厉害，不希望竞争对手模仿；\n2. 担心用户拿到代码，就不给钱了；\n3. 没有找到或者建立自己的护城河；\n4. 代码太丑，不好意思开源；\n5. 怕被人找到 Bug。\n\n其中以前三种答案居多，我非常能理解，这些回答也都是非常正当的理由，只是这篇文章我们好好的就事论事的挨个分析一下，对于第四第五个理由，其实我不想过多展开，未来有机会再聊聊，我们聊聊前两种，先看第一种，我在后边会聊聊第二种。\n\n对于第一种原因，我们再深入思考一下，一般可能有下面两种情况：\n1. 我的核心代码很短，可能是一个很巧妙的算法，或者一套很巧妙的参数；\n2. 我的工程上的设计和实现得很优秀，系统架构是领先的。\n\n对于第一种情况，我一直以来的观点是：如果在同一个行业里面，除非你达到了彻彻底底的人才垄断，那么在一个充分竞争的环境，如果这个问题是一个高价值问题，那么你能想到的短短的 「核心算法」，别人也同样能想得到。天下没有银弹，计算机科学就是在无数种妥协和不完美中寻找平衡的艺术（当然，图灵奖级别的 idea 或者量子计算机这种现象级的东西另说，但是这种机会是很少见的），即使通过闭源创造出短期的垄断优势，但是这个平衡一定会被另一个竞争对手打破，最终也一定会出现一个优质的开源替代品全部吞掉（这个开源事实标准短期看甚至不一定是更好的）。\n\n其实多数的产品优势是体现在工程实现上，也就是上面的第二种，一群优秀的工程师，在正确的设计下，构建出优质的软件。对于这种情况，无论开源还是不开源，竞争对手都没有办法很好的模仿，就像一个学霸，考了一个100分的答卷，把这个答卷给一个学渣看，学渣朋友肯定也没法马上变成学霸，因为代码只是结果，是什么样的思考和选择得到了这个结果，这个过程是没法开放的，所谓知其然不知其所以然，当然，就算你也很厉害，也有一批优秀工程师，短时间也做出了一个不错的产品，但是没关系，结局和前面提到那种情况也是一样的：只要你是闭源的，这个问题又足够普遍且高价值，那么长远来看一定会有一个开源的解决方案吞掉一切。这背后的原因其实和代码没有什么关系，因为代码在这里其实并不是核心竞争力。关于前面提到的第三种理由，我认为是和第一种类似，作者可能认识到代码并不一定是核心竞争力，但是没有构建好护城河的情况下，只能选择将代码作为护城河。\n\n\n\n## 二、代码不是核心竞争力，那什么才是？\n\n在聊真正的核心竞争力之前，我们来聊聊闭源软件的局限性。\n\n我们看看一个闭源的软件的一生：立项的动机可能是某个公司或者个人对于一个市场机会的洞见找到了一个高价值的场景，通过开发一个软件能够很好的提高效率或创造价值，甚至可能就是一张来自甲方的合同，总之这个公司招募了一伙程序员，设计师，产品经理，开始项目的开发。一切顺利的情况，顺利的满足了甲方的需求，甲方也很开心的付钱了，然后这个公司发现，好像这个软件改一改（甚至不用改）也就能够在同行业另一个客户那边卖出去，这就太好了，感觉找到了一条致富路。可是好境不长，客户这边的场景和需求在变化，原来的软件可能不一定能够满足新的需求了，但是开发团队就这几杆枪，稍有不慎一个方向判断错误，可能时间和机会窗口就错过了。这就意味着，对于项目领头人的要求就很高，要求持续能够引领行业的方向。还有一种方式是挑选一个相对狭窄或迭代不快的领域，存活时间能够延长一些。对于甲方也很难受，总是感觉需求的满足慢半拍，甚至对于有些有着研发能力的甲方，因为受限于没有源码，就算知道如何改进，也只能干瞪眼。\n\n其实这个问题的本质在于：闭源软件开发商虽然可能是技术的专家，但是并不一定是业务或者场景的专家，软件进化的速度受限于开发团队和产品经理自己的认知和见识的进化速度，除非开发商强大到能够持续引领整个行业的进化方向，否则无解。\n\n其实这个问题，教员早就给出了答案：「…凡属正确的领导，必须是从群众中来，到群众中去。这就是说，将群众的意见（分散的无系统的意见）集中起来（经过研究，化为集中的系统的意见），又到群众中去作宣传解释，化为群众的意见，使群众坚持下去，见之于行动，并在群众行动中考验这些意见是否正确。然后再从群众中集中起来，再到群众中坚持下去，如此无限循环，一次比一次地更正确、更生动、更丰富…」 — 《关于领导方法的若干问题 32》, 1943\n\n要我说教员放在当代，就算是当个程序员，也能是一个大师级别的。教员的这段话，包含两个关键的点，完美的解释了开源软件的生命力的来源，我下面的详细讲讲。\n\n\n**第一点，开源软件的生命力来自于场景的垄断，而背后更本质的垄断是人才垄断。**\n\n为什么强调从群众中来？回顾刚才我们闭源软件的那段，其实一个关键的点是，软件的初始动机虽然来自于少数人的洞见，但是持续保持洞见并不是一件容易的事情，这就是为什么很多技术团队或者产品团队容易「自嗨」，一旦脱离用户，极易出现这样的问题。闭源软件厂商触及用户的手段不外乎于传统的商业宣传和销售，用户从感兴趣到使用起来的门槛很高，实施的周期也很长，另外通常销售会站在产品团队和客户中间，通过一些信息不对称来获取超额的利润，其中最大的信息不对称就是封闭的源代码本身或者定制化。这导致的问题是，相比流行的开源软件，闭源软件没有办法高效的获取，吸收和理解更多的场景，这对于一个通用的基础软件产品来说通常是一个致命的问题，如果见过的场景不够多，更没有办法判断产品那些需求该做是普遍需求，哪些是伪需求坚决不做，我认为这就是做产品的「触感」。\n\n对于一个流行的开源软件，本身不会有上面提到的问题：因为有足够多的用户，那么一定能看到足够多的场景，也能看到足够多的稀奇古怪的用法，这一个个用户的反馈，修过的一个个 bug，提出的一个个建议，会持续的产生类似「复利」的效果，你的软件越强壮，见过的场景越广，会进一步让你接触到更大的用户群，帮助软件变得更强大，如此循环。实际上开源软件本质上是通过放弃一部分通过信息不对称产生的潜在利润，换取了极其高效的传播和场景触及效率，但是有意思的是，实际上牺牲掉的这些潜在利润大概率也不一定真的牺牲掉，一来可能本身付费能力有限，二来可能实际上这些用户通过宣传站台二次传播或者代码贡献等方式回馈了项目本身。\n\n在上面那个过程中还会产生一个更加厉害的效应：人才的垄断。正所谓「事在人为」，上面提到的场景垄断中种种的技术决策和实践都是人来操作的。一个流行的开源软件在变成事实标准的过程中，一定会培养出大量熟悉这个产品的工程师，用户，摇旗呐喊的粉丝，代码贡献者，甚至挑刺吐槽的人。传统意义上，大家理解的开源社区只是狭义上的开发者社区，只有贡献代码才算参与，但是我认为只要和这个产品发生关联的人，都算是社区的一部分，「人尽其材」才是构建开源社区的终极目标。这个优势是会随着时间的流逝不断累积，这个很好理解，举个例子：A 公司的工程师在 A 公司的工作中学习使用了 TiDB 也很好的解决了问题，然后这个工程师作为数据库专家跳槽到了 B 公司，遇到同样的问题时，你猜他会选什么？\n\n**第二点，迭代，迭代，迭代，只有高速迭代才能立于不败之地**\n\n上面教员的话里面有个关键的点，关于正向循环，也就是迭代。这个道理同样也适用于软件开发，软件从来都不是静止的，随着市场和竞争环境的变化，你今天的竞争优势，很可能明天就不是了。很多人都喜欢用静态的眼光看待问题，热衷于各种方案的横向对比，而忽略了进化速度，在这点上，我可能更看重的是同一个产品的纵向对比，举个例子：目前有 A, B, C三个方案，可能当下看这三个方案差距不大，也许在百分之五十之内。但是如果其中一个开源方案每次和自己半年前比都是在翻倍的提升（背后开源社区推动），但是闭源的方案的进步受限于团队规模和资源。这时候的选择除非是那种火烧眉毛的情况，否则一定应该选择一个迭代速度更快，增长率更好，更代表未来的方案，这个也很好理解。这是人的思维的一个惯性，人总是倾向用线性思维去看待问题，于是对非线性增长的事物往往会习惯性的低估。\n\n说一个更加震撼的例子，我粗略统计了一下，从 2018 到现在，也就短短一年多时间，整个 TiDB 的 SQL 层这么一个项目发生了 30000 多次提交（https://github.com/pingcap/tidb ） ，有接近 60% 的源码被修改。也就是说，每一年的 TiDB 都和上一年是不一样的，是一个更适应当下的，更加进步的一个 TiDB，而且随着社区的不断壮大，迭代的速度会越来越快。我完全不能想象，如果 TiDB 是一个闭源软件，从第一行代码开始写，到现在短短的 5 年时间，如何能够到达现在这个成熟度，这一切都是得益于开源社区的带来的加速度和反复迭代。\n\n\n\n## 三，如何挣钱？未来在云端\n\n刚才我们聊了很多产品哲学上的东西，我们接下来聊聊商业，以及在云时代开源软件的位置。让我们回到开篇提到的那个话题：担心用户拿到代码，就不给钱了。这个观点背后的一个暗示是，用户付费买的是代码，如果有代码，用户就没有其他理由付钱。其实这个结论是靠不住的，客户付费买的是解决问题和创造价值，而不是代码，如果拿到你的代码自己折腾付出的成本大于给你的钱（如果你能如实交付价值的话），用户没有任何理由不付钱。而且这里的成本包括，比较明显的成本，例如人力成本，机器成本。也包括一些经常被人忽略的成本，例如错失市场机会的沉没成本，业务改造迁移成本，学习成本，线上出问题没人懂修带来的风险成本，这些隐性的成本往往是比显性的成本高得多的。\n\n上面我的解释中暗示了一点：软件的价值取决于它解决了什么问题，创造了什么价值，而不是开源与否。举个例子：一个分布式关系性数据库，一定比一个分布式缓存更加有商业价值，这是由前者的应用场景，存储的数据以及提供的能力决定的，而不是开源与否。所以这就是为什么我们要做通用数据库的核心原因，因为价值天花板更高。\n\n还有一点需要强调的，开源并不是一个商业模式，而是一种更好的软件开发和分发模式。另外，我认为商业模式和软件本身一样，也是需要设计的，这个设计取决于产品特性和公司的属性，这就意味着适用于 A 产品的商业模式，不一定适用于 B，甚至同一个产品，不同的公司，可能适合的商业模式都是不一样的。\n\n用我很崇敬的华为公司举个例子，华为是一个很厉害的通信设备制造商，很成功的手机终端厂商，很成功的硬件厂商。卖通信设备，卖手机，卖服务器，大家发现共性了吗？ 华为很会卖硬件和盒子，巨大的商业成功带来了很大的惯性，硬件和通讯设备的市场的特点是：各家产品本身能力差不太多（至少没有代差），比拼的是满足客户其他需求的能力以及低价（例如：服务，更快的响应，充分的定制化）。所以不难理解，华为软件的思路会通过低价甚至软件免费进入客户场景，然后通过硬件获取利润的商业模式。这个模式的问题在于，客户不能多，一旦战线拉得太长，项目的预算和硬件的利润都没有办法的抹平定制化软件的研发成本和支持成本时，这个模式就会出现问题。\n\n我认为如果想要通过软件创造可规模化的持续利润，需要两个关键点：\n\n1. 生态，软件能形成生态或者和现有生态有机整合，由生态补齐单一产品的能力，从而才能进一步能形成解决方案。\n2. 渠道，高效的分发渠道和支持渠道，这确保在用户规模化后，作为厂商的销售和售后成本不会随着客户的增长而增长（至少成本增长的斜率需要更缓）。\n两者缺一不可。对于第一点，开源软件构建生态是很天然的，开发者和解决方案提供商会很自然的通过不同开源软件的组合做到解决方案的覆盖，这个效率是闭源定制化软件很难跟上的，这点不赘述。\n\n第二点，其实理想的渠道就是云。云标准化了硬件，标准化了计算力，甚至标准化了计算力的交付方式，尤其是公有云。一切都是标准化的好处就是可以自动化，这个对于软件供应商来说才是真正的价值。\n\n所以开源 + 云的模式，在开源这端，完成了开发者的心智占领和解决方案的成型，然后在云这端完成极其高效的分发和价值传递。看上去很美不是吗？理论上确实没问题，但是一定会有朋友挑战我说：这个模式里面没有你们开源软件厂商什么事情啊？云为什么不自己提供开源软件服务？这几年沸沸扬扬的 AWS 吸血事件逼得一堆开源公司和项目改协议，就是一个例子呀。\n\n关于这个问题，我的看法可能和主流观点有点不一样：\n\n**Cloud is eating Open-source? No, Open-source is eating the cloud.**\n\n\n云厂商就像当年的运营商一样，占据着和客户对接的第一位置，当然很自然的在关键路径上放自家的产品。但是移动梦网和飞信的故事后来大家都看到了，拿飞信做一个例子，大家还记得作为移动的飞信，当年是没有办法和联通电信的手机号码互通的，直到后来微信的出现，终于事实上打通了各个运营商，所以市场格局就出现了很明显的分水岭，运营商是谁不重要，只要保证网络通信号好就行。对于云也是一样，AWS 肯定不会为 GCP 提供舒服的迁移和打通方案，反过来也不可能，但是对于客户来说，这个选择就像逼着用户选移动的飞信还是联通的沃友一样（我猜你可能都没听说过沃友吧 ），用户肯定说：不好意思，两个都不要，我选微信。从另一方面来说，对于在云上提供开源软件服务这件事情，云厂商本身的投入其实不一定有这个开源项目背后的公司多，一个很好的例子是 Databricks 是 Spark 创始团队的公司，也是一个 100% 在 AWS 上提供 Spark 服务的公司，相比起 AWS 的官方 EMR，Databricks 完全不占下风甚至客户和产品都胜过原生的 EMR。就像飞信的开发团队的质量肯定没有微信高，是一样的。\n\n**由于开源软件的中立性，使得开源软件成为用户在多个云厂商之间保持统一体验和统一服务的几乎唯一选项**。因为开源软件和开源服务商的存在，市场我相信会进入一个平衡：云厂商会持续优化它擅长的东西，真正的将云基础能力变成水电煤一样的规模化生意，开源软件厂商基于云的标准基础设施构建服务并交付业务价值，开源软件项目和社区由于厂商的持续持续，不断的蓬勃发展，占领更多用户的心智。三者形成一个价值链的闭环。不要着急，让子弹飞一会儿。\n\n洋洋洒洒写了几千字，聊了聊开源，最后我想用一段《大教堂与集市》书里我很喜欢的一句话作为结尾：\n\n>…通常，那些最有突破性和最有创新力的解决方案来自于你认识到你对问题的基本观念是错的…","image":{"alt":" ","media":{"url":"https://img1.www.pingcap.com/prod/img_insight_1_87e27ae169.jpg"}},"lable":"技术趋势","title":"大教堂终将倒下，但集市永存","description":"作为一个在中国的数据库软件从业者，我始终坚信：基础软件，未来只有开源一条路。如果不开源，或者说内核不开源的话，产品的生命力是有限的。开源软件的生命力来自于场景的垄断，而背后更本质的垄断是人才垄断。"}},{"node":{"id":"Insights_5","customUrl":"from-big-data-to-database","type":"detail","body":"作为一个从大数据转行做数据库的人，我自以为能感受到两个世界的异同。在这里，斗胆聊下这个话题，以及对未来的看法。\n\n## 大数据兴起\n\n从 70 年代关系型数据库进入历史舞台，很长一段时间它几乎是包打天下的选择。你很可能可以用一套数据库玩转所有业务，你也不需要一个连的工程师来维护她。哪怕你也许业务复杂，需要不同的数据库，但她们终究是还是数据库，温柔体贴。\n\n这个黄金时代整整延续了 20 多年。\n\n上世纪 90 年代人们开始讨论「Big Data」。SGI 首席科学家 John Mashey 在一个名为「[Big Data… and the Next Wave of Infrastress](https://static.usenix.org/event/usenix99/invited_talks/mashey.pdf)」让这个词汇变得流行。那个时候，人们讨论着硬盘容量和网络带宽，在未来数据爆炸的阴影下瑟瑟发抖。那个时候，互联网公司是第一批真正尝试解决大数据问题的先行者。有别传统的运营方式让它们率先面对了大数据时代著名的 [3V 问题](https://www.gartner.com/en/blog)（By Gartner）。\n\n- 容量（Volumn）：爆炸性的交易量带来爆炸性的数据容量。\n- 速度（Velocity）：和在这个规模下仍提供高速的数据应用。\n- 多样性（Variety）: 以及为了支持业务变更和复杂性所造成的数据多样性。\n\n与传统公司不同，互联网公司的数据单位价值偏低，但数据量极其庞大。而且它们并不一定是结构化的，并非完全能用 SQL 来处理。简而言之，它们已经超出了当时数据库的能力边界。而当时的互联网公司巨头们如 Google 和 Amazon，纷纷选择抛弃了传统手段，重起炉灶，由此拉开了「大数据」时代的大幕。\n\n有兴趣的童鞋，可以翻翻下面的论文：\n\n- [The Google File System](https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf) - 2003\n- [MapReduce: Simplified Data Processing on Large Clusters](https://static.googleusercontent.com/media/research.google.com/en//archive/mapreduce-osdi04.pdf) - 2004\n- [Bigtable: A Distributed Storage System for Structured Data](https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdf) - 2006\n- [Dynamo: Amazon’s Highly Available Key-value Store](https://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf) - 2007\n\n也许你并不了解 GFS，Google 内的 MapReduce 或者 BigTable 具体是什么样子的。不过相信既然你看到了这里，你一定听说过 Apache Hadoop 和 NoSQL。Hadoop 加上属于 NoSQL 的 HBase，就是以上面 Google 的几篇论文为基础开发而成的。这是一个真正现象级的开源通用大规模分布式数据存储和处理套件。它的影响力是巨大的，稍具规模的互联网公司就不得不用，稍有经验的从业者就可以领取不菲的薪水，人人都以能向其提交一个补丁为荣，更不用提一个实打实的 Committer，你都可以从他脑后看到光环。不管现在多少人宣称 Hadoop 已死，XXX 是真理，但是以 Hadoop + NoSQL 为基础，所谓大数据基础架构所带来的想法变迁，一直延续到了今天，且并没有太大变化：\n\n- 选用白菜价的硬件组成集群，突出 Scale Out 而非 Scale Up。\n- 极度简化和粗暴的计算模型。\n- 几乎不经整理的存储格式，在多种引擎之间共享，所谓数据湖。\n- 忽略 / 弱化一致性，抛弃关系模型，简化甚至无视事务，所谓 NoSQL。\n\n你可以说这是开源社区的威力，但追根究底还是 Google，Amazon 这些先行者卓有远见的工作为大家铺平了道路。不过，有些反直觉的是：这些引用数几千几万的论文其实并没有提出巧夺天工的设计；相反，它们本质上是告诉了业界，把数据库换成设计如此粗糙狂野的架构，仍然可以解决问题：就算你没钱买超高端的软硬件，只要你放宽心，告诉自己，无视一致性，忘掉精巧的优化执行器和存储结构，忽略半结构化带来的混乱，干掉 SQL 语言，多雇几个码农，你仍然活的下去，而且可以活的还不错。\n\n这些到底为我们带来了什么？且看曾经非常著名的 Sort Benchmark。\n\n- 2004 年，NEC Express 5800 / 1320 Xd 单机，价格可能介于 200-600 万 USD 之间，1 分钟排序 34G。\n- 2006 年，Fujitsu PrimeQuest 480 单机，2 年将结果推高 6G，1 分钟排序 40G 数据；机器价格不可考。\n- 2007 年，麻省理工林肯国防实验室，Bradley C. Kuszmaul 使用 TX-2500 磁盘集群（550 万 + USD），440 节点用 Infiband 串联，使用了自制系统（文件系统，通信模块），在经历了无数硬件软件故障之后，一分钟内排序了 214GB 数据；该试验相比之前的超豪华服务器，已经开始使用「便宜硬件」，但是使用自制软件系统。\n- 2009年，Yahoo! 使用 Hadoop 以近似的总价（500 万 USD，以单价反推）但近 1/3 的单价串联了 1400 个白菜价节点集群，得到了一倍多的速度，排序了 500G。而这里 1400 的节点数是为了凑整 500G / 1 分钟，而非只能这么多或者必须这么多。\n\n请允许我用一句诗来总结它的意义：「旧时王谢堂前燕，飞入寻常百姓家」。\n\n\n\n## 王之蔑视\n\n与业界的欢腾不同，当时数据库研究者圈子对此的反应已经不是嗤之以鼻，而是痛心疾首了。这有点像，老师傅练了一辈子武艺，你突然告诉他，打架只要抡大锤就行了。\n\n[MapReduce: A major step backwards](https://homes.cs.washington.edu/~billhowe/mapreduce_a_major_step_backwards.html) by David DeWitt & Michael Stonebraker\n\n上面这篇文章是 DeWitt 和 Stonebraker 大神合写的对 MapReduce 的批评。这两尊是真神，DeWitt 是美国工程院院士，微软 Jim Gray 实验室老大，而石破天，则是图灵奖获得者。在他们看来，这破玩意抛弃了数据库所有美好的特点，实现也丑陋，还接不上数据库工具，简直臭不可闻。文末，老人家们「酸酸」地说，我们很高兴看到社区对这些技术感兴趣，但是也别把我们几十年的研究成果当 X 啊。\n\n两位的评论，哪怕延伸到整个大数据生态，就算放到时隔多年的今天，也还是套的上去。但这套糙快猛的理念催生的技术栈，已经无需赘述获得了多大的成功。哪怕是数据库圈内的人，也时有抱怨：老一辈的人有时候不够 Open-Minded。所以，他们说错了么？\n\n也许他们对业界面临的困扰不够感同身受，也许他们不够有包容心。不过，他们对技术的判断着实是精准到位的。\n\n事实上，没过多久，人们在大数据体系中引入了 SQL、MPP 引擎、列存，加入了向量化、JIT，实现了 CBO。对于数据库圈外的童鞋们，有时你看社区兴高采烈地宣称，他们实现了多么神奇的技术，仿佛普罗米修斯从天上带来了火种，其实他们只是从十几甚至几十年前的故纸堆中汲取了养分。\n\n是大数据社区的人无知无能因此重新「发明」数据库界玩烂的技术么？不，只是因为业界等不了数据库圈子慢慢悠悠匠心打磨：没有合适的工具，他们每分每秒都在损失 $。且不说大规模分布式交易型数据库一直是老大难，就算脱开交易型场景不谈，分布式的分析型数据库早已有之，却也因为包袱沉重，还没来得及跟上时代的步伐，就被大数据的浪头打的狼狈不堪。Pivotal 先是由 Greenplum 折腾了对接 Hadoop 的 HAWQ ，继而被迫双双开源；就连 Teradata 这样的巨擘也不得不支持 Hadoop。\n\n只是，一旦社区步入小康，虽是野蛮生长的生态，也还是阻挡不了人们追求小资生活的决心：用户希望友好、快速、高效、稳定的数据存储和处理手段，这是亘古不变的需求。而这些，恰恰是数据库领域多年积累所在。\n![洞见-ma2.png](https://img1.www.pingcap.com/prod/ma2_cd45f7ea56.png)\n<center>摘自 pramodgampa.blogspot.com</center>\n\n现今的大数据生态，如同哥斯拉，强大而难以驯服。不管什么场景，似乎都经不起它尾巴一扫。但若说干净灵巧地解决问题，却是难如登天。毕竟狂野粗放基因的产物，不管如何演化，都很难优雅起来。对数据湖而言，开放形态加上公共存储格式，能轻易串联多种引擎，但也几乎抹杀了精细整理数据的可能；而混沌的存储体系和不受控的数据入口，也限制了整个体系可以伸展腾挪的空间。对 NoSQL 而言，孱弱或者干脆不存在的事务，所谓最终一致性，小儿科的 SQL 支持，也都成为人们诟病的理由。而整个圈子野蛮生长的开放体系，在得到巨大动能的同时，也使得用户体验几乎不可能良好。这些种种，使得大数据生态很大程度上都只服务于工程师，而你需要一大票专家才能真的驯服大数据平台。从这个角度看，MapR 变卖家当给 HP，Hortonworks 被收购，Cloudera 巨亏股价狂泻，都是必然的：大数据生态基本不可能做成类似 Oracle 这样的标准件生意。\n\n也许，更偏向于数据库形态的方案，才是更友善的方案；也许，随着技术的成熟，我们还有机会回到黄金时代。\n\n\n## 回归数据库\n\n随着时间的推进，Google 这样的巨人自己也忍受不了自己创造的怪物，又开始了新的探索：哪怕是 Google 这样聪明脑袋汇聚的地方，也不想总是需要自己花心思处理一致性，或者用繁琐的代码实现 SQL 逻辑。\n\n[Spanner: Google’s Globally-Distributed Database](https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf) - 2012\n\nSpanner 是一个能像 NoSQL 一样延展（甚至横跨多个大陆），但却支持传统数据库事务的分布式交易型数据库。它创造性地用原子钟解决了以往分布式事务一致性需要依赖中心节点，因而无法大规模扩展的问题。这算是拉开了所谓 NewSQL 的大幕。这启发了很多项目，比如小强，比如我们的 TiDB。她们拥有对业务透明的 Sharding 设计和分布式事务，良好的可扩容性，又兼顾了一致性，这让分布式体系很大程度上拥有单机数据库近似的用户体验。不过有意思的是，哪怕论文最创新的点是基于原子钟的分布式事务，但是对很多人来说，它更大的意义仍然是：证明给一个类似 NoSQL 架构加上传统数据库特性，用来做传统数据库业务，是可行的（当然共识算法 Paxos / Raft 的应用也很重要）。天知道这背后经历了多少试错，这就是先行者的伟大。\n\n至此，业界也许可以说解决了整个体系中最难啃的问题：分布式交易型数据库。而随着技术不断成熟，人们也逐渐开始接受这个新鲜事物：光就 TiDB 而言，从第一个用户拿来做并不那么 TP 的边缘业务，到现在登上银行核心系统。也许你在刷二维码付费的时候，背后支撑你这笔交易的数据库就是 TiDB。\n\n对我们来说，现有的 Multi-Raft 体系，提供了可自由伸缩，对用户透明的分片体系，以及可均衡的并行复制机制。以这些为基础，通过 Raft Learner 将数据从 TP 行存到 AP 列存进行异步异构复制但提供一致性读取，我们得以整合了 TP 和 ODS 层，而且互相之间不影响，这就是今年我们折腾的 TiFlash。希望明年能尝试进一步同样通过 Raft 协议将列存引擎延伸到传统的数仓业务，而统一更多场景。很多人不相信最终数据库能做到一站式服务（Silver Bullet），能简化到一个产品，去除平台间数据的迁移。毕竟，有些设计的取舍很难兼顾。我个人的看法是，也许，但通过小心的设计，我们现在已经可以做到将不同的引擎无缝地整合到一个产品中。毕竟，经过这十多年的大数据浪潮，哪怕浪不再那么高，社区终究沉淀下了宝贵的财富，前人设计的得失也好，强大的开源引擎如 Spark 也好（Spark 已经慢慢脱离野蛮生态直通云霄了），甚至更多有经验的小伙伴也好，这都成为我们能借力的抓手，让我们能有勇气挑战似乎不切实际的目标：让用户从大数据生态复杂的技术栈解放出来，让数据平台收敛到单一一个产品，因为这才是数据处理应有的模样，哪怕这是一条很长很长的路。","image":{"alt":" ","media":{"url":"https://img1.www.pingcap.com/prod/img_insight_2_c5e1128bab.jpg"}},"lable":"技术趋势","title":"从大数据到数据库","description":"让用户从大数据生态复杂的技术栈解放出来，让数据平台收敛到单一一个产品，因为这才是数据处理应有的模样，哪怕这是一条很长很长的路。"}},{"node":{"id":"Insights_3","customUrl":"philosophy-of-tidb-architecture-evolution","type":"detail","body":"大家可能知道我是 PingCAP CEO，但是不知道的是，我也是 PingCAP 的产品经理，应该也是最大的产品经理，是对于产品重大特性具有一票否决权的人。中国有一类产品经理是这样的，别人有的功能我们统统都要有，别人没有的功能，我们也统统都要有，所以大家看到传统的国内好多产品就是一个超级巨无霸，功能巨多、巨难用。所以我在 PingCAP 的一个重要职责是排除掉“看起来应该需要但实际上不需要”的那些功能，保证我们的产品足够的专注、足够聚焦，同时又具有足够的弹性。\n\n## 一、最初的三个基本信念\n本次分享题目是《TiDB 的架构演进哲学》，既然讲哲学那肯定有故事和教训，否则哲学从哪儿来呢？但从另外的角度来说，一般大家来讲哲学就先得有信念。有一个内容特别扯的美剧叫做《美国众神》，里面核心的一条思路是“你相信什么你就是什么”。其实人类这么多年来，基本上也是朝这条线路在走的，人类对于未知的东西很难做一个很精确的推导，这时信念就变得非常重要了。\n![图1 最初的基本信念](https://img1.www.pingcap.com/prod/31_efc85e5d7a.png)\n      \n\n实际上，我们开始做 TiDB 这个产品的时候，第一个信念就是相信云是未来。当年 K8s 还没火，我们就坚定的拥抱了 K8s。第二是不依赖特定硬件、特定的云厂商，也就是说 TiDB 的设计方向是希望可以 Run 在所有环境上面，包括公有云私有云等等。第三是能支持多种硬件，大家都知道我们支持 X86、AMD64、ARM 等等，可能大家不清楚的是 MIPS，MIPS 典型代表是龙芯，除此之外，TiDB 未来还可以在 GPU 上跑（TiFlash 的后续工作会支持 GPU）。\n\n## 二、早期用户故事\n### 2.1 Make it work\n有一句话大概是“眼睛里面写满了故事，脸上没有一点沧桑”，其实现实是残酷的，岁月一定会给你沧桑的。我们早期的时候，也有相对比较难的时候，这时候就有一些故事关于我们怎么去经历、怎么渡过的。  \n\n首先大家做产品之前肯定先做用户调研，这是通用的流程，我们当初也做过这个事，跟用户聊。我们通常会说：“我们要做一个分布式数据库，自动弹性伸缩，能解决分库分表的问题，你会用吗？”用户说“那肯定啊，现在的分库分表太痛苦了。”这是最初我们获取需求最普通的方式，也是我们最容易掉入陷阱的方式，就好像“我有一百万，你要不要？肯定要。”“我有一瓶水，喝了之后就健康无比，延年益寿你要不要？肯定要。”很容易就得到类似的结论。\n\n所以这个一句话结论的代价是我们进行了长达两年的开发。在这两年的时间里，我们确定了很多的技术方向，比如最初 TiDB 就决定是分层的。很显然一个复杂的系统如果没有分层，基本上没有办法很好的控制规模和复杂度。TiDB 分两层，一层是 SQL 层，一层是 key-value 层，那么到底先从哪一个层开始写呢？其实从哪层开始都可以，但是总要有一个先后，如何选择？\n\n这里就涉及到 TiDB 的第一条哲学。我们做一个产品的时候会不断面临选择，那每次选择的时候核心指导思想是什么？核心思想是能一直指导我们持续往前去迭代，所以我们第一条哲学就是：**永远站在离用户更近的地方去考虑问题**。\n\n为什么我们会定义这样一条哲学？因为离用户越近越能更快的得到用户的反馈，更快的验证你的想法是不是可行的。显然 SQL 层离用户更近，所以我们选择从 SQL 层写起。其实一直到现在，绝大多数用户用 TiDB 的时候根本感受不到 KV 层的存在，用户写的都是 SQL，至于底层存储引擎换成了别的，或者底层的 RocksDB 做了很多优化和改进，这些变化对于用户关注的接口来说是不可见的。\n\n选择从 SQL 层开始写之后，接下来面临的问题就是怎么做测试，怎么去更好的做验证，怎么让整个架构，先能够完整跑起来。\n\n在软件开发领域有一条非常经典的哲学：「**Make it work, make it right, make it fast**」。我想大家每一个学软件开发的人，或者每一个学计算机的人可能都听过这样一句话。所以当时我们就做另外一个决定，先在已有的 KV 上面构建出一个原形，用最短的时间让整个系统能够先能 work。\n\n我们在 2015 年的 9 月份开源了第一个版本，当时是没有存储层的，需要接在 HBase 上。当这个系统能跑起来之后，我们的第一想法是赶紧找到当初调研时说要用的那些用户，看看他们是什么想法，尽快的去验证我们的想法是不是可行的。因为很多人做产品思维属于自嗨型，“我做的东西最厉害，只要一推出去肯定一群人蜂拥而至。”抱有这种想法的人太多了，实际上，只有尽快去验证才是唯一的解决之道，避免产品走入误区。\n![图 2 与调研用户第二次对话](https://img1.www.pingcap.com/prod/32_f0feeb053f.png)\n\n\n然而当我跟用户讲，你需要先装一个 Hadoop，可能还要装一组 Zookeeper，但用户说：“**我只想要一个更强大的 MySQL，但是让我装这一堆东西，你是解决问题还是引入问题**？”\n\n这个问题有什么解决办法呢？一个办法是你去解决用户，可以通过销售或者通过某些关系跟用户聊，显然这是一个不靠谱的思路。作为一个产品型的公司，我们很快就否了这个想法。用户的本质要求是：你不要给我装一堆的东西，要真正解决我的问题。所以我们马上开始启动分布式 KV 的开发工作，彻底解决掉这个问题，满足用户的要求。\n![图 3 开发 TiKV 前的技术考量](https://img1.www.pingcap.com/prod/33_e9fc116b23.png)\n\n开始开发 KV 层时候又会面临很多技术选择，我们有很多考量（如图 3）。\n\n**第一点，我们认为作为数据库最重要的是正确性**。 假设这个数据库要用在金融行业，用在银行、保险、证券，和其他一些非常关键的场合的时候，正确性就是无比重要的东西。没有人会用一个不正确的数据库。\n\n**第二点是实现简洁、易用**。 用户对于一个不简洁、不易用的东西是无法接受的，所以我们当时的一个想法是一定要做得比 HBase 更加易用，代码量也要比 HBase 小，所以时至今天 TiDB 代码量仍然是比 HBase 小得多，大约还不到 HBase 的十分之一。\n\n**第三点考虑是扩展性**。 TiDB 不仅在整体上是分层的，在存储层 TiKV 内部也是分层的，所以有非常好的扩展性，也支持 Raw KV API、Transaction API，这个设计后来也收获了很多用户的支持，比如一点资讯的同学就是用的 Raw KV API。\n\n**第四点就是要求高性能低延迟**。 大家对于数据库的性能和延迟的追求是没有止境的，但是我们当时并没有把太多精力花在高性能低延迟上。刚才说到我们有一条哲学是「Make it work, make it right, make it fast」，大家可以看到这句话里面 「Fast」是放最后的，这一点也是 TiDB 和其他产品有非常大的差异的地方。作为一个技术人员，通常大家看一个产品好不好，就会想：“来，不服跑个分，产品架构、易用性、技术文档、Community 这些指标都不看，先跑个分让大家看看行不行”。这个思路真正往市场上去推时是不对的。很多事情的选择是一个综合的过程。你可以让你的汽车跑的巨快无比，上面东西全拆了就留一个发动机和四个轮子，那肯定也是跑得巨快，重量轻，而且还是敞篷车，但没有一个人会在路上用的。同样的，选择 Rust 也是综合考量的结果。我们看中了 Rust 这个非常具有潜力的语言。当时 Rust 没有发布 1.0，还不是一个 stable 版本，但我们相信它会有 1.0。大概过了几个月，Rust 就发布了 1.0 版本，证明我们的选择还是非常正确的。\n\n**最后一点就是稳定性**。 作为一个分布式数据库，每一层的稳定性都非常重要。最底下的一个存储引擎，我们选择了非常稳定的 RocksDB。不过后来我们也查到几个 RocksDB 掉数据的 Bug。这也是做数据库或者说做基础产品的残酷性，我们在做产品的过程中找到了 Rust 编译器的 Bug，XFS 掉数据的 Bug，RocksDB 掉数据的 Bug，好像几大基础组件的 Bug 都聚在这里开会。\n\n接着我们辛辛苦苦干了三个月，然后就开源了 TiKV，所以这时候看起来没有那么多的组件了。我们也不忘初心，又去找了我们当初那个用户，说我们做了一些改进，你要不要试一试。\n![图 4 与调研用户第三次对话](https://img1.www.pingcap.com/prod/34_a2531f574b.png)\n\n\n但是用户这时候给了一个让我们非常伤心非常难受的回答：没有，我们不敢上线，虽然你们的产品听起来挺好的，但是数据库后面有很大的责任，心理上的担心确实是过不去。于是我们回去开始加班加点写 TiDB Binlog，让用户可以把 binlog 同步给 MySQL。**毕竟用户需要一个 Backup：万一 TiDB 挂了怎么办，我需要切回 MySQL，这样才放心，因为数据是核心资产**。\n![图 5 第一个上线用户的架构图](https://img1.www.pingcap.com/prod/35_ba46d9a2b5.png)\n\n\n所以最终我们第一个用户上线的时候，整个 TiDB 的架构是这样的（如图 5）。用户通过 Client 连上 TiDB，然后 TiDB 后面就通过 Binlog 同步到 MySQL。后来过了一段时间，用户就把后面的 MySQL 撤了。我们当时挺好奇为什么撤了，用户说，第一个原因是后面 MySQL 撑不起一个集群给它回吐 Binlog，第二就是用了一段时间觉得 TiDB 挺稳定的，然后就不需要 Binlog 备份了。\n\n其实第一个用户上线的时候，数据量并不算大，大概 800G 的数据，使用场景是 OLTP 为主，有少量的复杂分析和运算，但这少量的复杂分析运算是当时他们选择 TiDB 最重要的原因。因为当时他们需要每隔几分钟算一个图出来，如果是在 MySQL 上面跑，大约需要十几分钟，但他们需要每隔几分钟打一个点，后来突然发现第二天才能把前一天的点都打出来，这对于一个实时的系统来说就很不现实了。虽然这个应用实践只有少部分运算，但也是偏 OLAP，我记得 TiDB 也不算特别快，大概是十几秒钟，因为支持了一个并行的 Hash Join。\n\n**不管怎样，这个时候终于有第一个用户能证明我们做到了「Make it work」**。\n\n### 2.2 Make it right\n接下来就是「Make it right」。大家可能想象不到做一个保证正确性的数据库这件事情有多么难，这是一个巨大的挑战，也有巨大的工作量，是从理论到实践的距离。\n![图 6 理论到实践的距离](https://img1.www.pingcap.com/prod/36_275a5517ee.png)\n\n\n#### 2.2.1 TLA+ 证明\n大家可能会想写程序跟理论有什么关系？其实在分布式数据库领域是有一套方法论的。这个方法论要求先实现正确性，而实现正确的前提是有一个形式化的证明。为了保证整个系统的理论正确，我们把所有的核心算法都用 TLA+ 写了一遍证明，并且把这个证明 [开源](https://github.com/pingcap/tla-plus) 出去了，如果大家感兴趣可以翻看一下。以前写程序的时候，大家很少想到先证明一下算法是对的，然后再把算法变成一个程序，其实今天还有很多数据库厂商没有做这件事。\n\n#### 2.2.2 千万级别测试用例\n在理论上保证正确性之后，下一步是在现实中测试验证。这时只有一个办法就是用非常庞大的测试用例做测试。大家通常自己做测试的时候，测试用例应该很少能达到十万级的规模，而我们现在测试用例的规模是以千万为单位的。当然如果以千万为单位的测试用例靠纯手写不太现实，好在我们兼容了 MySQL 协议，可以直接从 MySQL 的测试用例里收集一些。这样就能很快验证整个系统是否具备正确性。\n\n这些测试用例包括应用、框架、管理工具等等。比如有很多应用程序是依赖 MySQL，那直接拿这个应用程序在 TiDB 上跑一下，就知道 TiDB 跟 MySQL 的兼容没问题，如 Wordpress、无数的 ORM 等等。还有一些 MySQL 的管理工具可以拿来测试，比如 Navicat、PHP admin 等。另外我们把公司内部在用的 Confluence、Jira 后面接的 MySQL 都换成了 TiDB，虽然说规模不大，但是我们是希望在应用这块有足够的测试，同时自己「Eat dog food」。\n\n#### 2.2.3 7*24 的错误注入测试用例\n这些工作看起来已经挺多的了，但实际上还有一块工作比较消耗精力，叫 7*24 的错误注入测试。最早我们也不知道这个测试这么花钱，我们现在测试的集群已经是几百台服务器了。如果创业的时候就知道需要这么多服务器测试，我们可能就不创业了，好像天使轮的融资都不够买服务器的。不过好在这个事是一步一步买起来，刚开始我们也没有买这么多测试服务器，后来随着规模的扩大，不断的在增加这块的投入。\n\n大家可能到这儿的时候还是没有一个直观的感受，说这么多测试用例，到底是一个什么样的感受。我们可以对比看一下行业巨头 Oracle 是怎么干的。\n![图 7 前 Oracle 员工的描述](https://img1.www.pingcap.com/prod/37_78c7adea54.png)\n\n\n这是一篇 [在 HackNews上面的讨论](https://news.ycombinator.com/item?id=18442941&utm_source=wanqu.co&utm_campaign=Wanqu+Daily&utm_medium=website)，讨论的问题是：你觉得这个最坏的、规模最大的代码是什么样子的？下面就有一个 Oracle 的前员工就介绍了 Oracle Database 12.2 这个版本的情况。他说这个整体的源代码接近 2500 万行 C 代码，可能大家维护 25 万行 C 代码的时候就会痛不欲生了，可以想想维护这么多代码的是一种什么样的感受。到现在为止，TiDB 的代码应该还不到 25 万行。当然 TiDB 的功能远远没有 Oracle 那么多，Oracle 的功能其实是很多的，历史积累一直往上加，加的很凶。\n\n这位 Oracle 前员工介绍了自己在 Oracle 的开发工作的流程，如下图：\n![图 8  Oracle 开发者 fix bug 的过程](https://img1.www.pingcap.com/prod/38_ff048f551d.png)\n\n\n比如用户报了一个 Bug，然后他开始 fix。第一件事是花两周左右的时间去理解 20 个不同的 flag，看看有没有可能因为内部乱七八糟的原因来造成这个 Bug。大家可能不知道 MySQL 有多少变量，我刚做 TiDB 的时候也不知道，当时我觉得自己是懂数据库的，后来去看了一下 MySQL 的 flag 的变量数就惊呆了，但看到 Oracle 的 flag 变量数，那不是惊呆了，是绝望了。大家可能知道开启 1 个 flag 的时候会对什么东西有影响，但是要去理解 20 个 flag 开启时和另外几个 flag 组合的时候都有什么影响，可能会崩溃。所以其实精通 Oracle 这件事情，实际上可能比精通 C++ 这件事情更困难的。一个 Oracle 开发者在内部处理这件事情都这么复杂，更何况是外面的用户。但 Oracle 确实是功能很强大。\n\n说回这位前 Oracle 员工的描述，他接着添加了更多的 flag 处理一个新的用户场景的问题，然后加强代码，最后改完以后会提交一个测试。先在 100 到 200 台机器上面把这个 Oracle 给 build 出来，然后再对这个 Oracle 去做新的测试。他应该对 Oracle 的测试用例的实际数量了解不深刻，我猜他可能不知道 Oracle 有多少个测试，所以写的是 “millions of tests”，这显然太低估了 Oracle 的测试数量。通常情况下，只会看到挂了的测试，看不到全部的测试数量。\n\n下面的步骤更有意思了：Go home，因为整个测试需要 20-30 个小时，跑完之后测试系统反馈了一个报告：挂了 200 多个 test，更茫然的是这 200 tests 他以前都没见过，这也是 Oracle 非常强大的一个地方，如果一个开发者的代码提交过去挂掉一两百个测试，是很正常的事情，因为 Oracle 的测试能 Cover 东西非常多，是这么多年来非常强大的积累，不停的堆功能的同时就不停的堆测试，当然也不停的堆 flag。所以从另一个角度来看，限制一个系统的功能数量，对于维护来说是非常重要的。\n\n总之，看完这个回复之后，我对行业前辈们充满了敬畏之情。\n\n### 2.3 Make it fast\n#### 2.3.1 新问题\n随着 TiDB 有用户开始上线，用户的数量和规模越来越大，这时候就出现了一个很有意思的事情，一部分用户把 TiDB 当成了可以支持事务、拥有良好实时性的数据仓库在用，和我们说：我们把公司 Hadoop 换了，数据量十几 T。\n\n我们就一下开始陷入了深深的思考，因为 TiDB 本来设计的目的不是这个方向，我们想做一个分布式 OLTP 数据库，并没有想说我们要做一个 Data Warehouse。但是用户的理由让我们觉得也很有道理，无法反驳——TiDB 兼容 MySQL，会 MySQL 的人很多，更好招人，最重要的是 Hadoop 跑得还不够快。\n\n虽然我们自己也很吃惊，但这体现了 TiDB 另一方面的价值，所以我们继续问用户还有什么痛点。用户表示还有一部分查询不够快，数据没办法做到 shuffle，而且以前用 Spark，TiDB 好像没有 Spark 的支持。\n\n我们想了想，TiDB 直接连 Spark 也是可以的，但这样 Spark 对底下没有感知，事务跑得巨慢，就跟 Spark 接 MySQL 没什么差别。我们研究了一下，做出了一个新的东西——TiSpark。TiSpark 就开始能够同时在 TiDB 上去跑 OLAP 和 OLTP。\n![图 9 出现的新问题](https://img1.www.pingcap.com/prod/39_6bf260df2a.png)\n\n\n就在我们准备改进 TiDB 的数据分析能力的时候，突然又有一大批 TP 用户上线了，给我们报了一堆问题，比如执行计划不准确，选不到最优执行计划，数据热点分布不均匀，Raft store 单线程写入瓶颈，报表跑的慢等等……于是我们制定了 1.0 到 2.X 的计划，先把用户提的这些问题一一解决。\n\n**这里有另外一条哲学：将用户遇到的问题放在第一优先级。我们从产品最初设计和之后 Roadmap 计划永远是按照这个原则去做的**。\n\n**首先，执行计划不准确的问题**。 最简单有效的解决办法是加一个 Index Hint，就像是“你告诉我怎么执行，我就怎么执行，我自己不会自作聪明的选择”。但这不是长久之计，因为用户可能是在一个界面上选择各种条件、参数等等，最后拼成一个 SQL，他们自己没办法在里面加 Index Hint。我们不能决定用户的使用习惯，所以从这时开始，我们决定从 RBO（Rule Based Optimizer）演进到 CBO（Cost Based Optimizer），这条路也走了非常久，而且还在持续进行。\n\n**第二个是热点数据处理问题**。 我们推出了一个热点调度器，这个可能大家在分布式数据库领域第一次听说，数据库领域应该是 PingCAP 首创。 热点调度器会统计、监控整个系统热点情况，再把这些热点做一个快速迁移和平衡，比如整个系统有 10 个热点，某一个机器上有 6 个热点，这台机器就会很卡，这时热点调度器会开始将热点打散，快速分散到集群的其他机器上去，从而让整个集群的机器都处于比较正常的负载状态。\n\n**第三个就是解决 Raft store 单线程瓶颈的问题**。为了改变 Raft store 单线程，我们大概花了一年多的时间，目前已经在 TiDB 3.0 里实现了。我们将 Raft store 线程更多耗时的计算变成异步操作，offload 到其它线程。不知道有没有人会好奇为什么这个改进会花这么长时间？我们一直认为数据库的稳定性第一位的。分布式系统里面一致性协议本身也复杂，虽然说 Raft 是比 Paxos 要简单，但它实际做起来也很复杂，要在一个复杂系统里支持多线程，并且还要做优化，尽可能让这个 I/O 能 group 到一起，其实非常耗精力。\n\n**第四个就是解决报表跑得慢的问题**，这个骨头特别硬，我们也是啃到今天还在继续。首先要大幅提升 TiDB 在分析场景下的能力。大家都可以看到我们在发布每一个版本的时候，都会给出与上一个版本的 TPC-H 性能对比（TPC-H 是一个有非常多的复杂查询、大量运算的场景）。其次就是高度并行化，充分利用多核，并提供参数控制，这个特性可能很多用户不知道，我们可以配一下参数，就让 TiDB 有多个并发在底层做 Scan。\n\n解决完这些问题，我们终于觉得可以喘口气了，但喘气的时间就不到一个星期，很快又有很多用户的反馈开始把我们淹没了。因为随着用户规模的扩大，用户反馈问题的速度也变得越来越快，我们处理的速度不一定跟的上用户的增速。\n\n#### 2.3.4 新呼声\n这时候我们也听到了用户的一些「新呼声」。\n\n有用户说他们在跑复杂查询时 OLTP 的查询延迟变高了，跑一个报表的时候发现  OLTP 开始卡了。这个问题的原因是在跑复杂查询的时候，SQL 资源被抢占。我们又想有没有可能将 OLAP 和 OLTP 的 Workload 分开？于是我们搞了第一个实验版本，在 TiKV 里把请求分优先级，放到不同队列里面去，复杂 Query 放在第一优先级的队列， OLTP 放在高优先级。然后我们发现自己是对报表理解不够深刻，这个方案只能解决一部分用户的问题，因为有的报表跑起来需要几个小时，导致队列永远是满的，永远抢占着系统的资源。还有一部分用户的报表没有那么复杂，只是希望报表跑得更快、更加实时，比如一个做餐饮 SaaS 的用户，每天晚上需要看一下餐馆营收情况，统计一家餐馆时速度还行，如果统计所有餐馆的情况，那就另说了。\n\n另外，报表有一些必需品，比如 View 和 Window Function，没有这些的话 SQL 写起来很痛苦，缺乏灵活度。\n\n与此同时，用户关于兼容性和新特性的要求也开始变多，比如希望支持 MySQL 类似的 table partition，还有银行用户习惯用悲观锁，而 TiDB 是乐观锁，迁移过来会造成额外的改造成本（TiDB 3.0 已经支持了悲观锁）。\n\n还有用户有 400T 的数据，没有一个快速导入的工具非常耗时（当然现在我们有快速导入工具TiDB Lightning），这个问题有一部分原因在于用户的硬件条件限制，比如说千兆网导入数据。\n\n还有些用户的数据规模越来越大，到 100T 以上就开始发现十分钟已经跑不完 GC 了（TiDB 的 GC 是每十分钟一次），一个月下来 GC 已经整体落后了非常多。\n![图 10 用户的新呼声](https://img1.www.pingcap.com/prod/310_15b947ff56.png)\n\n\n我们当时非常头痛，收到了一堆意见和需求，压力特别大，然后赶紧汇总了一下，如图 10 所示。\n\n面对这么多的需求，我们考虑了两个点：\n\n- 哪些是共性需求？\n- 什么是彻底解决之道？\n\n**把共性的需求都列在一块，提供一个在产品层面和技术层面真正的彻底的解决办法**。\n\n比如图 10 列举的那么多问题，其实真正要解决三个方面：性能、隔离和功能。性能和隔离兼得好像很困难，但是这个架构有非常独特的优势，也是可以做得到的。那可以进一步「三者兼得」，同时解决功能的问题吗？我们思考了一下，也是有办法的。TiDB 使用的 Raft 协议里有一个 Raft Learner 的角色，可以不断的从 Leader 那边复制数据，我们把数据同步存成了一个列存，刚才这三方面的问题都可以用一个方案去彻底解决了。\n\n首先复杂查询的速度变快了，众所周知分析型的数据引擎基本上全部使用的是列存。第二就是强一致性，整个 Raft 协议可以保证从 Learner 读数据的时候可以选择一致性的读，可以从 Leader 那边拿到 Learner 当前的进度，判断是否可以对外提供请求。第三个是实时性可以保证，因为是通过 streaming 的方式复制的。\n\n所以这些看上去非常复杂的问题用一个方案就可以解决，并且强化了原来的系统。这个「强化」怎么讲？从用户的角度看，他们不会考虑 Query 是 OLAP 还是 OLTP，只是想跑这条 Query，这很合理。**用一套东西解决用户的所有问题，对用户来说就是「强化」的系统**。\n\n## 三、关于成本问题的思考\n![图 11 成本问题](https://img1.www.pingcap.com/prod/311_e186b2bc4e.png)\n\n\n很多用户都跟我们反馈了成本问题，用户觉得全部部署到  SSD 成本有点高。一开始听到这个反馈，我们还不能理解，SSD 已经很便宜了呀，而且在整个系统来看，存储机器只是成本的一小部分。后来我们深刻思考了一下，其实用户说得对，很多系统都是有早晚高峰的，如果在几百 T 数据里跑报表，只在每天晚上收工时统计今天营业的状况，那为什么要求用户付出最高峰值的配置呢？这个要求是不合理的，合不合理是一回事，至于做不做得到、怎么做到是另外一回事。\n\n于是我们开始面临全新的思考，这个问题本质上是用户的数据只有一部分是热的，但是付出的代价是要让机器 Handle 所有的数据，所以可以把问题转化成：我们能不能在系统里面做到冷热数据分离？能不能支持系统动态弹性的伸缩，伸展热点数据，用完就释放？\n\n如果对一个系统来说，峰值时段和非峰值时段的差别在于峰值时段多了 5% 的热点。我们有必要去 Handle 所有的数据吗？**所以彻底的解决办法是对系统进行合理的监控，检测出热点后，马上创建一个新的节点，这个新的节点只负责处理热点数据，而不是把所有的数据做动态的 rebalance，重新搬迁。在峰值时间过去之后就可以把复制出来的热点数据撤掉，占的这个机器可以直接停掉了，不需要长时间配备非常高配置的资源，而是动态弹性伸缩的**。\n\nTiDB 作为一个高度动态的系统，本身的架构就具有非常强的张力，像海绵一样，能够满足这个要求，而且能根据系统负载动态的做这件事。这跟传统数据库的架构有很大的区别。比如有一个 4T 的 MySQL 数据库，一主一从，如果主库很热，只能马上搞一个等配的机器重挂上去，然后复制全部数据，但实际上用户需要的只是 5% 的热数据。而在 TiDB 里，数据被切成 64MB 一个块，可以很精确的检测热数据，很方便的为热数据做伸展。这个特性预计在 TiDB 4.0 提供。\n\n这也是一个良好的架构本身带来的强大的价值，再加上基于 K8s 和云的弹性架构，就可以得到非常多的不一样的东西。同样的思路，如果我要做数据分析，一定是扫全部数据吗？对于一个多租户的系统，我想统计某个餐馆今天的收入，数据库里有成千上万个餐馆，我需要运算的数据只是其中一小块。如果我要快速做列存计算时，需要把数据全部复制一份吗？也不需要，只复制我需要的这部分数据就行。这些事情只有一个具有弹性、高度张力的系统才能做到。这是 TiDB 相对于传统架构有非常不一样的地方。时至今天，我们才算是把整个系统的架构基本上稳定了，基于这个稳定的架构，我们还可以做更多非常具有张力的事情。\n\n**所以，用一句话总结我们解决成本问题的思路是：一定要解决真正的核心的问题，解决最本质的问题**。\n\n## 四、关于横向和纵向发展的哲学\nTiDB 还有一条哲学是关于横向和纵向发展的选择。\n\n通常业内会给创业公司的最佳建议是优先打“透”一个行业，因为行业内复制成本是最低的，可复制性也是最好的。**但 TiDB 从第一天开始就选择了相反的一条路——「先往通用性发展」，这是一条非常艰难的路，意味着放弃了短时间的复制性，但其实我们换取的是更长时间的复制性，也就是通用性**。\n\n因为产品的整体价值取决于总的市场空间，产品的广泛程度会决定产品最终的价值。早期坚定不移的往通用性上面走，有利于尽早感知整个系统是否有结构性缺陷，验证自己对用户需求的理解是否具有足够的广度。如果只往一个行业去走，就无法知道这个产品在其他行业的适应性和通用性。如果我们变成了某个行业专用数据库，那么再往其他行业去发展时，面临的第一个问题是自己的恐惧。这恐惧怎么讲呢？Database 应该是一个通用型的东西，如果在一个行业里固定了，那么你要如何确定它在其他场景和行业是否具有适应性？\n\n**这个选择也意味着我们会面临非常大的挑战，一上来先做最厉害的、最有挑战的用户**。 如果大家去关注整个 TiDB 发展的用户案例的情况，你会注意到 TiDB 有这样一个特点，TiDB 是先做百亿美金以上的互联网公司，这是一个非常难的选择。但大家应该知道，百亿美金以上的互联网公司，在选择一个数据库等技术产品的时候，是没有任何商业上的考量的，对这些公司来说，你的实力是第一位的，一定要能解决他们问题，才会认可你整个系统。但这个也不好做，因为这些公司的应用场景通常都压力巨大。数据量巨大，QPS 特别高，对稳定性的要求也非常高。我们先做了百亿美金的公司之后，去年我们有 80% 百亿美金以上的公司用 TiDB，除了把我们当成竞争对手的公司没有用，其他全部在用。然后再做 30 亿美金以上的公司，今年是 10 亿美金以上的用户，实际上现在是什么样规模的用户都有，甭管多少亿美金的，“反正这东西挺好用的，我就用了。”所以我们现在也有人专门负责在用户群里面回答大家的提问。\n\n**其实当初这么定那个目标主要是考虑数据量，因为 TiDB 作为一个分布式系统一定是要处理具有足够数据量的用户场景**， 百亿美金以上的公司肯定有足够的数据，30 亿美金的公司也会有，因为他们的数据在高速增长，当我们完成了这些，然后再开始切入到传统行业，因为在这之前我们经过了稳定性的验证，经过了规模的验证，经过了场景的验证。\n![图 12 横向发展与纵向发展](https://img1.www.pingcap.com/prod/312_7774ec1e7b.png)\n\n\n**坚持全球化的技术视野也是一个以横向优先的发展哲学**。 最厉害的产品一定是全球在用的。这个事情的最大差异在于视野和格局，而格局最终会反映到人才上，最终竞争不是在 PingCAP 这两百个员工，也不是现在 400 多个 Contributors，未来可能会有上千人参与整个系统的进化迭代，在不同的场景下对系统进行打磨，所以竞争本质上是人才和场景的竞争。基于这一条哲学，所以才有了现在 TiDB 在新一代分布式数据库领域的全面领先，无论是从 GitHub Star 数、 Contributor 数量来看，还是从用户数据的规模、用户分布的行业来看，都是领先的。同样是在做一个数据库，大家的指导哲学不一样会导致产品最终的表现和收获不一样，迭代过程也会完全不一样。我们在做的方向是「携全球的人才和全球的场景去竞争」。\n\n关于横向和纵向发展，并不是我们只取了横向。\n\n**2019 年 TiDB 演进的指导思想是：稳定性排第一，易用性排第二，性能第三，新功能第四**。 这是我在 2018 年经过思考后，把我们发展的优先级做了排序。上半年我们重点关注的是前两个，稳定性和易用性。下半年会关注纵向发展，「Make it fast」其实是纵向上精耕细作、释放潜力的事情。这个指导思想看起来好像又跟其他厂商想法不太一样。\n\n我们前面讲的三条哲学里面，最后一条就是「Make it fast」，如果要修建五百层的摩天大楼，要做的不是搭完一层、装修一层，马上给第一层做营业，再去搭第二层。而一定要先把五百层的架构搭好，然后想装修哪一层都可以。**TiDB 就是「摩天大楼先搭架构后装修」的思路，所以在 TiDB 3.0 发布之后，我们开始有足够的时间去做「装修」的事情**。\n\n## 五、总结与展望\n说了这么多故事，如果要我总结一下 2015 - 2019 年外面的朋友对 TiDB 的感受，是下图这样的：\n![图 13 2015-2019 小结](https://img1.www.pingcap.com/prod/313_fb70e0472b.png)\n\n\n2015 年，当我们开始做 TiDB 的时候，大家说：啊？这事儿你们也敢干？因为写一个数据库本身非常难，写一个分布式数据库就是无比的难，然后还是国人自主研发。到 2016 年的时候，大家觉得你好像折腾了点东西，听到点声音，但也没啥。到 2017、2018 年，大家看到有越来越多用户在用。2019 年，能看到更多使用后点赞的朋友了。\n\n我昨天翻了一下 2015 年 4 月 19 日发的一条微博。\n![图 14 刚创业时发的微博](https://img1.www.pingcap.com/prod/314_5f685a4a61.png)\n\n\n当时我们正准备创业，意气风发发了一条这样微博。这一堆话其实不重要，大家看一下阅读量 47.3 万，有 101 条转发，44 条评论，然而我一封简历都没收到。当时大家看到我们都觉得，这事儿外国人都没搞，你行吗？折腾到今天，我想应该没有人再对这个问题有任何的怀疑。**很多国人其实能力很强了，自信也可以同步跟上来，毕竟我们拥有全球最快的数据增速，很多厂家拥有最大的数据量，对产品有最佳的打磨场景**。\n\n想想当时我也挺绝望的，想着应该还有不少人血气方刚，还有很多技术人员是有非常强大的理想的，但是前面我也说了，总有一个从理想到现实的距离，这个距离很长，好在现在我们能收到很多简历。所以很多时候大家也很难想象我们刚开始做这件事情的时候有多么的困难，以及中间的每一个坚持。**只要稍微有一丁点的松懈，就可能走了另外一条更容易走的路，但是那条更容易走的路，从长远上看是一条更加困难的路，甚至是一条没有出路的路**。\n![图 15 对 2020 年的展望](https://img1.www.pingcap.com/prod/315_2e5ee7881a.png)\n\n\n最后再说一下 2020 年。在拥有行业复制能力的之后，在产品层面我们要开始向着更高的性能、更低的延迟、更多 Cloud 支持（不管是公有云还是私有云都可以很好的使用 TiDB）等方向纵向发展。同时也会支持我刚刚说的，热点根据 Workload 自动伸缩，用极小的成本去扛，仅仅需要处理部分热点的数据，而不是复制整个数据的传统主-从思路。\n\n大家去想一想，如果整个系统会根据 Workload 自动伸缩，本质上是一个 self-driving 的事情。现在有越来越多的用户把 TiDB 当成一个数据中台来用，有了 TiDB 行列混存，并且 TiDB 对用户有足够透明度，就相当于是握有了 database 加上 ETL，加上 data warehouse，并且是保证了一致性、实时性的。\n\n昨天我写完 slides 之后想起了以前看的一个电视剧《大秦帝国》。第一部第九集里有一段关于围棋的对话。商鞅执黑子先行，先下在了一个应该是叫天元位置，大约在棋盘的中间。大家知道一般下围棋的时候都是先从角落开始落子居多。商鞅的对手就说，我许你重下，意思就是你不要开玩笑，谁下这儿啊？于是商鞅说这样一句话，“中枢之地，辐射四极，雄视八荒”，这也是一个视野和格局的事情。然后对手说：“先生招招高位，步步悬空，全无根基实地”，就是看起来好像是都还挺厉害的，一点实际的基础都没有，商鞅说：“旦有高位，岂无实地？”，后来商鞅赢了这盘棋，他解释道：“**棋道以围地为归宿，但必以取势为根本。势高，则围广**”。\n\n**这跟我们做 TiDB 其实很像，我们一上来就是先做最难最有挑战的具有最高 QPS 和 TPS、最大数据量的场景，这就是一个「取势」的思路，因为「势高，则围广」**。 所以我们更多时候是像我前面说的那样，站在哲学层面思考整个公司的运转和 TiDB 这个产品的演进的思路。这些思路很多时候是大家看不见的，因为不是一个纯粹的技术层面或者算法层面的事情。\n\n我也听说有很多同学对 TiDB 3.0 特别感兴趣，不过今天没有足够的时间介绍，我们会在后续的 TechDay 上介绍 3.0 GA 的重大特性，因为从 2.0 到 3.0 产生了一个巨大的变化和提升，性能大幅提升，硬件成本也下降了一倍的样子，需要一天的时间为大家详细的拆解。\n![洞见316.jpeg](https://img1.www.pingcap.com/prod/316_c749404cff.jpeg)\n\n\n>本文根据我司 CEO 刘奇在第 100 期 Infra Meetup 上的演讲整理。\n\n","image":{"alt":"势高，则围广：TiDB 的架构演进哲学","media":{"url":"https://img1.www.pingcap.com/prod/image_6_ba3b2dfde4.png"}},"lable":"架构洞察","title":"势高，则围广：TiDB 的架构演进哲学","description":"“棋道以围地为归宿，但必以取势为根本。势高，则围广”。这跟我们做 TiDB 其实很像，我们一上来就是先做最难最有挑战的具有最高 QPS 和 TPS、最大数据量的场景，这就是一个「取势」的思路，因为「势高，则围广」。"}}]}}}