企业重金打造的数据平台为何效果平平？

商业社会的发展使其越来越像一个复杂且精密的机器，我们已经很难通过主观猜测就可以窥视其内部细节、运转逻辑和未来走势了。这个社会中所有的商业竞争越来像一场数学游戏，而在这个时代数据化运营或许是企业发展壮大唯一可选择的道路。

较大规模的企业一般会选择自建数据平台，但从现状来看也并不是非常理想，很多互联网大厂不惜血本、投入重金打造数据化体系，成效却不显著，虽然看似功能强大，但流于表面，关键时候并不抗打。我们总能看到一些大厂朋友吐槽公司的数据基建平台接入成本太高，使用不太方便，有很多数据需求阻塞而难以快速实现，依然普遍存在一再被拖延的情况，究其原因在于企业对于数据需求的并行承载能力太差。而从企业层面来看研发数据基建的资源投入可谓非常巨大，而且后期维护成本也极为可观，如此庞大的投入，收益却并不显著，或者说与预期存在明显的差距，这甚至在一定程度上动摇了大厂对于基建价值的认同感和产生对数据化运营理念的怀疑态度。

问题究竟出在了哪里？ 作为一名业内技术人员，我们有必要思考一下这个问题。盲目的神话一个东西和盲目的贬低都是在走极端。当然企业的数据基建范围太大，我们今天只从其中的一小块 “数据化运营” 入手。为了表述简单起见，本文以下的数据平台都是指数据化运营相关的平台，希望不要引起歧义。

我认为企业的数据平台没有达到预期效果，根源在于以下几点：

1、没有抱着打造产品的目的，而是拿着做业务系统那套逻辑去做数据平台；

首先，我们想一个问题，大厂该如何衡量自己重金打造的数据平台究竟处于什么水平？

我看不少企业技术团队的宣传文章，总喜欢用有多大的数据量、有多少的任务接入，有多少的访问量和接口调用量，可以支撑百亿级千亿级多维查询等等这些因素来衡量数据平台的成功与否。 这种评判标准其实并不客观，更准确来说这更像是一种宣传的噱头，我认为有一个比较公正的办法可以衡量企业的数据平台究竟处于什么水平，我们可以假想一下：

• 所做的数据平台能否拆分成一个或多个产品；
• 能不能拿到市场上去销售，能不能让客户轻易的部署使用，能卖多少钱；

满足内部需要就是在满足某种市场需要，我认为优秀的数据平台能够经受的住市场的检验。这就像汽车一样，一辆汽车是一个产品，而汽车的每个零部件几乎都能是一个独立产品，都有它独立的市场价值。

虽然企业绝大多数的内部系统并不需要用这么严苛的标准来判定，但我觉得数据类系统有它的独特性。如果贵公司的数据平台，可以轻易拆分成多个产品，并能够灵活组织在一起，可以轻松部署到客户的服务器上，并可以让用户为此买单，即可以满足中小企业的需要，也可以满足大型集团公司的需要，那我由衷的钦佩此类技术人员的专业造诣。而反之，很多企业投入数年，耗费巨大资源所开发各种数据平台，或许在市场上一文不值。

有些朋友可能会反驳我，认为这种评判标准太高了，毕竟大多数企业打造基建，从一开始就没有想过要拿出去卖钱，而且不同公司的业务逻辑和数据集群的规模又可能截然不同，那凭什么要用这种标准来衡量其价值呢？

对此我的观点是：数据类平台的研发和业务类系统的研发有着本质的不同， 业务类系统更侧重于稳定性，系统运行满足高峰期的需要，并留有足够buffer即可，系统之间通过接口互通，就算后期重构影响范围也相对有限。 但数据类系统几乎从上线之日起就处于一个不断膨胀的状态，随着使用方的接入，前期设计缺陷会逐渐暴漏出来，而此类系统又会涉及大量的业务方和线上正在运行的任务以及各种已存储在内的庞大量级的业务数据，再加上庞大的集群规模使得后续的维护成本其实是远远高于业务系统的，数据平台对于弹性设计的要求也远高于业务系统。所以，数据平台的架构师如果一开始没有抱着打造可销售产品为目的去做设计，没有坚持较为严苛的标准，后期会很容易触达瓶颈，出现公司耗费庞大人力、物力维系的数据平台，投入和收益不成正比、尾大不掉的尴尬局面。 满足内部需要，就是在满足某种市场需求。

以销售为目的做架构设计，是一件极其困难的事情。因为以前只要考虑系统能跑起来且稳定就可以了，但现在你要考虑的多得多。需要深入思考各子系统之间的功能边界如何划分；需要考虑底层架构的设计将影响着页面的交互逻辑，页面的交互逻辑也会影响底层架构的设计；需要考虑服务器运算资源的成本，需要考虑接入成本，因为使用成本的增加，就意味着产品性价比的下降；需要考虑各种扩展性、规范性、考虑每个功能点的交互逻辑是否顺畅... 以销售为目的做架构设计，会发现所追逐的目标不是能实现，而是更好的实现，不是能用，而是好用，才会永恒的追求部署简单、运维成本低廉和使用方便，才能很谨慎的思考哪些功能点是否应该添加，哪些鸡肋的功能点是否应该裁剪掉，而不再追逐功能的花哨。 一款优秀的B端产品始终追求的应该是核心价值的最大化而不是一堆琐碎功能的堆砌。

