阿尔法公社
重度帮助创业者的天使投资基金
Databricks是一家正在崛起的企业软件巨头。2021年，它连续获得两轮10亿美元级别的大额融资，估值跃升到380亿美元，它在数据和人工智能领域具有全球雄心。
Databricks是一个非典型的创业故事，它由七位联合创始人创办，其中大部分是学者。它从Spark开源项目起步，现在引领了数据湖范式，这将加速其与主要竞争对手Snowflake的竞争。
本文是投资人Matt Turck与Databricks联合创始人兼CEO Ali Ghodsi的对话实录，Matt Turck在2015年就与Databricks的联合创始人Ion Stoica有过对话，对于Databricks的情况相当熟悉。在本文中Ali Ghodsi将透露Databricks从一个开源项目到大型公司的成长经历，以及在团队，产品，进入市场，扩张等方面积累的洞见，Enjoy。
科学家创始人们推动Databricks起步
Matt Turck： 我们谈一下Databricks的起步，AMPLab、Spark和Databricks，这一切是如何开始的？
Ali Ghodsi： 我们当时正处于人工智能革新的风口浪尖：Uber刚刚起步，Airbnb、Twitter处于早期，Facebook还不是巨头。他们声称，使用20世纪70年代诞生的机器学习算法实现了很好的效果。
以当时的常识来想这不可能是真的，我们觉得那些算法不可能Work，但他们说，“不，我们得到了非常厉害的结果。”当仔细观察后，我们的想法被颠覆了——他们确实获得了惊人的结果。以现代硬件和大量数据为支撑，运用上世纪的算法依旧可以获得令人难以置信的产出，我们对此感到震惊。我们想："需要使之普适化"。例如，在Facebook，他们可以提前检测到情侣分手，如果地球上的每个企业都有这种技术，这会对现有商业产生巨大影响。这就是AMPLab的起点。
Matt Turck： 当时AMPLab的Spark是怎么来的？
Ali Ghodsi： 图灵奖得主之一戴夫·帕特森当时是伯克利的教授，他非常相信人们应该聚在一起，打破孤岛。伯克利的教授们放弃了自己的私人办公室，和所有学生一起在巨大的开放区域办公。
他们试图解决的机器学习问题以当时的技术背景来说是很有挑战性的。AMPLab里做机器学习的人，做数学的人，不得不使用Hadoop，数据的每一次迭代都必须运行MapReduce，这样光是做一次迭代就需要20到30分钟。所以当时我们决定："联合起来，建立一个反应快速的基础架构。”我们在数据上做了很多迭代。因此，不只是做一次，不只是一个SQL引擎，而是可以做递归机器学习的东西，并可以极快地找到数据中的内涵模式。
Matt Turck： Databricks创始故事的特殊之处在于，你们有七、八个联合创始人。回过头看，拥有这样一个大的创始团队利与弊是什么？
Ali Ghodsi： 肯定是有利有弊的。如果你知道如何真正让由七个人组成的紧密小组真正信任对方，并在一起工作得很好，就会发生令人惊讶的事情。我认为Databricks的成功很大程度上归因于我们互相的信任。
创业早期的创始人，即使只有两个人，他们也会争吵，然后可能会在一两年内分裂，这就是问题所在。我们找到了一种方法，使大家真正了解对方的长处和短处，使这段创业旅程成为一种乐趣。
人们总说CEO是地球上最漫长的工作，我从来没有这种感觉。我有很多联合创始人和我在一起，他们一直都在，这对我们来说绝对是一种力量。如果我们没有这些人，就不会有现在的成就。
从开源项目到公司，
从0到100万美元ARR
Matt Turck： 你们是如何从学术性的开源项目（Spark）变成一家公司，然后从0做到1000万美元ARR的？这背后是否有任何决定性的时刻，或其他特别的增长手段？
Ali Ghodsi： 我们从0到100万美元ARR的旅程非常特别，与其他的旅程非常不同。我们经历了三个阶段，第一个阶段是PMF（产品与市场契合）阶段，当你有了一个产品，你能找到它与用户之间的契合点么？这对任何公司都存在挑战。
你一旦你找到PMF，接下来就得弄清楚什么是能将该产品与市场联系起来的渠道，你的产品或许符合市场需求，但怎么通过渠道销售呢？事实上，我们一开始在这方面走了弯路，花了几年时间才确定正确的发展方向。在这几年里，为了弄清楚Databricks的正确模式我们进行了大量的实验。
接下来，让我们从产品开始，然后再谈谈渠道。
产品方面，我们有在伯克利建立的开源技术，但这不一定符合大企业的需要，因为在大企业，他们没有来自伯克利的博士。因此，我们需要为他们大简化问题，我们开始在云中托管它，但事实证明，即使是云版本对他们来说也太复杂了，无法使用。
因此，我们开始与用户一起进行迭代。我们在这之后削减了很多特性和功能，甚至可以说重新构建了一个产品。我们问自己："如果我们知道现在的一切，回去再做一次，会怎么做？"
于是，我们重新做了另一个开源项目，Delta，你可以把它看作Spark为大型企业所做的非常简单和自动化的软件。当我们在伯克利时，我们的产品设想是提供尽可能多的功能和设置项，因为可能是一个博士在用它做研究。但当我们把产品在企业中推广时，我们意识到不是每个人都有博士学位，大家不知道如何使用它。这就是早期我们遇到的问题。在渠道方面，错误在于，我们在早期真的是非常相信这种产品主导的增长。
关于销售，当时我们的设想是，有了一个简化的产品，我们把它做成基于云的产品，就会有人会使用它，会为它刷xyk，我们会非常成功。我们可以雇用销售人员，给年轻人打电话进行推销，我们不会雇佣企业的销售人员。我们更喜欢这种模式，它更便宜，更简单。
但那是一个错误。你不能凭空选择你的渠道。你有一个产品和相应的市场，必须找到正确的渠道来连接它们。
Databricks如何开发产品，
数据仓库VS数据湖
Matt Turck： 我们一会再继续谈进入市场。现在让我们先谈谈产品，我在Databricks观察到的令人着迷的事情之一是，你们发布新产品并将其转化为一个平台的速度。从Spark到机器学习到AI工作台再到Lakehouse，请向我们介绍一下产品的思路——一个产品如何导致另一个产品的出现。
Ali Ghodsi： 我们从Spark开始起步，它让用户可以访问所有数据；于是人们开始在企业中创建数据库，并在其中积累了大量数据。但过了一段时间，企业高管会问：“我不在乎我们获得和存储了多少数据，你能用这些数据为我做什么？ ” 这就是我们试图建立其他应用程序的原因。
起初我们的收入很少，然后我们意识到它太复杂了，有太多的选项和配置。我们就问自己："如果必须重做，必须简化，会做什么？"这种思路后的第一个创新是Delta，它重新定义了Spark，以一种真正企业友好的简化方式。但最初我们没有将它开源。
接下来，我们想：“如果拓宽数据库的用途，不仅仅是数据科学家和机器学习工程师，而是真正广泛的用例，应该怎么做？ ” 这就是我们开始重视商业分析师的原因。
商业分析师习惯于像Tableau那样的 *** 作软件。如果他们想做一些更复杂的事情，只能使用SQL。因此，我们在四年前开始致力于构建数据仓库能力，把它建立在我们称为Lakehouse的核心基础设施中，然后在前年较大规模的推广。
我们的秘诀是：看企业的问题，弄清楚那是什么，通过实际的客户问题来深入了解它，把问题带回来，解决这个问题，在云中与客户快速迭代。一旦它有了产品的市场适应性，就把它开放出来。建立巨大的开源势头，几乎像一个B2C病毒式的形式。然后，用基于云的SaaS版本将其变现。
这是受AWS的启发，当创立Databricks时，我们认为AWS是地球上最好的云计算开源公司。他们本身不进行开发，其盈利模式基于开源软件，托管它并在上面赚很多钱。我们只是在这一点上进行了调整和演变。我们认为：“这是一个伟大的商业模式。我们将在云上托管开源软件。但不同的是，我们将自己创建开源软件。这样一来，就获得了相对于其他任何想做同样事情的人的竞争优势。 ” 否则，任何人都可以建立任何开源软件并在云中托管它。
Matt Turck： 接下来，让我们从Lakehouse开始，了解一下数据湖和数据仓库的演变，以及Lakehouse是如何在这两个领域中取得最好的成绩。
Ali Ghodsi： 这很简单。人们在数据湖里存储所有的数据：数据集，视频、音频、随机文本，这既迅速又便宜。利用各种各样的数据集，你可以基于数据湖进行AI创新，AI与数据湖密切相关。如果你想做BI，而不是AI，你就使用数据仓库，数据仓库和BI有一个单独的技术堆栈，但是它其实和AI一样，有很多同样的数据集。
BI用于回答过去的问题，比如上个季度的收入是多少；AI用来问关于未来的问题，哪些客户将会回来？所以，这意味着需要两个独立的堆栈，你必须有两个数据副本，而且你必须管理它们，这造成了很多复杂性。但当年的FAANG（硅谷几个顶尖互联网巨头的联合简称）可不是这样做的，他们有一个统一的平台。所以，我们的想法是把这两个统一成一个平台—Lakehouse、人工智能数据湖--提出关于未来的问题。这两者的结合将使企业能够更快地发展。它是数据工程师、数据科学家和商业分析师的平台，这样他们就可以在整个企业内一起工作。所以这是一个用于AI和BI的数据平台。
Matt Turck： 实现这一点靠的是什么重大的技术突破么？是Delta Lake？还是Iceberg？那是如何工作的？
Ali Ghodsi： 是的， 我认为有四个技术突破是在2016、2017年同时发生的，Hudi、Hive ACID、Iceberg、Delta Lake，我们贡献的是Delta Lake。问题是这样的，在数据湖里有人们收集了所有的数据，这些数据非常有价值，但很难对它们进行结构化查询。之前的传统方式是利用SQL数据库，然后应用在BI领域。因此，你需要一个单独的数据仓库。
为什么这么难？因为数据湖是为大数据、大数据集建立的，它并不是为真正的快速查询而建立的。它太慢了，而且没有任何方法来结构化数据，并以表格的形式展现数据，这就是问题所在。那么，你如何把像一个大的数据块存储的东西，变成一个数据仓库？这就是这些项目的秘诀。我们找出了解决这些数据湖效率低下的方法，并使用户能够直接从数据湖的数据仓库中获得相同的价值。
Matt Turck： 这种方法有什么取舍吗？
Ali Ghodsi： 事实上并非如此，我们做到了鱼与熊掌可以兼得。我知道这听起来很疯狂，但试试就是如此。我们减少了很多在80、90年代由数据仓库供应商发明的技术，调整它们，使它们在数据湖上工作。你可以问：“为什么这在10或15年前没有发生？ ” 因为开放标准的生态系统并不存在，它是随着时间的推移慢慢出现的。所以，它从数据湖开始，然后有一个很大的实际技术先导突破。我们在这里谈论的，是数据的标准化格式。他们被称为Parquet和ORC，但这些是数据格式，行业要将所有的数据集标准化。
这些类型的标准化步骤是需要的，以获得数据湖的突破。这有点像USB，一旦你有了它，你就可以把任何两个设备相互连接起来。所以，正在发生的事情是，开源领域的一个生态系统正在出现，在那里你可以在数据湖的范式中做所有的分析。最终，你将不需要所有这些自八十年代以来的专有旧系统，包括数据仓库和其他类似系统。
Matt Turck： 我会针对这个再问问题，业界有很多关于Snowflake和Databricks之间即将发生大冲突的议论，作为这个领域的两个巨大的公司，你对未来的看法是，数据湖最终成为范式，然后随着时间的推移，其他一切都被吸收？还是你认为未来更多的是混合，用户可以用数据仓库做某些事情，数据湖做其他事情？
Ali Ghodsi： 我将从两个方面回答这个问题。首先，人们把这说成是零和博弈，但你认为谷歌云会淘汰AWS和微软云，还是AWS会淘汰其他云？没有人这么认为，对吧。他们会共存，都将获得成功。
数据空间是巨大的。将会有很多供应商参与其中。我认为Snowflake将获得成功，他们现在有一个伟大的数据仓库，可能是市场上最好的数据仓库。而它肯定会与Databricks共存。事实上，Databricks与Snowflake共存于可能70%的客户中。我认为这种情况将继续存在，人们将使用数据仓库进行商业智能。
但是，如果长期来看，我认为数据湖的范式将获胜。为什么？因为数据太重要了，人们所有的数据都在这些数据湖中，而且更多的数据正在进入数据湖中。公有云计算供应商也有动力推动更多的动力让人们把数据存到他们的数据湖中，因为这对他们来说是既得利益。因此，任何使其真正有价值的解决方案，都将是未来的趋势。所以，我认为从长远来看，越来越多的人将倾向于这种数据湖的范式。
为什么Databricks能够不断产出创新产品？
Matt Turck： 我想了解你的产品和工程团队是如何组织的？对于一家公司，能够在第一个产品成功的基础上做第二个产品是非常罕见的。但在这里，我们正在谈论，如何成功的做出三个、四个、五个不同的产品。你的公司是如何管理好团队组织结构和其他资源，以不断创新？
Ali Ghodsi： 我们从创立Databricks时，就在试图找到这个问题的答案。我们不想靠一个单一的产品生存。当我们有了Spark，却并没有把它当成公司的名字，因为如果Spark变得落后了，我们就会把它迭代掉，然后继续向前，我们想不断找到数据的最佳答案。那么如何不断的有创新产品出现？我认为非常重要的是，要把创新和现有的现金流业务分开。
有一本关于这个问题的好书，叫Zone To Win。书中谈到，当你创造出一些新东西时，你需要快速迭代。你需要让工程师直接与客户交谈，甚至不一定要让产品经理来做，快速的创新迭代是最要紧的。而在在企业端，你需要一个慢得多的周期来迭代。
另外，所有的工程和产品团队组织被分成两个不同的部分。一部分专注于企业客户需要的东西：加密，安全，认证，稳定性等。另一部分则专注于创新，而且你应该把这些分开，分别的投入资源，否则前者（企业那部分）将得到所有的资源。你会倾向于不断地建立那些扩大你的TAM的东西。TAM扩展实际上是安全能力，它本身并没有任何创新。
我认为，有些公司已经做得很好了，比如AWS，它不是一招鲜，亚马逊本身也不是一招鲜，它不断有新的创新。所以我们希望我们的公司也是这样的，因此取名为Databricks。
Matt Turck： MLflow Delta Lake, Koalas。这属于创新阵营还是商业阵营的子层？
Ali Ghodsi： 这些都是创新阵营。当然，其中一些项目，当他们不那么创新的时候，像Spark，会转移到维护方面，我们通常也会移动核心人员。因此，实际上是同一个人或同一拨人在不断地进行创新。我们试图培养更多的创新者，但我们试图把那种已经真正有诀窍破解从0到1的人转移到下一个问题，然后把现有的项目移交给其他人去运行，比方说Spark，这已经是一个巨大的成功项目。
当我们把已经创造出东西的人转移到别的地方去创造下一个东西，对于一个优秀人才，获得这种责任是一个很大的职业提升。而我们也会发现谁是擅长从0到1人。我们实际上是在做实验，给研发部门的人一个机会去试验从0到1的东西，他们并不总是成功。这需要几次尝试，直到他们成为真正擅长的人。所以你必须慎重考虑这种高失败的策略。
开源的商业模式，有何优越性？
Matt Turck： 如果你今天要再开一家企业软件公司，你会先去开源代码吗？
Ali Ghodsi： 是的，我认为它很优越。我认为如果你从进化的角度来考虑，它在进化上比以前的商业模式要好。为什么我这么说？因为任何专有的软件公司都是成熟的，可以被开源的竞争者破坏。因此，任何专有的东西都可以立即被颠覆，就像Windows被Linux颠覆一样。我的意思是，那是最先进的东西，是真正复杂的技术 *** 作系统，对吗？你不会认为大学里的某个家伙会发明，然后成为工业的标准。任何专有软件都是成熟的，可以进行这样的颠覆。问题是，你能靠它赚钱吗？在红帽和所有这些做支持网络服务的公司之前，这真的很难，直到AWS破解了商业模式的密码。
商业模式是我们为你运行软件，你从我们这里租用它。这是一个优越的商业模式，因为你实际上可以拥有大量的IP，这是很难复制的。所以我认为我创办的下一家公司将是这样的。如果你要问我，我的下一次创业会在哪个领域开始，我会在人工智能方面做什么？我会认为我们现在在人工智能方面的应用还很浅层，尤其是 *** 作性的人工智能。人工智能未来将会被嵌入到各个地方。我知道这很老套。马克·安德森说，软件正在吞噬世界。我们真的相信，人工智能将吞噬所有的软件。你拥有的任何软件，人工智能都会悄悄进入，就像软件悄悄进入你的 汽车 、冰箱和恒温器一样。所以这真的是早期的事情，我认为任何加入或创办人工智能领域公司的人，他们还在早期，他们有机会创办下一个谷歌。所以这就是我想做的。
Matt Turck： 我们谈到了开源，也继续谈进入市场的问题，在这个阶段，作为一个非常晚期的创业公司。开源在进入市场的过程中处于什么位置？你们进入市场的策略是自下而上与自上而下？你们如何分配BDR小组与AE的工作，让他们协作而不是互相拖后腿？
Ali Ghodsi： Databricks是混合模式，我们是自下而上与自上而下在同一时间结合。一开始我们是自下而上，但是也会做自上而下的事情。我们有BDRs和SDRs。这是一个从市场营销开始的筛选器。
Databricks社区版是完全免费的，你想怎么用就怎么用，永远不需要付钱，而且有完整的功能。但是从这里产生的线索会导入到SDR。因此，这也是一个非常重要的管道。我们一半的线索来自于此，这就是为什么开源对我们是一个重要的引擎。
现在，我们也有传统的企业销售动作，比如给CIO递名片，一对一的交流，但发生的情况是，开发人员在这些组织中也变得越来越强大。例如，CIO说，我与Databricks的CEO进行了一次很好的谈话，我正在 探索 这项技术，但我担心，这对我们来说是正确的选择吗？那家公司的听众中会有人说，是的，我使用社区版。我们不需要做6个月的POC。我认识这些人，他们真的非常好，或者我认识他们，他们来自伯克利。我已经使用了这些技术。我去参加了一些聚会等。
因此，这有助于证实用例，你可以消除整个POC，因为他们已经知道它是什么，而不是像10-20年前那样，一个销售人员进来，解释这个软件有多棒，但你不能相信他们。因此你就必须去做POC，然后去花时间检验这个软件是不是真的有用。我们不必这样做，我们可以穿过所有这些层次。因此，我们把自上而下和自下而上结合起来，而这两方面对于Databricks的成功都是非常必要的。
从创业公司到超级独角兽，
领导者的修炼之路
Matt Turck： 你已经把一家小型创业公司带成了超级独角兽，很快还会上市。你是如何让自己完成角色转变的，从一个讲愿景，讲故事的人，变成管理一个全球组织？
Ali Ghodsi： 其实就是如何找到你可以信任的具有领导力的帮手，并和他们建立更深的信任。我可以把我大部分时间都花在这上面，而公司能够继续正常运行。我有运行良好的销售团队，市场营销团队，工程团队，我却不需要自己直接参与其中，因为我找到了适合领导这些部门的领导者，并且花了很多时间与他们建立起信任。
这是你在早期就要开始准备的事情，早期时，你的组织规模小，你可以参与到每个环节，如臂使指。但是当团队规模扩展到150-200人直到超过邓巴数。你会感觉自己完全被淹没了。因此你必须找到可以信任的正确的，而且要找到自己与组织沟通的方法，因为现在不是直接沟通，而是通过领导层间接沟通，所以帮助你与团队组织沟通的人就特别重要。
Matt Turck： 你如何找到他们？你是偏向在内部提拔人才，还是从外部引入已经获得成功的高管，哪一个效果更好？你是如何处理的？
Ali Ghodsi： 要找到与公司文化相适应的、你能与之建立强大信任的高管是非常困难的，我认为不应该排除任何选项。如果能够从内部提拔人，那很好，但是如果只是内部晋升，你就不能获得市场上已经存在的成功经验，这种经验可能是超级有价值的。
如果我们寻找外部的高管，他必须经历过我们现在所处的阶段，有实战的经验。不是说他必须从零开始创建一个估值几百亿的公司，而是建立和 *** 作过这种阶段公司的工程等相应部门，他是否在这个过程中有第一性思考，有自己的沉淀。我认为能力和智商还是非常重要的。
文化看起来是个很复杂的东西，但是对与我，会把它分解成一连串问题：我可以和这个人相处吗？愿意每天花10个小时和他在一起工作么？当事情变得非常棘手和困难的时候，我们能一起去解决问题么？所以你要做的就是花大量时间与这个人相处，然后问自己是否喜欢他们，就像婚姻一样。你可以问他们一些困难的问题，与他们争论或者听取他们的意见，直到确定这就是正确的人。如果你感觉到自己无法和某个人一起好好工作，那他就可能是文化不匹配。
本文编译整理自Matt Turck个人博客，略有删节。
关于阿尔法公社
阿尔法公社（Alpha Startup Fund）是中国领先的早期投资基金，由曾带领公司在纳斯达克上市的许四清和前创新工场联合管理合伙人蒋亚萌在2015年共同创立。
阿尔法公社基金的三大特点是系统化投资、社交化创业者社区运营和重度产业资源加速成长。专注在半导体、企业服务软件、人工智能应用、物联网技术、金融 科技 等 科技 创新领域进行早期投资。目前已经在天使轮投资了包括白山云 科技 、领创集团(Advance Intelligence Group)、Zenlayer、帷幄 科技 、所思 科技 等为数众多的优秀项目。
上一篇文章发出来，得到些好评，还是很欣慰的，我们会继续努力把美国的数据做成标杆，并且尽快推动其它国家进入实施阶段。晚上正好和一个朋友兼客户说起来，他说他们业务需要正在筹建全球的 POP 点，我说也许我可以把全球数据中心的概况给大家介绍一下，所以，这篇又来让你了解一下了。先声明一下，这个算是科普文，所以资深人士请绕行。
现在越来越多的国内互联网公司在做出海的事情，既然是互联网公司，那么海外网络规划自然是一大重点。曾经流行的段子说互联网有两个，一个是全球互联网，一个是中国互联网。无论国内国外，费心做了选择，合同签了，款也付了，服务也上架了，结果发现体验远不如预期，用户天天投诉慢慢慢，钱其实是小事，重新评估和再次迁移业务可是很麻烦麻烦的。
那么既然是网络地理知识，我们分开从两个角度说。还有一个限定，就是这里说的数据中心应该是指可以面向全球化服务的数据中心，如果是个面向本地的数据中心，估计在运营商的机房里辟块地方就够了。大可不必拿来讨论。
先说地理位置：
既然是谈数据中心，地理位置一定是个重点，那么大家都大概率的知道数据中心的选址要地理位置尽量远离地震带，温度适宜，PUE 越低越好，电费也是越便宜越好。但是因为数据中心理论上算是个数字房地产项目，所以不太可能离城市太远，不然运输和单位建造成本会很高，数据中心规模又不能太小，你都面向全球了，至少几千个机架起吧。交通方面也需要尽量便利，你运台服务器过去，国内都要两个礼拜，大家就都跪哭了。还有就是方便接入到足够多的运营商网络，尽力覆盖全国包括跨境流量，所以海边的城市会有便宜可占。最后一项，数据中心需要足够能力的人来运营，你弄个山沟沟，谁愿意去呢？
还是先说结论，一般来说，国家的首都和第二大城市，其次包括人口密集的城市比如区域的中心城市，都会是建设数据中心的首选位置。
我们假设我们是一个全球化的大型互联网公司，要建设自己的 CDN 网络，不差钱（但还没有钱到自己建设数据中心），只想提供最好的网络体验给用户，那么我们会在哪里选择数据中心呢？我们总结了国内外的各种 CDN 厂商的数据中心位置情况，大体总结如下。
先看看中国内地的情况：
运营商的三大网络出口城市，北京、上海、广州，应该是首选。
几亿人的规模，估计要做省级覆盖。那么每个省的省会是首选，是否有其它城市可选择会随着本地用户数量以及网络发达程度密切相关，还有一个特殊情况。比如山东青岛、江苏无锡，广东特殊一点，至少东莞、深圳都可以入选。西部就会比较弱，一般就只剩省会了。
当然，国内有个比较现实的问题，因为 CDN 在国内早已经进入红海阶段，所以各大 CDN 公司的数据中心选址都在从大城市往二线甚至更低的城市数据中心迁移，因为带宽成本便宜，这会导致省内网络流量不均衡，但是其实从体验上讲不如放在省会城市更好的，不过价格战胜了一切。
可能有人会说中卫，中卫应该说是没有更好选择下的最好选择了。也许很多公司会把灾备和数据存储放在那里，但未必是主力机房。而且中卫不是为全球准备的，是为中国准备的。包括苹果的国内数据中心也是如此。这个话题以后有机会再说。
那么看看去掉中国内地的亚太地区的选择：
香港、新加坡是亚洲核心，如果我只能选择两个，我会选择他们。
日本：东京和大阪，双轮驱动。
韩国：首尔。
印度：最好是德里/新德里、孟买、金奈、班加罗尔等几个城市一起上。
台湾：首选台北市，用户足够多再来一个高雄市。
印度尼西亚：雅加达
越南：胡志明市、河内
泰国：曼谷
马来西亚：吉隆坡
菲律宾：马尼拉
以上基本按照各自国家拥有的 IP 数量排序。
澳大利亚：五大护法，悉尼、墨尔本、布里斯班、阿德莱德和珀斯。
新西兰：奥克兰。
中东部分选择比较少，首选阿联酋的迪拜和以色列的特拉维夫。
说说北美地区：
美国的选择很多，但是通常来说是分为几个区域：
西部：加利福尼亚州的洛杉矶、圣地亚哥、湾区（旧金山到圣何塞之间）和华盛顿州西雅图和俄勒冈州波特兰，内华达州拉斯维加斯。犹他州的盐湖城、科罗拉多州的丹佛。
中部：德克萨斯州的达拉斯、休斯顿、奥斯汀、圣安东尼奥，堪萨斯州和密苏里州各有一个堪萨斯城。
北部地区：伊利诺伊州的芝加哥、明尼苏达州的明尼阿波利斯、密歇根州的底特律、印第安纳州的印第安纳波利斯。
南部地区：乔治亚州亚特兰大，佛罗里达州的迈阿密，北卡罗来纳州的夏洛特。
东部地区：宾夕法尼亚州的费城，华盛顿特区，弗吉尼亚州的阿什本/赫恩登/雷斯顿等贴近华盛顿特区的地区，纽约州纽约市，新泽西州的皮斯卡特维、纽瓦克、锡考克斯等贴近纽约市的地区，马萨诸塞州的波士顿。
其中数据中心最密集的区域是洛杉矶、湾区、西雅图、达拉斯、芝加哥、亚特兰大、迈阿密、贴近华盛顿特区的弗吉尼亚州的阿什本/赫恩登/雷斯顿地区。
加拿大反而简单，一般来说，西部的温哥华、东部的多伦多、蒙特利尔，再加上中部的温尼伯就足够覆盖加拿大了。最多再加一个卡尔加里。
墨西哥，简单，墨西哥城。
南美地区的选择比较少，巴西是互联网最发达的国家，一般是圣保罗和里约热内卢，首选。
阿根廷：布宜诺斯艾利斯。
哥伦比亚：波哥大和麦德林。
秘鲁：利马。
智利：圣地亚哥，附近还有一个瓦尔帕莱索。
厄瓜多尔：基多。
换到欧洲：
首选：荷兰阿姆斯特丹、德国法兰克福、英国伦敦、俄罗斯莫斯科。
德国：除了法兰克福，还有汉堡、柏林、慕尼黑可选。还有科隆、杜塞尔多夫备选。
英国：除了伦敦地区，还有曼彻斯特可选。
法国：巴黎，里昂和马赛。
意大利：米兰和罗马。
俄罗斯：除了莫斯科以外，还可以选择圣彼得堡。
西班牙：马德里、巴塞罗那。
瑞典：除了首都斯德哥尔摩以外，马尔默也是一个网络集散地。因为他的对面是哥本哈根。还有哥德堡备选。
波兰：华沙。
瑞士：苏黎世。
土耳其：伊斯坦布尔。
挪威：奥斯陆。
芬兰：赫尔辛基。
比利时：布鲁塞尔。
丹麦：哥本哈根
爱尔兰：都柏林。
乌克兰：基辅、哈尔科夫。
奥地利：维也纳。
捷克：布拉格。
罗马尼亚：布加勒斯特。
葡萄牙：里斯本。
希腊：雅典。
匈牙利：布达佩斯。
保加利亚：索非亚。
立陶宛：维尔纽斯。
拉脱维亚：里加。
爱沙尼亚：塔林。
塞尔维亚：贝尔格莱德。
以上基本按照各自国家拥有的 IP 数量排序。
最后说非洲，非洲的情况和南美差不多：
首选南非的开普敦和约翰内斯堡。
埃及：开罗。
肯尼亚：蒙巴萨。
没了。
还有一些小国家没列，但是请看下一句话。
如果你对地理知识比较熟悉的话，你会发现我提到的城市名字是比较符合“一般来说，国家的首都和第二大城市，其次包括人口密集的城市比如区域的中心城市，都会是建设数据中心的首选位置。”这句话的。
另外基于国土面积，越大的越会有多个区域性中心城市存在，比如中国、美国、加拿大、印度、澳大利亚。
再说网络：
先说一个概念，Internet Exchange，简称 IX，互联网流量交换中心。
在国外，如果两个运营商之间没有互联互通，那么绕路访问几乎是必然的，甚至在欧洲是要跨国家了。为了解决本地流量本地消化的这个问题，所以诞生了很多营利的非营利的机构和公司提供流量交换服务，有第三方，也有一些运营商自己提供此项服务。一般来说，接入的 IX 越多，可选路径越多，绕路的情况就会越少。
在中国，IX 几乎是官办的，而且运营商强势，收费方式跟国外也是巨大的差别，第三方出口这个中国特色也跟这个有很大关系，所以基本上大家都不了解这个事情。但是国外自己的网络只要有点规模就可以考虑接入 IX，差别很大。
IX 里规模比较大的有主要业务在荷兰阿姆斯特丹的 ams-ixnet，主要业务在德国的 de-cixnet，亚太这边有香港的 hkixnet。欢迎大家去了解一下。
所以考察一个数据中心的网络情况，首先要了解他们基本接入哪些运营商，哪些 IX，再看他可以选择接入哪些运营商和 IX。
这个情况跟国内也有区别，国内基本上方案上没得选，两线三线还是几线是定死的。但是在国外，有钱你就可以选择性接入，但是前提是人家方案最好是现成即用即接的。不过这种情况下，就很难选择某运营商自己的机房了，往往是第三方中立机房。
还有一个问题，就是既然是出海业务，除了面向区域用户，从国内或者 SOC/NOC 访问各地 POP 进行运维管理的方便性考察也是必须的，无论是公网还是专线。国内互联网公司用的比较简单的方案是在洛杉矶或者圣何塞建点，专门用于维护。而且这两个地方的网络非常丰富，无论是机房还是网络接入的选择余地大，而且到任何一个洲的延迟相对比较均匀。更何况三大运营商在这里都有 POP 点，回国应该是最快最稳定的选择了。
还有一个基于业务类型的带宽储备和机房的能力支持，也是必然要考虑的问题，有些机房能做高防，有些不能，真被攻击也很麻烦，而且前面说了，有 BGP 能力做流量调度为基础才能更好的对抗攻击，国内是运营商说了算，大部分只能靠带宽和硬件硬抗，但在国外是可以自己做很多种方案的，好不好看你自己了。
因为国外的运营商数量真的很多，所以基于你的用户在运营商的分布情况，去做网络规划和运营，还要做到成本尽量低，是个必备能力，也是个考验。
当然你说你用 AWS 就够了，当我什么都没说。
注意事项：
1、国内运营商的限制，导致 ANYCAST 很难做到，都是 DNS 调度居多。而国外基本上自己搭建 BGP 能力是基础，IP 申请、公告与维护也是基础工作，这个是国内公司的网络运维人员要补课的地方。你如果不知道 RADB 是啥，建议赶紧去搜索。
2、地面上的地理位置近不等于网络位置近，实际上要看网络地理的情况才更合适。比如在非洲地区和南美地区，运营商之间的互联互通比较差，如果一个巴西圣保罗运营商的网内用户想要访问另外一个巴西圣保罗运营商网内的网站，很有可能会绕路到迈阿密或者纽约，再绕回来。有一个比较有名的 CDN 厂商，是这么做的，根据网络互连情况，把本地有互联的用户访问导入到本地的 CDN 节点，剩下没有互联或者不好确认的，宁可让他们回到迈阿密或者纽约的节点，这样做用户访问平均延迟反而更低。还有一个例子就是非洲旁边有几个法属的领地，马约特、留尼汪岛这些，我们看到的情况都是从法国马赛的海缆接入网络的，反而没从最近的非洲网络接入，所以如何考虑网络上的区域覆盖，是个非常认真细致的事情，需要了解的知识点非常多。虽然可能和我们的关系没那么大，但是了解了认为可以忽略总比不知道实际情况想当然要好。
3、适当规划，先大区域部署，再根据实际情况慢慢推进网络规划。
你需要先知道目前的用户地理分布情况以及运营商情况，再基于这个做地理位置和网络接入的规划。
而且要明确一点，IX 接入和 TRANSIT 接入的角度不同，费用不同，接入情况也不同，你要根据运营商情况进行选择。
我看到的情况是大型运营商通常为收入考量，一般不太会主动接入 IX，有也可能是 Selective 或者 Private 的方式，你可能得单独 Transit 接入，但是中型、区域以及小型运营商，尤其是 IDC、CDN 厂商，是比较愿意主动接入 IX 的，所以你要明确知道你的网络使用情况，才好去选择网络接入的方式。
假设说你在国外，有自建 POP 点也使用 AKAMAI / CLOUDFLARE 等网络服务的话，那你就最好是和他们都接入 IX，这样也就不用担心回源质量问题了，一举两得。
好在 IX 官网一般都会有成员以及接入方式列表，PEERINGDB 也应该会有更新。如果有必要，也可以单独联系确认情况。
总之记住一个最高原则，无论在哪里，能做到运营商网内服务，都是最佳选择。
如果上面说的巴西的情况，跨运营商提供服务，跨国绕路都是很有可能的。
对了，想从 IP 和 ASN/BGP 角度查看用户的地理位置和运营商情况，IPIP 都可以帮助你。
4、对于一个数据中心的网站，我觉得除了详细介绍数据中心的硬件条件以外，我觉得也要明确地理位置和网络接入的情况，也是必须有的。如果能够提供 looking glass，那就最好了。
目前常见的情况是数据中心会标注在 NYC 和 WDC，其实很大程度上真实位置是在附近的新泽西州和弗吉尼亚州，这个算是行业惯例了吧。个人觉得还是明确为好。
即使从强迫症角度说，我对那些没有明确写明数据中心具体地理位置的公司，没有好感。：D
5、假设你在海外的用户不是很多，但是确实有一些，那么我建议在洛杉矶设个点覆盖一下海外用户就好。
对此有兴趣延伸话题讨论的，可以留言给我，一起交流。
延伸阅读：
1、Internet Exchange Map: >
检测 | >
欢迎分享，转载请注明来源：内存溢出
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）