用错误的方式做数据仓库

如果数据管道和数据流是未来的趋势，为什么我们仍然认为数据是静态的？

撰稿人，InfoWorld

robynmac / Getty Images

一段时间以来，人们明显感觉到，作为一个行业，我们一直试图将方形的数据仓库工具塞进圆形的数据驱动的应用孔中。但直到我读到Decodeable首席执行官Eric Sammer的优秀文章《我们正在滥用数据仓库》。RETL、ELT和其他奇怪的东西"，我才明白为什么，以及我们在这个过程中造成了什么损害。正如Sammer所写的，"把高价的分析性数据库系统放在热的路径上，对可支持性和操作性引入了反模式的裤子"。

如果你想知道，"穿裤子的反模式 "并不是一种恭维。它是一种痛苦的呼喊："谁来阻止这种疯狂的行为！"

[也在InfoWorld上：如何选择云数据仓库] 。

复杂的数据问题

问问企业对他们的数据仓库有什么感觉，有很高的比例（在这项调查中为83%）表示不满意。他们在加载数据时很费劲。他们有非结构化的数据，但数据仓库不能处理它，等等。然而，这些并不一定是数据仓库的问题。我敢打赌，通常情况下，不满是由于试图强迫数据仓库（或分析性数据库，如果你愿意的话）做一些它不适合做的事情而引起的。

根据Sammer的说法，这里是错误开始的一种方式。

现在，每个人都已经看到了rETL（反向ETL）的趋势。你想用1号应用（例如Salesforce）的数据来丰富2号应用（例如Marketo）的数据。因为大多数商店已经用Fivetran这样的ELT工具将数据从应用#1发送到数据仓库，许多人采取了他们认为的捷径，在数据仓库中进行转换，然后用rETL工具将数据从仓库中移出，进入应用#2。

高价的数据仓库和数据湖、ELT和rETL公司很乐意帮助用户部署这种看起来很实用的方法，将应用程序结合在一起，即使成本和复杂性很高。

他们为什么不呢？"Sammer说："云数据仓库可能是目前最昂贵的CPU周期。数据仓库的拓扑结构最终会使数据成倍增加（造成治理问题，以及其他问题），但它确实有方便的优势。数据仓库的方便之处在于它们被充分理解。很多人都接受过使用它们的培训，而且它们已经在使用了。

正确的问题，错误的解决方案

Sammer提出了一个令人信服的观点，即它们是建立数据驱动的应用程序的完全错误的、最昂贵的方式。为什么呢？因为 "在两个一级应用之间放一个数据仓库是一个[坏]主意"。公司往往不把他们的分析系统 "当作第一层的关键业务组件"。因此，"公司不复制分析工具和数据，以实现跨可用区的高可用性；他们（通常）不携带传呼机；他们不复制流程。"其结果是 "巨大的成本和风险"。或者，正如他所总结的，"我们不小心把我们的客户体验设计成依赖缓慢的批量ELT流程"。

那么，有什么选择呢？

对于Sammer来说，这一切都与流数据有关，而不是ELT（或reETL）。它是关于基于Kappa架构的实时数据管道。Kappa架构意味着你有一个 "仅适用于不可变的日志。毕马威的大数据工程专家Milinda Pathirage解释说："从日志中，数据通过计算系统进行流转，并被送入辅助存储中进行服务。或者正如Confluent首席执行官Jay Kreps在2014年写的那样，当时他在LinkedIn担任工程负责人，反对的正是Sammers所否定的那种 "管道连接 "的Lambda架构方法，"为什么不能改进流处理系统，以处理其目标领域的全部问题集？"

也就是说，让流成为数据世界的中心。

萨默斯建议，这样做的好处有几个。"它的成本要低得多，可以提供1级质量的SLA，而不需要重复数据的成本，允许零星故障而不是全部故障，并使你的数据仓库脱离关键路径。简单地说，Kappa意味着在数据发生时从1号应用中提取数据，将其以小块的形式发送到数据网关，必要时进行转换/丰富，然后并行交付给所有需要它的地方。"

即使你不认为数据流取代了数据库（我个人不这么认为），也很容易接受这样的观点，即数据管道/数据流比试图在分析数据库之间来回推送数据更有前途。尽管Kappa和类似的方法提供了实时数据，但这并不是真正的问题。根据Sammer的说法，它是关于结束 "rETL正在积累的大量技术债务。这是关于解开对分析工具的关键依赖的巢穴，并使支持可持续"。

下一次，当你正在建立一个有排行榜的应用程序，或者需要从数据中获得信息时（这在应用程序中的比例不断增加），问问自己为什么你的默认数据假设是停滞的：数据坐在存储中，然后你必须从应用程序到应用程序，从系统到系统地推进。我们不再生活在那个面向批处理的世界里了。Sammers似乎是正确的：流应该是默认的，而不是例外。