前言
本来自己一直酝酿想写一篇对数据技术栈发展的总结和展望的文章，在阅读dbt的官方博客的时候，发现dbt的CEO-Trisan Handy在去年12月1日发表过一篇相关的文章，另外还有Continual的Jordan Volz的一篇相关的文章。两篇文章写的都非常对好，因此我决定先把两篇文章翻译过来，然后再自己写一篇文章讲讲我的观点和想法。本文为第一篇，编译自dbt官方博客Tristan Handy发表在2020年12月一日的文章: The Modern Data Stack:Past Present, and Future
在过去的十年，数据产品已经获得了相当多的关注，并且在资本市场融到了大笔的资金，并且产生了很大的吸引力。他们对于大多数数据优先的公司的运营方式产生了巨大的变化-Stitch Fix与一个传统的服装公司具有天壤之别，Airbnb则与一个传统的酒店经营者完全不同。数据产品从根本上改变了很多我们数据专业人士的职业生涯，为全新的职位创造了新的空间并将曾经卑微的角色提高到了高度战略性的位置。
但是对于所有的这些变化，我感觉在过去几年我们进入了一个平台期。我个人从2015年开始整理"现代技术栈"，已经整整五年！在这五年时间里，构成最佳技术栈的这个集合一直维持没有变化(当然这个列表并不是穷尽了所有产品)
数据集成：Fivetran, Stitch
数据仓库：Snowflake, Bigquery, Redshift
数据转换：dbt
BI: Looker, Mode, Periscope, Chartio, Metabase, Redash
更重要的是，虽然在那个时间段内这些产品中的每一个肯定都有渐进性的进步，但它们的核心用户体验都没有从根本上发生改变。如果你像Rip Van Winkle(注：美国著名短篇小说作家华盛顿.欧文的一篇短篇小说，主人公一觉睡了20年)一样的在 2016 年睡着了然后在今天醒来，你完全不需要去对你大脑中关于现代数据技术栈如何工作进行更新。更多的集成、更好的窗口函数支持、更多的配置选项、更好的可靠性……所有这些固然都是非常好的优化，但它们暗示着某种成熟，某种停滞。我们在 2012 年至 2016 年间看到的大规模创新发生了什么变化呢？
需要澄清的是，所有上边的内容就像对其他产品一样同样适配于dbt。如果你去对比2016年的dbt和2020年的dbt，尽管现在的版本更加强大，但是核心用户体验和过去并没有本质区别。我的目标不是诋毁，而是试图去理解我们所有人都在其基础上去发展自己职业生涯的产品生态系统的动态。
这种感觉对我非常对重要。人类是构建工具以及使用工具的物种-我们的工具定义了我们的能力，并且定义了我们整个物种的历史。
在这篇博客中，我的目标是在三个不同时间段内看一下的现代数据技术栈：
寒武纪大爆发第一阶段，从2012-2016
部署阶段，从2016-2020
寒武纪大爆发第二阶段，从2020-2025
在这篇博客中，我会头戴好几顶帽子，一个人分饰多个角色。我的首要的角色是一个实践者：一个超过20年在数据领域发展自己职业生涯的分析师，并且对于这里边每一个工具都有很深的使用经验。我有时也会戴上我创始人的帽子，这个我能有机会去构建一个在今天的现代数据技术栈中重要的一个产品。无论我戴哪顶帽子，我对未来都感到无比的兴奋。
01
寒武纪第一阶段，从2012到2016
当Fishtown Analytics(dbt labs前身)在2019年11月份搬家到我们的新的办公室的时候，我做的第一件事情是在我们的墙上挂了一副画。这是一副来自于70年代的现代艺术叫做Redshift，我在一次Everything But The House的拍卖会上购买了这幅画，因为我非常喜欢它的名字。在我看来，现代数据技术栈是围绕着亚马逊2012年10月份发布的Amazon Redshift而产生的，因此在我们办公室的入口处悬挂这副巨大的画是为了纪念这个重要的历史时刻。
让我们看一下现在数据技术栈中其他层的核心产品的创建日期：
Chartio: 2010
Looker: 2011
Mode: 2012
Periscope: 2012
Fivetran: 2012
Metabase: 2014
Stitch: 2015
Redash: 2015
dbt: 2016
或者可以对相关的数据集有另外一个视图：从其中一些公司的总的融资的数据，你可以看到2012年的确是时代开始了。
尽管这里有一些产品是在Redshift发布之前创立，Redshift的发布才使得这些产品起飞。与Redshift一起使用这些产品可以使得用户大幅度的提高他们的生产力。在Postgres上使用Looker感觉不错，但是在Redshift上使用Looker的感觉则是美妙。
这种天地之别是由于像Redshift这种MPP(大规模并行计算)/OLAP系统的内部架构和类似于Postgres这种OLTP系统的显著的区别带来的。对这些内部架构的完整的讨论不是本篇文章的重点，但是如果你不熟悉相关的概念，我强烈建议你去学习一下相关的知识，因为它几乎塑造了今天现代数据技术栈的一切。
简而言之，Redshift能够在巨大的数据集上响应分析查询，处理很多个数据表关联，比OLTP数据库要快10-1000倍。
虽然Redshift是一个能力非常强大的MPP数据库，但它并不是第一个MPP数据库。MPP数据库在前十年就已经普及，而且很多产品都具备非常出色的性能。但是Redshift是一个云原生的MPP数据库，是第一个你可以按照160$一个月进行采买而不是一年花超过10万美金。随着价格的下降，使用MPP数据库这个闸门突然打开了。当时Redshift是AWS有史以来增长最快的服务。
10-1000倍的性能提高往往会改变你对产品构建的看法。在Redshift发布之前，BI面临的最难的问题是速度：即使在一个中等规模的数据集上做相对简单分析都可能会非常对耗费时间，并且构建了一整套生态系统来缓解这个问题。
数据在被装入到数据仓库之前首先要进行转换，因为数据仓库太慢和受限而不能处理这些繁重的数据处理工作。
BI工具进行了大量的本地数据处理以解决数据仓库的瓶颈从而能够给最终用户一个可以接受的响应时间。
数据处理工作由中央的团队来严格控制从而避免数据仓库处理太多来自于最终用户的请求而不堪重负。
一夜之间，所有这些问题突然都消失了。Redshift速度很快，而且对于所有人都很便宜。这意味着围绕解决这些性能问题而构建的BI和ETL产品都立刻成为了遗留软件，构建适合新的世界的产品的新的供应商也应运而生。企业家看到了机会并且蜂拥而至，这些产品在很大程度上定义了我们今天生活的世界。
在结束这个部分之前，我只想说我对于Redshift历史的陈述不应该视为关于谁是当今最好的数据仓库的立场。BigQuery直到2016年才发布标准SQL的支持，因此在这之前并没有被广泛采用。Snowflake的产品直到2017-2018年才真正的成熟。事实上，如果你查看2016年这三种产品之间的使用细分，你会发现Redshift的使用是其他两个合起来的10倍。因此对于我们这些在现代数据堆栈中构建产品的人来讲，Redshift是我们进化的海洋。
02
部署期，从2016-2020
如果说Redshift的推出使得在2012-2016有了非常多的创新，那么为什么进展开始变得缓慢。这是当2018年我第一次发自内心的感受到变化率的下降开始就一直在思考的事情。我意识到从我们创立Fishtown Analytics开始起，我们推荐给我们的咨询客户的产品技术栈一直保持不变，这件事情深深的困着我。我们是否错过了一些开创性的新产品？我们变得陈腐了吗？
事实证明，这是行业要经历的一个正常的周期。一个主要的使能技术一旦发布，它激发了该领域的一系列创新，然后这些产品会经历一个部署阶段使得公司去采用它们。你可以在有史以来的重大技术变革中看到这个现象。事实上，我仅仅搜索了"铁路轨道的累计里程数"，获取了一些数据，瞧，这是一个S曲线。
每个技术都会经历它自己的S曲线，从开发到部署，然后每一轮的技术开始进入成熟，从而能够吸引到更多的新客户，然后变得技术上更加的成熟。
Carlotta Perez在她的founditional 2010 paper中非常有效的对这个过程进行了描述，随着世界上技术变革的涟漪一次一次的在重复的发生，只是大小不同。
我们从2005年(Vertica发布）到2012年(Redshift发布）是MPP数据库的早期开发阶段--S曲线的开始。从那时开始，它经历了数据仓库->BI->数据注入->数据转换。需要注意的是，我们仍旧在部署曲线的早期阶段！
当我作为一个用户来去检查这个理论时，就能检查出来这个结论。我可以根据我的第一手的资料告诉你，在过去的四年中，使用我前面列到的所有产品的体验都有了显著的改善。的确是，Fivetran和Stitch仍旧在把数据从一个点搬到另外一个点，但是他们的可靠性却取得了显著的改善，包括他们的连接器的覆盖。这个理论同样适用于数据栈的其他层上的产品。dbt-我非常了解的它的发展路径，从2016年开始已经做了彻底的重构使得它更加的模块化，有更好的性能，并且具备更好的可扩充性--所有这一切并没有从根本上改变用户体验。
这就是向上遍历S曲线的一个过程，早期采用者是宽容的，但是技术需要改进才能被越来越多的受众所采纳。电报也经历了同样的过程：托马斯.爱迪生在1874年发明了一种电报多路复用器，从而使得西联可以将其先有的线路的吞吐量提高四倍。相同的电报，更高的吞吐量。
透过这个知识框架来看，事情会让人非常对激动。我们正在见证这些基础的技术的成熟：扩充他们的使用到更多的用例场景，变得更加可靠。这些正是是的现代技术栈进入下一波创新浪潮所必须要做的事情。这些创新浪潮就是被现在这些基础的技术解锁的。
03
寒武纪第二阶段，2021-2025
让我们快速的做个总结，在2012年Redshift发布之后，我们立刻看到了大量的创新，释放了全新水平的性能、效率以及新的使用行为。然后我们看到了一个成熟期，这些新生的产品被部署到市场，改进他们的技术，并且完善了他们的功能集。到现在为止，这些新产品已经准备好可以充当建立新的后续创新的基石。
所以：我们准备迎接新的一波创新，一个新的寒武纪大爆炸。这将带来哪些类型的创新？
我不是一个先知，但是我的确花了很多时间来思考这个问题，并且与在这个领域构建和投资产品的有趣的人士进行了非常多的沟通。我认为我们能够从当今世界的状况中获取有用的线索：包含好的和不足。好的这一面代表我们擅长的地方，我们去构建新的创新的基础，不足的这一面则代表着将来创新的机会。
我相信我们可以看到酝酿这些变化的种子已经在发芽和萌发，让我们接下来去看一下。
数据治理
数据治理是一个时机成熟的产品领域。这个产品领域包括非常广泛的用户用例，包括数据集的发现，查看数据的血缘关系和谱系，以及为数据优先的公司内地广泛的数据使用者提供数据导航和数据痕迹。到了几天，现代数据栈使得这个问题变得更为痛苦，因为数据注入、建模和对更多的数据进行分析变得越来越容易。
没有很好的治理，更多的数据==更多的混乱==更少的信任。
尽管在这个领域已经有商用产品已经有一段时间了(Collibra和Alation经常会被提到），他们通常专注于企业买家，因此并没有被现在技术栈的广泛的用户所采纳。因此，大多数公司今天并没有一个数据治理产品。
关于这个主题我已经写了很多相关的文章，因为它与我们在dbt所做的工作非常接近。dbt实际上是采用自己搭建的轻量的文档治理界面-dbt Docs-我们预计未来会做大量的工作来拓展这个现有的功能。
我们对这个领域的兴趣很大程度上是受到了在Big Tech内部所做的工作所启发。很多大型的技术公司已经在自己公司内部构建了非常不错的内部数据治理产品：
Linkedin有DataHub
Lyft有Amundsen
Wework有Marquez
Airbnb有Dataportal
Spotify有Lexikon
Netflix有Metacat
Uber有Databook
我相信我肯定会遗漏一些产品，因此如果你在一个项目中使用我没有提到的产品，请允许我表示抱歉。
其中有不少在Big Tech公司中参与这些项目的人已经离开了他们服务的公司开始去商业化他们的工资，风险投资也对这个趋势充满了热情，这种组合是创新的秘诀。
实时
如果你仅仅是构建回答分析问题等仪表盘，你可能并不会关心你的数据的实时性的需求。实际上，每天一次去获取新的数据可能已经足够能够回答诸如收入、分群行为以及活跃用户趋势等等。但是事实上，作为现代数据技术战队一部分，我们正在构建的数据基础设施的许多的潜在的用例远远超过了通常认为的"数据分析"，如下就是一些例子：
产品内分析
你可能需在你自己的产品内构建仪表盘从而给你的用户构建有用的报告。
运营智能
你可能有负责你的业务的核心运营的员工，他们想知道当前业务的运行的状况，库存和物流情况是在这个领域里最常见的需求。
流程自动化
你已经为分析构建了复杂的数据处理流程，但是如果你能够构建一个管道能够把数据输送给CRM或者消息平台并且能够触发下游的事件会发生什么呢？这会是一个巨大的机会，我会在接下来的一节详细讨论。
的确，对于今天的现代数据技术栈的主要用例来讲，实时数据当然不是必须的，但是将整个数据处理流的延迟降低15-60秒可以为这个技术解锁全新的用例。最终，为您的运营报告提供支持的神经系统应该与为其他用例提供支持的神经系统是相同的。
并且我们已经有信号能够感受到这个领域的技术已经触手可及。每个主要的数据仓库开始实现支持构造更多的实时数据流：Snowflake非常强大依赖它的流式功能，而Bigquery和Redshift都强调他们的物化视图。这两种方法都在朝着正确的方向前进，但是以我来看，这两种方法都无法让我们走到终点。所有三个供应商在这方面的创新仍然在继续。
这里另外有趣的话题是KSQL, 一个在Kafka之上构建的流式SQL。它的确非常对有趣并且有前景，但是围绕着SQL还是存在一些限制(尤其是在表关联上)，因此对于我来讲，它还是一个“还欠点火候”的东西。
对于新的产品领域，我对一个叫做Materialize的产品感到非常对兴奋。它是一个Postgres兼容的数据存储，能够原生的支持近实时的物化视图，是一个从头就是基于流式处理进行构建的产品。
最后，尽管数据库自身支持实时处理，数据注入也需要实时。这也就是为什么我对一个叫做Meroxa的产品非常兴奋-从关系数据库存储和webhooks的CDC的即插即用的支持。这种类型的产品是我们进入流式世界的关键，没有人想要站起来去管理Debezium。
我们还没真正达到目标，但是我们已经能够看到胜利的曙光。这些将在未来的几年一起到来，并且会非常的棒。
完成反馈闭环
今天，数据从运营系统流入到现代数据技术栈，并在这里进行分析。从这里开始，如果数据要推动任何行动，则需要人主动获取并采取行动。如果现代数据技术栈不仅仅支持数据分析，并且能够把数据灌入到运营系统中会怎么样？
这里有大量的潜在用例，我将会列出一些基本的：
客户支持员工将所有的时间都花在使用公司的帮助台(help desk)上。将关键用户行为数据从数据仓库直接灌入到帮助台产品中，可以使客服代表去用来更好的帮助他们的客户。
同样，销售专家花费所有他们的时间在他们的CRM系统中。把产品用户行为数据直接输入到他们的CRM界面将使得他们可以跟客户有上下文更丰富的对话。
与其处理无数的事件跟踪，不如将你的核心产品的点击流直接输入到你的消息产品去触发自动的消息流。
还有很多我没有提到的-我相信这里列出来的显而易见的用例仅仅是冰水的一角。这一趋势实际上将要解锁的是数据/业务分析师去编排整个业务的能力。虽然实时让这个趋势的一切变得非常对强大，但是端到端有几个小时的延迟对于很多用例已经足够有用了。
从2014年以来，我一直在编写一些脚本去促进这些类型的数据的移动，但是我们终于可以看到在这个领域的一些工具开始得到关注。Census和Tray是我最熟悉的，但是我相信这里还其他我不知道的。
如果你今天正在编写dbt代码，请假设在不久的将来，这些代码不仅仅会用于内部分析，还会去支持生产业务系统。这将使得你的工作更加富有挑战和令人兴奋。
民主化数据探索
这是一个可能引起争议的观点。我认为决策者-你知道，实际上通过数据负责制定运营决策的人-并没有被现代数据技术栈很好的服务。高管？他们当然得到了让人吃惊的仪表盘。分析师？绝对的。但是很多人(估计有数亿人）的主要专业工具是Excel，我相信随着现代数据栈的出现，他们的数据体验实际上在变得更糟。突然间，他们被数据排除在外。
我知道这听起来很奇怪，但是在某一个时刻，Excel就是生产力。在网络驱动器上，你可以从一个工作簿引用另外一个工作簿，并且能够最终创建强大的数据系统。当然，这一切都非常对脆弱，不安全并且容易出错，所以请相信我并不是要重新创造他。但是我真正的相信有大量的数据消费者在那个环境中比今天得到了更多的支持。
当然，今天不使用SQL的数据消费者有很多的选择。所有的主流的BI工具都有一些不用SQL就能辅助数据探索的操作界面。但是绝对没有一个(包括LookML，遗憾的是)甚至能够远远的接近Excel的广泛采用水平或者纯粹的创作的灵活性。作为一个对这个范式粘性的证明，你会经常看到数据消费者从他们的BI工具中把数据导出到Excel工作簿，然后继续在那里使用他。
这个挑战是不平凡的，如果没有一个强大的，灵活的工具能让数据消费者自服务，现代数据技术栈将永远只为少数人服务，这是一个非常糟糕的结果。
这是另外一个有争议的声明：如果电子表格就是实际正确的答案怎么办？他是一个易于理解的，强大的，用于数据探索的灵活的用户界面。问题是电子表格UI还没有被引入到现代数据栈，它会是什么样子？
我已经看到了两个比较有前景的候选想法。第一个，把数据倒入到电子表格。几乎每个BI产品都有可以做到这一点："另存为Excel"。但是这不是一个很好的解决方案-它会立即将你的电子表格与其他的数据基础设施切断。就像我以前提到的，相互关联的电子表格以及实时更新始终是以前基于Excel的一个关键的方面。
一个比较好的版本看起来更像"与Google Sheets"同步的过程，其中电子表格保持与数据源的链接，并且数据会定期更新。然后用户可以在数据源上构建新的选项卡。我见过的在这种实现方式上的最佳的实现是一个叫SeekWell的产品，看起来非常对有前途。
第二个候选的想法是使用表格来构建公式，然后变异为可以在数据库上执行的SQL。从本质上，你的电子表格界面是与数据仓库进行查询到UI，但是是一个为更广泛的数据消费者理解的一个。Sigma Computing点产品是这种方法都最佳例子。不过它并没有实现完整的电子表格，因为你不得不受限于每列一个共识的范式，但是我仍然认为这是一个非常有趣的想法。
综上所述，我并不能肯定给数据消费者进行数据探索的正确答案一定是电子表格，我认为这是当前一条比较有前途的路，当然它肯定也有缺点。我非常有信心的是，数据消费者自助服务进行数据探索在未来的几年会被解决。我们将围绕着这个想法进行大量的实验和迭代，因为痛点太明显，商业机会太大。
这里没有需要解决的技术障碍，所有的构建模块都已经就位，最困难的是弄清楚用户体验。
垂直分析体验
2012年的web分析世界存在一个巨大而且明显的问题，Google Analytics, Mixpanel以及KissMetrics是这个世界的仅有的玩家，他们是数据孤岛。你能够访问他们的数据的唯一的方式是通过他们的GUI，并且你不能将其与其他地方的数据结合起来。如果你想要关联从其他系统来的数据，你不得不采用事件方式去推送数据，这将引起数据的重复。
这个时代导致了大量的不同的垂直化数据存储，它们拥有自己的数据副本，并被锁在专有的接口内。但是正是这种丰富数据源推动了数据仓库的需求。但是！我们得到了数据仓库却丢失了很多垂直分析体验。
垂直化的数据分析经验具有非常巨大的价值。与仅仅按照行和列进行数据查看分析的工具相比，将数据视为一系列网络事件的分析工具将能够给你提供更加智能的选择。与现代数据技术栈中的BI工具相比，Google Analytics是一个更为强大的分析Web流量的工具，这不足为奇。
那么，将所有的数据视为行和列的工具和专门用于某种特定数据类型的分析工具哪种更好？答案是：我们两者都需要。但是我们缺少的是在现代数据技术栈上构建的垂直的分析界面。我们需要的是一个像Google Analytics这样的产品，它不是插入Google的专有后端，而是插入到你的数据仓库中。你告诉他去哪里寻找你的事件表并调出关键字段-user id, timestamp, session id等等-然后它允许你通过将所有的交互编译为SQL来探索它。
在2012年，这并不是构建分析产品的现实的方式，但是今天，有了快速的数据仓库，标准的数据注入工具，以及内置包管理的开源的建模工具，你可以比较现实的想象去告诉你的用户“指给我你的网络分析数据”而且他们可以真正的做到这点。突然之间，你不是在孤岛工作，也不是在次优的探索体验中受罪，你获得了两全其美的好处。
我的信念是随着使用现代数据技术栈的公司的增加，构建像这种新的、轻量级的、垂直的应用的机会将会大大的增加。你已经可以在Looker的应用市场中看到这个方向。但是我相信这个机会比在Looker那里大的多。我的猜测是公司将围绕着现代数据技术栈用这种方式构建一系列单个产品，就像之前的Google Analytics一样。
04
有用的叙述？
上面的叙述是我在这个话题上整整两年的思考的产物。我当然不相信我所做的任何一个预测都一定会成真，但是我确信我的总体的叙述在方向上是正确和有价值的。
随着行业历经开发和部署的浪潮-影响在这个行业中的每个从业者的浪潮-将这张地图保存在你的脑袋中是一个很好的定位方式。对于每个人或者公司来说，快速变化的事情都充满了各种可能性，我认为我们正在看到另外一个开始。
