传统数据分析流程

一次完整的数据分析，大体上依次经过数据接入、数据准备、数据展示三个环节，这三个环节在传统的流程里分别由开发工程师、分析师和业务人员三类角色承担。当新的数据分析需求产生时，几乎都是从最前端的业务侧发起，给到数据开发工程师，经过层层的需求沟通，最终进入开发、测试、上线环节。这个流程下来，平均一个数据报表的开发周期至少需要一周到三个月的时间。

首当其冲的是算力。在 ELT 模式中，大量计算是实时产生的，对计算的性能的要求很高。20年前的软硬件环境，大部分数据分析使用的还是面向业务处理的单机版 OLTP 数据库，查询1G的数据就可能需要1min 的时间；2010年之后，以 Hadoop 为代表的大数据发展，让我们有能力处理TB甚至PB级别的数据；近年来以 Clickhouse、Doris 为代表的高性能分析型数据库技术出现，以及如 SSD 硬盘等硬件升级，使得在亿级数据上的秒级查询变成可能。正是这些底层算力的提升，为从 ETL 向 ELT 的模式转变提供了基础。

第二个限制是专业门槛。数仓建模一直都是专业性很强的工作。在传统流程中，数据准备都是开发工程师用 SQL 建模的方式完成，这也导致绝大部分业务运营人员无法涉足这一环节。随着各个 BI 工具厂商纷纷推出了可视化拖拽的建模工具，大大降低了数据准备的门槛，也让业务人员能像传统开发工程师一样进行完成数据准备。

虽然我们通过分析范式从 ETL 向 ELT 的转变，逐步实现了分析平民化。但同时也带来了新的挑战和问题。

首先，硬件算力的发展永远跟不上软件对性能的需求。更多的复杂计算逻辑和高级分析功能被应用，如诊断分析、预测性分析等，同时人们永远希望用最省的资源提供足够的分析能力。

其次，在新的模式下，为了满足分析的灵活性，人们进行更多的实时建模，更多的底层数据被直接查询。在 ETL 时代底层的明细数据被逐层聚合构建聚合表，大量计算在分析前被提前完成。而在 ELT 模式下，即使有可用的聚合表，业务人员也会倾向于直接使用 DWD 层明细表，因为这样他们能触达更多的分析维度，进行更灵活的数据探索。

最后是建模专业性上的差异。之前我们有一个专业的数仓团队帮大家背负各种性能问题，他们知道何时做索引、分区，何时该落地预计算。而现在，虽然可视化工具让业务人员能自由建模，但在模型优化和性能瓶颈等方面，他们常常无力又无心（性能优化上的很多必要措施往往是业务逻辑上的冗余步骤，业务人员缺少相关优化意识）

赋能数据科学家：HENGSHI SENSE 数据科学模块支持 Python,为数据科学家提供更好的语言来应对复杂的机器学习和高级分析需求。

更强大的数据源适配能力：HENGSHI SENSE 提供更强大的数据源适配能力帮助客户接入更多的数据。如支持原生 MangoDB，避免用户再从 MangoDB 往传统关系型数据库搬运数据，提升接入数据的效率；在 API 上对接了旺店通、石墨文档和企业微信，后续这些接口来源的数据可以便捷地接入 HENGSHI SENSE 与其他数据做关联分析。