现代职场所比拼的除了聪明才智、过往经验之外，很多软性技能也尤为重要。
现在已经不是像网络游戏开局拿着一根小木棍打天下的时代了，这将是一场武装到牙齿的较量，对于各类"装备"的驾驭能力有时候甚至可以决定胜负。
ChatGPT是提升职场人工作效率的绝佳装备，相关的介绍已经很多，今天我向大家推荐另外一款很实用的工具：XL-LightHouse。
XL-LightHouse是一款通用型流式数据统计系统，可能有些朋友会觉得这个领域距离自己的工作太遥远，其实不然，不管你的职业是产品经理、前端、后端、算法、数据分析师、运维、运营、UI...，我都认为通用型流式数据统计与你的工作息息相关，通用型流式数据统计将让你成为一个更加强大的个体。
商业社会的发展使其越来越像一个复杂且精密的机器，我们已经很难通过主观猜测就可以窥探其内部细节、运转逻辑和未来走势了。这个社会中所有的商业竞争越来像一场数学游戏，而在这个时代数据化运营或许是企业发展壮大唯一可选择的道路。
通用型流式大数据统计技术将深刻改变现代企业运营的理念和方式，通用型流式大数据统计是我所认为的唯一一种有可能支撑上百万量级数据指标，而成本仍可以控制在企业可承受范围之内的一项技术。而这项技术将使得各种业务指标的获取成本被大大的降低，这意味着职场人士将可以轻松获得到比以往更为全面、更为细粒度的数据指标。而拥有更敏锐的数据辨识度，驾驭和运用数据能力更强的职场人士将显著的拉开与其他人的差距。
企业是一个个员工的集合，而员工驾驭数据的综合水平反应了企业的数据化运营水平。驾驭数据的能力体现在两个方面：
1、布局数据的能力
布局数据的能力就是将自身工作建立数据指标体系，量化业务目标，将业务目标拆解成一个或多个核心数据指标，并为这些核心数据指标建立关联指标和上下游指标，从而搭建起数据指标体系。
不同职能人员所关注的数据指标可能略有不同：
以一个电商平台来说：
公司的决策层关注的是平台的交易额、交易量、下单用户数；
App上某个功能模块的产品经理可能关注的是所负责模块的pv、uv和转化率；
运营人员关注可能是拉新用户量，站内广告点击量、广告收益率；
一个开发人员可能关心的是接口的调用量、异常量、耗时情况；
一个算法工程师关心的是模型的准确率，上线后的效果收益；
一个运维人员可能关心的是线上服务器的运行状况；
一个UI设计师可能关心的是不同的广告图片的点击转化；
一个数据分析师可能需要依赖各种数据指标来更准确的判断业务的短板、业务的走势、辅助决策层有针对性的制定营销计划；
企业中每个员工都应该有自己所关注的数据指标体系，用来辅助自己的工作，而这些数据指标体系共同组成了企业的数据化运营体系。
2、运用数据的能力
运用数据是一项综合能力，它体现在多个方面：
- 排查问题：数据化运营是让企业业务进入到一种"可控"的状态，帮助决策者在业务运转不正常的时候，能够快速的判断出问题所在。
- 业务洞察：数据化运营是让业务运转的各个环节更加透明，帮助企业更清晰的看到目前的"短板"是在什么地方，辅助产品的优化迭代。
- 明确方向：数据化运营是培养敏锐的嗅觉，让企业可以更加准确的判断出市场的走势、捕捉到其中具有业务价值的信息。
- 科学试错：在试错成本日益高企的今天，数据化运营是帮助企业改变以往靠"拍脑袋"来做决定的方式，打破过往的经验主义，辅助决策者思考，快速验证想法，让企业减少成本更加科学的"试错"。
此外，对于职场人来说，运用数据也是快速验证想法、佐证自己的结论、辅助个人思考、制定相关策略、体现个人价值的有效途径。
虽然以上观点大家可能都会认同，但真在工作中实施的时候发现其实困难重重，远没有想象中美好。不少朋友可能会吐槽公司基建水平之差以及研发资源的严重短缺。很多数据需求一再被拖延，甚至最后不了了之。我也深知行业目前的一些现状，这些情况别说是一些中小企业，即便是在一些互联网大厂，相同或相似的问题其实也是广泛存在，反复的上演，究其原因在于企业对于数据需求的并行承载能力太差。
造成企业对于数据需求的并行承载能力太差的原因对于中小企业和规模较大的企业来说是不同的，我们分开来看：
中小企业一般没有充足的资金用于数据基建平台的开发，他们往往选择投入少量研发人员单独开发这些数据需求或者购买一些第三方产品来实现，而大多第三方产品并非提供自助化的数据获取方式，功能相对有限或者承载的数据量、并发量有限再或者是使用门槛太高、接入成本太高等等原因，所以中小企业对数据需求并行承载能力有限是容易理解的。
而较大规模的企业一般会选择自建数据平台，但从现状来看也并不是非常理想，很多互联网大厂不惜血本、投入重金打造数据化体系，成效却不显著，虽然看似功能强大，但流于表面，关键时候并不抗打。我们总能看到一些大厂朋友吐槽公司的数据基建平台接入成本太高，使用不太方便，有很多数据需求阻塞而难以快速实现，依然普遍存在一再被拖延的情况。而从企业层面来看研发数据基建的资源投入可谓非常巨大，而且后期维护成本也极为可观，如此庞大的投入，收益却并不显著，或者说与预期存在明显的差距，这甚至在一定程度上动摇了大厂对于基建价值的认同感和产生对数据化运营理念的怀疑态度。
问题究竟出在了哪里？
作为一名业内技术人员，我们有必要思考一下这个问题。盲目的神话一个东西和盲目的贬低都是在走极端。当然企业的数据基建范围太大，我们今天只从其中的一小块"数据化运营"入手。为了表述简单起见，本文以下的数据平台都是指数据化运营相关的平台，希望不要引起歧义。
我认为互联网大厂的数据平台没有达到预期效果，根源在于以下几点：
1、没有抱着打造产品的目的，而是拿着做业务系统那套逻辑去做数据平台；
首先，我们想一个问题，大厂该如何衡量自己重金打造的数据平台究竟处于什么水平？
我看不少企业技术团队的宣传文章，总喜欢用有多大的数据量、有多少的任务接入，有多少的访问量和接口调用量，可以支撑百亿级千亿级多维查询等等这些因素来衡量数据平台的成功与否。
这种评判标准其实并不客观，更准确来说这更像是一种宣传的噱头，我认为有一个比较公正的办法可以衡量企业的数据平台究竟处于什么水平，我们可以假想一下：
（1）、所做的数据平台能否拆分成一个或多个产品；
（2）、能不能拿到市场上去销售，能不能让客户轻易的部署使用，能卖多少钱；
满足内部需要就是在满足某种市场需要，我认为优秀的数据平台能够经受的住市场的检验。这就像汽车一样，一辆汽车是一个产品，而汽车的每个零部件几乎都能是一个独立产品，都有它独立的市场价值。
虽然企业绝大多数的内部系统并不需要用这么严苛的标准来判定，但我觉得数据类系统有它的独特性。如果贵公司的数据平台，可以轻易拆分成多个产品，并能够灵活组织在一起，可以轻松部署到客户的服务器上，并可以让用户为此买单，即可以满足中小企业的需要，也可以满足大型集团公司的需要，那我由衷的钦佩此类技术人员的专业造诣。而反之，很多企业投入数年，耗费巨大资源所开发各种数据平台，或许在市场上一文不值。
有些朋友可能会反驳我，认为这种评判标准太高了，毕竟大多数企业打造基建，从一开始就没有想过要拿出去卖钱，而且不同公司的业务逻辑和数据集群的规模又可能截然不同，那凭什么要用这种标准来衡量其价值呢？
对此我的观点是：数据类平台的研发和业务类系统的研发有着本质的不同，
业务类系统更侧重于稳定性，系统运行满足高峰期的需要，并留有足够buffer即可，系统之间通过接口互通，就算后期重构影响范围也相对有限。
但数据类系统几乎从上线之日起就处于一个不断膨胀的状态，随着使用方的接入，前期设计缺陷会逐渐暴漏出来，而此类系统又会涉及大量的业务方和线上正在运行的任务以及各种已存储在内的庞大量级的业务数据，再加上庞大的集群规模使得后续的维护成本其实是远远高于业务系统的，数据平台对于弹性设计的要求也远高于业务系统。所以，数据平台的架构师如果一开始没有抱着打造可销售产品为目的去做设计，没有坚持较为严苛的标准，后期会很容易触达瓶颈，出现公司耗费庞大人力、物力维系的数据平台，投入和收益不成正比、尾大不掉的尴尬局面。
满足内部需要，就是在满足某种市场需求。以销售为目的做架构设计，是一件极其困难的事情。因为以前只要考虑系统能跑起来且稳定就可以了，但现在你要考虑的多得多。需要深入思考各子系统之间的功能边界如何划分；需要考虑底层架构的设计将影响着页面的交互逻辑，页面的交互逻辑也会影响底层架构的设计；需要考虑服务器运算资源的成本，需要考虑接入成本，因为使用成本的增加，就意味着产品性价比的下降；需要考虑各种扩展性、规范性、考虑每个功能点的交互逻辑是否顺畅...
以销售为目的做架构设计，会发现所追逐的目标不是能实现，而是更好的实现，不是能用，而是好用，才会永恒的追求部署简单、运维成本低廉和使用方便，才能很谨慎的思考哪些功能点是否应该添加，哪些鸡肋的功能点是否应该裁剪掉，而不再追逐功能的花哨。
2、技术路线选择错误；
企业数据化运营目前发展的困境，我认为阻塞点并不在于能否支撑相关的数据需求，而在于能否快速支撑相关数据需求。对于数据需求的快速支撑能力是衡量企业数据化运营基建水平的重要标准。
我查阅一些互联网大厂相关技术方案，无一例外清一色的使用各种以流式计算框架、离线计算框架、OLAP类引擎为主体的数仓设计方案来支撑数据化运营。我认为这是一种笨拙低效的解决方案，以流式计算、离线计算、OLAP框架为主体的实现方案笨拙的像头狗熊一样，注定只是企业数据化运营技术演进历程中一个微不足道的过渡阶段。
重申一下：我这里只是谈数据化运营领域，并不是否定数仓方案，数仓方案在很多其他应用领域是非常有价值的，只是认为以这类数仓方案为主来支撑数据化运营是不可取的。
企业对数据的追求是无止境的，而目前业内的相关产品都太过于臃肿和笨拙，这些产品是没有可能支撑企业数据化运营再上升两三个数量级的。
我认为未来企业数据化运营的技术方案应以通用型流式数据统计为主，以其他技术方案为辅，更准确点来说是能用通用型流式统计技术实现的需求，就用通用型流式统计实现，而通用型流式统计实现不了的需求，再用其他技术方案实现。
通用型流式数据统计的价值并不是帮你完成所有的数据需求，而是高效的、低成本的帮你完成相当大一部分数据需求，对于不同业务或处于不同的数据化运营阶段的企业来说这个比例并不相同，但我认为数据指标需求越多，通用型流式数据统计服务所能发挥的价值比例也就越大。
虽然通用型流式数据统计并不完美，有很多数据需求并不适合使用流式统计来实现，但我依然认为它是唯一一种有可能支撑百万量级数据指标，并且成本仍可控制在企业可承受范围之内的技术，相比其他技术的实施成本都太过于高昂。
我认为通用型流式数据统计是企业数据化运营发展到一定阶段后的唯一选择，我希望XL-LightHouse可以帮助企业实现上百万的数据指标，但依然如小鸟般轻灵。建议云服务厂商全面拥抱通用型流式数据统计，我个人也期望与云服务厂商达成合作，共同推进通用型流式统计底层运算引擎的研发事项。我相信在不远的将来，流式统计技术将会被极大范围的应用和推广，凭借通用型流式数据统计，未来云服务厂商的一个计算集群就可以支撑上千万数据指标的并行计算，满足众多企业和用户的同时使用。
3、缺乏一种高效的大批量数据指标管理机制
我所说的数据指标管理并不是单纯的Web端的页面功能，而是一种相关统计数据的存储和查询机制。这个问题往往被人忽视，很多朋友认为这不就把统计结果存到数据库中，然后用户在页面查询时把数据取出来再显示成图表不就行了。
其实这个问题要比想象中复杂，我认为对于庞大数量级的数据指标管理，数据平台和使用方之间必须遵循一个"约定"，否则很容易触达瓶颈。
我们可以看一下业内目前的实现方案，我觉得这些数据平台更多像是一个"壳"，不管是OLAP还是流式计算、离线计算框架的解决方案，往往是提交任务（SQL或者程序）到运算引擎，底层运算引擎计算完毕后将结果返回给数据平台，数据平台再返回给用户，在这个过程中数据平台更像是数据的透传方，有些OLAP的计算方式都不会存储统计结果。这种方案的问题在于数据平台本身对计算逻辑几乎是完全不可掌控的，对于数据平台来说这将限制了它的承载能力，有以下方面的影响：
（1）、对于计算任务没有办法进行细粒度的控制，只能从资源占用这种很粗粒度层面上来管理计算任务。
（2）、不太容易提供便捷的可视化展示和接口查询等功能，比如数据平台不知道计算任务的统计周期，就不能直接展示出可视化图表；数据平台不知道计算任务的统计维度，就不能灵活的展示筛选条件。而如果用户需要可视化展示和维度筛选，一般以业内产品的做法是需要用户再进行额外的配置，这增加了系统使用的复杂度，增加了数据指标接入成本。
所以，我认为大批量数据指标的管理维护，数据平台方和使用方之间必须遵循一个"约定"，否则很容易达到瓶颈。
我向大家推荐XL-Formula，XL-Formula是一种通用型流式数据统计配置标准，它也是一种更为高效便捷的数据指标管理方式，即便您的数据指标不是基于流式统计得来也可以使用XL-Formula来管理。使用XL-Formula的好处：
（1）、数据平台对于统计指标的计算逻辑是完全清晰的，可以进行细粒度的管理和控制。
（2）、很方便的进行统计结果的可视化展示、接口查询、维度筛选等操作。
（3）、平台所有统计指标的数据均按照相同的规范进行存储，统计结果具有很好的可迁移性，可以很方便的完成统计数据的导入、导出、备份、迁移等操作。
关于XL-LightHouse的使用和XL-Formula可以访问dtstep.com了解更多信息。
以上是我认为制约目前企业数据平台对于数据需求快速支撑能力的几点原因。通用型流式数据统计凭借其广阔的应用场景、低廉的使用成本和彪悍的运算性能足以弥补它一切的缺点，这一技术将深远改变企业数据化运营的理念和方式，使得企业数据化运营水平迈入一个全新的阶段。XL-LightHouse以通用型流式大数据统计为切入点，寄希望于通过更加贴合场景、更具有实用价值的技术方案帮助企业降低数据化运营方面的成本。对于职场人来说，我相信灵活的使用XL-LightHouse可以帮助您解决很多棘手的问题，希望XL-Lighthouse成为您职业生涯常伴左右的工具。
本文可以随意转载。