将此作为对其他情况相似的人的帮助。 我们已经进行了各种测试，并可以得出以下结论

-更好地查询性能，在我们的案例中，我们试图从HANA视图中读取177列，这降低了性能。 如果我在同一视图中查询60列，则其性能会好得多

-将列拆分成较小的块然后合并是另一种选择，但这仍然会影响性能

-将数据包大小从默认值更改可能会显着提高性能，但这再次适用于精益查询，而不适用于宽列集。 我们尝试使用PACKETSIZE = 2; 在连接字符串中，效果很好

Lars Breddemann - 很抱歉在这里为您加标签，但是我看到您已经对与HANA Client/ODBC性能相关的一些查询做出了响应，在这里的任何帮助将不胜感激

谢谢

Abhishek Shanbhogue

您是否进行了其他任何调查，将总时间分解成几个部分，例如 在HANA中选择数据，传输数据量，将其保存到int数据湖中？ 数据卷在Azure中保留后的大小是多少？ 您是否尝试过并行化数据移动以创建多个流来读取HANA中的数据分区？

感谢 Witalij Rudnicki ，请查看我的回复

我们正在从HANA计算视图（6个投影结合在一起）读取175列具有300万条记录的数据

Q1：您是否进行了其他任何调查，将总时间分解成几个部分，例如 在HANA中选择数据，传输数据量，将其保存到int数据湖中？

是的，这些运行时用于将数据从HANA CV加载到Azure Data Lake，我们尝试使用默认参数，耗时约1小时，而在更改SSIS参数（引擎线程，批处理大小，缓冲区大小..）后，它没有 运行时间明显减少

Q2：数据卷在Azure中保留后的大小是多少？

我们正在从HANA简历中读取175列，具有300万条记录

问题3：您是否尝试过并行化数据移动以创建多个流来读取HANA中的数据分区？

已尝试通过更改SSIS包和Azure Data Factory V2在Azure端进行参数更改以实现并行化，但这没有帮助。 我可以尝试创建一个具有分区的临时表，并从CV加载数据以检查情况是否有所改善，但这将意味着在将数据从HANA运送到Azure之前需要执行额外的步骤！

谢谢

Abhishek尚博格