写在前面正在数字化转型或者规划数字化转型的企业，肯定也逃不出数据平台这样的项目或者话题，再往下探究就是数据数据湖（Data Lake）以及数据仓库（Data Warehouse），对于一家企业到底应该怎样规划，什么才是大数据处理的未来，是值得我们静下心来思考的。
数据处理方式与架构的选择对于一家初创公司来说，想要做数字化转型，想要构建自己的数据仓库，可能一个MySQL8构建的数据仓库就能满足大部分的需求了。但是切记不要犯手里拿着锤子，满眼看到的都是钉子的错误，任何一种数据处理的架构都不能解决所有的问题，随着公司的发展，新技术的涌现，每种技术架构都有它的生命周期，我们要尊重它。 如何选择：选择能够最大限度满足主要矛盾（主要需求）的技术栈。 我们这里说的大数据，可以理解是以Parquet或者ORC等开源存储格式，存储在HDFS，阿里的OSS、AWS的S3等存储介质中的数据。如果你看一下数据仓库应用的用户案例，大多都是数据分析驱动的，数据基本都是我们熟知的数据表（Table），依靠特定的数据流、ETL、构建数据模型来满足查询的需求。而对于数据湖，可能有所不同，它们会包含很多非结构化的数据，更多是关注于机器学习等AI处理以及计算密集型的事务。 随着物联网的兴起，对于各种非结构化数据处理的需求，例如视频数据，音频数据，图片，以及半结构化数据，例如JSON数据，更多的时候以数据湖的视角去规划公司的数据产品更为合理，而不仅仅局限于数据仓库。 对于结构化数据和半结构化数据，永远有一个话题是逃不过的，就是统一SQL层（Union SQL），对于一般的数据分析需求来说，统一的SQL查询基本上已经覆盖了所有的需求。对于诸如图片、文档、视频等数据，越来越多的机器学习算法将应用于解析这些数据，最终输出诸如JSON这样的半结构化数据用于我们构建复杂数据应用以及做数据预测分析。所以，你将面对还是统一SQL能够处理的数据。 通过统一SQL方式的离线数据处理场景 对于非结构化数据处理的通用方法 即使是非结构化的数据，我们也是通过处理将其转化为结构化的数据来使用的，所以，统一SQL的方式仍然适用。 纵观整个科技的发展，都有一个封装复杂的趋势，工具越来越能降低技术的使用难度，以及普惠大众。在大数据处理领域的统一SQL就是这么一个趋势，曾几何时，我们的大数据开发工程师还在用着MapReduce来做大数据ETL，用代码写着复杂的函数。如今，SQL的广泛普及并占据了数据处理。 所以对于现代企业来说，以统一SQL处理为数据处理手段，多种存储介质支持统一查询为基础，以API形式对外提供服务的数据湖架构，是我们需要考虑的技术路线，并且随着公司业务的发展，不断演变。 如何对待数据延迟一定铭记于心：不是所有的数据应用的构建都需要低延迟，低延迟总会和高成本挂钩。 我们要的延迟有多低能够满足当前数据应用的需求，是我们需要考虑的事情，不能将一味地寻求低延迟以及炫耀技术作为目标，要结合实际，从实际业务需求出发才是我们应该做的。比如，各个公司都会有在一段时间内的实时数据处理的需求，要求最低延迟，618以及双11就是这样的场景；而对于某些场景，比如统计用户激活，老用户留存，T+1的数据处理完全够用。 真实的情况，数据工程师们往往面对着几十上百个甚至成百上千个业务系统，并且随着业务的增长，会越来越多。这些系统往往都是公司数据的来源，不断向数据仓库或者数据湖补充新的数据并沉淀下来。面对这种场景，应该有怎样的数据处理延迟呢？显然，粗暴地划分固定延迟并不合适。 一定要结合用户的场景，特别是作为公司的大数据架构的决策者，一定要在延迟和数据应用的吞吐量上做权衡。如果你要更高的吐出量，选择批处理并通过离线MPP的方式实现。 纵观大多数的系统和应用，不仅仅是数据应用，你都可以做出这样的权衡。你可以在数据湖的架构中实践低延迟，也可以在数据仓库的架构中实践高吞吐量，反之亦然。数据湖和数据仓库只存在概念上的分别，架构上并没有太多局限，一切要以实际的项目出发。再往下推演，就是要以公司成本的角度考虑，这个项目需要多低的延迟以及多高的吞吐量能够在可承受的成本下满足用户需求，说到底也就是，你的用户肯为它花多少钱。 总结- 在明晰数据湖和数据仓库的前提下，规划你公司的数据产品。在数据维度以及品类丰富的今天，数据湖的架构可能更为合适；
- 一切数据最终都会转化为结构化数据，所以统一SQL层将是大数据处理发展的必然；
- 在低延迟和高吞吐量上的权衡，一定要立足于项目的实际，你的用户愿意为它花多少钱。
推荐阅读： 更多数字化原创好文，请关注微信公众号汇智研习院 | 
发表于 2022-9-2 19:03:11
站点公告
公司地址
官方微信
在线客服