2、技术路线选择错误；

企业数据化运营目前发展的困境，我认为阻塞点并不在于能否支撑相关的数据需求，而在于能否快速支撑相关数据需求。对于数据需求的快速支撑能力是衡量企业数据化运营基建水平的重要标准。 我查阅一些互联网大厂相关技术方案，无一例外清一色的使用各种以流式计算框架、离线计算框架、OLAP类引擎为主体的数仓设计方案来支撑数据化运营。我认为这是一种笨拙低效的解决方案，以流式计算、离线计算、OLAP框架为主体的实现方案笨拙的像头狗熊一样，注定只是企业数据化运营技术演进历程中一个微不足道的过渡阶段。

重申一下：我这里只是谈数据化运营领域，并不是否定数仓方案，数仓方案在很多其他应用领域是非常有价值的，只是认为以这类数仓方案为主来支撑数据化运营是不可取的。

企业对数据的追求是无止境的，而目前业内的相关产品都太过于臃肿和笨拙，这些产品是没有可能支撑企业数据化运营再上升两三个数量级的。 我认为未来企业数据化运营的技术方案应以通用型流式数据统计为主，以其他技术方案为辅，更准确点来说是能用通用型流式统计技术实现的需求，就用通用型流式统计实现，而通用型流式统计实现不了的需求，再用其他技术方案实现。

通用型流式数据统计的价值并不是帮你完成所有的数据需求，而是高效的、低成本的帮你完成相当大一部分数据需求，对于不同业务或处于不同的数据化运营阶段的企业来说这个比例并不相同，但我认为数据指标需求越多，通用型流式数据统计服务所能发挥的价值比例也就越大。

虽然通用型流式数据统计并不完美，有很多数据需求并不适合使用流式统计来实现，但我依然认为它是唯一一种有可能支撑百万量级数据指标，并且成本仍可控制在企业可承受范围之内的技术，相比其他技术的实施成本都太过于高昂。

我认为通用型流式数据统计是企业数据化运营发展到一定阶段后的唯一选择，我希望开源项目XL-LightHouse可以帮助企业实现上百万的数据指标，但依然如小鸟般轻灵。建议云服务厂商全面拥抱通用型流式数据统计，我相信在不远的将来，流式统计技术将会被极大范围的应用和推广，凭借通用型流式数据统计，未来云服务厂商的一个计算集群就可以支撑上千万数据指标的并行计算，满足众多企业和用户的同时使用。

3、缺乏一种高效的大批量数据指标管理机制

我所说的数据指标管理并不是单纯的Web端的页面功能，而是一种相关统计数据的存储和查询机制。这个问题往往被人忽视，很多朋友认为这不就把统计结果存到数据库中，然后用户在页面查询时把数据取出来再显示成图表不就行了。 其实这个问题要比想象中复杂，我认为对于庞大数量级的数据指标管理，数据平台和使用方之间必须遵循一个“约定”，否则很容易触达瓶颈。

我们可以看一下业内目前的实现方案，我觉得这些数据平台更多像是一个“壳”，不管是OLAP还是流式计算、离线计算框架的解决方案，往往是提交任务（SQL或者程序）到运算引擎，底层运算引擎计算完毕后将结果返回给数据平台，数据平台再返回给用户，在这个过程中数据平台更像是数据的透传方，有些OLAP的计算方式都不会存储统计结果。这种方案的问题在于数据平台本身对计算逻辑几乎是完全不可掌控的，对于数据平台来说这将限制了它的承载能力，有以下方面的影响：

• 对于计算任务没有办法进行细粒度的控制，只能从资源占用这种很粗粒度层面上来管理计算任务。
• 不太容易提供便捷的可视化展示和接口查询等功能，比如数据平台不知道计算任务的统计周期，就不能直接展示出可视化图表；数据平台不知道计算任务的统计维度，就不能灵活的展示筛选条件。而如果用户需要可视化展示和维度筛选，一般以业内产品的做法是需要用户再进行额外的配置，这增加了系统使用的复杂度，增加了数据指标接入成本。 所以，我认为大批量数据指标的管理维护，数据平台方和使用方之间必须遵循一个“约定”，否则很容易达到瓶颈。

我向大家推荐XL-Formula，XL-Formula是一种通用型流式数据统计配置标准，它也是一种更为高效便捷的数据指标管理方式，即便您的数据指标不是基于流式统计得来也可以使用XL-Formula来管理。使用XL-Formula的好处：

• 数据平台对于统计指标的计算逻辑是完全清晰的，可以进行细粒度的管理和控制。
• 很方便的进行统计结果的可视化展示、接口查询、维度筛选等操作。
• 平台所有统计指标的数据均按照相同的规范进行存储，统计结果具有很好的可迁移性，可以很方便的完成统计数据的导入、导出、备份、迁移等操作。

以上是我认为制约目前企业数据平台对于数据需求快速支撑能力的几点原因。通用型流式数据统计凭借其广阔的应用场景、低廉的使用成本和彪悍的运算性能足以弥补它一切的缺点，这一技术将深远改变企业数据化运营的理念和方式，使得企业数据化运营水平迈入一个全新的阶段。

本文可以随意转载。